[lemonade] Re: Lemonade Profile Comments

I'm resending this to make it easier to read.

Here are my comments.  See lines starting with "]]]".

                           <Lemonade Profile>             February 2005 

Lemonade                                                                
Internet Draft: Lemonade Profile                             S. H. Maes 
Document: draft-ietf-lemonade-profile-01.txt                A. Melnikov 
Expires: August 2005                                      February 2005 

                             Lemonade Profile 

Status of this Memo 

   This document is an Internet-Draft and is subject to all provisions 
   of Section 10 of RFC2026. 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 become aware will be disclosed, in accordance with 
   RFC 3668. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 

Abstract 

   This document describes the Lemonade profile to allow clients to 
   submit new email messages incorporating content which resides on 
   locations external to the client ("forward without download").  
]]] ...describes a profile (a set of required extensions, restrictions,
]]] and usage modes) of mail protocols such as IMAP and Submission.
]]] This profile allows clients (especially those that are constrained
]]] in memory, bandwidth, processing power, or other areas) to
]]] effeciently use IMAP and Submission to access and submit mail.
]]] This includes the ability to forward received mail without needing
]]] to download and upload the mail, to have media attached to a
]]] message converted if required, and to more efficiently maintain
]]] a synchronized cache of received messages.

   The Lemonade profile relies upon extensions to other protocols; 
]]]                                               ^^^^^ -> "various"
   specifically URLAUTH, CATENATE, Lemonade Command Extensions in the 
   IMAP protocol [RFC 3501] and BURL in the SUBMIT protocol [RFC 2476]. 

   In addition, the Lemonade profile contains Lemonade Command 
   extensions for quick reconnect and media conversion. 
]]] No, these must not be in a profile document, they must be in
]]] their own documents and referenced here.

Conventions used in this document 

Maes                    Expires - August 2005                [Page 1] 

                          <Lemonade Profile>             February 2005 

   In examples, "M:", "I:" and "S:" indicate lines sent by the client 
   messaging user agent, IMAP e-mail server and 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 [RFC2119]. 

Table of Contents 

   Status of this Memo...............................................1 
   Abstract..........................................................1 
   Conventions used in this document.................................1 
   Table of Contents.................................................2 
   1. Introduction...................................................2 
   2. Forward without download.......................................3 
      2.1. Motivations...............................................3 
      2.2. Message Sending Overview..................................3 
      2.3. Traditional Strategy......................................4 
      2.4. Step by step description..................................4 
      2.5. Additional Considerations.................................8 
      2.6. The fcc problem...........................................8 
   3. Media Conversion...............................................9 
      3.1. Introduction..............................................9 
      3.2. Static media conversion...................................9 
      3.3. Conversion of streamed media..............................9 
      3.4. Quick Reconnect scheme....................................9 
   4. Future work...................................................10 
   Security Considerations..........................................10 
   References.......................................................10 
   Version History..................................................12 
   Acknowledgments..................................................12 
   Authors Addresses................................................12 
   Intellectual Property Statement..................................12 
   Full Copyright Statement.........................................13 

1. 
   Introduction 

   Lemonade provides enhancements to Internet email to support diverse 
   service environments.  

   This document describes the lemonade profile that includes: 
      - The Lemonade Pull Model that describes exchanges between 
        Lemonade Agents to allow clients to submit new email messages 
        incorporating content which resides on locations external to 
        the client and allow forward without download. 
      - Media conversion 

Maes                    Expires - August 2005                [Page 2] 

                          <Lemonade Profile>             February 2005 

      - Quick reconnect   

   The organization of this document is as follows.  Section 2 describes 
   the Lemonade Pull Model. Section 3 Section 3 describes the Media 
   Conversion. Section 4 describes quick reconnect  

2. 
  Forward without download 

2.1. 
    Motivations 

   The advent of client/server email using the [RFC3501] and [RFC2821] 
   protocols has changed what formerly were local disk operations to 
   become excessive and repetitive network data transmissions. This is 
]]]       ^^^^^^^^^^^^^^^^^^^^^^^^ <<delete>>
   an onerous burden for clients operating over low-bandwidth and/or 
]]] ^^^^^^^^^ <<delete>>
   high-latency links. 

   The Lemonade Pull Model makes use of the [BURL] SUBMIT 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 store is 
   possible with a minimal trust relationship between the IMAP and 
   SUBMIT servers. 

   Pull has the distinct advantage of maintaining one submission 
]]]^^^^ -> "This approach"
]]]             ^^^^^^^^ <<<delete 'distinct'>>>
   protocol, and thus avoids the risk of having multiple parallel and 
   possible divergent mechanisms for submission.  Furthermore, by 
   keeping the details of message submission in the SUBMIT server, the 
   Lemonade Pull Model can work with other message retrieval protocols 
   such as POP, NNTP, or whatever else may be designed in the future. 

2.2. 
    Message Sending Overview 

   The act of sending an email message is best 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 on the MUA. 
   Frequently, users choose to save more complex and/or time-consuming 
]]]                                                     ^^^^^^^^^^^^^^
]]] (What is a "time-consuming message"?)
   messages on an [RFC3501] 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 [RFC2821] infrastructure, typically using the [RFC2476] 
   protocol. 

Maes                    Expires - August 2005                [Page 3] 

                          <Lemonade Profile>             February 2005 

2.3. 
    Traditional Strategy 

   Traditionally, messages are initiated, edited, and assembled entirely 
   within an MUA, although drafts may be saved to an [RFC3501] 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, once 
   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. 

   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. 

2.4. 
    Step by step description 

Maes                    Expires - August 2005                [Page 4] 

                          <Lemonade Profile>             February 2005 

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

        +--------------------+               +--------------+ 
        |                    | <------------ |              |   
        |     MUA (M)        |               | IMAPv4 Rev1  | 
        |                    |               |  Server      | 
        |                    | ------------> | (Server I)   | 
        +--------------------+               +--------------+ 
               ^  |                             ^     | 
               |  |                             |     | 
               |  |                             |     | 
               |  |                             |     | 
               |  |                             |     | 
               |  |                             |     | 
               |  |                             |     v 
               |  |                          +--------------+ 
               |  |------------------------->|              |   
               |                             |   Submit     | 
               |-----------------------------|   Server     | 
                                             |  (Server S)  | 
                                             +--------------+ 
                     Figure 1: Lemonade Pull Model 

   The Lemonade Pull Model 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 server. 

   In the [BURL]/[CATENATE] variant of the pull strategy, messages are 
   initially composed and edited within an MUA.  The [CATENATE] 
   extension to [RFC3501] is then used to upload the message to the IMAP 
   server and assemble it, and finally a [URLAUTH] format URL is given 
   to a [RFC2476] server with the [BURL] extension for submission. 

   The flow involved to support such a use case consists of: 
      M: {to I -- Optional} The client connectects to the IMAP server 
     and IMAP Fetch of body structures and UIDs (See [RFC3501]) 

     Example: 
           M: A0051 FETCH 161 (UID BODYSTRUCTURE) 
           I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 
     ("CHARSET" "US-ASCII") NIL 
              NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" 
     "NAME" 
              "cc.diff") 
              "<960723163407.20117h@washington.example.net>" "Compiler 
     diff" 

Maes                    Expires - August 2005                [Page 5] 

                          <Lemonade Profile>             February 2005 

              "BASE64" 4554 73) "MIXED")) 
           I: A0051 OK completed 

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

     <<Editors note: Draft editing/catenation is omitted for now>> 

        M: A0052 CATENATE Sent FLAGS (\Seen $MDNSent) TEXT {738} 
        I: + Ready for literal data 
        M: Return-Path: <bar@example.org> 
        M: Received: from [127.0.0.2] 
        M:           by rufus.example.org via TCP (internal) with 
     ESMTPA; 
        M:           Thu, 11 Nov 2004 16:57:07 +0000 
        M: Message-ID: <419399E1.6000505@example.org> 
        M: Date: Thu, 12 Nov 2004 16:57:05 +0000 
        M: From: Bob Ar <bar@example.org> 
        M: X-Accept-Language: en-us, en 
        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; charset=us-ascii; format=flowed 
        M: Content-Transfer-Encoding: 7bit 
        M:  
        M: Our travel agent has sent the updated schedule. 
        M:  
        M: Cheers, 
        M: Bob 
        M: --------------030308070208000400050907 
        M:  URL "imap://imap.example.org/INBOX;UIDVALIDITY=385759045/; 
           UID=25627;Section=1.2" TEXT {44} 
        I: + Ready for literal data 
        M: --------------030308070208000400050907-- 
        M:  
        I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed 
        M: A0053 UID STORE XXX +FLAGS.SILENT ($Forwarded) 
        I: A0053 OK STORE completed 

     << Editors note: Recommend UIDPLUS extension  especially useful 
     when appending messages to a non-selected mailbox>> 

Maes                    Expires - August 2005                [Page 6] 

                          <Lemonade Profile>             February 2005 

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

     M: A0054 GENURLAUTH 
     "imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;uid=45/;urla
     uth=submit+bar" INTERNAL 
            I: * GENURLAUTH 
     "imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;uid=45/;urla
     uth=submit+bar:internal:91354a473744909de610943775f92038" 
            I: A0054 OK GENURLAUTH completed 

      M: {to S} The client connects to the submission server and starts 
     a new mail transaction. It uses BURL to let the submit server fetch 
     the content of the message from the IMAP server (See [BURL] for 
     details of the semantics and steps  this allows the MUA to 
     authorize the submit server to access the message composed as a 
     result of the CATENATE step). 

     M: EHLO potter.example.org 
        S: 250-owlry.example.com 
        S: 250-8BITMIME 
        S: 250-BURL imap 
        S: 250-AUTH PLAIN 
        S: 250-DSN 
        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:<ron@gryffindor.example.com> 
        S: 250 2.1.5 ron@gryffindor.example.com OK. 
        M: BURL 
     imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;uid=45/;urlau
     th=submit+bar:internal:91354a473744909de610943775f92038 LAST 

      S: {to I} The submission server uses URLFETCH to fetch the message 
     to be sent (See [URLAUTH] 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} Provides the message composed as a result of the 
     CATENATE step). 

     Submission server opens IMAP connection to the IMAP server: 

            I: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP 
     server ready 

Maes                    Expires - August 2005                [Page 7] 

                          <Lemonade Profile>             February 2005 

            S: a001 LOGIN submitserver secret 
            I: a001 OK submitserver logged in 
            S: a002 URLFETCH " 
     imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;uid=45/;urlau
     th=submit+bar:internal:91354a473744909de610943775f92038" 
            I: * URLFETCH " 
     imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;uid=45/;urlau
     th=submit+bar:internal:91354a473744909de610943775f92038" {15065} 
            ...message body follows... 
            S: a002 OK URLFETCH completed 

     << Editors note: The submission server may LOGOUT>>    

      S2: {to M} OK (2XX) 

     Submission server returns OK to the MUA: 
        S: 250 2.5.0 Ok. 

   The messaging user agent, mail server and submit server MUST support 
   IMAPv4 Rev1 [RFC3501], CATENATE [CATENATE] and URLAUTH [URLAUTH]. 

2.5. 
    Additional Considerations 

   The so-called "pawn-ticket" authorization mechanism uses a URI which 
   contains its own authorization credentials using [URLAUTH].  The 
   advantage of this mechanism is that the submit [RFC2476] server can 
   not access any data on the [RFC3501] server without a "pawn-ticket" 
   created by the client.  The "pawn-ticket" grants acces only to the 
   specific data that the submit [RFC2476] server is authorized to 
   access, can be revoked by the client, and can have a time-limited 
   validity. 

2.6. 
    The fcc problem 

   The "fcc problem" refers to a frequent need to deliver a copy of the 
   message to a "file carbon copy" recipient.  By far, the most common 
   case of fcc is a client leaving a copy of outgoing mail in a "sent 
   messages" 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 
   "excessive and repetitive network data transmissions" which 
   represents the "problem" aspect of the "fcc problem". 

   The [CATENATE] extension to [RFC3501] addresses the fcc problem.  It 
   requires making several simplifying assumptions: 

Maes                    Expires - August 2005                [Page 8] 

                          <Lemonade Profile>             February 2005 

       (1a) there is one, and only one, fcc destination on a single 
   server 
       (2a) the server which holds the fcc is the same as the server 
   which stages the outgoing message for submission 
       (3a) it is desired that the fcc be a copy of the complete message 
   text with all external data inserted in the message 

   << Editors note: [POSTADDRESS] can be used to address issues (1a) 
   and (2a). To be done later>> 

3. 
  Media Conversion 

3.1. 
    Introduction 

   <<Editors note: To be done when agreed by WG>> 

3.2. 
    Static media conversion 

   <<Editors note: To be done when agreed by WG>> 

3.3. 
    Conversion of streamed media 

   <<Editors note: To be done when agreed by WG>> 

3.4. 
    Quick Reconnect scheme 

   Mobile operators usually charge users for the time their mobile 
   client gets connected to the Internet and/or for the amount of 
   information sent/received. Thus a mobile client should minimize time 
   it stays connected to its mail server, which suggests that it should 
   disconnect and reconnect frequently. 

   Also, it is possible that the mobile client unexpectedly leaves area 
   of connectivity, which will require that the client reconnects when 
   connectivity returns. 

   << Editors note: Discussion about voluntarily versa non-voluntarily 
   disconnects might go here>> 

   IMAP can be verbose. Usually, in order to synchronize a client with a 
   server after a disconnect, the client needs to issue at least the 
   following commands: LOGIN/AUTHENTICATE, SELECT and several FETCH 
   commands (see [IMAP-DISC] for more details). 

   Thus, there is a desire to have a quick reconnect facility in IMAP, 
   which will give a mobile client ability to resume a previously 
   abandoned session, without the need to perform the full 
   synchronization sequence as described above. 

Maes                    Expires - August 2005                [Page 9] 

                          <Lemonade Profile>             February 2005 

   << Editors note: Example is as per reconnect-02, syntax is subject 
   to change>> 

      S: * OK [CAPABILITY IMAP4REV1 STARTTLS AUTH=LOGIN CONDSTORE 
         X-DRAFT-W02-RECONNECT] imap.example.com IMAP4rev1 2001.315rh 
         at Thu, 15 Jul 2004 11:47:49 -0400 (EDT) 
      C: b0002 authenticate login (SID P1234567890 56789 
   20010715194045000 
      41,43:211,214:541) 
      S: + VXNlciBOYW1lAA== 
      C: dGVzdDg= 
      S: + UGFzc3dvcmQA 
      C: dGVzdDg= 
      S: * FOLDER INBOX 
      S: * 464 EXISTS 
      S: * 3 RECENT 
      S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 
      S: * OK [UIDNEXT 550] Predicted next UID 
      S: * OK [HIGHESTMODSEQ 20010715194045007] 
      S: * 1 FETCH (UID 1 FLAGS (\Seen)) 
      S: b0002 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS 
   SCAN 
      SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User 
      test8 authenticated 

4. 
  Future work 

   Future versions of the Lemonade profile are expected to address 
   issues related to access of email form mobile devices, possibly 
   including: 
      - transport optimization for low or costly bandwidth and less 
        reliable mobile networks 
      - server to client notifications outside of the traditional IMAP 
        band 
      - dealing with firewall and intermediaries 
      - compression 
      - filtering  

Security Considerations 

   Security considerations on the Lemonade Pull Model are discussed 
   throughout section 2. 

   << Editors note: TBD (Reconnect, etc.)>> 

References 

Maes                    Expires - August 2005               [Page 10] 

                          <Lemonade Profile>             February 2005 

   [IMAP-DISC] Melnikov, A.  "Synchronization Operations For 
      Disconnected Imap4 Clients", IMAP-DISC, work in progress,  draft-
      melnikov-imap-disc-XX.txt 

   [RFC2119] Brader, S.  "Keywords for use in RFCs to Indicate 
      Requirement Levels", RFC 2119, March 1997.  
      http://www.ietf.org/rfc/rfc2119 

   [RFC2180] Gahrns, M.  "IMAP4 Multi-Accessed Mailbox Practice", RFC 
      2180, July 1997.  
      http://www.ietf.org/rfc/rfc2180 

   [RFC2234] Crocker, D. and Overell, P.  "Augmented BNF for Syntax 
      Specifications", RFC 2234, Nov 1997.  
      http://www.ietf.org/rfc/rfc2234 

   [RFC2683] Leiba, B. "IMAP4 Implementation Recommendations", RFC 2683 
      Sep 1999. 
      http://www.ietf.org/rfc/rfc2683  

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

   [RFC2822] Resnick, P. "Internet Message Format", RFC 2822, April 
      2001.  http://www.ietf.org/rfc/rfc2822 

   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 
      Version 4 rev1", RFC 3501, March 2003. 
      http://www.ietf.org/rfc/rfc3501 

   [RFC2476] Gellens, R. and Klensin, J., "Message Submission", RFC 
      2476, December 1998. 

   [CATENATE]Resnick, P., "Internet Message Access Protocol (IMAP) 
      CATENATE Extension", draft-ietf-lemonade-catenate-XX, (work in 
      progress). 

   [BURL]    Newman, C., "Message Composition", draft-ietf-lemonade-
      burl-xx (work in progress). 

   [URLAUTH] Crispin, M. and Newman, C., "Internet Message Access 
      Protocol (IMAP) - URLAUTH Extension", draft-ietf-lemonade-urlauth-
      XX.txt, (work in progress). 

   [POSTADDRESS] Melnikov, A., "IMAP4 POSTADDRESS extension", work in 
      progress, draft-melnikov-imap-postaddress-XX.txt 

Maes                    Expires - August 2005               [Page 11] 

                          <Lemonade Profile>             February 2005 

   [RECONNECT] Melnikov, A. and C. Wilson, " IMAP4 extension for quick 
      reconnect ", work in progress, draft-ietf-lemonade-reconnect-
      XX.txt 

Version History 

   [1] We removed the sections of the profile related to mobile e-mail 
      as well as discussion. This will be part of the next version of 
      the Lemonade profile work. 
   [2] We added detailed examples for the different steps included in 
      section 2.4. 
   [3] We added section 3 on media conversion 
   [4] We added examples on Quick reconnect schemes in section 4. 
   [5] We updated the security considerations 
   [6] We fixed references based on updates above 
   [7] We added a future work section 
   [8] We fixed the boiler plate statements on the Ùstatus of this memo 
      and ÙCopriright. 

Acknowledgments 

   This document is based on the work in progress described in draft-
   crispin-lemonade-pull-xx.txt. 

Authors Addresses 

   Stephane H. Maes 
   Oracle Corporation 
   500 Oracle Parkway 
   M/S 4op634 
   Redwood Shores, CA 94065 
   USA 
   Phone: +1-650-607-6296 
   Email: stephane.maes@oracle.com 

   Alexey Melnikov 
   Isode Limited 
   5 Castle Business Village 
   36 Station Road 
   Hampton, Middlesex 
   TW12 2BX 
   UK  
   Email: Alexey.melnikov@isode.com 

Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   intellectual property or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 

Maes                    Expires - August 2005               [Page 12] 

                          <Lemonade Profile>             February 2005 

   this document or the extent to which any license under such rights 
   might or might not be available; neither does it represent that it 
   has made any effort to identify any such rights.  Information on the 
   IETF's procedures with respect to rights in standards-track and 
   standards-related documentation can be found in BCP-11.  Copies of 
   claims of rights made available for publication 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 implementors or users of this specification can 
   be obtained from the IETF Secretariat.  

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights which may cover technology that may be required to practice  
   this standard.  Please address the information to the IETF Executive  
   Director. 

Acknowledgement 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

Full Copyright Statement 

   Copyright (C) The Internet Society 2004. 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.  

   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph are 
   included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 

Maes                    Expires - August 2005               [Page 13] 

                          <Lemonade Profile>             February 2005 

   followed, or as required to translate it into languages other than 
   English.  

   The limited permissions granted above are perpetual and will not be  
   revoked by the Internet Society or its successors or assigns. 

Maes                    Expires - August 2005               [Page 14] 

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade