draft-ietf-sieve-imapflags-00.txt   draft-ietf-sieve-imapflags-01.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-00.txt Isode Limited Document: draft-ietf-sieve-imapflags-01.txt Isode Limited
Expires: August 2005 February 2005 Expires: November 2005 May 2005
Sieve -- IMAP flag Extension Sieve Mail Filtering Language: IMAP flag Extension
Status of this memo Status of this memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
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 The protocol discussed in this document is experimental and subject
to change. Persons planning on either implementing or using this to change. Persons planning on either implementing or using this
protocol are STRONGLY URGED to get in touch with the author before protocol are STRONGLY URGED to get in touch with the author before
skipping to change at line 69 skipping to change at line 67
0.1. Discussion 0.1. Discussion
This draft defines an extension to the Sieve mail filtering This draft defines an extension to the Sieve mail filtering
language (RFC 3028) being discussed on the MTA Filters language (RFC 3028) being discussed on the MTA Filters
mailing list at <ietf-mta-filters@imc.org>. Subscription requests mailing list at <ietf-mta-filters@imc.org>. Subscription requests
can be sent to <ietf-mta-filters-request@imc.org> (send an email can be sent to <ietf-mta-filters-request@imc.org> (send an email
message with the word "subscribe" in the body). More information on message with the word "subscribe" in the body). More information on
the mailing list along with a WWW archive of back messages is the mailing list along with a WWW archive of back messages is
available at <http://www.imc.org/ietf-mta-filters/>. available at <http://www.imc.org/ietf-mta-filters/>.
0.2. Open issues 0.2. Changes from the version submitted to the Sieve mailing list
1. Rob has suggested that we should keep syntax backward compatible
with revision 03, that was widely deployed (in particular by CMU).
Does anybody have any opinion on this?
0.3. Changes from the version submitted to the Sieve mailing list
1. Added addflag and removeflag actions 1. Added addflag and removeflag actions
2. Changed the semantics of setflag (setflag is not additive any 2. Changed the semantics of setflag (setflag is not additive any
more) more)
3. Corrected section "Interaction with Other Sieve Actions". 3. Corrected section "Interaction with Other Sieve Actions".
Removed incorrect reference to the forward action as to an Removed incorrect reference to the forward action as to an
action that prohibits setflag. action that prohibits setflag.
4. Added paragraph about the mutual order of "fileinto"/"keep" and 4. Added paragraph about the mutual order of "fileinto"/"keep" and
"setflag"/"addflag"/"removeflag" actions. "setflag"/"addflag"/"removeflag" actions.
0.4. Changes from the revision 00 0.3. Changes from the revision 00
1. Corrected Capability Identifier section (Section 2) 1. Corrected Capability Identifier section (Section 2)
2. Corrected "Interaction with Other Sieve Actions" section 2. Corrected "Interaction with Other Sieve Actions" section
(Section 4) (Section 4)
3. Examples were updated to be compatible with Sieve-07 draft 3. Examples were updated to be compatible with Sieve-07 draft
4. Added "mark" and "unmark" actions 4. Added "mark" and "unmark" actions
0.5. Changes from the revision 01 0.4. Changes from the revision 01
1. Some language fixes based on Tony Hansen comments 1. Some language fixes based on Tony Hansen comments
2. Clarified that the extension allows to set both IMAP System 2. Clarified that the extension allows to set both IMAP System
Flags and Keywords Flags and Keywords
0.6. Changes from the revision 02 0.5. Changes from the revision 02
1. BugFix: all backslashes must be escaped 1. BugFix: all backslashes must be escaped
2. Added extended example and more detailed description of 2. Added extended example and more detailed description of
"addflag"/"removeflag" additivity. "addflag"/"removeflag" additivity.
3. Minor example bugfixes 3. Minor example bugfixes
0.7. Changes from the revision 03 0.6. Changes from the revision 03
1. Added second way to specify flags to be set (via optional tagged 1. Added second way to specify flags to be set (via optional tagged
arguments). [Tim Showalter] arguments). [Tim Showalter]
2. Rules for using Reject with imapflags relaxed. [Randall Gellens] 2. Rules for using Reject with imapflags relaxed. [Randall Gellens]
3. Removed ABNF section completely, added syntax description to 3. Removed ABNF section completely, added syntax description to
action definition. [Tim Showalter] action definition. [Tim Showalter]
4. Cleaned up the example. [Ken Murchison] 4. Cleaned up the example. [Ken Murchison]
5. Added FM (Flag Manupulation) acronym. 5. Added FM (Flag Manupulation) acronym.
6. Clarified "mark"/"unmark" bahavior. [Randall Gellens] 6. Clarified "mark"/"unmark" bahavior. [Randall Gellens]
0.8. Changes from the revision 04 0.7. Changes from the revision 04
1. "Interaction with Other Sieve Actions" was simplified based on 1. "Interaction with Other Sieve Actions" was simplified based on
comments from Tim Showalter. Added sentence saying that comments from Tim Showalter. Added sentence saying that
imapflags doesn't change an implicit keep. imapflags doesn't change an implicit keep.
2. Several editorial comments from Tim Showalter. 2. Several editorial comments from Tim Showalter.
0.9. Changes from the revision 05 0.8. Changes from the revision 05
1. Updated copyright, author address, section numbers and references. 1. Updated copyright, author address, section numbers and references.
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 anymore,
as imapflags now depends on variables and a variable can have an arbitrary as imapflags now depends on variables and a variable can have an arbitrary
value. value.
0.10. Changes from the revision 06 0.9. Changes from the revision 06 (now 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
1. Added back the internal variable, made the variable parameter to all
actions optional.
2. Some editorial suggestions from Mark E. Mallett.
3. Updated boilerplate once again.
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.
This extension depends on the presence of "variables" extension
[Variables].
Sieve interpreters that don't support integration with IMAP SHOULD Sieve interpreters that don't support integration with IMAP SHOULD
ignore this extension. 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".
<<Extension name has been changed as revision 03 of this document is widely <<Extension name has been changed as revision 03 of this document is widely
deployed in CMU Cyrus server>> deployed in CMU Cyrus server>>
The "imap4flags" extension can be used with or without the "variables"
extension [Variables]. When the "variables" extension is also present
a script can use explicit variable names in setflag/addflag/removeflag
actions. See also section 3 for more details.
When the "variables" extension is not present the explicit variable name
parameter to setflag/addflag/removeflag MUST NOT be used.
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 "Syntax:" 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 actions,
hasflag test and :flags tagged argument. 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 list-of-flags
parameter. parameter.
The Sieve interpreter SHOULD check the list of flags for validity as described The Sieve interpreter SHOULD check the list of flags for validity as
by [IMAP] ABNF. In particular non-ASCII characters are not allowed in described by [IMAP] ABNF. In particular non-ASCII characters are not
flag names. However spaces MUST be always allowed and multiple spaces allowed in flag names. However spaces MUST be always allowed and multiple
between flag names MUST be treated as a single space character. A string spaces between flag names MUST be treated as a single space character.
containing a space separated list of flags is equivalent to a string list A string containing a space-separated list of flags is equivalent to a
consisting of the flags. The last requirement is to simplify amalgamation string list consisting of the flags. The last requirement is to simplify
of multiple flag lists. amalgamation of multiple flag lists.
If a flag validity check fails the flag should be silently If a flag validity check fails the flag should be silently
dropped, but a warning message should be logged by the Sieve interpreter. ignored, but a warning message SHOULD be logged by the Sieve interpreter.
3. Actions 3. Actions
All actions described in this specification (setflag, addflag, removeflag) All actions described in this specification (setflag, addflag, removeflag)
operate on string variables that contain a set of [IMAP] flags. operate on string variables that contain a set of [IMAP] flags.
On variable substitution a set of flags is represented as a string On variable substitution a set of flags is represented as a string
containing space separated list of flag names. containing space-separated list of flag names.
<<Should this cause an automatic duplicate elimination?>> <<Should this cause an automatic duplicate elimination?>>
Note that the parameter specifying a variable name to setflag/addflag/
removeflag actions is optional. If the parameter is not specified
the actions operate on the internal variable, which has the empty
value when the script starts execution. If the SIEVE interpreter doesn't
support the "variables" extension [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 replaces an existing set of flags defined in [Variables] can be used to replace an existing set of flags
with a new set as well. The :flags tagged argument to "keep" and "fileinto" with a new set as well.
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 referenced by a variable
with the current message. with the current message. If the :flags tagged argument is not specified
with those 2 actions, the current value of the internal variable is used
instead. The value also applies to the implicit keep.
<<When keep/fileinto is used multiple times and duplicate elimination
is used, the last flag value wins.>>
3.1. Setflag Action 3.1. Setflag Action
Syntax: setflag <variablename: string> <list-of-flags: string-list> Syntax: setflag [<variablename: string>] <list-of-flags: string-list>
Setflag is used for setting [IMAP] system flags or Setflag is used for setting [IMAP] system flags or keywords.
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.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> Syntax: 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 occurrences
of addflag are treated additively. The order of the flags MAY NOT of addflag are treated additively. The order of the flags MAY NOT
be preserved and duplicates are allowed. be preserved and duplicates are allowed.
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";
skipping to change at line 276 skipping to change at line 295
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> Syntax: 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.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] Syntax: hasflag [MATCH-TYPE]
<variable-list: string-list> <list-of-flags: string-list> <variable-list: 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 any
skipping to change at line 402 skipping to change at line 421
"* " { "* " {
set <variable> "${1}"; set <variable> "${1}";
} }
7. Interaction with Other Sieve Actions 7. Interaction with Other Sieve Actions
This extension work only on the message that is currently being This extension work only on the message that is currently being
processed by Sieve, it doesn't affect another message generated processed by Sieve, it doesn't affect another message generated
as a side affect of any action. as a side affect of any action.
The extension decribed in this document doesn't change an implicit The extension decribed in this document doesn't change the implicit
keep (see section 2.10.2 of [SIEVE]). keep (see section 2.10.2 of [SIEVE]).
8. Other Considerations 8. Other Considerations
This extension intentionally doesn't allow setting [IMAP] flags on This extension intentionally doesn't allow setting [IMAP] flags on
an arbitrary message in the [IMAP] message store. an arbitrary message in the [IMAP] message store.
9. Security Considerations 9. Security Considerations
Security considerations are discussed in the [IMAP] and [SIEVE]. Security considerations are discussed in the [IMAP], [SIEVE] and
[Variables].
It is belived that this extension doesn't introduce any additional It is belived that this extension doesn't introduce any additional
security concerns. security concerns.
10. Extended example 10. 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 special mailbox
# #
if size :over 1M if size :over 1M
{ {
addflag "MyFlags" "Big"; addflag "MyFlags" "Big";
if header :is "From" "boss@company.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"
{ {
skipping to change at line 453 skipping to change at line 473
# "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"; # move to "GrandMa" folder
} }
# #
# 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@imc.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
keep :flags "${MyFlags}"; keep :flags "${MyFlags}";
} }
# #
# Keep all messages to or from people in my company # Keep all messages to or from people in my company
# #
elsif anyof address :domain :is ["From", "To"] "company.com" elsif anyof address :domain :is ["From", "To"] "company.example.com"
{ {
keep :flags "${MyFlags}"; # keep in "Inbox" folder keep :flags "${MyFlags}"; # keep in "Inbox" folder
} }
# #
# 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.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, # If message header does not contain my address,
# it's from a list. # it's from a list.
fileinto :flags "${MyFlags}" "spam"; # move to "spam" folder fileinto :flags "${MyFlags}" "spam"; # move to "spam" folder
} }
else else
{ {
# Move all other (non-company) mail to "personal" # Move all other external mail to "personal"
# folder. # folder.
fileinto :flags "${MyFlags}" "personal"; fileinto :flags "${MyFlags}" "personal";
} }
11. Acknowledgments 11. Acknowledgments
This document has been revised in part based on comments and This document has been revised in part based on comments and
discussions which took place on and off the Sieve mailing list. discussions which took place on and off the Sieve mailing list.
The help of those who took the time to review the draft and make The help of those who took the time to review the draft and make
suggestions is appreciated, especially that of Tim Showalter, suggestions is appreciated, especially that of Tim Showalter,
Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo,
Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson,
and Kjetil Torgrim Homme. Kjetil Torgrim Homme and Mark E. Mallett.
Special thanks to Tony Hansen and David Lamb for helping me Special thanks to Tony Hansen and David Lamb for helping me
better explain the concept. better explain the concept.
12. Author's Address 12. Author's Address
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
skipping to change at line 530 skipping to change at line 550
[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 4rev1",
University of Washington, RFC 3501, March 2003. University of Washington, RFC 3501, March 2003.
[Variables] Homme, K. T., "Sieve -- Variables Extension", University of [Variables] Homme, K. T., "Sieve -- Variables Extension", University of
Oslo, work in progress, draft-ietf-sieve-variables-XX.txt Oslo, work in progress, draft-ietf-sieve-variables-XX.txt
14. Full Copyright Statement 14. Intellectual Property Statement
Copyright (C) The Internet Society (2005). This document is subject The IETF takes no position regarding the validity or scope of any
to the rights, licenses and restrictions contained in BCP 78, and Intellectual Property Rights or other rights that might be claimed
except as set forth therein, the authors retain all their rights. 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.
15. Full 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.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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.
15. 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.
 End of changes. 

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