          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
Lemonade                                                     S. H. Maes 
Internet Draft: Lemonade TCP Challenged                     R. Cromwell 
Environments                                                  (Editors) 
                                                                        
Document: draft-maes-lemonade-tcp-challenged-      
environments-01 
Expires: December 2006                                        June 2006 
    
    
                  Lemonade in TCP Challenged Environments 
                                      
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 November 30, 2006. 
    
Abstract 
    
   The IETF lemonade group has defined extensions to the IMAP and SMTP 
   protocols that provide optimizations for clients in a variety of 
   settings, such as mobile networks. This document discusses issues 
   related to deployments where TCP support in the client is degraded or 
   non-existent, and techniques for overcoming these limitations. 
 
Conventions used in this document 
    
   In examples, "C:" and "S:" indicate lines sent by the client and 
   server respectively. 
    
 
Maes                   Expires – December 2006               [Page 1] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   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]. 
    
   An implementation is not compliant if it fails to satisfy one or more 
   of the MUST or REQUIRED level requirements for the protocol(s) it 
   implements. An implementation that satisfies all the MUST or REQUIRED 
   level and all the SHOULD level requirements for a protocol is said to 
   be "unconditionally compliant" to that protocol; one that satisfies 
   all the MUST level requirements but not all the SHOULD level 
   requirements is said to be "conditionally compliant."  When 
   describing the general syntax, some definitions are omitted as they 
   are defined in [RFC3501], [RFC821], and related documents.   
 
 
Table of Contents 
          
   Status of this Memo...............................................1 
   Abstract..........................................................1 
   Conventions used in this document.................................1 
   Table of Contents.................................................2 
   1. Introduction and motivation....................................2 
   2. Techniques.....................................................3 
      2.1. Tunneling Approaches......................................3 
         2.1.1. Non-Persistent HTTP for Batch Connectivity Mode......5 
         2.1.2. Using Persistent HTTP/HTTPS + Chunked Transfer 
		Encoding for Stream Connectivity Mode................7 
         2.1.3. Using HTTP as a binding for SMTP.....................8 
   3. Asynchronous Approaches........................................8 
      3.1. Transmission Methods......................................9 
      3.2. Authentication............................................9 
      3.3. Response Payload..........................................9 
   4. Tracking and Controlling Tunneled Traffic......................9 
   5. Security Considerations.......................................10 
   References.......................................................10 
   Future Work......................................................11 
   Version History..................................................11 
   Acknowledgments..................................................12 
   Authors Addresses................................................12 
   Intellectual Property Statement..................................12 
   Disclaimer of Validity...........................................13 
   Copyright Statement..............................................13 
    
    
1. 
   Introduction and motivation 
    
   The IETF lemonade working group is designing a set of extensions to 
   IMAP and SMTP to facilitate access to internet email in diverse 
   service environments, such as on resource constrained devices, and 
 
 
Maes                   Expires – December 2006               [Page 2] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   slow or high latency networks. The preferred model and best current 
   practices for doing this is described in [DEPLOYMENTS].  
 
   Not all networks and clients permit the preferred deployment model at 
   this point in time, such as some devices which do not provide a TCP 
   stack to the application (some mobile phones and set-top box 
   environments), and some networks with very high and unpredictable 
   latency like satellite networks. Over time, it is expected that as 
   technology improves, some of these limitations will be lifted to 
   permit deployment using best current practices. However, it is 
   desirable to provide some form of access for users of these networks 
   until that time. 
     
2. 
  Techniques 
 
   Examples of major markets that have some TCP limitations include: 
    
   - Some Java MIDP devices do not permit arbitrary TCP, but do permit 
   HTTP 
   - TV Set-top box providers which may provide degraded TCP or HTTP 
   over MPEG-2 
   - Global satellite wireless networks which provide email in remote 
   environments and at sea. 
    
   This document considers two techniques to overcome these 
   difficulties. The first is HTTP Tunneling to attempt regular IMAP and 
   SMTP layered on top of HTTP. The second technique is a URL mapping 
   approach which uses [IMAPURL] as a compact representation for sending 
   batches of IMAP commands over severely limited physical networks like 
   two-way satellite networks.  
    
   Servers and clients adhering to this draft MUST support HTTP 
   tunneling, and MAY support section 3's IMAPURL approach. 
    
   2.1. 
        Tunneling Approaches 
    
   There are two approaches for achieving tunneling over HTTP, depending 
   on whether keep-alive chunked-transfer-encoded is supported by any 
   intermediaries in the network (i.e. HTTP proxy servers) or not. The 
   general approach is to use a content-type for packaging a payload of 
   IMAP commands, described below. 
    
   To use HTTP/HTTPS as the transfer protocol for IMAP commands and 
   responses between the IMAP client and server, the client MUST send an 
   HTTP POST request to the server, and embed IMAP commands (commands to 
   an IMAPv4 Rev1 server or IMAP servers supporting Lemonade extensions) 
   in the body of the request. A server MUST reject a HTTP GET request 
   from the client.  The content-type header of the POST request MUST be 
   set to "application/vnd.lemonade.imap".  Multiple IMAP commands may 
 
 
Maes                   Expires – December 2006               [Page 3] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   be included in one POST request. In general, the HTTP server is 
   expected to preserve session state between HTTP commands to the best 
   of its ability, therefore the client does not need to reauthenticate 
   and reissue a SELECT until it receives an (IMAP) error response 
   showing that it is not authenticated. 
    
   In what follows, the term Lemonade client/server is used to refer to 
   a client/server that supports both IMAPv4 Rev1 as well as any 
   LEMONADE extensions. 
    
   When the HTTP binding is used, the Lemonade server listens on 
   whatever port has been configured for this. 
    
   The following is an example of a Lemonade HTTP request: 
    
      POST /lemonadePath HTTP/1.1 <CRLF> 
      Content-Type: application/vnd.lemonade.imap <CRLF>  
      X-Http-Binding: imap <CRLF> 
      [other headers] 
      <CRLF> 
      (<tag> SP <Lemonade command> <CRLF> | literal ) 
      [(<tag> SP <Lemonade command> <CRLF> | literal )] 
    
   The Lemonade command MUST be plain text (7bit). 
    
   Multiple Lemonade commands MAY be sent on the same request. The 
   client must be able to deal with recovering from errors when commands 
   are batched. See RFC2442 Batch SMTP for a further discussion. In 
   general, if a command is expected to produce a synchronized literal 
   or continuation request, it MUST be the last command in the batch. 
    
   The Content-Type and X-Http-Binding headers are the only HTTP headers 
   that MUST be sent to a Lemonade server. Other headers such as Cache-
   Control MAY be included.  
    
   When the Lemonade server sends back a response it is in following 
   format: 
    
      HTTP/1.1 <HTTP Status Code> <CRLF>   
      Content-Type: application/vnd.lemonade.imap <CRLF> 
      X-Http-Binding: imap <CRLF> 
      <CRLF> 
      [<untagged responses>] 
      <tag> SP <Lemonade Server response> <CRLF> 
      [<untagged responses>] 
      <tag> SP <Lemonade Server response> <CRLF> 
    
   The Lemonade Server uses the following HTTP status codes, and what 
   each code indicates is given below: 
 
 
Maes                   Expires – December 2006               [Page 4] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   - 200  
        -This indicates normal execution of the Lemonade commands from 
        an IMAP perspective.    The client should further parse the 
        response body to get the tagged responses to the commands and 
        process those accordingly. 
         
   - 401  
         - This indicates that the execution of the IMAP commands might      
         have been successful, but the session is no longer   
         authenticated. The client should try to reauthenticate to the 
         IMAP server, and then resend the commands. 
          
   - 5xx 
         - This indicates that at least one command was 
         malformed/protocol level error, or, a command could not 
         complete due to a problem in the IMAP server. In conforming to 
         HTTP semantics, this means the IMAP server responses such as 
         BAD or NO on a tagged response generate a HTTP 500 response 
         code.  Also, if the HTTP request includes batched commands 
         after the command which generates a continuation request or 
         synchronized literal, the server MUST generate a 5xx request.  
          
 
   When using HTTP to transfer IMAP commands and responses, the client 
   SHOULD utilize built-in features of HTTP to their advantage.  For 
   example, the client SHOULD use HTTPS instead of HTTP whenever 
   possible, since HTTPS has built in encryption and MAY have 
   compression capabilities.   
    
   HTTP can be used in both batch and stream modes.  Details about these 
   transport modes are given in the following two subsections. 
 
    
   2.1.1. 
          Non-Persistent HTTP for Batch Connectivity Mode 
    
   If the client uses a traditional HTTP connection (either by 
   establishing a different socket for each HTTP request to the Lemonade 
   server, or by reusing the same socket for all HTTP requests, but 
   sending each request in different HTTP commands), it has batch 
   connectivity to the server.  The client can issue as many commands as 
   it would like in one HTTP request to the server, and the server 
   responds by sending back one HTTP response with all the responses to 
   all the commands in the HTTP request.  With this connectivity mode, 
   the IDLE command nor any commands that depend on unsolicited 
   responses in a session. Other commands that use a continuation 
   response or synchronized literal cannot be issued unless they are the 
   last command in the batch. [LITERAL+] SHOULD be used to eliminate 
   synchronized literals when using APPEND. 
 
 
Maes                   Expires – December 2006               [Page 5] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   In order for the server to identify separate HTTP requests as 
   belonging to the same session, a batch HTTP client needs to accept 
   cookies.  A session-id is passed in the cookie to identify the 
   session.   
    
   Example: the headers for a HTTP batch response after the client has 
   issued its first HTTP request to the server. 
    
      HTTP/1.1 <HTTP Status Code> <CRLF>   
      Content-Type: application/vnd.lemonade.imap <CRLF> 
      X-Http-Binding: imap <CRLF> 
      Set-Cookie:JSESSIONID=94571a8530d91e1913bfydafa; 
   path=/lemonade<CRLF> 
      <CRLF> 
      [<untagged responses>] 
      <tag> SP <Lemnade Server response> <CRLF> 
      [[<untagged responses>] 
      <tag> SP <Lemonade Server response> <CRLF>] 
    
    
   Example: the headers for a HTTP batch response after the client has 
   issued its first HTTP request to the server, with the final command 
   generating a continuation request. 
    
      HTTP/1.1 200 Ok <CRLF>   
      Content-Type: application/vnd.lemonade.imap <CRLF> 
      X-Http-Binding: imap <CRLF> 
      Set-Cookie:JSESSIONID=94571a8530d91e1913bfydafa; 
   path=/lemonade<CRLF> 
      <CRLF> 
      [<untagged responses>] 
      <tag> SP <Lemnade Server response> <CRLF> 
      +continuation-request 
    
    
   The client must then save this cookie and send it back to the server 
   with the next request in order for the server to reattach these 
   commands to the same session as the previous commands. 
    
      POST /lemonadePath HTTP/1.1 <CRLF> 
      Content-Type: application/vnd.lemonade.imap <CRLF> 
      X-Http-Binding: imap <CRLF> 
      Cookie: JSESSIONID=94571a8530d91e1913bfydafa 
      [other headers] 
      <CRLF> 
      <tag> SP <Lemonade command> <CRLF> 
      [<tag> SP <Lemonade command> <CRLF>] 
    
 
Maes                   Expires – December 2006               [Page 6] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   2.1.2. 
          Using Persistent HTTP/HTTPS + Chunked Transfer Encoding for 
       Stream Connectivity Mode 
    
   It is possible to use persistent HTTP or persistent HTTPS plus 
   chunked-transfer-encoding so that the client and server can use 
   stream style communications. The client needs to open a persistent 
   HTTP connection and keep it active. In this case, the HTTP headers 
   must be sent the first time the client device opens the connection to 
   the Lemonade Server and these headers MUST set the transfer coding to 
   be chunk-encoded [RFC2616, Sec. 3.6.1]. All subsequent client-server 
   requests are written to the open connection, without needing any 
   additional HTTP headers. In this case, the client does not need to 
   accept cookies. 
    
   The client must send the HTTP headers one time only: 
    
      POST /lemonadeServletPath HTTP/1.1 <CRLF> 
      Content-Type: application/vnd.lemonade.imap <CRLF> 
      Connection: keep-alive <CRLF> 
      X-Http-Binding: imap <CRLF> 
      Pragma: no-cache <CRLF> 
      Transfer-Encoding: chunked <CRLF> 
       
   The server responds with the following header: 
    
      HTTP/1.1 <HTTP Status Code> <CRLF> 
      Cache-Control: private 
      Keep-Alive: timeout=15, max=100 (or other suitable setting) 
      Connection: Keep-Alive 
      X-Http-Binding: imap <CRLF> 
      Transfer-Encoding: chunked 
      Content-Type: application/vnd.lemonade.imap 
    
    
   Then the client can send a command anytime it wants with the 
   following format: 
      <length of Lemonade command, including bytes in CRLF> <CRLF> 
      <tag> SP <Lemonade command> <CRLF>  
      <CRLF> 
    
   And example of an actual client command is: 
      e <CRLF> 
      2 CAPABILITY<CRLF> 
      <CRLF> 
    
   The server responds to each command with as many untagged responses 
   as needed, and one tagged response, where each response is in the 
   format that follows: 
 
 
Maes                   Expires – December 2006               [Page 7] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
      <length of a single response, including bytes in CRLF> <CRLF> 
      <tagged or untagged response> <CRLF>  
      <CRLF> 
    
   An actual Server response might be: 
      d5 <CRLF> 
      * CAPABILITY IMAP4REV1 AUTH=LOGIN NAMESPACE SORT MULTIAPPEND 
   LITERAL+ UIDPLUS IDLE XORACLE X-ORACLE-LIST X-ORACLE-COMMENT X-
   ORACLE-QUOTA X-ORACLE-PREF X-ORACLE-MOVE X-ORACLE-DELETE ACL X-
   ORACLE-PASSWORD LDELIVER LZIP LCONVERT LFILTER LSETPREF LGETPREF 
   <CRLF>   <CRLF> 
      1b <CRLF> 
      2 OK CAPABILITY completed <CRLF> 
      <CRLF> 
     
    
   Note however that the HTTP protocol is in general not meant to be 
   used in such a way. To maintain such an open channel might be a 
   practical challenge to proxies, which might not forward the requests 
   chunk by chunk to the server, and meanwhile route responses back to 
   the client chunk by chunk. Consequently the session closes. Chunked 
   transfer encoding requests MAY not be honored by an HTTP proxy 
   server. In cases where such requests are denied, the client should be 
   prepared to use the non-chunked encoding technique from section 
   2.1.1.   
    
   The session may be automatically started again by the client after a 
   lost connection or by the server through out-of-band; after some 
   defined time-out.  
    
 
   2.1.3. 
          Using HTTP as a binding for SMTP 
 
      All of the techniques described in sections 2.1 may be used for 
   SMTP as well. The only difference between IMAP and SMTP will be the 
   HTTP URL used. Servers implementing the HTTP binding are expected to 
   differentiate between IMAP and SMTP protocol bodies via the URL. 
 
3. 
  Asynchronous Approaches 
 
   Some networks, such as satellite networks, may present challenges to 
   the HTTP request-response approach in the preceding chapter due to 
   extreme latency. Clients expecting near-synchronous response to IMAP 
   commands would face huge delays, and may inappropriately timeout too 
   soon, or provide a UI to the user that is geared around immediate 
   response which will expose long delays to end users. 
    
   Satellite networks resemble store-and-forward systems, it is thus 
   desirable to provide a mechanism for interacting with an IMAP 
 
 
Maes                   Expires – December 2006               [Page 8] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   Lemonade server that is geared for asynchronous requests and 
   responses. 
    
   [IMAPURL] already provides a standard for encoding a series of IMAP 
   commands into a compact URL, and describes a subset of functionality 
   that is adequately suited to accessing email when roaming on 
   satellite networks.  
    
   3.1. 
        Transmission Methods 
    
   It is not in the scope of this document to describe the mechanism by 
   which IMAPURL payloads are sent through such networks (which are 
   typically proprietary) However, the end result should be an HTTP 
   request invoked on a server which decodes the IMAPURL payload and 
   processes the request on behalf of the client. 
    
   IMAPURLs of the form imap://<iserver>/path?query where iserver = 
   [iuserinfo "@"] host [":" port] must be rewritten into a URL of the 
   following form: 
    
   http://host:port/lemonade?imapurl=<enc-imapurl> 
    
   where <enc-imapurl> is imap://<iserver>/path?query encoded according 
   to standard HTTP url encoding. 
     
   3.2. 
        Authentication 
    
   <<Ray: TBD, Perhaps the Delay Tolerant Networking working group has 
   some material on authenticating over DTNs? Or perhaps a mechanism for 
   obtaining longer lived URLAUTH tokens which can be reused multiple 
   URLs within a time span?>> 
    
 
   3.3. 
        Response Payload 
    
   The response to any IMAPURL processed according to [IMAPURL] on the 
   server should be sent to the client as a set of raw IMAP responses. 
   However, [IMAPURL] suggests that the result of a search should be to 
   fetch all the messages returned from the SEARCH.  For the purposes of 
   this document, the result of an IMAPURL containing a search should be 
   the SEARCH response from the IMAP server, without performing any 
   FETCHes. 
    
    
4. 
  Tracking and Controlling Tunneled Traffic 
    
   In order to simplify deployment and provisioning issues, as well as 
   help network administrators track and control IMAP/SMTP traffic 
   wrapped in HTTP requests, the HTTP requests and responses of a 
 
 
Maes                   Expires – December 2006               [Page 9] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   binding should provide a non-ambiguous way of recognizing binding 
   traffic. 
    
   It is therefore mandated that a "X-HTTP-Binding" HTTP header MUST 
   specified in all requests and responses. The header may take a value 
   of "imap" or "smtp" depending on the type of traffic being tunneled. 
    
    
5. 
  Security Considerations 
    
   The HTTPS protocol can and should be used to provide end-to-end 
   security where it is available when tunneling, especially because of 
   the existence of HTTP proxies. 
    
   Caching is also a concern, especially if HTTPS isn't used. The client 
   SHOULD use the HTTP Cache-Control directive (no-cache, no-store, 
   must-revalidate, or combinations thereof) to inform proxy servers, 
   origin servers, and client libraries not to cache or store the HTTP 
   response. To deal with HTTP 1.0 servers that may exist in the 
   network, Pragma: no-cache should be used as well. 
    
   Attacks on HTTP sessions and the HTTP server may also be a concern, 
   since the HTTP server is maintaining an authenticated session to the 
   IMAP server on behalf of the user in most cases. 
    
   Network administrators wishing to block stealth deployments of HTTP 
   IMAP bindings may block HTTP requests with Content-Type 
   application/vnd.lemonade.[imap|smtp]  via an application level 
   firewall and/or block any HTTP traffic with the X-Http-Binding header 
   defined. 
    
    
References 
    
   [DEPLOYMENTS] Gellens, R., " Deployment Considerations for lemonade-
   compliant Mobile Email", draft-ietf-lemonade-deployments-03.txt, June 
   2006. 
    
   [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", 
   draft-ietf-lemonade-profile-XX.txt, (work in progress). 
    
   [LUOTONEN] Luotonen, A., “Tunneling TCP based protocols through Web 
   proxy servers”, draft-luotonen-web-proxy-tunneling-01.txt, August 
   1998 
    
   [LITERAL+] Myers, J. “IMAP non-synchronizing literals”, RFC2088, 
   January 1997 
      http://www.ietf.org/rfc/rfc2088 
    
 
Maes                   Expires – December 2006              [Page 10] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and 
   Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S-
   M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Protocol 
   (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). 
    
   [RFC2119] Brader, S.  "Keywords for use in RFCs to Indicate 
   Requirement Levels", RFC 2119, March 1997.  
      http://www.ietf.org/rfc/rfc2119 
    
   [RFC2442] Freed, N. et al. "The Batch SMTP Media Type", RFC 2442, 
   November 1998.  
      http://www.ietf.org/rfc/rfc2442  
    
   [RFC2616] Fielding, R. et al.  "Hypertext Transfer Protocol -- 
   HTTP/1.1", RFC 2616, June 1999.  
      http://www.ietf.org/rfc/rfc2616 
    
   [RFC2817] Khare, R., “Upgrading to TLS Within HTTP/1.1”, RFC2817, May 
   2000 
      http://www.ietf.org/rfc/rfc2817.txt, May 2000 
    
   [RFC3205] Moore, K. ”On the use of HTTP as a Substrate”, RFC 3205, 
   February 2002. 
   http://www.ietf.org/rfc/rfc3205 
    
   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 
   Version 4 rev1", RFC 3501, March 2003. 
   http://www.ietf.org/rfc/rfc3501 
    
Future Work 
    
   - Detail normative statements on binding method to support versus 
   other options that were considered. 
 
 
Version History 
    
   Release 01 
      Change name and focus to TCP challenged environment 
      Emphasize usage in challenged network and platform environments 
      Added more examples of challenged environments 
      Discussion of IMAPURL for satellite networks, 
      New X-HTTP-Binding header 
      Normative statements 
       
   Release 00 
      Rename from firewall binding.  
     
 
Maes                   Expires – December 2006              [Page 11] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
Acknowledgments 
    
   The authors want to thank all who have contributed key insight and 
   extensively reviewed and discussed the concepts in this draft as well 
   as the authors of the early introduction of the binding concept in 
   [P-IMAP].  
    
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 
    
   Ray Cromwell 
   Oracle Corporation 
   500 Oracle Parkway 
   Redwood Shores, CA 94065 
   USA 
 
   Nilo Mitra 
   Ericsson 
   Tel: +1 212-843-8451 
   Email: nilo.mitra@ericsson.com 
    
Intellectual Property Statement 
    
   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. 
    

Maes                   Expires – December 2006              [Page 12] 

          <Lemonade in TCP Challenged Environments>            June 2006 
 
 
   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. 
 
Disclaimer of Validity 
    
   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. 
    
Copyright Statement 
    
   Copyright (C) The Internet Society (2006).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
    
Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
 

Maes                   Expires – December 2006              [Page 13]