draft-ietf-sieve-imapflags-02.txt   draft-ietf-sieve-imapflags-03.txt 
Network Working Group Network Working Group
Internet Draft: Sieve -- IMAP flag Extension A. Melnikov Internet Draft: Sieve -- IMAP flag Extension A. Melnikov
Document: draft-ietf-sieve-imapflags-02.txt Isode Limited Document: draft-ietf-sieve-imapflags-03.txt Isode Limited
Expires: April 2006 October 2005 Expires: July 2006 January 2006
Sieve Mail Filtering Language: IMAP flag Extension SIEVE Email Filtering: IMAP flag Extension
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 30 skipping to change at line 30
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
The protocol discussed in this document is experimental and subject
to change. Persons planning on either implementing or using this
protocol are STRONGLY URGED to get in touch with the author before
embarking on such a project.
Copyright
Copyright (C) The Internet Society 2005. All Rights Reserved.
Abstract Abstract
Recent discussions have shown that it is desirable to set different Recent discussions have shown that it is desirable to set different
[IMAP] flags on message delivery. This can be done, for example, [IMAP] flags on message delivery. This can be done, for example,
by a Sieve interpreter that works as a part of a Mail Delivery by a Sieve interpreter that works as a part of a Mail Delivery
Agent. Agent.
This document describes an extension to the Sieve mail filtering This document describes an extension to the Sieve mail filtering
language for setting [IMAP] flags. The extension allows to set both language for setting [IMAP] flags. The extension allows to set both
[IMAP] system flags and [IMAP] keywords. [IMAP] system flags and [IMAP] keywords.
skipping to change at line 144 skipping to change at line 135
2. Added dependency on Sieve "variables" extension. 2. Added dependency on Sieve "variables" extension.
3. Several editorial comments from Matthew Elvey. 3. Several editorial comments from Matthew Elvey.
4. Removed "mark" and "unmark" actions. 4. Removed "mark" and "unmark" actions.
5. Added "hasflag" test. 5. Added "hasflag" test.
6. Dropped ":globalflags" 6. Dropped ":globalflags"
7. An invalid flag name doesn't cause a script execution failure anymore, 7. An invalid flag name doesn't cause a script execution failure
as imapflags now depends on variables and a variable can have an arbitrary anymore, as imapflags now depends on variables and a variable
value. can have an arbitrary value.
0.9. Changes from the revision 06 (now draft-ietf-sieve-imapflags-00.txt) 0.9. Changes from the revision 06 (draft-ietf-sieve-imapflags-00.txt)
1. Updated boilerplate and references. 1. Updated boilerplate and references.
2. Fixed capability string in the extended example. 2. Fixed capability string in the extended example.
3. Improved implementation using macros (section 6). 3. Improved implementation using macros (section 6).
0.10. Changes from draft-ietf-sieve-imapflags-00.txt 0.10. Changes from draft-ietf-sieve-imapflags-00.txt
1. Added back the internal variable, made the variable parameter to all 1. Added back the internal variable, made the variable parameter
actions optional. to all actions optional.
2. Some editorial suggestions from Mark E. Mallett. 2. Some editorial suggestions from Mark E. Mallett.
3. Updated boilerplate once again. 3. Updated boilerplate once again.
0.11. Changes from draft-ietf-sieve-imapflags-01.txt 0.11. Changes from draft-ietf-sieve-imapflags-01.txt
1. Clarified that if "variables" is not available, then usage of 1. Clarified that if "variables" is not available, then usage of
the explicit variable parameter causes a runtime error. the explicit variable parameter causes a runtime error.
2. Clarified handling of spaces, in particular that leading/ 2. Clarified handling of spaces, in particular that leading/
trailing spaces in a flag variable are to be ignored. trailing spaces in a flag variable are to be ignored.
3. Clarified that the extension can't be used to set the \Recent flag. 3. Clarified that the extension can't be used to set the \Recent
flag.
4. Made the variable list parameter to hasflag test optional, for 4. Made the variable list parameter to hasflag test optional, for
consistency with all actions. consistency with all actions.
5. Dropped the "Implementation Notes" section. 5. Dropped the "Implementation Notes" section.
6. Fixed an error in section 5: when the :flags tagged argument is not 6. Fixed an error in section 5: when the :flags tagged argument is
specified, the correct behavior is to use flags from the internal not specified, the correct behavior is to use flags from the
variable. internal variable.
7. Other minor editorial changes. 7. Other minor editorial changes.
0.12. Changes from draft-ietf-sieve-imapflags-02.txt
1. Changed "Syntax:" label to "Usage:".
2. Updated the Introduction section to mention that hasflag also has
an optional parameter.
3. Clarified that a failure to store flags for a message is not
a runtime error.
4. Minor editorial nits from Philip
1. Introduction 1. Introduction
This is an extension to the Sieve language defined by [SIEVE] for This is an extension to the Sieve language defined by [SIEVE] for
setting [IMAP] flags. It adds a new tagged argument to "keep" and setting [IMAP] flags. It adds a new tagged argument to "keep" and
"fileinto" that describes the list of flags that have to be set "fileinto" that describes the list of flags that have to be set
when the message is delivered to the specified mailbox. It also when the message is delivered to the specified mailbox. It also
adds several actions to help manipulate list of flags and a test adds several actions to help manipulate list of flags and a test
to check if a flag belongs to a list. to check if a flag belongs to a list.
Sieve interpreters that don't support integration with IMAP SHOULD
ignore this extension.
The capability string associated with extension defined in this The capability string associated with extension defined in this
document is "imap4flags". document is "imap4flags".
The "imap4flags" extension can be used with or without the "variables" The "imap4flags" extension can be used with or without the
extension [VARIABLES]. When the "variables" extension is enabled in "variables" extension [VARIABLES]. When the "variables" extension
a script using <require "variables">, the script can use explicit is enabled in a script using <require "variables">, the script can
variable names in setflag/addflag/removeflag actions. See also section use explicit variable names in setflag/addflag/removeflag actions
3 for more details. When the "variables" extension is not enabled and hasflag test. See also section 3 for more details. When the
the explicit variable name parameter to setflag/addflag/removeflag "variables" extension is not enabled the explicit variable name
MUST NOT be used and MUST cause an error according to [SIEVE]. parameter to setflag/addflag/removeflag/hasflag MUST NOT be used
and MUST cause an error according to [SIEVE].
2. Conventions used. 2. Conventions used.
Conventions for notations are as in [SIEVE] section 1.1, including Conventions for notations are as in [SIEVE] section 1.1, including
use of [KEYWORDS] and "Syntax:" label for the definition of action use of [KEYWORDS] and "Usage:" label for the definition of action
and tagged arguments syntax. and tagged arguments syntax.
2.1. General requirements for flag handling 2.1. General requirements for flag handling
The following notes apply to processing of Addflag and Removeflag actions, The following notes apply to processing of Addflag and Removeflag
hasflag test and :flags tagged argument. actions, hasflag test and :flags tagged argument.
A Sieve interpreter MUST ignore empty strings (i.e. "") in a list-of-flags A Sieve interpreter MUST ignore empty strings (i.e. "") in a
parameter. list-of-flags parameter.
The Sieve interpreter SHOULD check the list of flags for validity as The Sieve interpreter SHOULD check the list of flags for validity as
described by [IMAP] ABNF. In particular non-ASCII characters are not described by [IMAP] ABNF. In particular non-ASCII characters are not
allowed in flag names. However spaces MUST be always allowed. Multiple allowed in flag names. However spaces MUST be always allowed.
spaces between flag names MUST be treated as a single space character, Multiple spaces between flag names MUST be treated as a single space
leading and trailing spaces MUST be ignored. character, leading and trailing spaces MUST be ignored.
A string containing a space-separated list of flags is equivalent to a A string containing a space-separated list of flags is equivalent to
string list consisting of the flags. The last requirement is to simplify a string list consisting of the flags. The last requirement is to
amalgamation of multiple flag lists. simplify amalgamation of multiple flag lists.
If a flag validity check fails the flag MUST be ignored. If a flag validity check fails the flag MUST be ignored.
Note that it is not possible to use this extension to set or clear the Note that it is not possible to use this extension to set or clear
\Recent flag or any other special system flag which is not settable the \Recent flag or any other special system flag which is not
in [IMAP]. Any such flags MUST be ignored if included in a flag list. settable in [IMAP]. Any such flags MUST be ignored if included in
a flag list.
3. Actions 3. Actions
All actions described in this specification (setflag, addflag, removeflag) All actions described in this specification (setflag, addflag,
operate on string variables that contain a set of [IMAP] flags. removeflag) operate on string variables that contain a set of [IMAP]
On variable substitution a set of flags is represented as a string flags. On variable substitution a set of flags is represented as
containing space-separated list of flag names. a string containing space-separated list of flag names.
Any of setflag/addflag/removeflag action MAY alter the flag list in any Any of setflag/addflag/removeflag action MAY alter the flag list in
way that leaves its semantics as a set of case-insensitive words unaltered. any way that leaves its semantics as a set of case-insensitive words
For example, it may reorder the flags, alter the case of the letters in unaltered. For example, it may reorder the flags, alter the case of
them, or add or remove duplicates or extraneous spaces. Scripts the letters in them, or add or remove duplicates or extraneous
MUST NOT make assumptions about the ordering of flags in lists or spaces. Scripts MUST NOT make assumptions about the ordering of
the preservation of their case. flags in lists or the preservation of their case.
Note that the parameter specifying a variable name to setflag/addflag/ Note that the parameter specifying a variable name to setflag/
removeflag actions and the hasflag test is optional. If the parameter addflag/removeflag actions and the hasflag test is optional. If the
is not specified the actions operate on the internal variable, which parameter is not specified the actions operate on the internal
has the empty value when the script starts execution. If the SIEVE variable, which has the empty value when the script starts execution.
interpreter doesn't support the "variables" extension [VARIABLES], If the SIEVE interpreter doesn't support the "variables" extension
the present variable name parameter MUST cause runtime error. [VARIABLES], the present variable name parameter MUST cause runtime
error.
The "addflag" action adds flags to an existing set. The "removeflag" The "addflag" action adds flags to an existing set. The "removeflag"
action removes flags from an existing set. The "setflag" action action removes flags from an existing set. The "setflag" action
replaces an existing set of flags with a new set. The "set" action replaces an existing set of flags with a new set. The "set" action
defined in [VARIABLES] can be used to replace an existing set of flags defined in [VARIABLES] can be used to replace an existing set of
with a new set as well. However it should be noted that the "set" flags with a new set as well. However it should be noted that the
action can't perform any flag reordering, duplicate elimination, etc. "set" action can't perform any flag reordering, duplicate
elimination, etc.
The :flags tagged argument to "keep" and "fileinto" The :flags tagged argument to "keep" and "fileinto"
actions is used to associate a set of flags referenced by a variable actions is used to associate a set of flags
with the current message. If the :flags tagged argument is not specified with the current message. If the :flags tagged argument is not
with those 2 actions, the current value of the internal variable is used specified with those 2 actions, the current value of the internal
instead. The value also applies to the implicit keep. variable is used instead. The value also applies to the implicit
keep.
Note that when keep/fileinto is used multiple times in a script and Note that when keep/fileinto is used multiple times in a script and
duplicate message elimination is performed, the last flag list value MUST duplicate message elimination is performed, the last flag list value
win. MUST win.
3.1. Setflag Action 3.1. Setflag Action
Syntax: setflag [<variablename: string>] <list-of-flags: string-list> Usage: setflag [<variablename: string>]
<list-of-flags: string-list>
Setflag is used for setting [IMAP] system flags or keywords. Setflag is used for setting [IMAP] system flags or keywords.
Setflag replaces any previously set flags. Setflag replaces any previously set flags.
Example: if size :over 500K { Example: if size :over 500K {
setflag "flags" "\\Deleted"; setflag "flags" "\\Deleted";
} }
A more substantial example is: A more substantial example is:
Example: Example:
if header :contains "from" "boss@frobnitzm.example.edu" { if header :contains "from" "boss@frobnitzm.example.edu" {
setflag "flagvar" "\\Flagged"; setflag "flagvar" "\\Flagged";
fileinto :flags "${flagvar}" "INBOX.From Boss"; fileinto :flags "${flagvar}" "INBOX.From Boss";
} }
3.2. Addflag action 3.2. Addflag action
Syntax: addflag [<variablename: string>] <list-of-flags: string-list> Usage: addflag [<variablename: string>]
<list-of-flags: string-list>
Addflag is used to add flags to a list of [IMAP] flags. It doesn't Addflag is used to add flags to a list of [IMAP] flags. It doesn't
replace any previously set flags. This means that multiple occurrences replace any previously set flags. This means that multiple
of addflag are treated additively. occurrences of addflag are treated additively.
The following examples demonstrate requirements described in 2.1. The following examples demonstrate requirements described in 2.1.
The following two actions The following two actions
addflag "flagvar" "\\Deleted"; addflag "flagvar" "\\Deleted";
addflag "flagvar" "\\Answered"; addflag "flagvar" "\\Answered";
produce the same result as the single action produce the same result as the single action
addflag "flagvar" ["\\Deleted", "\\Answered"]; addflag "flagvar" ["\\Deleted", "\\Answered"];
skipping to change at line 323 skipping to change at line 331
or or
addflag "flagvar" "\\Deleted \\Answered"; addflag "flagvar" "\\Deleted \\Answered";
or or
addflag "flagvar" "\\Answered \\Deleted"; addflag "flagvar" "\\Answered \\Deleted";
3.3. Removeflag Action 3.3. Removeflag Action
Syntax: removeflag [<variablename: string>] <list-of-flags: string-list> Usage: removeflag [<variablename: string>]
<list-of-flags: string-list>
Removeflag is used to remove flags from a list of [IMAP] flags. Removeflag is used to remove flags from a list of [IMAP] flags.
Removeflag clears flags previously set by "set"/"addflag". Calling Removeflag clears flags previously set by "set"/"addflag". Calling
removeflag with a flag that wasn't set before is not an error and removeflag with a flag that wasn't set before is not an error and
is ignored. Note, that if an implementation doesn't perform automatic is ignored. Note, that if an implementation doesn't perform automatic
duplicate elimination, it MUST remove all occurences of the flags duplicate elimination, it MUST remove all occurences of the flags
specified in the second parameter to removeflag. Empty strings in the specified in the second parameter to removeflag. Empty strings in the
list-of-flags MUST be ignored. Also note, that flag names are list-of-flags MUST be ignored. Also note, that flag names are
case-insensitive, as described in [IMAP]. case-insensitive, as described in [IMAP].
Multiple removeflag actions are treated additively. Multiple removeflag actions are treated additively.
Example: Example:
if header :contains "Disposition-Notification-To" "mel@example.com" { if header :contains "Disposition-Notification-To"
"mel@example.com" {
addflag "flagvar" "$MDNRequired"; addflag "flagvar" "$MDNRequired";
} }
if header :contains "from" "imap@cac.washington.example.edu" { if header :contains "from" "imap@cac.washington.example.edu" {
removeflag "flagvar" "$MDNRequired"; removeflag "flagvar" "$MDNRequired";
fileinto :flags "${flagvar}" "INBOX.imap-list"; fileinto :flags "${flagvar}" "INBOX.imap-list";
} }
4. Test hasflag 4. Test hasflag
Syntax: hasflag [MATCH-TYPE] Usage: hasflag [MATCH-TYPE] [<variable-list: string-list>]
[<variable-list: string-list>] <list-of-flags: string-list> <list-of-flags: string-list>
The "hasflag" test evaluates to true if any of the variables matches any The "hasflag" test evaluates to true if any of the variables matches
flag name. The type of match defaults to ":is". any flag name. The type of match defaults to ":is".
If the list of variables is omitted, value of the internal variable is If the list of variables is omitted, value of the internal variable
used instead. is used instead.
Flagname comparisons is always done with the "i;ascii-casemap" operator, Flagname comparisons is always done with the "i;ascii-casemap"
i.e., case-insensitive comparisons, as defined in [IMAP]. operator, i.e., case-insensitive comparisons, as defined in [IMAP].
Example: Example:
If the variable "MyFlags" has the value "A B", the following test If the variable "MyFlags" has the value "A B", the following test
hasflag :is "MyFlags" "b A" hasflag :is "MyFlags" "b A"
evaluates to true. The above test can be also written as evaluates to true. The above test can be also written as
hasflag "MyFlags" ["b","A"] hasflag "MyFlags" ["b","A"]
5. Tagged argument :flags 5. Tagged argument :flags
This specification adds a new optional tagged argument ":flags" that This specification adds a new optional tagged argument ":flags" that
alter the behavior of actions "keep" and "fileinto". alter the behavior of actions "keep" and "fileinto".
The :flags tagged argument specifies that the flags provided in the The :flags tagged argument specifies that the flags provided in the
subsequent argument should be set when fileinto/keep deliver the message subsequent argument should be set when fileinto/keep delivers the
to the target mailbox/user's main mailbox. If the :flags tagged argument message to the target mailbox/user's main mailbox. If the :flags
is not specified, "keep" or "fileinto" will use the current value of the tagged argument is not specified, "keep" or "fileinto" will use
internal variable when delivering message to the target mailbox. the current value of the internal variable when delivering message
to the target mailbox.
Syntax: ":flags" <list-of-flags: string-list> Usage: ":flags" <list-of-flags: string-list>
The copy of the message filed into mailbox will have only flags The copy of the message filed into mailbox will have only flags
listed after ":flags". listed after the ":flags" tagged argument.
The Sieve interpreter MUST ignore all flags that it can't store The Sieve interpreter MUST ignore all flags that it can't store
permanently. This means that the interpreter must not treat failure permanently. This means that the interpreter MUST NOT treat failure
to store any flag as a runtime failure to execute the Sieve to store any flag as a runtime failure to execute the Sieve
script. For example, if the mailbox "INBOX.From Boss" can't store any script. For example, if the mailbox "INBOX.From Boss" can't store any
flags, then flags, then
fileinto :flags "\\Deleted" "INBOX.From Boss"; fileinto :flags "\\Deleted" "INBOX.From Boss";
and and
fileinto "INBOX.From Boss"; fileinto "INBOX.From Boss";
skipping to change at line 430 skipping to change at line 441
9. Extended example 9. Extended example
# #
# Example Sieve Filter # Example Sieve Filter
# Declare any optional features or extension used by the script # Declare any optional features or extension used by the script
# #
require ["fileinto", "imap4flags", "variables"]; require ["fileinto", "imap4flags", "variables"];
# #
# Move large messages to special mailbox # Move large messages to a special mailbox
# #
if size :over 1M if size :over 1M
{ {
addflag "MyFlags" "Big"; addflag "MyFlags" "Big";
if header :is "From" "boss@company.example.com" if header :is "From" "boss@company.example.com"
{ {
# The message will be marked as "\Flagged Big" when filed into # The message will be marked as "\Flagged Big" when filed into
# mailbox "Big messages" # mailbox "Big messages"
addflag "MyFlags" "\\Flagged"; addflag "MyFlags" "\\Flagged";
} }
fileinto :flags "${MyFlags}" "Big messages"; fileinto :flags "${MyFlags}" "Big messages";
} }
if header :is "From" "grandma@example.net" if header :is "From" "grandma@example.net"
{ {
addflag "MyFlags" ["\\Answered", "$MDNSent"]; addflag "MyFlags" ["\\Answered", "$MDNSent"];
# If the message is bigger than 1Mb it will be marked as # If the message is bigger than 1Mb it will be marked as
# "Big \Answered $MDNSent" when filed into mailbox "grandma". # "Big \Answered $MDNSent" when filed into mailbox "grandma".
# If the message is shorter than 1Mb it will be marked as # If the message is shorter than 1Mb it will be marked as
# "\Answered $MDNSent" # "\Answered $MDNSent"
fileinto :flags "${MyFlags}" "GrandMa"; # move to "GrandMa" folder fileinto :flags "${MyFlags}" "GrandMa";
} }
# #
# Handle messages from known mailing lists # Handle messages from known mailing lists
# Move messages from IETF filter discussion list to filter folder # Move messages from IETF filter discussion list to filter folder
# #
if header :is "Sender" "owner-ietf-mta-filters@example.org" if header :is "Sender" "owner-ietf-mta-filters@example.org"
{ {
set "MyFlags" "\\Flagged $Work"; set "MyFlags" "\\Flagged $Work";
# Message will have both "\Flagged" and $Work flags # Message will have both "\Flagged" and $Work flags
skipping to change at line 482 skipping to change at line 493
# #
# Try and catch unsolicited email. If a message is not to me, # Try and catch unsolicited email. If a message is not to me,
# or it contains a subject known to be spam, file it away. # or it contains a subject known to be spam, file it away.
# #
elsif anyof (not address :all :contains elsif anyof (not address :all :contains
["To", "Cc"] "me@company.example.com", ["To", "Cc"] "me@company.example.com",
header :matches "subject" header :matches "subject"
["*make*money*fast*", "*university*dipl*mas*"]) ["*make*money*fast*", "*university*dipl*mas*"])
{ {
remove "MyFlags" "\\Flagged"; remove "MyFlags" "\\Flagged";
# If message header does not contain my address, fileinto :flags "${MyFlags}" "spam";
# it's from a list.
fileinto :flags "${MyFlags}" "spam"; # move to "spam" folder
} }
else else
{ {
# Move all other external mail to "personal" # Move all other external mail to "personal"
# folder. # folder.
fileinto :flags "${MyFlags}" "personal"; fileinto :flags "${MyFlags}" "personal";
} }
10. Acknowledgments 10. Acknowledgments
skipping to change at line 521 skipping to change at line 530
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
Hampton, Middlesex Hampton, Middlesex
United Kingdom, TW12 2BX United Kingdom, TW12 2BX
Email: alexey.melnikov@isode.com Email: alexey.melnikov@isode.com
12. Normative References 12. Normative References
[SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint, [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
RFC 3028, January 2001. Language", work in progress, I-D draft-ietf-sieve-3028bis.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", Harvard University, RFC 2119, March 1997. Requirement Levels", Harvard University, RFC 2119, March 1997.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
University of Washington, RFC 3501, March 2003. 4rev1", University of Washington, RFC 3501, March 2003.
[VARIABLES] Homme, K. T., "Sieve -- Variables Extension", University of [VARIABLES] Homme, K. T., "Sieve -- Variables Extension", University
Oslo, work in progress, draft-ietf-sieve-variables-XX.txt of Oslo, work in progress, draft-ietf-sieve-variables-XX.txt
13. Intellectual Property Statement 13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights such rights. Information on the procedures with respect to rights
skipping to change at line 559 skipping to change at line 568
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
14. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 42 change blocks. 
111 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/