Lemonade Internet Draft: Lemonade Profile S. H. Maes Document: draft-ietf-lemonade-profile-00.txt A. Melnikov Expires: January 2005 July 2004 Lemonade Profile Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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") and to optimize e-mail exchanges between clients and servers in a mobile environment. The Lemonade profile relies upon extensions to other protocols; specifically URLAUTH, CATENATE, Lemonade Command Extensions in the IMAP protocol [RFC 3501] and BURL in the SUBMIT protocol [RFC 2476]. It also provides optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources by relying on Lemonade Server to Client Notifications to support to push crucial changes actively to a client, rather then requiring the client to initiate contact to ask for state changes. Maes Expires - January 2005 [Page 1] July 2004 In addition, the Lemonade profile contains Lemonade Command extensions for email filter management, message delivery, maintaining up-to-date personal information and quick reconnect. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and 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.................................2 Table of Contents.................................................2 1. Introduction...................................................3 2. The Lemonade Pull Model........................................3 2.1. Motivations...............................................3 2.2. Message Sending Overview..................................3 2.3. Traditional Strategy......................................4 2.4. Forward without download..................................4 2.5. Additional Considerations.................................6 2.6. The fcc problem...........................................6 3. Mobile Optimization............................................7 3.1. Introduction..............................................7 3.2. Motivation................................................7 3.3. The Poll Model vs. the Push Model.........................7 3.4. Synchronization Techniques................................8 3.4.1. State-Comparison-Based Synchronization...............9 3.4.2. Event-based Synchronization.........................10 3.5. The Server-Side Filtering in Lemonade Profile............11 3.6. Lemonade Command Extensions..............................11 3.7. Fast Reconnect...........................................12 3.8. HTTP Binding.............................................12 3.9. Revisions to IMAPv4 Rev1 Behavior........................12 Security Considerations..........................................13 References.......................................................13 Acknowledgments..................................................15 Authors Addresses................................................15 Intellectual Property Statement..................................15 Full Copyright Statement.........................................16 Maes Expires - January 2005 [Page 2] July 2004 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. - Mobile optimizations that defines extensions to the IMAPv4 Rev1 protocol [RFC3501] aimed at delivering extended functionality for mobile devices with limited resources including support to push crucial changes actively to a client, rather then requiring the client to initiate contact to ask for state changes and extensions for email filter management, message delivery, and maintaining up-to-date personal information and quick reconnect. The organization of this document is as follows. Section 2 describes the Lemonade Pull Model. Section 3 describes the Lemonade Mobile Optimizations. 2. The Lemonade Pull Model 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 an onerous burden for clients operating over low-bandwidth and/or 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 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 Maes Expires - January 2005 [Page 3] July 2004 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 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. 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. Forward without download The model distinguishes between a Messaging User Agent (MUA), an IMAPv4Rev1 Server ([RFC3501]) and a submit server ([RFC2476]), as illustrated in Figure 1. +--------------------+ +--------------+ | | <------------ | | | MUA | | IMAPv4 Rev1 | Maes Expires - January 2005 [Page 4] July 2004 | | | Server | | | ------------> | (Server S1) | +--------------------+ +--------------+ ^ | ^ | | | | | | | | | | | | | | | | | | | | | | | | v | | +--------------+ | |------------------------->| | | | Submit | |-----------------------------| Server | | (Server S2) | +--------------+ 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 initiated 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 S1 -- Optional} The client uses IMAP Fetch of body structures (See [RFC3501]) M: {to S1} 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. S1: {to M} OK (See [CATENATE]). M: {to S1} The client uses GENURLAUTH command to request and URLAUTH URL (See [URLAUTH]). S1: {to M} The IMAP server returns URLAUTH URL suitable for later retrieval with URLFETCH (See [URLAUTH] for details of the semantics and steps). M: {to S2} 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). Maes Expires - January 2005 [Page 5] July 2004 S2: {to S1} 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.). S1: {to S2} Provides the message composed as a result of the CATENATE step). S2: {to M} OK (2XX) 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: (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 <<[POSTADDRESS] can be used to address issues (1a) and (2a). To be done later>> Maes Expires - January 2005 [Page 6] July 2004 3. Mobile Optimization 3.1. Introduction The Lemonade profile provides optimizations for the exchanges between a mobile client and e-mail server by specifying additional enhancements for optimization in a mobile setting. Thus, the client devices in this profile are assumed to be mobile with limited resources. This profile takes into account the limited resources of mobile devices, as well as extra functionality desired. Figure 2 illustrates the exchanges specified by the mobile optimizations of the Lemonade Profile. The e-mail server MAY comply with the Lemonade Pull Model described in section 2. +--------------------+ +--------------+ | Mobile | <------------ | | | Lemonade | | Lemonade | | E-mail Client | |E-mail Server | | | ------------> | | +--------------------+ +--------------+ Figure 2: Lemonade CS Profile Model A disconnected mobile client should behave like a good disconnected client [IMAP-DISC]. Additional requirements for optimization for Mobile access are discussed in section 3.6. 3.2. Motivation Today, most of the existing email clients have a polling model, where the end user is notified of changes to an email account only after his/her email client asks the server, called polling. How long it takes a client to learn of a change on the server is thus dependent on how often the client polls for changes. Many clients can poll at high rates so that the client can quickly learn of changes and reflect them on the client display to achieve a quasi-real time. The mobile optimization of the Lemonade profile can support both Poll and Push Models. 3.3. The Poll Model vs. the Push Model Today, most of the existing email clients implement a polling model, where the end user is notified of changes to an email account only after the email client polls the server for changes. How long it Maes Expires - January 2005 [Page 7] July 2004 takes a client to learn of a change on the server is thus dependent on how often the client polls for changes. Many clients can poll at high rates so that the client can quickly learn of changes and reflect them on the client display to achieve a quasi-real time synchronization experience for the end user. The periodic poll model is used on conventional email clients. Because the client must continuously poll the server for changes, the bandwidth requirements can be quite high and the connection quality must be good in order to provide a quasi-real time experience to the user. This also generates additional load on the IMAP server. The periodic poll model is illustrated in Figure 2. +--------------------+ Poll +--------------+ | | <------------ | | | Mail Server | | Email Client | | | ------------> | | +--------------------+ Response +--------------+ Figure 3: Periodic Poll Model Another way to achieve synchronization is for the email server to initiate a session with the client when a crucial change to an email occurs, which is the push model. When important events happen to a userÆs email account, the server informs the client device about the event, and then the client can respond to that event as necessary. In this case, the client device does not need to periodically poll the mail server, so the push model is particularly effective in the mobile computing environment when the cost of constant polling is high. [NOTIFICATIONS] defines the semantics for pushing events to a client. The push model is seen in Figure 2. Event +----------------+ Push +--------------+ --------> | Mail Server | ---------> | Email Client | +----------------+ +--------------+ Figure 4: Push Model 3.4. Synchronization Techniques After a client receives a notification that informs it that changes have occurred to a mailbox, it needs to employ a synchronization technique to reflect the server side changes onto the client device. There are many techniques for determining what the changes between a server and client are. In this section, two techniques are presented that aim to keep a client device in sync with a given email account, meaning that the set of messages on the client device is the same as that in the given email account. Maes Expires - January 2005 [Page 8] July 2004 3.4.1. State-Comparison-Based Synchronization IMAPv4Rev1 clients use a state-comparison-based synchronization technique to be in sync with an email account. This technique requires the client to ask the server for information regarding all the folders and all the messages in each folder stored on the server. The client must then compute the difference between the server state and the client device state, and make all necessary changes so that the client device state matches the server state. An example of the interaction between the client and server in the IMAPv4Rev1 protocol for performing a state-comparison-based sync follows. This is described in more details in [IMAP-DISC]. First, the client must retrieve the folders from the server. The client should issue LIST to figure out which folders has to be retrieved. It than uses LSUB to determine which folders are subscribed. For example: C: A002 LIST "" "%" S: * LIST (\NoInferiors) "/" "Drafts" S: * LIST () "/" "Friends" S: * LIST (\NoInferiors) "/" "INBOX" S: A002 OK completed C: A003 LSUB "" "*" S: * LSUB () "/" "Drafts" S: * LSUB () "/" "Friends" S: * LSUB () "/" "INBOX" S: A003 OK LSUB completed Note, that the client should not use LIST "" *, as it might cause too much data to be returned. This is discussed in [RFC2683] in more details. The client must compare its folders with the responses of the command above. If it does not have a folder, it must create that folder on the client device. If there is a folder on the device that is not in any of these responses, then the client must delete that folder. In order to avoid loosing changes performed on the client, the client should apply its changes first. In case when the client has changes to a folder that was deleted on the server, it should ask the user whether the changes should be uploaded to a different mailbox or be discarded (or be configured to automatically do one of the two). Next, the client needs to make sure that the emails in each of its folders match the server. It performs a SELECT and then a FETCH command for each folder. A sample of a SELECT and FETCH command for the inbox is as follows: C: A003 SELECT ôINBOX" S: * 60 EXISTS Maes Expires - January 2005 [Page 9] July 2004 S: ... more untagged responses with information about the folder S: A003 OK SELECT completed C: A004 FETCH 1:* (FLAGS UID) S: * 1 FETCH (FLAGS (\Answered) UID 120) S: * 2 FETCH (FLAGS (\Seen) UID 121) S: ... flags for messages with message sequence numbers 3-59 S: * 60 FETCH (FLAGS () UID 250) S: A004 OK FETCH completed The client must go through the full list of email messages in each folder. It must download an email message from this list if it is not already on the client. Any changes to the mutable flags a message must be reflected on the server using IMAP STORE command. Also, the client should remove any emails on the client device not in this list. After performing these operations, the client is in sync with the server. <> 3.4.2. Event-based Synchronization Another technique is event-based synchronization. Event-based synchronization is used to keep the client device in sync with the server. This method requires that the client has been fully synchronized with the server at some earlier point. In the IMAPv4Rev1 protocol, the client must perform a state-comparison-based sync when it selects a folder, but then it can use event-based synchronization to keep itself in sync after that. Although event- based synchronization cannot totally replace state-comparison-based synchronization, it is a faster alternative for the client to maintain synchrony when the server is capable of change tracking for a client. In event-based synchronization, the server keeps track of what changes have occurred to the email account that are not yet reflected on the client device. Such a change is called an event. When the client finishes processing all events since the last time it was in sync with the server, it is again in sync with the server. Event- based synchronization is particularly effective when the server can push events to the client for immediate processing. In this case, there are likely to be only a small number of events the client needs to process at one time. Also, when a Lemonade client drops a connection or accidentally disconnects the server can retain the session and cache all events during the time the client is disconnected. When the client reconnects it does not need to perform a state-comparison-based synchronization all over again, and the server sends the list of pending events to the client.. Maes Expires - January 2005 [Page 10] July 2004 Lemonade Mobile Clients and Servers MUST support Lemonade Server to Client Notifications as described in [NOTIFICATIONS]. 3.5. The Server-Side Filtering in Lemonade Profile The Lemonade server MUST support Server-side filtering as described in [NOTIFICATIONS]. 3.6. Lemonade Command Extensions The Lemonade server MUST support the rich set of extra functionality over the IMAP server to support extra features for a mobile client described as Lemonade Command Extensions in [EXTENSIONS]. These include: [1] Compression û Lemonade CS Profile allows for compression of responses to a command. Preliminary testing results shows significant performance results when the response to FETCH FLAGS or header information are compressed. Details are found in [EXTENSIONS]. [2] Sending emails - The Lemonade server can be used to send email, thus eliminating the need for the Lemonade client to connect to a separate SMTP server. When interfacing with a server that supports LEMONADEDELIVER as discovered via CAPABILITY commands as described in [Extensions], this is the mechanism that SHOULD be used. Otherwise, the client is expected to implement the Lemonade Pull Model described in section 2. [3] Support for unstable mobile connections û After a client drops a connection, the Lemonade server can temporarily maintain the session for the mobile client. During this time, the server caches any events concerning the mobile repository while the client is disconnected, which it can then send to the client upon reconnection. This is described in more details in Section 3.7 of this document. [4] Longer periods of inactivity tolerated - A Lemonade server should wait at least 24 hours before logging out an inactive mobile client and ending its session. <> [5] Attachments forward/reply behavior - When forwarding/replying to a message from the Lemonade client, the end user may choose to reattach the original's message attachments by just specifying the UID of the original message and specifiers for the required bodyparts. The client need not download the attachments of the Maes Expires - January 2005 [Page 11] July 2004 original message itself. This is an expected server behavior. It MAY also be implemented following the Lemonade Pull Model. [6] Attachments conversion - The Lemonade server can convert attachments to other formats to be viewed on a mobile device. This is an expected server behavior. [7] PIM - The protocol also provides support for updating personal information on a client device, even when these changes are initiated from another client (i.e. a personal assistant connects to an end userÆs account from a desktop and changes contact information.) These additional uses are especially useful for mobile devices, where end users need up-to-date information on the fly. <> 3.7. Fast Reconnect 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. 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. <> 3.8. HTTP Binding For mobile clients, the Lemonade Profile exchanges MAY be transported on HTTP as described in [HTTPBINDINGS]. 3.9. Revisions to IMAPv4 Rev1 Behavior Maes Expires - January 2005 [Page 12] July 2004 A Lemonade server MUST responds to all IMAPv4Rev1 commands. A compliant Lemonade server must implement all the commands in IMAPv4 Rev1, with the revisions described in [NOTIFICATIONS] and [EXTENSIONS]. Security Considerations Security considerations on the Lemonade Pull Model are discussed throughout section 2. The mobile optimization of the Lemonade profile calls for the same security requirements for an in-response and inband connectivity mode as IMAP. For the outband connectivity mode, servers should use encryption methods for notifications if sensitive information is included in the payload of that notification. When an implementation of Lemonade Mobile Profile is proxy-based, this may create new security issues. These issues are discussed in detail in [EXTENSIONS], because the issues are dependent on the implementation of this protocol rather than inherent to the protocol itself. References [OMA-EN] Open Mobile Alliance Email Notification Version 1.0, August 2002. http://www.openmobilealliance.org/tech/docs/EmailNot/OMA- Push-EMN-V1_0-20020830-C.pdf [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 Maes Expires - January 2005 [Page 13] July 2004 [RFC2420] Kummert, H. "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998. http://www.ietf.org/rfc/rfc2420 [RFC2616] Fielding, R. et al. "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. http://www.ietf.org/rfc/rfc2616 [RFC2617] Franks, J. et al. "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. http://www.ietf.org/rfc/rfc2617 [RFC2683] Leiba, B. "IMAP4 Implementation Recommendations", RFC 2683 Sep 1999. http://www.ietf.org/rfc/rfc2683 [RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997. http://www.ietf.org/rfc/rfc2177 [RFC2818] Rescorla, E. "HTTP over TLS", RFC 2818, May 2000. http://www.ietf.org/rfc/rfc2818 [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-01, (work in progress), January 2004. [BURL] Newman, C., "Message Composition", draft-newman-lemonade- compose-00.txt (work in progress), June 2003. [URLAUTH] Crispin, M. and Newman, C., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", draft-crispin-imap-urlauth- 09.txt, (work in progress), July 2004. [EXTENSIONS] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., "Lemonade Command Extensions", draft-maes-lemonade- command-extensions-00.txt, (work in progress), July 2004. Maes Expires - January 2005 [Page 14] July 2004 [NOTIFICATIONS] Maes, S.H. and Wilson C., "Lemonade Server to Client Notifications", draft-ietf-lemonade-server-to-client- notifications-00.txt, (work in progress), July 2004. [HTTPBINDINGS] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., "Lemonade HTTP Binding", draft-maes-lemonade-http- binding-00.txt, (work in progress), July 2004. [POSTADDRESS] Melnikov, A., "IMAP4 POSTADDRESS extension", work in progress, draft-melnikov-imap-postaddress-XX.txt Acknowledgments This document is based on the work in progress described in draft- crispin-lemonade-pull-01.txt and draft-maes-lemonade-p-imap-03.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 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 Maes Expires - January 2005 [Page 15] July 2004 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 2003. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Maes Expires - January 2005 [Page 16]