draft-ietf-sieve-vacation-05.txt   draft-ietf-sieve-vacation-06.txt 
SIEVE Email Filtering Working T. Showalter SIEVE Email Filtering Working T. Showalter
Group Group
Internet-Draft N. Freed, Ed. Internet-Draft N. Freed, Ed.
Expires: July 4, 2006 Sun Microsystems Expires: August 6, 2006 Sun Microsystems
December 31, 2005 February 2, 2006
Sieve Email Filtering: Vacation Extension Sieve Email Filtering: Vacation Extension
draft-ietf-sieve-vacation-05 draft-ietf-sieve-vacation-06
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 page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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.
This Internet-Draft will expire on July 4, 2006. This Internet-Draft will expire on August 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes an extension to the Sieve email filtering This document describes an extension to the Sieve email filtering
language for an autoresponder similar to that of the Unix "vacation" language for an autoresponder similar to that of the Unix "vacation"
command for replying to messages. Various safety features are command for replying to messages. Various safety features are
included to prevent problems such as message loops. included to prevent problems such as message loops.
Change History (to be removed prior to publication as an RFC) Change History (to be removed prior to publication as an RFC)
Changes from draft-showalter-sieve-vacation-06.txt: Changes from draft-showalter-sieve-vacation-06.txt:
skipping to change at page 3, line 10 skipping to change at page 3, line 10
18. Added text making it explicit that it is OK to have additional 18. Added text making it explicit that it is OK to have additional
implementation-specific checks to see if a vacation response implementation-specific checks to see if a vacation response
should be sent. (This just reiterates the advice in RFC 3834.) should be sent. (This just reiterates the advice in RFC 3834.)
19. Added an implementation note about how to construct a hash of 19. Added an implementation note about how to construct a hash of
vacation action parameters. vacation action parameters.
20. Clarified what to do when :subject isn't used and the original 20. Clarified what to do when :subject isn't used and the original
message also doesn't contain a Subject field. message also doesn't contain a Subject field.
21. Corrected typos, added Internationalization Considerations
section.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4
4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4 4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 5 4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 5
4.3. Subject and from parameters . . . . . . . . . . . . . . . 7 4.3. Subject and from parameters . . . . . . . . . . . . . . . 7
4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7 4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 37 skipping to change at page 3, line 40
5.1. SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 10 5.1. SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 10
5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 11 5.6. Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 11
5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 11 5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 11
5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 11 5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 11
6. Relationship to Recommendations for Automatic Responses to 6. Relationship to Recommendations for Automatic Responses to
Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Internationalization Considerations . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
This document defines an extension to the Sieve language defined in This document defines an extension to the Sieve language defined in
[I-D.ietf-sieve-3028bis] for notification that messages to a [I-D.ietf-sieve-3028bis] for notification that messages to a
particular recipient will not be answered immediately. particular recipient will not be answered immediately.
2. Conventions used in this document 2. Conventions used in this document
Conventions for notations are as in [I-D.ietf-sieve-3028bis] section Conventions for notations are as in [I-D.ietf-sieve-3028bis] section
skipping to change at page 6, line 9 skipping to change at page 6, line 9
roadrunner@acme.example.com twice, once with the subject "Cyrus bug" roadrunner@acme.example.com twice, once with the subject "Cyrus bug"
and once with the subject "come over for dinner", and and once with the subject "come over for dinner", and
roadrunner@acme.example.com has the script shown below, roadrunner@acme.example.com has the script shown below,
coyote@desert.example.org would receive two responses, once with the coyote@desert.example.org would receive two responses, once with the
first message, once with the second. first message, once with the second.
require "vacation"; require "vacation";
if header :contains "subject" "cyrus" { if header :contains "subject" "cyrus" {
vacation "I'm out -- send mail to cyrus-bugs"; vacation "I'm out -- send mail to cyrus-bugs";
} else { } else {
vacation "I'm out -- call me at 304 555 1212"; vacation "I'm out -- call me at +1 304 555 0123";
} }
In the above example, coyote@desert.example.org gets the second In the above example, coyote@desert.example.org gets the second
message despite having gotten the first one because separate vacation message despite having gotten the first one because separate vacation
responses have been triggered. This behavior is REQUIRED. responses have been triggered. This behavior is REQUIRED.
There is one important exception to this rule, however. If the Sieve There is one important exception to this rule, however. If the Sieve
variables extension [I-D.ietf-sieve-variables] is used, the arguments variables extension [I-D.ietf-sieve-variables] is used, the arguments
MUST NOT have undergone variable expansion prior to their use in MUST NOT have undergone variable expansion prior to their use in
response tracking. This is so that examples like the following response tracking. This is so that examples like the following
skipping to change at page 7, line 10 skipping to change at page 7, line 10
hash of either the current handle and the recipient address or, if no hash of either the current handle and the recipient address or, if no
handle is provided, a hash of the vacation action parameters handle is provided, a hash of the vacation action parameters
specifying the message content and the recipient address. If a specifying the message content and the recipient address. If a
script is changed, implementations MAY reset the records of who has script is changed, implementations MAY reset the records of who has
been responded to and when they have been responded to. been responded to and when they have been responded to.
IMPLEMENTATION NOTE: Care must be taken in constructing a hash of IMPLEMENTATION NOTE: Care must be taken in constructing a hash of
vacation action parameters. In particular, since most parameters are vacation action parameters. In particular, since most parameters are
optional, it is important not to let the same string used as the optional, it is important not to let the same string used as the
value for different parameters produce the same hash value. One value for different parameters produce the same hash value. One
possible way to accomplish this qpply the hash to a series of counted possible way to accomplish this apply the hash to a series of counted
or null terminated strings, one for each possible parameter in or null terminated strings, one for each possible parameter in
particular order. particular order.
Implementations are free to limit the number of remembered responses, Implementations are free to limit the number of remembered responses,
however, the limit MUST NOT be less than 1000. When limiting the however, the limit MUST NOT be less than 1000. When limiting the
number of tracked responses, implementations SHOULD discard the number of tracked responses, implementations SHOULD discard the
oldest ones first. oldest ones first.
4.3. Subject and from parameters 4.3. Subject and from parameters
skipping to change at page 7, line 35 skipping to change at page 7, line 35
present. Implementations MUST generate an appropriate default present. Implementations MUST generate an appropriate default
subject line as specified below if no :subject parameter is subject line as specified below if no :subject parameter is
specified. specified.
A ":from" parameter may be used to specify an alternate address to A ":from" parameter may be used to specify an alternate address to
use in the From field of vacation messages. The string must specify use in the From field of vacation messages. The string must specify
a valid [RFC2822] mailbox-list. Implementations SHOULD check the a valid [RFC2822] mailbox-list. Implementations SHOULD check the
syntax and generate an error when a syntactically invalid ":from" syntax and generate an error when a syntactically invalid ":from"
parameter is specified. Implementations MAY also impose restrictions parameter is specified. Implementations MAY also impose restrictions
on what addresses can specified in a ":from" parameter; it is on what addresses can specified in a ":from" parameter; it is
suggested that values which fail such a security check simply be suggested that values which fail such a validity check simply be
ignored rather than causing the vacation action to fail. ignored rather than causing the vacation action to fail.
4.4. MIME Parameter 4.4. MIME Parameter
The ":mime" parameter, if supplied, specifies that the reason string The ":mime" parameter, if supplied, specifies that the reason string
is, in fact, a MIME entity as defined in [RFC2045] section 2.4, is, in fact, a MIME entity as defined in [RFC2045] section 2.4,
including both MIME headers and content. including both MIME headers and content.
If the optional :mime parameter is not supplied, the reason string is If the optional :mime parameter is not supplied, the reason string is
considered to be a UTF-8 string. considered to be a UTF-8 string.
skipping to change at page 9, line 6 skipping to change at page 9, line 6
addresses that a user might have. These addresses are considered to addresses that a user might have. These addresses are considered to
belong to the recipient user in addition to the addresses known to belong to the recipient user in addition to the addresses known to
the implementation. the implementation.
4.6. Restricting Replies to Automated Processes and Mailing Lists 4.6. Restricting Replies to Automated Processes and Mailing Lists
Implementations MAY refuse to send a vacation response to a message Implementations MAY refuse to send a vacation response to a message
which contains any header or content that makes it appear that a which contains any header or content that makes it appear that a
response would not be appropriate. response would not be appropriate.
Implementations MUST have a list of addresses that "vacation" MUST Implementations MUST have a list of addresses which "vacation" MUST
NOT send mail to. However, the contents of this list are NOT send mail to. However, the contents of this list are
implementation defined. The purpose of this list is to stop mail implementation defined. The purpose of this list is to stop mail
from going to addresses used by system daemons that would not care if from going to addresses used by system daemons that would not care if
the user is actually reading her mail. the user is actually reading her mail.
Implementations are encouraged, however, to include well-known Implementations are encouraged, however, to include well-known
addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other
addresses typically used only by automated systems. Additionally, addresses typically used only by automated systems. Additionally,
addresses ending in "-request" or beginning in "owner-", i.e., addresses ending in "-request" or beginning in "owner-", i.e.,
reserved for mailing list software, are also suggested. reserved for mailing list software, are also suggested.
skipping to change at page 11, line 43 skipping to change at page 11, line 43
be generated, and References need not be changed. be generated, and References need not be changed.
Section 3.6.4 of [RFC2822] provides a complete description of how Section 3.6.4 of [RFC2822] provides a complete description of how
References fields should be generated. References fields should be generated.
6. Relationship to Recommendations for Automatic Responses to 6. Relationship to Recommendations for Automatic Responses to
Electronic Mail Electronic Mail
The vacation extension implements a "Personal Responder" in the The vacation extension implements a "Personal Responder" in the
terminology defined in [RFC3834]. Care has been taken in this terminology defined in [RFC3834]. Care has been taken in this
specification to comply with the recommendations [RFC3834] makes in specification to comply with the recommendations of [RFC3834]
regards to how personal responders should behave. regarding how personal responders should behave.
7. Security Considerations 7. Internationalization Considerations
Internationalization capabilities provided by the base Sieve language
are discussed in [I-D.ietf-sieve-3028bis]. However, the vacation
extension is the first Sieve extension to be defined that is capable
of creating entirely new messages. This section deals with
internationalization issues raised by the use of the vacation
extension.
Vacation messages are normally written using the UTF-8 charset,
allowing text to be written in most of the world's languages.
Additionally, the :mime parameter allows specification of arbitrary
MIME content. In particular, this makes it possible to use
multipart/alternative objects to specify vacation responses in
multiple languages simultaneously.
The Sieve language itself allows a vacation response to selected
based on the content of the original message. For example, the
Accept-Language or Content-Language header fields [RFC3282] could be
checked and used to select appropriate text:
require "vacation";
if header :contains ["accept-language", "content-language"] "en"
{
vacation "I am away this week.";
} else {
vacation "Estoy ausente esta semana.";
}
Note that this rather simplistic test of the field values fails to
take the structure of the fields into account and hence could be
fooled by some more complex field values. A more elaborate test
could be used to deal with this problem.
The approach of explicitly coding language selection criteria in
scripts is preferred because in many cases language selection issues
are conflated with other selection issues. For example, it may be
appropriate to use informal text in one language for vacation
responses sent to a fellow employee while using more formal text in a
different language in a response sent to a total stranger outside the
company:
require "vacation";
if address :matches "from" "*@ourdivision.example.com"
{
vacation :subject "Gone fishing"
"Having lots of fun! Back in a day or two!";
} else {
vacation :subject "Je suis parti cette semaine"
"Je lirai votre message quand je retourne.";
}
IMPLEMENTATION NOTE: A graphical Sieve generation interface could in
principle be used to hide the complexity of specifying response
selection criteria from end users. Figuring out the right set of
options to present in a graphical interface is likely a nontrivial
proposition, but more because of the need to employ a variety of
criteria to select different sorts of responses to send to different
classes of people than because of the issues involved in selecting a
response in an appropriate language.
8. Security Considerations
It is critical that implementations correctly implement the behavior It is critical that implementations correctly implement the behavior
and restrictions described throughout this document. Replies MUST and restrictions described throughout this document. Replies MUST
NOT be sent out in response to messages not sent directly to the NOT be sent out in response to messages not sent directly to the
user, and replies MUST NOT be sent out more often than the :days user, and replies MUST NOT be sent out more often than the :days
argument states unless the script changes. argument states unless the script changes.
If mail is forwarded from a site that uses subaddressing, it may be If mail is forwarded from a site that uses subaddressing, it may be
impossible to list all recipient addresses with ":addresses". impossible to list all recipient addresses with ":addresses".
Security issues associated with mail auto-responders are fully Security issues associated with mail auto-responders are fully
discussed in the security consideration section of [RFC3834]. This discussed in the security consideration section of [RFC3834]. This
document is believed not to introduce any additional security document is believed not to introduce any additional security
considerations in this general area. considerations in this general area.
8. IANA Considerations 9. IANA Considerations
The following template specifies the IANA registration of the The following template specifies the IANA registration of the
vacation Sieve extension specified in this document: vacation Sieve extension specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve extension Subject: Registration of new Sieve extension
Capability name: vacation Capability name: vacation
Capability keyword: vacation Capability keyword: vacation
Capability arguments: N/A Capability arguments: N/A
Standards Track/IESG-approved experimental RFC number: this RFC Standards Track/IESG-approved experimental RFC number: this RFC
Person and email address to contact for further information: Person and email address to contact for further information:
Ned Freed Ned Freed
E-Mail: ned.freed@mrochek.com E-Mail: ned.freed@mrochek.com
This information should be added to the list of Sieve extensions This information should be added to the list of Sieve extensions
given on http://www.iana.org/assignments/sieve-extensions. given on http://www.iana.org/assignments/sieve-extensions.
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.ietf-sieve-3028bis] [I-D.ietf-sieve-3028bis]
Guenther, P. and T. Showalter, "Sieve: An Email Filtering Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", draft-ietf-sieve-3028bis-04 (work in progress), Language", draft-ietf-sieve-3028bis-04 (work in progress),
July 2005, <http://www.ietf.org/internet-drafts/ July 2005, <http://www.ietf.org/internet-drafts/
draft-ietf-sieve-3028bis-04.txt>. draft-ietf-sieve-3028bis-04.txt>.
[I-D.ietf-sieve-variables] [I-D.ietf-sieve-variables]
Homme, K., "Sieve Mail Filtering Language: Variables Homme, K., "Sieve Mail Filtering Language: Variables
Extension", draft-ietf-sieve-variables-04 (work in Extension", draft-ietf-sieve-variables-04 (work in
skipping to change at page 13, line 27 skipping to change at page 14, line 42
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003. RFC 3461, January 2003.
[RFC3834] Moore, K., "Recommendations for Automatic Responses to [RFC3834] Moore, K., "Recommendations for Automatic Responses to
Electronic Mail", RFC 3834, August 2004. Electronic Mail", RFC 3834, August 2004.
9.2. Informative References 10.2. Informative References
[I-D.ietf-sieve-refuse-reject] [I-D.ietf-sieve-refuse-reject]
Elvey, M. and A. Melnikov, "The SIEVE mail filtering Elvey, M. and A. Melnikov, "The SIEVE mail filtering
language - reject and refuse extensions", language - reject and refuse extensions",
draft-ietf-sieve-refuse-reject (work in progress), draft-ietf-sieve-refuse-reject (work in progress),
May 2005, <http://www.ietf.org/internet-drafts/ May 2005, <http://www.ietf.org/internet-drafts/
draft-ietf-sieve-refuse-reject.txt>. draft-ietf-sieve-refuse-reject.txt>.
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997. FUNCTIONS", RFC 2142, May 1997.
skipping to change at page 14, line 5 skipping to change at page 15, line 16
for Core Mail List Commands and their Transport through for Core Mail List Commands and their Transport through
Message Header Fields", RFC 2369, July 1998. Message Header Fields", RFC 2369, July 1998.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
and Namespace for the Identification of Mailing Lists", and Namespace for the Identification of Mailing Lists",
RFC 2919, March 2001. RFC 2919, March 2001.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This extension is obviously inspired by Eric Allman's vacation This extension is obviously inspired by Eric Allman's vacation
program under Unix. The authors owe a great deal to Carnegie Mellon program under Unix. The authors owe a great deal to Carnegie Mellon
University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil
Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov, Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov,
Jeffrey Hutzelman, Philip Guenther and many others whose names have Jeffrey Hutzelman, Philip Guenther and many others whose names have
been lost during the inexcusably long gestation period of this been lost during the inexcusably long gestation period of this
document. document.
skipping to change at page 16, line 41 skipping to change at page 17, line 41
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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
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. 18 change blocks. 
25 lines changed or deleted 92 lines changed or added

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