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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5550

LEMONADE                                                D. Cridland, Ed.
Internet-Draft                                          A. Melnikov, Ed.
Intended status: Standards Track                           Isode Limited
Expires: October 5, 2007                                    S. Maes, Ed.
                                                                  Oracle
                                                           April 3, 2007


                          The Lemonade Profile
                 draft-ietf-lemonade-profile-bis-05.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on October 5, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes a profile (a set of required extensions,
   restrictions and usage modes) of the IMAP and mail submission
   protocols.  This profile allows clients (especially those that are
   constrained in memory, bandwidth, processing power, or other areas)
   to efficiently use IMAP and Submission to access and submit mail.
   This includes the ability to forward received mail without needing to



Cridland, et al.         Expires October 5, 2007                [Page 1]

Internet-Draft              Lemonade Profile                  April 2007


   download and upload the mail, to optimize submission and to
   efficiently resynchronize in case of loss of connectivity with the
   server.

   The Lemonade profile relies upon several extensions to IMAP and Mail
   Submission protocols.


Table of Contents

   1.  Conventions used in this document  . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Summary of the required support  . . . . . . . . . . . . . . .  5
     3.1.  Lemonade Submission Servers  . . . . . . . . . . . . . . .  5
     3.2.  Lemonade Message Stores  . . . . . . . . . . . . . . . . .  6
   4.  Lemonade Submission Servers  . . . . . . . . . . . . . . . . .  7
     4.1.  Forward Without Download . . . . . . . . . . . . . . . . .  7
     4.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  DSN Support  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  Message size declaration . . . . . . . . . . . . . . . . .  7
     4.5.  Enhanced status code Support . . . . . . . . . . . . . . .  8
     4.6.  Encryption and Compression . . . . . . . . . . . . . . . .  8
   5.  Lemonade Message Stores  . . . . . . . . . . . . . . . . . . .  9
     5.1.  Quick resynchronization  . . . . . . . . . . . . . . . . .  9
     5.2.  Message part handling  . . . . . . . . . . . . . . . . . .  9
     5.3.  Compression  . . . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  In band notifications  . . . . . . . . . . . . . . . . . . 10
     5.5.  Searching and View Filters . . . . . . . . . . . . . . . . 10
     5.6.  Mailbox Handling . . . . . . . . . . . . . . . . . . . . . 11
     5.7.  Forward Without Download . . . . . . . . . . . . . . . . . 11
     5.8.  Additional IMAP extensions . . . . . . . . . . . . . . . . 11
     5.9.  Registration of $Forwarded IMAP keyword  . . . . . . . . . 11
   6.  Lemonade Mail User Agents  . . . . . . . . . . . . . . . . . . 12
   7.  Forward without download . . . . . . . . . . . . . . . . . . . 12
     7.1.  Motivations  . . . . . . . . . . . . . . . . . . . . . . . 12
     7.2.  Message Sending Overview . . . . . . . . . . . . . . . . . 13
     7.3.  Traditional Strategy . . . . . . . . . . . . . . . . . . . 13
     7.4.  Step by step description . . . . . . . . . . . . . . . . . 14
       7.4.1.  Message assembly using IMAP CATENATE extension . . . . 15
       7.4.2.  Message assembly using SMTP CHUNKING and BURL
               extensions . . . . . . . . . . . . . . . . . . . . . . 19
     7.5.  Security Considerations for pawn-tickets.  . . . . . . . . 23
     7.6.  Copies of Sent messages: The fcc problem . . . . . . . . . 23
   8.  OMA MEM Requirement document . . . . . . . . . . . . . . . . . 24
     8.1.  OMA MEM Architecture . . . . . . . . . . . . . . . . . . . 24
     8.2.  OMA MEM Deployment Issues  . . . . . . . . . . . . . . . . 24
     8.3.  OMA MEM proxy  . . . . . . . . . . . . . . . . . . . . . . 24
     8.4.  IETF Lemonade Architecture . . . . . . . . . . . . . . . . 25



Cridland, et al.         Expires October 5, 2007                [Page 2]

Internet-Draft              Lemonade Profile                  April 2007


     8.5.  Lemonade profile logical architecture  . . . . . . . . . . 26
       8.5.1.  Relationship between the OMA MEM and Lemonade
               logical architectures  . . . . . . . . . . . . . . . . 26
       8.5.2.  Lemonade realization of OMA MEM with non-Lemonade
               compliant servers  . . . . . . . . . . . . . . . . . . 28
     8.6.  Filters and server to client notifications and Lemonade  . 29
   9.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 31
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 31
     10.1. Confidentiality Protection of Submitted Messages . . . . . 31
     10.2. TLS  . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     10.3. Additional extensions and deployment models  . . . . . . . 32
   11. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 32
   12. Version history  . . . . . . . . . . . . . . . . . . . . . . . 32
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 34
     14.2. Informative References . . . . . . . . . . . . . . . . . . 36
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
   Intellectual Property and Copyright Statements . . . . . . . . . . 39
































Cridland, et al.         Expires October 5, 2007                [Page 3]

Internet-Draft              Lemonade Profile                  April 2007


1.  Conventions used in this document

   In examples, "M:", "I:" and "S:" indicate lines sent by the client
   messaging user agent, IMAP e-mail server and SMTP submit server
   respectively.

   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 [KEYWORDS].

   Other capitalised words are typically names of extensions or commands
   - these are uppercased for clarity only, and are case-insensitive.

   All examples in this document are optimized for Lemonade use and
   might not represent examples of proper protocol usage for a general
   use Submit/IMAP client.  In particular examples assume that Submit
   and IMAP servers support all Lemonade extensions described in this
   document, so they do not demonstrate fallbacks in the absence of an
   extension.


2.  Introduction

   The Lemonade Profile, or simply Lemonade, provides enhancements to
   Internet email to support diverse service environments.  Lemonade
   Mail Servers provide both a Lemonade Submission Server and a Lemonade
   Message Store, which are based on the existing [SUBMIT] and [IMAP]
   protocols respectively.

   This document describes the Lemonade profile that includes:
   o  General common enhancements to Internet Mail, described in
      Section 5 and Section 4.
   o  "Forward without download" that describes exchanges between
      Lemonade clients and servers to allow to submit new email messages
      incorporating content which resides on locations external to the
      client, described in Section 7.
   o  Quick mailbox resynchronization, described in Section 5.1.
   o  Extensions to support more precise, and broader, notifications
      from the store in support of notifications and view filters,
      described in Section 5.4 and Section 5.5.

   It is intended that the Lemonade profile support realizations of the
   OMA's mobile email enabler (MEM) (see [MEM-req] and [MEM-arch]) using
   Internet Mail protocols defined by the IETF.







Cridland, et al.         Expires October 5, 2007                [Page 4]

Internet-Draft              Lemonade Profile                  April 2007


3.  Summary of the required support

3.1.  Lemonade Submission Servers

   Lemonade Submission Servers MUST provide a service as described in
   [SUBMIT], and MUST support the following.  Note that the Lemonade
   Profile imposes further requirements for some cases, detailed in the
   sections cited.

        +---------------------+--------------------+--------------+
        |    SMTP extension   |      Reference     | Requirements |
        +---------------------+--------------------+--------------+
        |      PIPELINING     |  [SMTP-PIPELINING] |  Section 4.2 |
        |         DSN         |     [SMTP-DSN]     |  Section 4.3 |
        |         SIZE        |     [SMTP-SIZE]    |  Section 4.4 |
        | ENHANCEDSTATUSCODES | [SMTP-STATUSCODES] |  Section 4.5 |
        |       STARTTLS      |     [SMTP-TLS]     |  Section 4.6 |
        |      BURL imap      |     [SMTP-BURL]    |   Section 7  |
        |      BINARYMIME     |  [SMTP-BINARYMIME] |  Section 4.1 |
        |       CHUNKING      |  [SMTP-BINARYMIME] |  Section 4.1 |
        |       8BITMIME      |   [SMTP-8BITMIME]  |  [SMTP-BURL] |
        |         AUTH        |     [SMTP-AUTH]    |   [SUBMIT]   |
        |      QUICKSTART     |     <No Draft>     |  Section 4.6 |
        +---------------------+--------------------+--------------+



























Cridland, et al.         Expires October 5, 2007                [Page 5]

Internet-Draft              Lemonade Profile                  April 2007


3.2.  Lemonade Message Stores

   Lemonade Message Stores MUST provide a service as described in
   [IMAP], and MUST support the following.  Note that the Lemonade
   Profile imposes further requirements for some cases, detailed in the
   sections cited.

          +------------------+------------------+--------------+
          |  IMAP extension  |     Reference    | Requirements |
          +------------------+------------------+--------------+
          |     NAMESPACE    | [IMAP-NAMESPACE] |  Section 5.6 |
          |     CONDSTORE    | [IMAP-CONDSTORE] |  Section 5.1 |
          |     STARTTLS     |      [IMAP]      |       -      |
          |      URLAUTH     |  [IMAP-URLAUTH]  |  Section 5.7 |
          |     CATENATE     |  [IMAP-CATENATE] |  Section 5.7 |
          |      UIDPLUS     |  [IMAP-UIDPLUS]  |  Section 5.7 |
          |     LITERAL+     |  [IMAP-LITERAL+] |  Section 5.8 |
          |       IDLE       |    [IMAP-IDLE]   |  Section 5.4 |
          |      NOTIFY      |   [IMAP-NOTIFY]  |  Section 5.4 |
          |    $Forwarded    |         -        |  Section 5.9 |
          |      BINARY      |   [IMAP-BINARY]  |  Section 5.2 |
          |      QRESYNC     |  [IMAP-QRESYNC]  |  Section 5.1 |
          |      ESEARCH     |  [IMAP-ESEARCH]  |  Section 5.5 |
          |      WITHIN      |   [IMAP-WITHIN]  |  Section 5.5 |
          |      CONTEXT     |  [IMAP-CONTEXT]  |  Section 5.5 |
          |      CONVERT     |  [IMAP-CONVERT]  |  Section 5.2 |
          | COMPRESS=DEFLATE |  [IMAP-COMPRESS] |  Section 5.3 |
          |     METADATA     |  [IMAP-METADATA] |  Section 5.8 |
          |   LIST-EXTENDED  |  [IMAP-LISTEXT]  |  Section 5.8 |
          +------------------+------------------+--------------+





















Cridland, et al.         Expires October 5, 2007                [Page 6]

Internet-Draft              Lemonade Profile                  April 2007


4.  Lemonade Submission Servers

   All Lemonade Submission Servers implement the Mail Submission
   protocol described in [SUBMIT], which is in turn a specific profile
   of [ESMTP].  Therefore any MUA designed to submit email via [SUBMIT]
   or [ESMTP] will interoperate with Lemonade Submission Servers.

   In addition, Lemonade Submission Servers implement the following set
   of SMTP and Submission extensions to increase message submission
   efficiency.

4.1.  Forward Without Download

   In order to optimize network usage for the typical case where message
   content is copied to, or sourced from, the IMAP store, Lemonade
   provides support for a suite of extensions collectively known as
   Forward Without Download, discussed in detail in Section 7.

   Lemonade Submission Servers MUST support the BURL [SMTP-BURL],
   8BITMIME [SMTP-8BITMIME], BINARYMIME [SMTP-BINARYMIME] and CHUNKING
   [SMTP-BINARYMIME].

   BURL MUST support URLAUTH type URLs [IMAP-URLAUTH], and thus MUST
   advertise the "imap" option following the BURL EHLO keyword (See
   [SMTP-BURL] for more details).

4.2.  Pipelining

   Some clients regularly use networks with a relatively high latency,
   such as Mobile or Satellite based networks.  Avoidance of round-trips
   within a transaction has a great advantage for the reduction in both
   bandwidth and total transaction time.  For this reason Lemonade
   compliant mail submission servers MUST support the SMTP Service
   Extensions for Command Pipelining [SMTP-PIPELINING].

   In addition, Lemonade Submission Servers provide full support for the
   QUICKSTART framework described in <No Draft>.

4.3.  DSN Support

   Lemonade compliant mail submission servers MUST support SMTP service
   extensions for delivery status notifications [SMTP-DSN].

4.4.  Message size declaration

   There is a distinct advantage in detecting failure cases as early as
   possible in many cases, such as where the user is charged per-octet,
   or where bandwidth is low.  This is especially true of large message



Cridland, et al.         Expires October 5, 2007                [Page 7]

Internet-Draft              Lemonade Profile                  April 2007


   sizes.

   Lemonade Submission Servers MUST support the SMTP Service Extension
   for Message Size Declaration [SMTP-SIZE].

   Lemonade Submission Servers MUST NOT consider a supplied message size
   to be acceptable without expanding all BURL parts.

   A Lemonade capable client SHOULD use message size declaration.  In
   particular the client MUST NOT send a message to a mail submission
   server, if it knows that the message exceeds the maximal message size
   advertised by the submission server.  When including a message size
   in the MAIL FROM command, the client MUST use a value that is at
   least as large as the size of the assembled message data after
   resolution of all BURL parts.

4.5.  Enhanced status code Support

   Lemonade compliant mail submission servers MUST support SMTP Service
   Extension for Returning Enhanced Error Codes [SMTP-STATUSCODES].
   These allow a client to determine the precise cause of failure.

4.6.  Encryption and Compression

   Lemonade Compliant mail submission servers MUST support SMTP Service
   Extension for Secure SMTP over TLS [SMTP-TLS].

   Support for the DEFLATE compression method, as described in
   [TLS-COMP], is RECOMMENDED.

   Lemonade Submission Servers MUST support the QUICKSTART extension
   defined in $lt;No Draft>, which provides for considerably fewer
   round-trips at the commencement of a submission.


















Cridland, et al.         Expires October 5, 2007                [Page 8]

Internet-Draft              Lemonade Profile                  April 2007


5.  Lemonade Message Stores

   All Lemonade Message Stores implement Internet Message Access
   Protocol, as defined in [IMAP].  Therefore any MUA written to access
   messages using the facilities described in [IMAP] will interoperate
   with a Lemonade Message Store.

   In addition, Lemonade Message Stores provide a set of extensions to
   address the limitations of some clients and networks.

5.1.  Quick resynchronization

   Resynchronization is a costly part of an IMAP session, and mobile
   networks are generally more prone to unintended disconnection, which
   in turns makes this problem more acute.  Therefore Lemonade Message
   Stores provide a suite of extensions to reduce the synchronization
   cost.

   Lemonade Compliant IMAP servers MUST support the CONDSTORE
   [IMAP-CONDSTORE] and the QRESYNC [IMAP-QRESYNC] extensions.  These
   allow a client to quickly resynchronize any mailbox by asking the
   server to return all flag changes and expunges that have occurred
   since a previously recorded state.  This can also speed up client
   reconnect in case the transport layer is cut, whether accidentally or
   as part of a change in network.

   [IMAP-SYNC-HOWTO] details how clients perform efficient mailbox
   resynchronization.

5.2.  Message part handling

   The handling of message parts, especially attachments, represents a
   set of challenges to limited devices, both in terms of the bandwidth
   used, and the capability of the device.

   Lemonade Compliant IMAP servers MUST support the BINARY [IMAP-BINARY]
   extension.  This moves MIME body part decoding operations from the
   client to the server.  The decoded data is always equal or less than
   the encoded representation, so this reduces bandwidth effectively.

   [IMAP-BINARY] allows for servers to refuse to accept uploaded
   messages containing binary data, by not accepting the Binary content-
   transfer-encoding; however Lemonade Compliant IMAP servers SHALL
   always accept binary encoded MIME messages in APPEND commands for any
   folder.

   [IMAP-CONVERT] MUST also be supported by servers, which allows
   clients to request conversions between media types, and allows for



Cridland, et al.         Expires October 5, 2007                [Page 9]

Internet-Draft              Lemonade Profile                  April 2007


   scaling images, etc.  This provides the ability to view attachments
   (and sometimes body parts) without the facility to cope with a wide
   range of media types, or to efficiently view attachments.

5.3.  Compression

   The IETF has for some time generally agreed that compression is best
   handled at as low a level as possible, therefore Lemonade Message
   Stores SHOULD support the Deflate compression algorithm for TLS, as
   defined in [TLS-COMP].

   However, the working group acknowledges that for many endpoints, this
   is a rarely deployed technology, and as such, Lemonade Message Stores
   MUST provide [IMAP-COMPRESS] support for fallback application-level
   stream compression, where TLS is not actively providing compression.

5.4.  In band notifications

   Lemonade Message Stores MUST support the IDLE [IMAP-IDLE] extension.
   The extension allows clients to receive unsolicited notifications
   about changes in the selected mailbox, without needing to poll for
   changes.  The responses forming these notifications MUST be sent in a
   timely manner when such changes happen.

   Lemonade Message Stores also provide the NOTIFY extension described
   in [IMAP-NOTIFY], which allows clients to request specific event
   types to be sent immediately to the client, both for the currently
   selected folder and others.  Such event types include message
   delivery, and mailbox renames.

5.5.  Searching and View Filters

   Lemonade Message Stores MUST support the ESEARCH [IMAP-ESEARCH]
   extension.  The extension allows clients to efficiently find the
   first or last messages, find a count of matching messages, and obtain
   a list of matching messages in a considerably more compact
   representation.

   Lemonade Message Stores MUST support the WITHIN [IMAP-WITHIN]
   extension.  The extension allows clients to easily find all messages
   that were delivered within a specific time period.

   Lemonade Message Stores also provide a mechanism for clients to avoid
   handling an entire mailbox, instead accessing a view of the mailbox.
   This technique, common in many desktop clients as a client-side
   capability, is useful for constrained clients to minimize the
   quantity of messages and notification data.




Cridland, et al.         Expires October 5, 2007               [Page 10]

Internet-Draft              Lemonade Profile                  April 2007


   Lemonade Message Stores therefore MUST implement the CONTEXT
   extension defined in [IMAP-CONTEXT].

5.6.  Mailbox Handling

   Lemonade Message Stores MUST support the NAMESPACE [IMAP-NAMESPACE]
   extension.  The extension allows clients to discover shared mailboxes
   and mailboxes belonging to other users, and provide a normalized
   heirarchy view of the mailboxes available.

   Lemonade Message Stores MUST support the METADATA [IMAP-METADATA]
   extension.  This allows metadata to be stored against mailboxes,
   which is a facility used by other extensions mandated by this
   profile.

   Lemonade Message Stores MUST support the LIST-EXTENDED [IMAP-LISTEXT]
   extension.  This is required for the METADATA [IMAP-METADATA]
   extension.  It defines an extensible LIST command.

5.7.  Forward Without Download

   In order to optimize network usage for the typical case where message
   content is copied to, or sourced from, the IMAP store, Lemonade
   provides support for a suite of extensions collectively known as
   Forward Without Download, discussed in detail in Section 7.

   Lemonade Message Stores MUST support CATENATE [IMAP-CATENATE],
   UIDPLUS [IMAP-UIDPLUS] and URLAUTH [IMAP-URLAUTH].

5.8.  Additional IMAP extensions

   Lemonade Message Stores MUST support the LITERAL+ [IMAP-LITERAL+]
   extension.  The extension allows clients to save a round trip each
   time a non-synchronizing literal is sent.

   Lemonade Compliant IMAP servers MUST support IMAP over TLS [IMAP] as
   required by [IMAP].  As noted above in Section 5.3, servers SHOULD
   support the deflate compression algorithm for TLS, as specified in
   [TLS-COMP]

5.9.  Registration of $Forwarded IMAP keyword

   The $Forwarded IMAP keyword is used by several IMAP clients to
   specify that the marked message was forwarded to another email
   address, embedded within or attached to a new message.  A mail client
   sets this keyword when it successfully forwards the message to
   another email address.  Typical usage of this keyword is to show a
   different (or additional) icon for a message that has been forwarded.



Cridland, et al.         Expires October 5, 2007               [Page 11]

Internet-Draft              Lemonade Profile                  April 2007


   Once set the flag SHOULD NOT be cleared.

   Lemonade Message Stores MUST be able to store the $Forwarded keyword.
   They MUST preserve it on the COPY operation.  The servers MUST
   support the SEARCH KEYWORD $Forwarded.


6.  Lemonade Mail User Agents

   Although all existing IMAP MUAs are Lemonade compliant in as much as
   all Lemonade services are based on the existing [IMAP] and [SUBMIT]
   protocols, client implementors are encouraged to take full advantage
   of the facilities provided by Lemonade Submission Servers and
   Lemonade Message Stores, as described in Section 4 and Section 5
   respectively.

   Note that the explicit usage of [SUBMIT] means that when opening a
   connection to the submission server, clients MUST do so using port
   587 unless explicitly configured to use an alternate port.  If the
   TCP connection to the submission server fails to open using port 587,
   the client MAY then immediately retry using a different port, such as
   25.  See [SUBMIT] information on why using port 25 is likely to fail
   depending on the current location of the client, and may result in a
   failure code during the SMTP transaction.

   In addition, some specifications are useful to support interoperable
   messaging with an enhanced user experience.

   Lemonade capable clients SHOULD support the Format and DelSp
   parameters to the text/plain media type described in [FLOWED], and
   generate this format for messages.

   Lemonade capable clients SHOULD support, and use, the $Forwarded
   keyword described in Section 5.9.


7.  Forward without download

7.1.  Motivations

   The advent of client/server email using the [IMAP] and [SUBMIT]
   protocols changed what formerly were local disk operations to become
   repetitive network data transmissions.

   Lemonade "forward without download" makes use of the [SMTP-BURL]
   extension to enable access to external sources during the submission
   of a message.  In combination with the [IMAP-URLAUTH] extension,
   inclusion of message parts or even entire messages from the IMAP mail



Cridland, et al.         Expires October 5, 2007               [Page 12]

Internet-Draft              Lemonade Profile                  April 2007


   store is possible with a minimal trust relationship between the IMAP
   and SMTP SUBMIT servers.

   Lemonade "forward without download" has the advantage of maintaining
   one submission protocol, and thus avoids the risk of having multiple
   parallel and possibly divergent mechanisms for submission.  The
   client can use [SUBMIT] extensions without these being added to IMAP.
   Furthermore, by keeping the details of message submission in the SMTP
   SUBMIT server, Lemonade "forward without download" can work with
   other message retrieval protocols such as POP, NNTP, or whatever else
   may be designed in the future.

7.2.  Message Sending Overview

   The act of sending an email message can be thought of as involving
   multiple steps: initiation of a new draft, draft editing, message
   assembly, and message submission.

   Initiation of a new draft and draft editing takes place in the MUA.
   Frequently, users choose to save more complex messages on an [IMAP]
   server (via the APPEND command with the \Draft flag) for later recall
   by the MUA and resumption of the editing process.

   Message assembly is the process of producing a complete message from
   the final revision of the draft and external sources.  At assembly
   time, external data is retrieved and inserted in the message.

   Message submission is the process of inserting the assembled message
   into the [ESMTP] infrastructure, typically using the [SUBMIT]
   protocol.

7.3.  Traditional Strategy

   Traditionally, messages are initiated, edited, and assembled entirely
   within an MUA, although drafts may be saved to an [IMAP] server and
   later retrieved from the server.  The completed text is then
   transmitted to an MSA for delivery.

   There is often no clear boundary between the editing and assembly
   process.  If a message is forwarded, its content is often retrieved
   immediately and inserted into the message text.  Similarly, when
   external content is inserted or attached, the content is usually
   retrieved immediately and made part of the draft.

   As a consequence, each save of a draft and subsequent retrieve of the
   draft transmits that entire (possibly large) content, as does message
   submission.




Cridland, et al.         Expires October 5, 2007               [Page 13]

Internet-Draft              Lemonade Profile                  April 2007


   In the past, this was not much of a problem, because drafts, external
   data, and the message submission mechanism were typically located on
   the same system as the MUA.  The most common problem was running out
   of disk quota.

7.4.  Step by step description

   The model distinguishes between a Messaging User Agent (MUA), an
   IMAPv4Rev1 Server ([IMAP]) and a SMTP submit server ([SUBMIT]), as
   illustrated in Figure 1.

         +--------------------+               +--------------+
         |                    | <------------ |              |
         |     MUA (M)        |               | IMAPv4Rev1   |
         |                    |               |  Server      |
         |                    | ------------> | (Server I)   |
         +--------------------+               +--------------+
                ^    |                              ^     |
                |    |                              |     |
                |    |                              |     |
                |    |                              |     |
                |    |                              |     |
                |    |                              |     |
                |    |                              |     v
                |    |                        +--------------+
                |    |----------------------> |   SMTP       |
                |                             |   Submit     |
                |-----------------------------|   Server     |
                                              |  (Server S)  |
                                              +--------------+

   Figure 1: Lemonade "forward without download"

   Lemonade "forward without download" allows a Messaging User Agent to
   compose and forward an e-mail combining fragments that are located in
   an IMAP server, without having to download these fragments to the
   client.

   There are two ways to perform "forward without download" based on
   where the message assembly takes place.  The first uses extended
   APPEND command [IMAP-CATENATE] to edit a draft message in the message
   store and cause the message assembly on the IMAP server.  This is
   most often used when a copy of the message is to be retained on the
   IMAP server, as discussed in Section 7.6.

   The second uses a succession of BURL and BDAT commands to submit and
   assemble through concatenation, message data from the client and
   external data fetched from the provided URL.  The two subsequent



Cridland, et al.         Expires October 5, 2007               [Page 14]

Internet-Draft              Lemonade Profile                  April 2007


   sections provide step-by-step instructions on how "forward without
   download" is achieved.

7.4.1.  Message assembly using IMAP CATENATE extension

   In the [SMTP-BURL]/[IMAP-CATENATE] variant of the Lemonade "forward
   without download" strategy, messages are initially composed and
   edited within an MUA.  The [IMAP-CATENATE] extension to [IMAP] is
   then used to create the messages on the IMAP server by transmitting
   new text and assembling them.  The UIDPLUS [IMAP-UIDPLUS] IMAP
   extension is used by the client in order to learn the UID of the
   created messages.  Finally a [IMAP-URLAUTH] format URL is given to a
   [SUBMIT] server for submission using the BURL [SMTP-BURL] extension.

   The flow involved to support such a use case consists of:

   M: {to I -- Optional} The client connects to the IMAP server,
   optionally starts TLS (if data confidentiality is required),
   authenticates, opens a mailbox ("INBOX" in the example below) and
   fetches body structures (See [IMAP]).

   Example:

            M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
            I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
                ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
                "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
                "trip.txt")
                "<960723163407.20117h@washington.example.com>"
                "Your trip details" "BASE64" 4554 73) "MIXED"))
            I: A0051 OK completed

   M: {to I} The client invokes CATENATE (See [IMAP-CATENATE] for
   details of the semantics and steps) -- this allows the MUA to create
   messages on the IMAP server using new data combined with one or more
   message parts already present on the IMAP server.

   Note that the example for this step doesn't use the LITERAL+
   [IMAP-LITERAL+] extension.  Without LITERAL+ the new message is
   constructed using 3 round-trips.  If LITERAL+ is used, the new
   message can be constructed using one round-trip.










Cridland, et al.         Expires October 5, 2007               [Page 15]

Internet-Draft              Lemonade Profile                  April 2007


         M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent)
             CATENATE (TEXT {475}
         I: + Ready for literal data
         M: Message-ID: <419399E1.6000505@caernarfon.example.org>
         M: Date: Thu, 12 Nov 2004 16:57:05 +0000
         M: From: Bob Ar <bar@example.org>
         M: MIME-Version: 1.0
         M: To: foo@example.net
         M: Subject: About our holiday trip
         M: Content-Type: multipart/mixed;
         M:     boundary="------------030308070208000400050907"
         M:
         M: --------------030308070208000400050907
         M: Content-Type: text/plain; format=flowed
         M:
         M: Our travel agent has sent the updated schedule.
         M:
         M: Cheers,
         M: Bob
         M: --------------030308070208000400050907
         M:  URL "/INBOX;UIDVALIDITY=385759045/;
            UID=25627/;Section=2.MIME" URL "/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44}
         I: + Ready for literal data
         M:
         M: --------------030308070208000400050907--
         M: )
         I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed

   M: {to I} The client uses GENURLAUTH command to request a URLAUTH URL
   (See [IMAP-URLAUTH]).
   I: {to M} The IMAP server returns a URLAUTH URL suitable for later
   retrieval with URLFETCH (See [IMAP-URLAUTH] for details of the
   semantics and steps).

         M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent;
            UIDVALIDITY=387899045/;uid=45;expire=2005-10-
            28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
         I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
            UIDVALIDITY=387899045/;uid=45;expire=
            2005-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:91354a473744909de610943775f92038"
         I: A0054 OK GENURLAUTH completed

   M: {to S} The client connects to the mail submission server and
   starts a new mail transaction.  It uses BURL to let the SMTP submit
   server fetch the content of the message from the IMAP server (See
   [IMAP-URLAUTH] for details of the semantics and steps -- this allows



Cridland, et al.         Expires October 5, 2007               [Page 16]

Internet-Draft              Lemonade Profile                  April 2007


   the MUA to authorize the SMTP submit server to access the message
   composed as a result of the CATENATE step).  Note that the second
   EHLO command is required after a successful STARTTLS command.  Also
   note that there might be a third required EHLO command if the second
   EHLO response doesn't list any BURL options.  Section 7.4.2
   demonstrates this.

         S: 220 owlry.example.org ESMTP
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME
         S: 250-BINARYMIME
         S: 250-PIPELINING
         S: 250-BURL imap
         S: 250-CHUNKING
         S: 250-AUTH PLAIN
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250-STARTTLS
         S: 250 ENHANCEDSTATUSCODES
         M: STARTTLS
         S: 220 Ready to start TLS
         ...TLS negotiation, subsequent data is encrypted...
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME
         S: 250-BINARYMIME
         S: 250-PIPELINING
         S: 250-BURL imap
         S: 250-CHUNKING
         S: 250-AUTH PLAIN
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250 ENHANCEDSTATUSCODES
         M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
         S: 235 2.7.0 PLAIN authentication successful.
         M: MAIL FROM:<bob.ar@example.org>
         S: 250 2.5.0 Address Ok.
         M: RCPT TO:<foo@example.net>
         S: 250 2.1.5 foo@example.net OK.
         M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;
            uid=45/;urlauth=submit+bar:internal:
            91354a473744909de610943775f92038 LAST

   S: {to I} The mail submission server uses URLFETCH to fetch the
   message to be sent (See [IMAP-URLAUTH] for details of the semantics
   and steps.  The so-called "pawn-ticket" authorization mechanism uses
   a URI which contains its own authorization credentials.).



Cridland, et al.         Expires October 5, 2007               [Page 17]

Internet-Draft              Lemonade Profile                  April 2007


   I: {to S} Provides the message composed as a result of the CATENATE
   step).

   Mail submission server opens IMAP connection to the IMAP server:

         I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
             CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
             IMAP server ready
         S: a000 STARTTLS
         I: a000 Start TLS negotiation now
         ...TLS negotiation, if successful - subsequent data
            is encrypted...
         S: a001 LOGIN submitserver secret
         I: a001 OK submitserver logged in
         S: a002 URLFETCH "imap://bob.ar@example.org/Sent;
            UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
            internal:91354a473744909de610943775f92038"
         I: * URLFETCH "imap://bob.ar@example.org/Sent;
            UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
            internal:91354a473744909de610943775f92038" {15065}
         ...message body follows...
         S: a002 OK URLFETCH completed
         I: a003 LOGOUT
         S: * BYE See you later
         S: a003 OK Logout successful

   Note that if the IMAP server doesn't send CAPABILITY response code in
   the greeting, the mail submission server must issue the CAPABILITY
   command to learn about supported IMAP extensions as described in
   [IMAP].

   Also, if data confidentiality is not required the mail submission
   server may omit the STARTTLS command before issuing the LOGIN
   command.

   S: {to M} Submission server assembles the complete message and if the
   assembly succeeds it returns OK to the MUA:

         S: 250 2.5.0 Ok.

   M: {to I} The client marks the message containing the forwarded
   attachment on the IMAP server.

         M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
         I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
         I: A0053 OK STORE completed

   Note: the UID STORE command shown above will only work if the marked



Cridland, et al.         Expires October 5, 2007               [Page 18]

Internet-Draft              Lemonade Profile                  April 2007


   message is in the currently selected mailbox; otherwise, it requires
   a SELECT.  This command can be omitted, as it simply changes non-
   operational metadata not essential to client operations or
   interoperability.  The untagged FETCH response is due to
   [IMAP-CONDSTORE].  The $Forwarded IMAP keyword is described in
   Section 5.9.

7.4.2.  Message assembly using SMTP CHUNKING and BURL extensions

   In the [IMAP-URLAUTH]/[SMTP-BURL] variant of the Lemonade "forward
   without download" strategy, messages are initially composed and
   edited within an MUA.  During submission [SUBMIT], BURL [SMTP-BURL]
   and BDAT [SMTP-BINARYMIME] commands are used to create the messages
   from multiple parts.  New body parts are supplied using BDAT
   commands, while existing body parts are referenced using
   [IMAP-URLAUTH] format URLs in BURL commands.

   The flow involved to support such a use case consists of:
   M: {to I -- Optional} The client connects to the IMAP server,
   optionally starts TLS (if data confidentiality is required),
   authenticates, opens a mailbox ("INBOX" in the example below) and
   fetches body structures (See [IMAP]).

   Example:

            M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
            I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
               ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
               "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
               "trip.txt")
               "<960723163407.20117h@washington.example.com>"
               "Your trip details" "BASE64" 4554 73) "MIXED"))
            I: A0051 OK completed

   M: {to I} The client uses GENURLAUTH command to request URLAUTH URLs
   (See [IMAP-URLAUTH]) referencing pieces of the message to be
   assembled.
   I: {to M} The IMAP server returns URLAUTH URLs suitable for later
   retrieval with URLFETCH (See [IMAP-URLAUTH] for details of the
   semantics and steps).











Cridland, et al.         Expires October 5, 2007               [Page 19]

Internet-Draft              Lemonade Profile                  April 2007


         M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"
            INTERNAL "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
         I: * GENURLAUTH "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:A0DEAD473744909de610943775f9BEEF"
            "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:BEEFA0DEAD473744909de610943775f9"
         I: A0054 OK GENURLAUTH completed

   M: {to S} The client connects to the mail submission server and
   starts a new mail transaction.  It uses BURL to instruct the SMTP
   submit server to fetch from the IMAP server pieces of the message to
   be sent (See [SMTP-BURL] for details of the semantics and steps).

   Note that the second EHLO command is required after a successful
   STARTTLS command.  The third EHLO command is required if and only if
   the second EHLO response doesn't list any BURL options.  See
   Section 7.4.1 for an example of submission where the third EHLO
   command/response is not present.

         S: 220 owlry.example.org ESMTP
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME
         S: 250-BINARYMIME
         S: 250-PIPELINING
         S: 250-BURL
         S: 250-CHUNKING
         S: 250-AUTH DIGEST-MD5
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250-STARTTLS
         S: 250 ENHANCEDSTATUSCODES
         M: STARTTLS
         S: 220 Ready to start TLS
         ...TLS negotiation, subsequent data is encrypted...
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME
         S: 250-BINARYMIME
         S: 250-PIPELINING



Cridland, et al.         Expires October 5, 2007               [Page 20]

Internet-Draft              Lemonade Profile                  April 2007


         S: 250-BURL
         S: 250-CHUNKING
         S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250 ENHANCEDSTATUSCODES
         M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
         S: 235 2.7.0 PLAIN authentication successful.
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME
         S: 250-BINARYMIME
         S: 250-PIPELINING
         S: 250-BURL imap imap://imap.example.org
         S: 250-CHUNKING
         S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250 ENHANCEDSTATUSCODES
         M: MAIL FROM:<bob.ar@example.org> BODY=BINARY
         S: 250 2.5.0 Address Ok.
         M: RCPT TO:<foo@example.net>
         S: 250 2.1.5 foo@example.net OK.
         M: BDAT 475
         M: Message-ID: <419399E1.6000505@caernarfon.example.org>
         M: Date: Thu, 12 Nov 2004 16:57:05 +0000
         M: From: Bob Ar <bar@example.org>
         M: MIME-Version: 1.0
         M: To: foo@example.net
         M: Subject: About our holiday trip
         M: Content-Type: multipart/mixed;
         M:     boundary="------------030308070208000400050907"
         M:
         M: --------------030308070208000400050907
         M: Content-Type: text/plain; format=flowed
         M:
         M: Our travel agent has sent the updated schedule.
         M:
         M: Cheers,
         M: Bob
         M: --------------030308070208000400050907
         S: 250 2.5.0 OK
         M: BURL imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:A0DEAD473744909de610943775f9BEEF
         S: 250 2.5.0 OK
         M: BURL imap://bob.ar@example.org/INBOX;



Cridland, et al.         Expires October 5, 2007               [Page 21]

Internet-Draft              Lemonade Profile                  April 2007


            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:BEEFA0DEAD473744909de610943775f9
         S: 250 2.5.0 OK
         M: BDAT 44 LAST
         M:
         M: --------------030308070208000400050907--

   S: {to I} The mail submission server uses URLFETCH to fetch the
   pieces of the message to be sent (See [SMTP-BURL] for details of the
   semantics and steps.  The so-called "pawn-ticket" authorization
   mechanism uses a URI which contains its own authorization
   credentials.).
   I: {to S} Returns the requested body parts.

   Mail submission server opens IMAP connection to the IMAP server:

         I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
             CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
             IMAP server ready
         S: a001 LOGIN submitserver secret
         I: a001 OK submitserver logged in
         S: a002 URLFETCH "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:A0DEAD473744909de610943775f9BEEF" "imap://
            bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:BEEFA0DEAD473744909de610943775f9"
         I: * URLFETCH "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:A0DEAD473744909de610943775f9BEEF" {84}
         ...message section follows...
             "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:BEEFA0DEAD473744909de610943775f9" {15065}
         ...message section follows...
         S: a002 OK URLFETCH completed
         I: a003 LOGOUT
         S: * BYE See you later
         S: a003 OK Logout successful

   Note that if the IMAP server doesn't send CAPABILITY response code in
   the greeting, the mail submission server must issue the CAPABILITY
   command to learn about supported IMAP extensions as described in



Cridland, et al.         Expires October 5, 2007               [Page 22]

Internet-Draft              Lemonade Profile                  April 2007


   [IMAP].

   Also, if data confidentiality is required the mail submission server
   should start TLS before issuing the LOGIN command.

   S: {to M} Submission server assembles the complete message and if the
   assembly succeeds it acknowledges acceptance of the message by
   sending 250 response to the last BDAT command:

         S: 250 2.5.0 Ok, message accepted.

   M: {to I} The client marks the message containing the forwarded
   attachment on the IMAP server.

         M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
         I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
         I: A0053 OK STORE completed

   Note: the UID STORE command shown above will only work if the marked
   message is in the currently selected mailbox; otherwise, it requires
   a SELECT.  As in the previous example, this command is not critical,
   and can be omitted.  The untagged FETCH response is due to
   [IMAP-CONDSTORE].  The $Forwarded IMAP keyword is described in
   Section 5.9.

7.5.  Security Considerations for pawn-tickets.

   The so-called "pawn-ticket" authorization mechanism uses a URI, which
   contains its own authorization credentials using [IMAP-URLAUTH].  The
   advantage of this mechanism is that the SMTP submit [SUBMIT] server
   cannot access any data on the [IMAP-URLAUTH] server without a "pawn-
   ticket" created by the client.

   The "pawn-ticket" grants access only to the specific data that the
   SMTP submit [SUBMIT] server is authorized to access, can be revoked
   by the client, and can have a time-limited validity.

7.6.  Copies of Sent messages: The fcc problem

   The "fcc problem" refers to delivering a copy of a message to a
   mailbox, or "file carbon copy".  By far, the most common case of fcc
   is a client leaving a copy of outgoing mail in a "Sent Mail" or
   "Outbox" mailbox.

   In the traditional strategy, the MUA duplicates the effort spent in
   transmitting to the MSA by writing the message to the fcc destination
   in a separate step.  This may be a write to a local disk file or an
   APPEND to a mailbox on an IMAP server.  The latter is one of the



Cridland, et al.         Expires October 5, 2007               [Page 23]

Internet-Draft              Lemonade Profile                  April 2007


   "repetitive network data transmissions" which represents the
   "problem" aspect of the "fcc problem".

   The BURL [SMTP-BURL] extension can be used to eliminate the
   additional transmission.  The final message is uploaded to the
   mailbox designed for outgoing mail, by the APPEND command of [IMAP].
   Note that APPEND, including when enhanced by [IMAP-CATENATE], can
   only create a single copy of the message and this is only of use on
   the server which stages the outgoing message for submission.
   Additional copies of the message on the same server can be created by
   using one or more COPY commands.


8.  OMA MEM Requirement document

   The OMA MEM activity has collected a set of use cases and derived
   requirements for a mobile email enabler (MEM).  The resulting work is
   summarized in OMA MEM Requirement document [MEM-req].  Some
   requirements relate to email protocols, some involve other OMA
   technologies outside the scope of IETF and some relate to
   implementations and normative interoperability statements for clients
   and servers.

8.1.  OMA MEM Architecture

   The OMA MEM activity has derived a logical architecture from the
   requirements and use cases described in [MEM-req].  The logical
   architecture, its elements and interfaces and the notations that it
   uses can be found in [MEM-arch].

8.2.  OMA MEM Deployment Issues

   The OMA MEM Architecture document [MEM-arch] further identifies
   deployment models.

   Certain of these deployment models are not what IETF has
   conventionally modeled.  They require special attention to end-to-end
   security aspects and may warrant introduction of additional security
   measures (e.g. object level encryption).

8.3.  OMA MEM proxy

   The OMA MEM Architecture document [MEM-arch] identifies OMA MEM
   server proxies as server components that may be deployed.

   Both IMAP and SMTP generally are compatible with proxies between the
   client and the server.  Such proxies may disrupt end-to-end
   encryption, with the transport-level encryption ending at the proxy



Cridland, et al.         Expires October 5, 2007               [Page 24]

Internet-Draft              Lemonade Profile                  April 2007


   and re-generating from the proxy to the server.  Again this may
   require additional security measures like object level encryption,
   and this mode of operation is not recommended.

8.4.  IETF Lemonade Architecture

   This section gives a brief introduction to the Lemonade Architecture.

   The IETF Lemonade activity has derived a profile with the logical
   architecture represented in Figure 15, where arrows indicate content
   flows.

                            ______________
                           |              |
                  _________| Notification |
                 |         | Mechanism    |
                 |         |______________|
                 |Notif.              ^
                 |Protocol            |
                 |                 ___|______
                 |                |          |                 _____
               __v__    IMAP      | Lemonade |      ESMTP     |     |
              |     |<----------->| IMAP     |<---------------| MTA |
              | MUA |-            | Store    |                |_____|
              |_____| \           |__________|
                       \               |
                        \              |URLAUTH
                         \SUBMIT       |
                          \        ____v_____
                           \      |          |                 _____
                            \     | Lemonade |      ESMTP     |     |
                             ---->| Submit   |--------------->| MTA |
                                  | Server   |                |_____|
                                  |__________|

                 Figure 15: Lemonade logical architecture

   The Lemonade profile assumes: <<Editor's note: remove redundant
   information from the list below.>>
   o  IMAP protocol [IMAP] including Lemonade profile extensions
   o  Submit protocol ([SUBMIT], profile of [ESMTP]) including Lemonade
      profile extensions
   o  Lemonade profile compliant IMAP store connected to MTA (Mail
      Transfer Agent) via ESMTP [ESMTP].
   o  Lemonade profile compliant Submit server connected to MTA via
      ESMTP





Cridland, et al.         Expires October 5, 2007               [Page 25]

Internet-Draft              Lemonade Profile                  April 2007


   o  Lemonade profile message store / Submit server protocols (URLAUTH)
      (see [IMAP-URLAUTH]).
   o  Outband server to client notifications relying on external
      notification mechanisms (and notification protocols) that may be
      out of scope of the Lemonade profile.
   o  A Lemonade aware MUA (Mail User Agent).  While use of outband
      notification is described in the Lemonade profile, support for the
      underlying notifications mechanisms/protocols is out of scope of
      the Lemonade specifications.

   Note that in Figure 15 the IMAP server and Submit server are
   represented connected to MTAs (Mail Transfer Agents) via [ESMTP].
   This is not really essential.  It could as well be X.400 so long as
   the message in the store is in the internet form.

   OMA MEM identifies other functionalities.  These are considered as
   out of scope of the Lemonade work and will need to be specified by
   OMA MEM.

8.5.  Lemonade profile logical architecture

   This section details the Lemonade profile logical architecture.  This
   architecture is also expected to support the OMA MEM logical
   Architecture.

8.5.1.  Relationship between the OMA MEM and Lemonade logical
        architectures

   Figure 16 illustrates the mapping of the IETF Lemonade logical
   architecture on the OMA MEM logical architecture.





















Cridland, et al.         Expires October 5, 2007               [Page 26]

Internet-Draft              Lemonade Profile                  April 2007


                          _____________________
                         | Other_Mob. Enablers |
                         | |--------------|    |
                  _________| Notification |    |
                 |       | | Mechanism    |    |
                 |       | |______________|    |
                 |Notif. |____________^________|
                 |Protocol      ______|__________
            ME-4 |             |   ___|_ME-3_    |
              ___|____         |  |          |   |         _____
             | __v__ |  IMAP   |  | Lemonade |   |  ESMTP |     |
             ||     |<----------->| IMAP     |<-----------| MTA |
             || MUA ||   ME-2a |  | Store    |   |        |_____|
             ||_____||\ME-1    |  |__________|   |
             | MEM   | \       |       |         |
             | Client|  \      |       |URLAUTH  |
             |_______|   \SUBMIT       |         |
                          \    |   ____v_____    |
                           \   |  |          |   |         _____
                            \  |  | Lemonade |   |  ESMTP |     |
                             ---->| Submit   |----------->| MTA |
                         ME-2b |  | Server   |   |        |_____|
                               |  |__________|   |
                               |MEM        Email |
                               |Server     Server|
                               |_________________|
                                        ^
                                        |ME-5
                                        |

   Figure 16: Mapping of Lemonade profile logical architecture     onto
                     the OMA MEM logical architecture.

   As described in Section 8.4, the Lemonade profile assumes Lemonade
   profile compliant IMAP stores and Submit servers.  Because the
   Lemonade profile extends the IMAP store and the submit server, the
   mobile enablement of email provided by the Lemonade profile is
   directly provided in these server.  Mapped to OMA MEM logical
   architecture, for the case considered and specified by the Lemonade
   profile, the MEM server and email server logically combined.  They
   are however split into distinct Lemonade message store and Lemonade
   submit server.  The OMA MEM interfaces ME-2 ([MEM-arch]) consists of
   two interfaces ME-2a and ME-2b associated respectively to IMAP
   extended according to the Lemonade profile and SUBMIT extended
   according to the Lemonade profile.

   The MUA is part of the MEM client.




Cridland, et al.         Expires October 5, 2007               [Page 27]

Internet-Draft              Lemonade Profile                  April 2007


   External notifications mechanism can be part of the other OMA enabler
   specified by OMA (or other activities).

8.5.2.  Lemonade realization of OMA MEM with non-Lemonade compliant
        servers

   The OMA MEM activity is not limited to enabling Lemonade compliant
   servers.  It explicitly identifies the need to support other
   backends.

8.5.2.1.  Lemonade realization of OMA MEM with non-Lemonade enhanced
          IMAP servers

   Figure 17 illustrates the case of IMAP servers that are not (yet)
   Lemonade compliant / enhanced with Lemonade.  In such case, the I2
   interface between the MEM server components and the IMAP store and
   submit server are IMAP and SUBMIT.


                 ______________
                |              |
       _________| Notification |
      |         | Mechanism    |
      |         |______________|
      |Notif.            ^
      |Protocol          |
      |               ___|______          _____________
      |              | Lemonade |        |             |        _____
    __v__    IMAP    | MEM      |  IMAP  |NON-Lemonade | ESMTP |     |
   |     |<--------->|Enabler   |<------>|IMAP         |<----->| MTA |
   | MUA |\   ME-2a  | Server   |        |Store        |       |_____|
   |_____| \         |__________|        |_____________|
            \             |
             \            |URLAUTH
              \SUBMIT     |
               \      ____v_____          _____________
                \    |          |        |             |        _____
                 \   | Lemonade | SUBMIT |NON-Lemonade | ESMTP |     |
                  -->|  MEM     |        |Submit       |       |     |
                     | Enabler  |------->|Server       |------>| MTA |
              ME-2b  | Server   |        |             |       |_____|
                     |__________|        |_____________|


       Figure 17: Architecture to support non-Lemonade enhanced IMAP
          servers with a Lemonade realization of OMA MEM enabler.

   In Figure 17, the server may be a separate proxy.



Cridland, et al.         Expires October 5, 2007               [Page 28]

Internet-Draft              Lemonade Profile                  April 2007


8.5.2.2.  Lemonade realization of OMA MEM with non-IMAP servers

   <<Editor's note: This section and the previous section and figures
   may be combined in a future release of this draft.>

   Figure 18 illustrates the cases where the message store and submit
   servers are not IMAP store or submit servers.  They may be POP3
   servers or other proprietary message stores.

                 ______________
                |              |
       _________| Notification |
      |         | Mechanism    |
      |         |______________|
      |Notif.            ^
      |Protocol          |
      |               ___|______          _____________
      |              | Lemonade |        |             |        _____
    __v__    IMAP    | MEM      |    I2  |Proprietary  | ESMTP |     |
   |     |<--------->|Enabler   |<------>|Message      |<----->| MTA |
   | MUA |\   ME-2a  | Server   |        |Store        |       |_____|
   |_____| \         |__________|        |_____________|
            \             |
             \            |URLAUTH
              \SUBMIT     |
               \      ____v_____          _____________
                \    |          |        |             |        _____
                 \   | Lemonade |    I2  |Proprietary  | ESMTP |     |
                  -->| MEM      |        |Submit       |       |     |
                     | Enabler  |------->|Server       |------>| MTA |
              ME-2b  | Server   |        |             |       |_____|
                     |__________|        |_____________|


    Figure 18: Architecture to support non-IMAP servers with a Lemonade
                      realization of OMA MEM enabler.

   I2 designates proprietary adapters to the backends.  They may
   involved functions performed in the message stores or submit server
   as well as in the MEM enabler server.

   In Figure 18, the server may be a separate proxy.

8.6.  Filters and server to client notifications and Lemonade

   OMA MEM RD [MEM-req] and AD [MEM-arch] emphasize the need to provide
   mechanisms for server to client notifications of email events and
   filtering.  Figure 19 illustrates how notification and filterings are



Cridland, et al.         Expires October 5, 2007               [Page 29]

Internet-Draft              Lemonade Profile                  April 2007


   introduced in Lemonade profile.



                   ______________
                  |              |
         _________| Notification |
        |         | Mechanism    |
        |         |______________|
        |Notif.              ^
        |Protocol -------\  _|_
        |   ______|    ___\>|NF|____
        |  |          |     ----    |                 _____
      __v__|   IMAP   |__  Lemonade |___   ESMTP   __|     |
     |     |<-------->|VF| IMAP     |DF |<--------|AF| MTA |
     | MUA |\   ME-2a |--  Store    |---           --|_____|
     |_____| \        |_____________| ^
            \_\_______________|_______|
               \              |URLAUTH
                \SUBMIT       |
                 \        ____v_____
                  \      |          |                 _____
                   \     | Lemonade |      ESMTP     |     |
                    ---->| Submit   |--------------->| MTA |
                ME-2b    | Server   |                |_____|
                         |__________|


      Figure 19: Filtering mechanism defined in Lemonade architecture

   In Figure 19, four categories of filters are defined:
   o  AF: Administrative Filters - Set up by email service provider.  AF
      are typically not configured by the user and set to apply policies
      content filtering, virus protection, spam filtering etc...
   o  DF: Deposit Filters - Filters that are executed on deposit of new
      email messages.  They can be defined as [SIEVE].  They can include
      vacation notices.
   o  VF: View Filters - Filters that define which emails are visible to
      the MUA.  View filters can be performed via IMAP using the
      facilities described in Section 5.5.
   o  NF: Notification Filters - Filters that define for what email
      server events a notification is sent to the client, as described
      in Section 5.4.

   The filters are manageable from the MUA:
   o  NF and DF: via SIEVE Management protocol [MANAGESIEVE]





Cridland, et al.         Expires October 5, 2007               [Page 30]

Internet-Draft              Lemonade Profile                  April 2007


   o  VF: via extended IMAP SEARCH commands discussed in Section 5.5.


9.  Deployment Considerations

   Deployment considerations are discussed extensively in
   [LEMONADE-DEPLOYMENTS].


10.  Security Considerations

   Implementors are advised to examine the Security Considerations of
   all the referenced documents.  This section merely highlights these,
   and advises implementors on specific issues relating to the
   combination of extensions.

   Security considerations on Lemonade "forward without download" are
   discussed throughout Section 7.  Additional security considerations
   can be found in [IMAP] and other documents describing other SMTP and
   IMAP extensions comprising the Lemonade Profile.

   Note that the mandatory-to-implement authentication mechanism for
   SMTP submission is described in [SMTP-AUTH].  The mandatory-to-
   implement authentication mechanism for IMAP is described in [IMAP].

10.1.  Confidentiality Protection of Submitted Messages

   When clients submit new messages, link protection such as TLS guards
   against an eavesdropper seeing the contents of the submitted message.
   It is worth noting, however, that even if TLS is not used, the
   security risks are no worse if BURL is used to reference the text
   than if the text is submitted directly.  If BURL is not used, an
   eavesdropper gains access to the full text of the message.  If BURL
   is used, the eavesdropper may or may not be able to gain such access,
   depending on the form of BURL used.  For example, some forms restrict
   use of the URL to an entity authorized as a submission server or a
   specific user.

10.2.  TLS

   When Lemonade clients use the BURL extension to mail submission, an
   extension that requires sending a URLAUTH token to the mail
   submission server, such a token should be protected from interception
   to avoid a replay attack that may disclose the contents of the
   message to an attacker.  TLS based encryption of the mail submission
   path will provide protection against this attack.

   Lemonade clients SHOULD use TLS-protected IMAP and mail submission



Cridland, et al.         Expires October 5, 2007               [Page 31]

Internet-Draft              Lemonade Profile                  April 2007


   channels when using BURL-based message submission to protect the
   URLAUTH token from interception.

   Lemonade compliant mail submission servers SHOULD use TLS-protected
   IMAP connections when fetching message content using the URLAUTH
   token provided by the Lemonade client.

   When a client uses SMTP STARTTLS to send a BURL command which
   references non-public information, there is a user expectation that
   the entire message content will be treated confidentially.  To meet
   this expectation, the message submission server should use STARTTLS
   or a mechanism providing equivalent data confidentiality when
   fetching the content referenced by that URL.

10.3.  Additional extensions and deployment models

   This specification provides no additional security measures beyond
   those in the referenced Internet Mail and Lemonade documents.

   We note however the security risks associated to:
   o  Outband notifications
   o  Server configuration by client
   o  Client configuration by server
   o  Presence of proxy servers
   o  Presence of servers as intermediaries
   o  In general the deployment models considered by OMA MEM that are
      not conventional IETF deployment models.
   o  Measures to address a perceived need to traverse firewalls and
      mobile network intermediaries.


11.  IANA considerations

   This document does not require any IANA registration or action that
   are not covered by the different drafts and RFCs included in the
   realization described in this document.


12.  Version history

   o  Version 04:
      *  Major reorganization of text.
      *  Move checklist summary to beginning of document, collate
         Submission and Store server requirements.
   o  Version 03:
      *  Replaced RECONNECT (server side quick reconned) with QRESYNC
         (client side quick reconnect)




Cridland, et al.         Expires October 5, 2007               [Page 32]

Internet-Draft              Lemonade Profile                  April 2007


      *  Added WITHIN and LIST-EXTENDED.
      *  Moved IDLE extension to a separate section.
      *  Added requirement for clients to use Format=flowed.
   o  Version 02:
      *  Update of references and how they are displayed in the text
         (Comments from Randy Gellens)
      *  Update of list of extensions to support as MUST by the Lemonade
         Profile Bis
      *  Update of options for compression via placeholder imap-
         compression section describing compression requirements
      *  Update of support of TCP chalenged environments
      *  Update of support of object level encryption
      *  Clarified the use of $Forwarded in the examples, and
         demonstrated how to remove the \Draft flag from the sent
         message
      *  Clarified $Forwarded
      *  Added RECONNECT to imap-condstore section
      *  Add new section imap-bodypart, "Message part handling",
         describing BINARY and CONVERT requirements
      *  Added placeholder section for notifications
      *  Added various extensions to imap-other section, and added
         clarifying comments to IDLE, NAMESPACE, and a further
         references to TLS DEFLATE compression
      *  Added extension names to IMAP table
      *  Fixed all issues found with original Lemonade profile so far.
   o  Version 01:
      *  Lemonade profile has been introduced in-line, with some updates
         / corrections.
      *  Subsequent re-organization of the text
      *  Details of extensions proper to Lemonade Profile-bis have been
         updated to refer to the drafts newly accepted as WG IETF
         drafts.
      *  Addition of appendix on attachements streaming.
   o  Version 00:
      *  It evolved from a combination of the content of Lemonade
         profile and the OMA MEM realization internet draft.


13.  Acknowledgements

   The editors acknowledge and appreciate the work and comments of the
   IETF Lemonade working group and the OMA MEM working group.

   In particular, the editors would like to thank Eric Burger, Randall
   Gellens, Zoltan Ordogh, Greg Vaudreuil, and Fan Xiaohui for their
   comments and reviews.





Cridland, et al.         Expires October 5, 2007               [Page 33]

Internet-Draft              Lemonade Profile                  April 2007


14.  References

14.1.  Normative References

   [FLOWED]   Gellens, R., "The Text/Plain Format and DelSp Parameters",
              RFC 3676, February 2004.

   [IMAP]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [IMAP-BINARY]
              Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
              April 2003.

   [IMAP-CATENATE]
              Resnick, P., "Internet Message Access Protocol (IMAP)
              CATENATE Extension", RFC 4469, April 2006.

   [IMAP-COMPRESS]
              Gulbrandsen, A., "The IMAP COMPRESS Extension",
              draft-ietf-lemonade-compress-07 (work in progress),
              January 2007.

   [IMAP-CONDSTORE]
              Melnikov, A. and S. Hole, "IMAP Extension for Conditional
              STORE Operation or Quick Flag Changes Resynchronization",
              RFC 4551, June 2006.

   [IMAP-CONTEXT]
              Cridland, D. and C. King, "Contexts for IMAP4",
              draft-cridland-imap-context-00 (work in progress),
              October 2006.

   [IMAP-CONVERT]
              Maes, S. and R. Cromwell, "CONVERT",
              draft-ietf-lemonade-convert-05 (work in progress),
              October 2006.

   [IMAP-ESEARCH]
              Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
              Command for Controlling What Kind of Information Is
              Returned", RFC 4731, November 2006.

   [IMAP-IDLE]
              Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.

   [IMAP-LISTEXT]
              Leiba, B. and A. Melnikov, "IMAP4 LIST Command



Cridland, et al.         Expires October 5, 2007               [Page 34]

Internet-Draft              Lemonade Profile                  April 2007


              Extensions", draft-ietf-imapext-list-extensions-18 (work
              in progress), September 2006.

   [IMAP-LITERAL+]
              Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
              January 1997.

   [IMAP-METADATA]
              Daboo, C., "IMAP METADATA Extension",
              draft-daboo-imap-annotatemore-11 (work in progress),
              February 2007.

   [IMAP-NAMESPACE]
              Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
              May 1998.

   [IMAP-NOTIFY]
              King, C., "The IMAP NOTIFY Extension",
              draft-gulbrandsen-imap-notify-03 (work in progress),
              March 2007.

   [IMAP-QRESYNC]
              Melnikov, A., "IMAP4 Extensions for Quick Mailbox
              Resynchronization",
              draft-ietf-lemonade-reconnect-client-03 (work in
              progress), February 2007.

   [IMAP-UIDPLUS]
              Crispin, M., "Internet Message Access Protocol (IMAP) -
              UIDPLUS extension", RFC 4315, December 2005.

   [IMAP-URLAUTH]
              Crispin, M., "Internet Message Access Protocol (IMAP) -
              URLAUTH Extension", RFC 4467, May 2006.

   [IMAP-WITHIN]
              Maes, S., "WITHIN Search extension to the IMAP Protocol",
              draft-ietf-lemonade-search-within-04 (work in progress),
              March 2007.

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

   [SMTP-8BITMIME]
              Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
              RFC 1652, July 1994.



Cridland, et al.         Expires October 5, 2007               [Page 35]

Internet-Draft              Lemonade Profile                  April 2007


   [SMTP-AUTH]
              Myers, J., "SMTP Service Extension for Authentication",
              RFC 2554, March 1999.

   [SMTP-BINARYMIME]
              Vaudreuil, G., "SMTP Service Extensions for Transmission
              of Large and Binary MIME Messages", RFC 3030,
              December 2000.

   [SMTP-BURL]
              Newman, C., "Message Submission BURL Extension", RFC 4468,
              May 2006.

   [SMTP-DSN]
              Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

   [SMTP-PIPELINING]
              Freed, N., "SMTP Service Extension for Command
              Pipelining", RFC 2197, September 1997.

   [SMTP-SIZE]
              Klensin, J., Freed, N., and K. Moore, "SMTP Service
              Extension for Message Size Declaration", STD 10, RFC 1870,
              November 1995.

   [SMTP-STATUSCODES]
              Freed, N., "SMTP Service Extension for Returning Enhanced
              Error Codes", RFC 2034, October 1996.

   [SMTP-TLS]
              Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [SUBMIT]   Gellens, R. and J. Klensin, "Message Submission for Mail",
              RFC 4409, April 2006.

   [TLS-COMP]
              Hollenbeck, S., "Transport Layer Security Protocol
              Compression Methods", RFC 3749, May 2004.

14.2.  Informative References

   [ESMTP]    Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [IMAP-SYNC-HOWTO]



Cridland, et al.         Expires October 5, 2007               [Page 36]

Internet-Draft              Lemonade Profile                  April 2007


              Melnikov, A., "Synchronization Operations for Disconnected
              IMAP4 Clients", RFC 4549, June 2006.

   [LEMONADE-DEPLOYMENTS]
              Gellens, R., "Deployment Considerations for lemonade-
              compliant Mobile Email",
              draft-ietf-lemonade-deployments-06 (work in progress),
              March 2007.

   [MANAGESIEVE]
              Martin, T. and A. Melnikov, "A Protocol for Remotely
              Managing Sieve Scripts", draft-martin-managesieve-07 (work
              in progress), November 2006.

   [MEM-arch]
              Open Mobile Alliance, "Mobile Email Architecture
              Document", OMA (Work in Progress),
              http://www.openmobilealliance.org/, October 2005.

   [MEM-req]  Open Mobile Alliance, "Mobile Email Requirements
              Document", OMA http://www.openmobilealliance.org/
              release_program/docs/RD/
              OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005.

   [SIEVE]    Showalter, T. and P. Guenther, "Sieve: An Email Filtering
              Language", draft-ietf-sieve-3028bis-12 (work in progress),
              February 2007.


Authors' Addresses

   Dave Cridland (editor)
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: dave.cridland@isode.com












Cridland, et al.         Expires October 5, 2007               [Page 37]

Internet-Draft              Lemonade Profile                  April 2007


   Alexey Melnikov (editor)
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: Alexey.Melnikov@isode.com


   Stephane H. Maes (editor)
   Oracle
   MS 4op634, 500 Oracle Parkway
   Redwood Shores, CA  94539
   USA

   Phone: +1-203-300-7786
   Email: stephane.maes@oracle.com

































Cridland, et al.         Expires October 5, 2007               [Page 38]

Internet-Draft              Lemonade Profile                  April 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.


Acknowledgment

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





Cridland, et al.         Expires October 5, 2007               [Page 39]


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