Lemonade Working Group B. Leiba
Internet-Draft IBM T.J. Watson Research Center
Expires: June 21, 2006 December 18, 2005
Support for Sieve in Internet Message Access Protocol (IMAP4)
draft-ietf-lemonade-imap-sieve-00
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 June 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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).
Note
Leiba Expires June 21, 2006 [Page 1]
Internet-Draft Lemonade-Sieve December 2005
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 June 21, 2006 [Page 2]
Internet-Draft Lemonade-Sieve December 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Conventions used in this document . . . . . . . . . . . . . 5
2. The IMAP "IMAPSieve" Extension . . . . . . . . . . . . . . . 6
2.1 The "IMAPSieve" Capability String . . . . . . . . . . . . . 6
2.2 Existing IMAP Functions Affected by IMAPSieve . . . . . . . 6
2.2.1 The IMAP APPEND Command . . . . . . . . . . . . . . . . . . 6
2.2.2 The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . . 6
2.2.3 The IMAP COPY Command . . . . . . . . . . . . . . . . . . . 6
2.2.4 Changes to IMAP Message Flags . . . . . . . . . . . . . . . 6
2.2.5 New or Changed IMAP Message Annotations . . . . . . . . . . 7
2.3 New IMAP Functions Defined by IMAPSieve . . . . . . . . . . 7
2.3.1 The IMAP SIEVEFILTER Command . . . . . . . . . . . . . . . . 7
3. Applicable Sieve Actions and Interactions . . . . . . . . . 9
3.1 The Implicit Keep . . . . . . . . . . . . . . . . . . . . . 9
3.2 The Keep Action . . . . . . . . . . . . . . . . . . . . . . 9
3.3 The Fileinto Action . . . . . . . . . . . . . . . . . . . . 9
3.4 The Redirect Action . . . . . . . . . . . . . . . . . . . . 10
3.5 The Reject Action . . . . . . . . . . . . . . . . . . . . . 10
3.6 The Discard Action . . . . . . . . . . . . . . . . . . . . . 10
3.7 The Notify Action . . . . . . . . . . . . . . . . . . . . . 10
3.8 The Addheader and Deleteheader Actions . . . . . . . . . . . 10
3.9 The Setflag, Deleteflag, and Removeflag Actions . . . . . . 11
3.10 The Vacation Action . . . . . . . . . . . . . . . . . . . . 11
3.11 New Sieve Variable: IMAPSieve.cause . . . . . . . . . . . . 11
3.12 New Sieve Variable: IMAPSieve.mailbox . . . . . . . . . . . 12
3.13 New Sieve Variable: IMAPSieve.changed.flags . . . . . . . . 12
3.14 New Sieve Variable: IMAPSieve.changed.annotations . . . . . 12
3.15 Interaction With Sieve Tests (Comparisons) . . . . . . . . . 12
4. Open Issues With This Document . . . . . . . . . . . . . . . 13
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
9.2 Non-Normative References . . . . . . . . . . . . . . . . . . 18
Leiba Expires June 21, 2006 [Page 3]
Internet-Draft Lemonade-Sieve December 2005
Author's Address . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20
Leiba Expires June 21, 2006 [Page 4]
Internet-Draft Lemonade-Sieve December 2005
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 June 21, 2006 [Page 5]
Internet-Draft Lemonade-Sieve December 2005
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
specified with the SIEVEFILTER command (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 specified with the
SIEVEFILTER command.
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 specified with the SIEVEFILTER command.
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 June 21, 2006 [Page 6]
Internet-Draft Lemonade-Sieve December 2005
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.
o [[Flags-Others?: Are there other ways?]]
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
specified with the SIEVEFILTER command. 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
[[Annotate?: Do we want this to apply to annotate too? If so, does
that make annotate a normative reference?]]
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 specified with the SIEVEFILTER
command.
2.3 New IMAP Functions Defined by IMAPSieve
2.3.1 The IMAP SIEVEFILTER Command
[[Do we need this?: I'm not sure whether we need this command, but
I've put it here as a placeholder, and to start discussion. It may
be that it's OK for all modifications to result in calls to the a
Sieve filter, to have the filter designated elsewhere, and to have
the filter decide what to handle and what to ignore.]]
The SIEVEFILTER command is a command that we might need in order to
tell the IMAP server which script to use for which mailbox(es). If
we decide we need this, the idea would be that no Sieve script is
invoked unless this command sets it up, and the command would "turn
on" filtering for a particular mailbox, or set of mailboxes.
Leiba Expires June 21, 2006 [Page 7]
Internet-Draft Lemonade-Sieve December 2005
SIEVEFILTER Command
Arguments: to be defined
Responses: to be defined
Result: OK - command completed, filtering controls updated.
NO - failure: the server was unable to complete the
command and update the filtering controls.
BAD - command unknown (not supported, or invalid in this
state), or arguments invalid.
Leiba Expires June 21, 2006 [Page 8]
Internet-Draft Lemonade-Sieve December 2005
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 specified 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.
If a keep action, implicit or explicit, is also in effect, 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, for APPEND, MULTIAPPEND, and
COPY, the message is stored into the fileinto mailbox INSTEAD OF in
the original target mailbox. For flag or annotation changes, the
message is MOVED, as an atomic operation, into the fileinto mailbox.
This MUST happen as an atomic operation, and MUST NOT be done by
copying the message and setting the \Deleted flag for the original.
Leiba Expires June 21, 2006 [Page 9]
Internet-Draft Lemonade-Sieve December 2005
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.
If a keep action, implicit or explicit, is also in effect, 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, for APPEND, MULTIAPPEND, and
COPY, the message is NOT stored into the target mailbox. For flag or
annotation changes, the message is REMOVED, as an atomic operation,
from the mailbox. This MUST happen as an atomic operation, and MUST
NOT be done by setting the \Deleted flag for the message.
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. If a keep action, implicit or explicit, is also in
effect, the discard action does nothing. Otherwise, for APPEND,
MULTIAPPEND, and COPY, the message is NOT stored into the target
mailbox. For flag or annotation changes, the message is REMOVED, as
an atomic operation, from the mailbox. This MUST happen as an atomic
operation, and MUST NOT be done by setting the \Deleted flag for the
message.
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
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
If the [EditHeader] extension is available, the addheader and
deleteheader actions are applicable for NEW MESSAGES ONLY (messages
Leiba Expires June 21, 2006 [Page 10]
Internet-Draft Lemonade-Sieve December 2005
created by APPEND, MULTIAPPEND, and COPY). The requested header
changes are made to the new message before it is stored into the
target mailbox.
Since messages in IMAP mailboxes are immutable, these actions are NOT
applicable in the case of flag or annotation changes to existing
messages. If a script uses addheader or deleteheader in these cases,
the action MUST have no effect (and MUST NOT generate an error
condition).
[[editheader No Effect?: Is this what we want, or should it be an
error?]]
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.
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 Variable: IMAPSieve.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 [Variables] extension is
available, the implementation MUST set the reserved variable
"${IMAPSieve.cause}", which contains 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)
Leiba Expires June 21, 2006 [Page 11]
Internet-Draft Lemonade-Sieve December 2005
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 Variable: IMAPSieve.mailbox
If the [Variables] extension is available, the implementation MUST
set the reserved variable "${IMAPSieve.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 variable 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 Variable: IMAPSieve.changed.flags
If the [Variables] 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 reserved
variable "${IMAPSieve.changed.flags}" to the name(s) of the flag(s)
that have changed. If the script was not invoked because of flag
changes, this variable MUST be unknown (and, thus, its value MUST be
the empty string). The script will not know from this variable
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 Variable: IMAPSieve.changed.annotations
If the [Variables] 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
reserved variable "${IMAPSieve.changed.annotations}" to the name(s)
of the annotation(s) that have changed. If the script was not
invoked because of annotation changes, this variable MUST be unknown
(and, thus, its value 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 June 21, 2006 [Page 12]
Internet-Draft Lemonade-Sieve December 2005
4. Open Issues With This Document
When this section is empty, I guess we're done....
1. Do we need the SIEVEFILTER command? If so, exactly what should
it do?
2. If EditHeader stuff is used with FLAG or ANNOTATE, should it be
ignored or should it be an error?
3. If the reject action is used at all, should it be ignored or
should it be an error? Same question for other inappropriate
actions.
4. Requirement to Variables extension: We should probably generalize
the "cause" variable, and require it for all Sieve invocations.
Normal delivery situations can have the value "DELIVERY".
Otherwise, it's awkward to write a script that has to assume
something about the ABSENCE of a "cause" variable.
5. Requirement to Variables document: There should be an example of
a variable with a namespace attribute.
6. Do we need any more reserved Sieve variables for this? Do we
have too many?
7. All of the extensions that we describe how to work with: are they
normative, or non-normative references?
8. Can anyone come up with some examples that use only features from
the base Sieve spec?
Leiba Expires June 21, 2006 [Page 13]
Internet-Draft Lemonade-Sieve December 2005
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 (${IMAPSieve.cause} :is "APPEND",
${IMAPSieve.cause} :is "COPY") {
if ${IMAPSieve.mailbox} :is "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 ${IMAPSieve.changed.flags} :contains "\\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 June 21, 2006 [Page 14]
Internet-Draft Lemonade-Sieve December 2005
6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [ABNF]. Non-terminals referenced
but not defined below are as defined by [IMAP].
[[Maybe...: If we decide we need this command, the syntax goes
here.]]
command_auth =/ sievefilter
; Valid only in Authenticated or Selected state
sievefilter = "SIEVEFILTER" to be defined
Leiba Expires June 21, 2006 [Page 15]
Internet-Draft Lemonade-Sieve December 2005
7. 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 June 21, 2006 [Page 16]
Internet-Draft Lemonade-Sieve December 2005
8. IANA Considerations
[[IANA?: Do we need this, since there's not actually a Sieve
capability defined here?]]
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 <leiba@watson.ibm.com>
This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions.
Leiba Expires June 21, 2006 [Page 17]
Internet-Draft Lemonade-Sieve December 2005
9. References
9.1 Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[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.
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", work in
progress, draft-ietf-sieve-3028bis, November 2005.
9.2 Non-Normative References
[Annotate]
Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", work
in progress, draft-ietf-imapext-annotate, November 2005.
[Copy] Degener, J., "Sieve Extension: Copying Without Side
Effects", RFC 3894, October 2004.
[]
Degener, J. and P. Guenther, "Sieve Email Filtering:
Editheader Extension", work in
progress, draft-ietf-sieve-editheader, October 2005.
[IMAP4Flags]
Melnikov, A., "Sieve Mail Filtering Language: IMAP flag
Extension", work in progress, draft-ietf-sieve-imapflags,
October 2005.
[Include] Daboo, C., "SIEVE Email Filtering: Include Extension",
work in progress, draft-daboo-sieve-include, August 2005.
[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, December 2005.
[Vacation]
Leiba Expires June 21, 2006 [Page 18]
Internet-Draft Lemonade-Sieve December 2005
Showalter, T. and N. Freed, Ed., "Sieve Email Filtering:
Vacation Extension", work in
progress, draft-ietf-sieve-vacation, October 2005.
[Variables]
Homme, K., "Sieve Extension: Variables", work in
progress, draft-ietf-sieve-variables, October 2005.
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 June 21, 2006 [Page 19]
Internet-Draft Lemonade-Sieve December 2005
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.
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 (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Leiba Expires June 21, 2006 [Page 20]
