Lemonade Working Group B. Leiba Internet-Draft IBM T.J. Watson Research Center Intended status: Standards Track March 7, 2007 Expires: September 8, 2007 Support for Sieve in Internet Message Access Protocol (IMAP4) draft-ietf-lemonade-imap-sieve-02 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 September 8, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Leiba Expires September 8, 2007 [Page 1] Internet-Draft Lemonade-Sieve March 2007 Abstract Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Leiba Expires September 8, 2007 [Page 2] Internet-Draft Lemonade-Sieve March 2007 Note While this document defines extensions to IMAP and Sieve, it is the work of the Lemonade Working Group (Enhancements to Internet email to support diverse service environments), and discussion of it is on the lemonade mailing list at mailto:lemonade@ietf.org. Subscription requests can be sent to mailto:lemonade-request@ietf.org?body=subscribe (send an email message with the word "subscribe" in the body). A WWW archive of back messages is available at http://www.ietf.org/mail-archive/web/lemonade/index.html Leiba Expires September 8, 2007 [Page 3] Internet-Draft Lemonade-Sieve March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Conventions used in this document . . . . . . . . . . . . 6 2. The IMAP "IMAPSieve" Extension . . . . . . . . . . . . . . 7 2.1. The "IMAPSieve" Capability String . . . . . . . . . . . . 7 2.2. Existing IMAP Functions Affected by IMAPSieve . . . . . . 7 2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 7 2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 7 2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7 2.2.5. New or Changed IMAP Message Annotations . . . . . . . . . 8 2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 8 2.3.1. Changes to Manage Sieve or Metadata . . . . . . . . . . . 8 3. Applicable Sieve Actions and Interactions . . . . . . . . 10 3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10 3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10 3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10 3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11 3.5. The Reject Action . . . . . . . . . . . . . . . . . . . . 11 3.6. The Discard Action . . . . . . . . . . . . . . . . . . . . 11 3.7. The Notify Action . . . . . . . . . . . . . . . . . . . . 11 3.8. The Addheader and Deleteheader Actions . . . . . . . . . . 12 3.9. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12 3.10. The Vacation Action . . . . . . . . . . . . . . . . . . . 12 3.11. New Sieve Environment Item: cause . . . . . . . . . . . . 12 3.12. New Sieve Environment Item: mailbox . . . . . . . . . . . 13 3.13. New Sieve Environment Item: changedflags . . . . . . . . . 13 3.14. New Sieve Environment Item: changedannotations . . . . . . 13 3.15. Interaction With Sieve Tests (Comparisons) . . . . . . . . 13 4. Open Issues With This Document . . . . . . . . . . . . . . 14 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 17 7.1. Registration of imapsieve extension . . . . . . . . . . . 17 7.2. Registration of environment item: cause . . . . . . . . . 17 7.3. Registration of environment item: mailbox . . . . . . . . 18 7.4. Registration of environment item: changedflags . . . . . . 18 7.5. Registration of environment item: changedannotations . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . 20 Leiba Expires September 8, 2007 [Page 4] Internet-Draft Lemonade-Sieve March 2007 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.2. Non-Normative References . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . 23 Leiba Expires September 8, 2007 [Page 5] Internet-Draft Lemonade-Sieve March 2007 1. Introduction 1.1. Overview Some applications have a need to apply [Sieve] filters in situations other than initial mail delivery. This is especially true in diverse service environments, such as when the client is sporadically connected, is connected through a high-latency or high-cost channel, or is on a limited-function device. For such clients, it may be very important, for higher performance and reliability, to take advantage of server capabilities, including those provided by Sieve filtering (and Sieve extensions, such as [Notify]). This specification defines extensions to [IMAP] to support the invocation of Sieve scripts at times when the IMAP server creates new messages, or modifies existing ones. It also defines how Sieve scripts will process these invocations. 1.2. 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Keywds]. Leiba Expires September 8, 2007 [Page 6] Internet-Draft Lemonade-Sieve March 2007 2. The IMAP "IMAPSieve" Extension 2.1. The "IMAPSieve" Capability String An IMAP server advertises support for this extension through the capability string "IMAPSieve" (the string is not case-sensitive, and is shown here with this capitalization for readability). A server that advertises IMAPSieve is claiming to be in compliance with this specification in all aspects. 2.2. Existing IMAP Functions Affected by IMAPSieve The subsections below describe in detail the IMAP commands and situations on which IMAPSieve has an effect. Not all Sieve actions make sense in the case of messages affected by IMAP commands. See Section 3 for details. If more than one message is affected at the same time, each message triggers the execution of a Sieve script separately. The scripts MAY be run in parallel. 2.2.1. The IMAP APPEND Command A message may be added to a mailbox through the IMAP APPEND command. In a server that advertises IMAPSieve, new messages added in this way MUST trigger the execution of a Sieve script, subject to the settings defined through Manage Sieve or Metadata (see Section 2.3.1). 2.2.2. The IMAP MULTIAPPEND Command If the IMAP server supports the IMAP [MultiAppend] extension, messages may be added to a mailbox through the IMAP MULTIAPPEND command. In a server that advertises IMAPSieve, new messages added in this way MUST trigger the execution of a Sieve script, as with the APPEND command, also subject to the settings defined through Manage Sieve or Metadata. 2.2.3. The IMAP COPY Command One or more messages may be added to a mailbox through the IMAP COPY command. In a server that advertises IMAPSieve, new messages added in this way MUST trigger the execution of a Sieve script, subject to the settings defined through Manage Sieve or Metadata. 2.2.4. Changes to IMAP Message Flags One or more existing messages can have their flags changed in a number of ways, including: Leiba Expires September 8, 2007 [Page 7] Internet-Draft Lemonade-Sieve March 2007 o The FETCH command (may cause the \Seen flag to be set). o The STORE command (may cause the \Answered, \Deleted, \Draft, \Flagged, and \Seen flags to be set or reset, and may cause keywords to be set or reset). o The invocation of a Sieve script on an existing message, where the Sieve implementation supports the [IMAP4Flags] extension and the script uses one of the actions defined in that extension. In a server that advertises IMAPSieve, messages whose flags are changed in any way (except as explained in the next sentence) MUST trigger the execution of a Sieve script, subject to the settings defined through Manage Sieve or Metadata. The exception is that in order to avoid script loops, flag changes that are made as a result of a script that was itself invoked because of flag changes SHOULD NOT result in another script invocation. In any case, implementations MUST take steps to avoid such loops. 2.2.5. New or Changed IMAP Message Annotations If the IMAP server supports the [Annotate] extension, one or more existing messages can have annotations added or changed through the ANNOTATE command. In a server that advertises IMAPSieve, messages getting new or changed annotations MUST trigger the execution of a Sieve script, subject to the settings defined through Manage Sieve or Metadata. 2.3. New Functions Defined by IMAPSieve 2.3.1. Changes to Manage Sieve or Metadata [[Manage Sieve/Metadata placeholder: This section is a placeholder right now, for changes to the Manage Sieve protocol or the Metadata extension. We'll fill in more detail on the next iteration of this draft.]] Manage Sieve ([Manage]) is a protocol for managing Sieve scripts. We define here an extension to that protocol to support multiple active scripts, each serving a different function. The extension here will allow us to tell the IMAP server which script to use for which mailbox(es) for the conditions described in this document. No Sieve script is invoked for an IMAP condition unless Manage Sieve has defined a script for it, and has "turned on" filtering for a particular mailbox or set of mailboxes. ...or... Leiba Expires September 8, 2007 [Page 8] Internet-Draft Lemonade-Sieve March 2007 Metadata ([Metadata]) is a protocol for including extra information about IMAP servers and mailboxes. We define here an extension to that protocol to add specific information about sieve scripts. Leiba Expires September 8, 2007 [Page 9] Internet-Draft Lemonade-Sieve March 2007 3. Applicable Sieve Actions and Interactions Since some Sieve actions relate specifically to the delivery of mail, not all actions make sense when the messages are created by other means, or when changes are made to data associated with existing messages. This section describes how actions in the base Sieve specification, and those in extensions known at this writing, relate to this specification. In addition to what is specified here, interactions noted in the individual specifications apply, and must be considered. 3.1. The Implicit Keep For all cases that fall under IMAPSieve, the implicit keep means that the message is treated as it would have been if no Sieve script were run. For APPEND, MULTIAPPEND and COPY, the message is stored into the target mailbox normally. For flag or annotation changes, the message is left in the mailbox. 3.2. The Keep Action The keep action is applicable in all cases that fall under IMAPSieve. Its behaviour is as described for implicit keep, in Section 3.1. 3.3. The Fileinto Action If the Sieve implementation supports the fileinto action, that action is applicable in all cases that fall under IMAPSieve. If the [Copy] extension is available and the :copy option is specified, the implicit keep is retained; otherwise, fileinto cancels the implicit keep, as specified in the base Sieve specification. For APPEND, MULTIAPPEND, and COPY, the message is stored into the fileinto mailbox IN ADDITION TO the original target mailbox. For flag or annotation changes, the message is COPIED into the fileinto mailbox, without removing the original. If a keep action is NOT also in effect, the original message is then marked with the \Deleted flag (and a flag-change Sieve script is NOT invoked). The implementation MAY then expunge the original message (WITHOUT expunging other messages in the mailbox), or it MAY choose to have expunges batched, or done by a user. The effect is as though a client had flagged the message and done a UID EXPUNGE (see [UIDPlus]). Handling it this way allows clients to handle messages consistently, and avoids hidden changes that might invalidate their message caches. Leiba Expires September 8, 2007 [Page 10] Internet-Draft Lemonade-Sieve March 2007 3.4. The Redirect Action The redirect action is applicable in all cases that fall under IMAPSieve. It causes the message to be sent, as specified in the base Sieve specification, to the designated address. If the [Copy] extension is available and the :copy option is specified, the implicit keep is retained; otherwise, redirect cancels the implicit keep, as specified in the base Sieve specification. For APPEND, MULTIAPPEND, and COPY, the message is stored into the target mailbox in addition to being redirected. For flag or annotation changes, the message remains in its original mailbox. If a keep action is NOT also in effect, the original message is then marked with the \Deleted flag (and a flag-change Sieve script is NOT invoked). The implementation MAY then expunge the original message (WITHOUT expunging other messages in the mailbox), or it MAY choose to have expunges batched, or done by a user. The effect is as though a client had flagged the message and done a UID EXPUNGE (see [UIDPlus]). Handling it this way allows clients to handle messages consistently, and avoids hidden changes that might invalidate their message caches. 3.5. The Reject Action The reject action is NOT applicable to any case that falls under IMAPSieve. Its use MUST result in an error condition that will terminate the Sieve script. 3.6. The Discard Action The discard action is applicable in all cases that fall under IMAPSieve. For APPEND, MULTIAPPEND, and COPY, the message is first stored into the target mailbox. If a keep action, implicit or explicit, is also in effect, the discard action now does nothing. Otherwise, the original message is then marked with the \Deleted flag (and a flag-change Sieve script is NOT invoked). The implementation MAY then expunge the original message (WITHOUT expunging other messages in the mailbox), or it MAY choose to have expunges batched, or done by a user. The effect is as though a client had flagged the message and done a UID EXPUNGE (see [UIDPlus]). Handling it this way allows clients to handle messages consistently, and avoids hidden changes that might invalidate their message caches. 3.7. The Notify Action If the [Notify] extension is available, the notify action is applicable in all cases that fall under IMAPSieve. The result is Leiba Expires September 8, 2007 [Page 11] Internet-Draft Lemonade-Sieve March 2007 that the requested notification is sent, and that the message is otherwise handled as it would normally have been. 3.8. The Addheader and Deleteheader Actions Even if the [EditHeader] extension is available, since messages in IMAP mailboxes are immutable these actions are NOT applicable. Using them for flag or annotation changes to existing messages would cause the message to be changed. Using them for APPEND, MULTIAPPEND, and COPY would cause unexpected differences in the stored copy as compared to what the client expected, and would make the client's message cache invalid unexpectedly. Use of these MUST result in an error condition that will terminate the Sieve script. 3.9. The Setflag, Deleteflag, and Removeflag Actions If the [IMAP4Flags] extension is available, the actions associated with it are all applicable to any case that falls under IMAPSieve. It is worth noting also that the "hasflag" test that is defined in the IMAP4Flags extension might be particularly useful in scripts triggered by flag changes. The flag changes behave as though a client had made the change. As explained above, in order to avoid script loops flag changes that are made as a result of a script that was itself invoked because of flag changes SHOULD NOT result in another script invocation. In any case, implementations MUST take steps to avoid such loops. 3.10. The Vacation Action Even if the [Vacation] extension is available, the vacation action is NOT applicable to any case that falls under IMAPSieve. Its use MUST result in an error condition that will terminate the Sieve script. 3.11. New Sieve Environment Item: cause Implementations MAY invoke different Sieve scripts for the different conditions described in this document (append, copy, flag changes, annotation changes). If the actions to be taken are common, and the implementation supports the [Include] extension, the common script code can be included as specified there. It may be preferable, though, to use a single script for all these conditions. To support that, if the [Environment] extension is available, the implementation MUST set the environment item "cause", which contains the name of the action that caused the script to be invoked. Its value is one of the following: Leiba Expires September 8, 2007 [Page 12] Internet-Draft Lemonade-Sieve March 2007 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) o COPY (for invocations resulting from COPY) o FLAG (for invocations resulting from flag changes) o ANNOTATE (for invocations resulting from new or changed annotations) 3.12. New Sieve Environment Item: mailbox If the [Environment] extension is available, the implementation MUST set the environment item "mailbox" to the name of the mailbox that the affected message is in, in the case of existing messages, or is targeted to be stored into, in the case of new messages. The value of this item is fixed when the script begins, and, in particular, MUST NOT change as a result of any action, such as "fileinto". 3.13. New Sieve Environment Item: changedflags If the [Environment] extension is available, the [IMAP4Flags] extension is available, AND the script was invoked because of flag changes to an existing message, the implementation MUST set the environment item "changedflags" to the name(s) of the flag(s) that have changed. If the script was not invoked because of flag changes, the value of this item MUST be the empty string. The script will not know from this item whether the flags have been set or reset, but it can use the "hasflag" test to determine the current value. See example 2 in Section 5 for an example of how this might be used. 3.14. New Sieve Environment Item: changedannotations If the [Environment] extension is available, the [Annotate] extension is available, AND the script was invoked because of annotation changes to an existing message, the implementation MUST set the environment item "changedannotations" to the name(s) of the annotation(s) that have changed. If the script was not invoked because of annotation changes, the value of this item MUST be the empty string. 3.15. Interaction With Sieve Tests (Comparisons) This extension does not affect the operation of any tests or comparisons. Leiba Expires September 8, 2007 [Page 13] Internet-Draft Lemonade-Sieve March 2007 4. Open Issues With This Document When this section is empty, I guess we're done.... 1. The Manage Sieve/Metadata changes need to be specified. 2. All of the extensions that we describe how to work with: are they normative, or non-normative references? 3. Can anyone come up with some examples that use only features from the base Sieve spec? Leiba Expires September 8, 2007 [Page 14] Internet-Draft Lemonade-Sieve March 2007 5. Examples Example 1: If a new message is added to the "ActionItems" mailbox, a copy is sent to the address "actionitems@example.com". require ["copy", "variables"]; if anyof (environment :is "cause" "APPEND", environment :is "cause" "COPY") { if environment :is "mailbox" "ActionItems" { redirect :copy "actionitems@example.com"; } } Example 2: If the script is called for any message with the \Flagged flag set (tested through the [IMAP4Flags] extension), a notification is sent using the [Notify] extension. No notification will be sent, though, if we're called with an existing message that already had that flag set. require ["nofity", "imap4flags", "variables"]; if allof (hasflag "\\Flagged", not environment :contains "changedflags" "\\Flagged") { notify :message "Important message in ${IMAPSieve.mailbox}"; } Example 3: [[More examples?: Can anyone come up with some examples that use only features from the base Sieve spec?]] Leiba Expires September 8, 2007 [Page 15] Internet-Draft Lemonade-Sieve March 2007 6. Security Considerations It is possible to introduce script processing loops by having a Sieve script that is triggered by flag changes use the actions defined in the [IMAP4Flags] extension. Implementations MUST take steps to prevent such loops. One way to avoid this problem is that if a script is invoked by flag changes, and that script further changes the flags, those flag changes SHOULD NOT trigger a Sieve script invocation. Other security considerations are discussed in [IMAP], and [Sieve], as well as in some of the other extension documents. Leiba Expires September 8, 2007 [Page 16] Internet-Draft Lemonade-Sieve March 2007 7. IANA Considerations 7.1. Registration of imapsieve extension The following template specifies the IANA registration of the Sieve extension specified in this document: To: iana@iana.org Subject: Registration of new Sieve extension Capability name: imapsieve Capability keyword: imapsieve Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: this RFC Person and email address to contact for further information: Barry Leiba This information should be added to the list of sieve extensions given on http://www.iana.org/assignments/sieve-extensions. 7.2. Registration of environment item: cause The following template specifies the IANA registration of a sieve environment item specified in this document: To: iana@iana.org Subject: Registration of new Sieve environment item Item name: cause Description: The name of the action that caused the script to be invoked. Its value is one of the following: o APPEND (for invocations resulting from APPEND or MULTIAPPEND) o COPY (for invocations resulting from COPY) o FLAG (for invocations resulting from flag changes) o ANNOTATE (for invocations resulting from new or changed annotations) RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve environment item names given in the [Environment] extension. Leiba Expires September 8, 2007 [Page 17] Internet-Draft Lemonade-Sieve March 2007 7.3. Registration of environment item: mailbox The following template specifies the IANA registration of a sieve environment item specified in this document: To: iana@iana.org Subject: Registration of new Sieve environment item Item name: mailbox Description: The name of the mailbox that the affected message is in, in the case of existing messages, or is targeted to be stored into, in the case of new messages. The value of this item is fixed when the script begins, and, in particular, MUST NOT change as a result of any action, such as "fileinto". RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve environment item names given in the [Environment] extension. 7.4. Registration of environment item: changedflags The following template specifies the IANA registration of a sieve environment item specified in this document: To: iana@iana.org Subject: Registration of new Sieve environment item Item name: changedflags Description: If the script was invoked because of flag changes to an existing message, this contains the name(s) of the flag(s) that have changed. Otherwise, the value of this item MUST be the empty string. RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve environment item names given in the [Environment] extension. 7.5. Registration of environment item: changedannotations The following template specifies the IANA registration of a sieve environment item specified in this document: To: iana@iana.org Subject: Registration of new Sieve environment item Item name: changedannotations Description: If the script was invoked because of annotation changes to an existing message, this contains the name(s) of the Leiba Expires September 8, 2007 [Page 18] Internet-Draft Lemonade-Sieve March 2007 annotation(s) that have changed. Otherwise, the value of this item MUST be the empty string. RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve environment item names given in the [Environment] extension. Leiba Expires September 8, 2007 [Page 19] Internet-Draft Lemonade-Sieve March 2007 8. References 8.1. Normative References [Environment] Freed, N., "Sieve Email Filtering: Environment and Ihave Extensions", work in progress, draft-freed-sieve-environment-ihave-00, November 2006. [IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. [Keywds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [Manage] Martin, T. and A. Melnikov, Ed., "A Protocol for Remotely Managing Sieve Scripts", work in progress, draft-martin-managesieve-07, November 2006. [Metadata] Daboo, C., "IMAP METADATA Extension", work in progress, draft-daboo-imap-annotatemore-11, February 2007. [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", IESG Evaluation, draft-ietf-sieve-3028bis-12, February 2007. 8.2. Non-Normative References [Annotate] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", RFC Editor Queue, draft-ietf-imapext-annotate-16, August 2006. [Copy] Degener, J., "Sieve Extension: Copying Without Side Effects", RFC 3894, October 2004. [EditHeader] Degener, J. and P. Guenther, "Sieve Email Filtering: Editheader Extension", work in progress, draft-ietf-sieve-editheader-07, November 2006. [IMAP4Flags] Melnikov, A., "Sieve Mail Filtering Language: IMAP flag Extension", RFC Editor Queue, draft-ietf-sieve-imapflags-05, May 2006. [Include] Daboo, C., "SIEVE Email Filtering: Include Extension", Leiba Expires September 8, 2007 [Page 20] Internet-Draft Lemonade-Sieve March 2007 work in progress, draft-daboo-sieve-include-05, June 2006. [MultiAppend] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003. [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Martin, "Sieve Extension: Notifications", work in progress, draft-ietf-sieve-notify-07, February 2007. [UIDPlus] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS Extension", RFC 4315, December 2005. [Vacation] Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: Vacation Extension", RFC Editor Queue, draft-ietf-sieve-vacation-06, February 2006. Leiba Expires September 8, 2007 [Page 21] Internet-Draft Lemonade-Sieve March 2007 Author's Address Barry Leiba IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US Phone: +1 914 784 7941 Email: leiba@watson.ibm.com Leiba Expires September 8, 2007 [Page 22] Internet-Draft Lemonade-Sieve March 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). Leiba Expires September 8, 2007 [Page 23]