draft-ietf-sieve-mime-loop-00.txt   draft-ietf-sieve-mime-loop-01.txt 
Internet Engineering Task Force T. Hansen Internet Engineering Task Force T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Expires: August 31, 2006 C. Daboo Intended status: Standards Track C. Daboo
Cyrusoft International, Inc. Expires: April 25, 2007 Apple Computer
February 26, 2006 October 22, 2006
Sieve Extensions: MIME Tests, MIME Bodypart Iteration, Replacement and SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and
Enclosure Enclosure
draft-ietf-sieve-mime-loop-00.txt draft-ietf-sieve-mime-loop-01.txt
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 36 skipping to change at page 1, line 36
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 August 31, 2006. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The current Sieve language has no way to look at individual MIME The SIEVE email filtering language has no way to examine individual
parts, looping mechanism, or any way to manipulate those individual MIME parts or any way to manipulate those individual parts. However,
parts. This document defines extensions for each of these needs. being able to filter based on MIME content is important. This
document defines extensions for these needs.
Note Note
This document is being discussed in the MTA-FILTERS mailing lists,
This document is being discussed on the MTA-FILTERS mailing list,
ietf-mta-filters@imc.org. ietf-mta-filters@imc.org.
1. Introduction 1. Introduction
Sieve scripts are used to make decisions about the disposition of a SIEVE scripts are used to make decisions about the disposition of an
mail message. The original Sieve spec, [5], defined operators for email message. The base SIEVE specification,
looking at the message headers, such as addresses and the subject. [I-D.ietf-sieve-3028bis], defines operators for looking at the
Other extensions provide access to the body of the message, or allow message headers, such as addresses and the subject. Other extensions
you to manipulate the header of the message. But none of these provide access to the body of the message ([I-D.ietf-sieve-body]), or
extensions take into account that MIME messages ([1]) are often allow you to manipulate the header of the message
complex objects, consisting of many parts and sub-parts. This ([I-D.ietf-sieve-editheader]). But none of these extensions take
extension defines mechanisms for performing tests on MIME body parts, into account that MIME messages ([RFC2045]) are often complex
looping through the MIME body parts, changing the contents of a MIME objects, consisting of many parts and sub-parts. This extension
body part, and enclosing the message with a wrapper. defines mechanisms for performing tests on MIME body parts, looping
through the MIME body parts, changing the contents of a MIME body
part, and enclosing the message with a wrapper.
2. Sieve Loops 2. Conventions Used in This Document
The current Sieve language has no looping mechanism. Given that Conventions for notations are as in [I-D.ietf-sieve-3028bis] section
messages may contain multiple attachments, in order to support 1.1.
filters that apply to any and all attachments, we introduce a new
control command: "for_every_part", which is an iterator that walks
though every MIME part of a message, including nested parts, and
applies the specified block to each of them. The iterator will start
with the first MIME part (as its current context) and will execute a
command block (Sieve commands enclosed by { ...}). Upon completion
of this command block, the iterator advances to the next MIME part
(as its current context) and executes the same command block again.
NOTE: Need to deal with this comment The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
(http://www.imc.org/ietf-mta-filters/mail-archive/msg02707.html): "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
What will this do: for.every.part { if (some test here) { document are to be interpreted as described in [RFC2119].
for.every.part { ... } } } i.e. will the internal "for" be anchored
at the focus established by the enclosing "for" ? I'd hope so, but
this should be stated.
NOTE: Need to deal with this comment 3. SIEVE Loops
(http://www.imc.org/ietf-mta-filters/mail-archive/msg02707.html):
BTW, shouldn't there be a "mime" shorthand for testing the type/
subtype, without requiring if allof (mime :type "multipart", mime
:subtype "alternative") ? Especially for any recursive version of
"mime" (since the elements inside of "allof" can be matching
different mime parts).
The iterator can be terminated prematurely by a new sieve command, The base SIEVE language has no looping mechanism. Given that
messages may contain multiple parts, in order to support filters that
apply to any and all parts, we introduce a new control command:
"for_every_part", which is an iterator that walks though every MIME
part of a message, including nested parts, and applies the commands
in the specified block to each of them. The iterator will start with
the first MIME part (as its current context) and will execute a
command block (SIEVE commands enclosed by { ...}). Upon completion
of this command block, the iterator advances to the next MIME part
(as its current context) and executes the same command block again.
The iterator can be terminated prematurely by a new SIEVE command,
"break". "break".
Usage: for_every_part block Usage: for_every_part block
Usage: break; Usage: break;
3. Test "mime" "for_every_part" commands can be nested inside other "for_every_part"
commands. When this occurs, the nested "for_every_part" iterates
over the MIME parts contained within the MIME part current being
targeted by the nearest enclosing "for_every_part" command. If that
MIME part is a terminal MIME part (i.e. does not contain other MIME
parts) then the nested "for_every_loop" is simply ignored.
Usage: mime [:anychild] [COMPARATOR] [MATCH-TYPE] <header-names: SIEVE implementations MAY limit the number of nested loops that occur
string-list> [<parameter-names: string-list>] <key-list: string- within one another, however they MUST support at least one nested
list> loop inside another loop.
Usage: mime [:filename] ... 4. Changes to SIEVE tests
Usage: mime [:type] ... This specification extends the base SIEVE "header", "address" and
"exists" tests to support targeting those tests at a specific MIME
part or at all MIME parts in the enclosing scope.
Usage: mime [:subtype] ... 4.1. Test "header"
For Sieve tests on MIME parts, a new Sieve test ("mime") is defined. The "header" test is extended with the addition of a new ":mime"
Similar in concept to the Sieve "header" test, it will parse the MIME tagged argument, which takes a number of other arguments.
header lines so that tests can be performed on specific elements.
If :anychild is NOT specified: Usage: header [:mime] [:anychild] [MIMEOPTS]
[COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
If used within the context of a "for_every_part" iterator, the Usage: The definition of [MIMEOPTS] is:
"mime" test will examine the headers associated with the current
MIME part context.
If used outside the context of a "for_every_part" iterator, the Syntax: ":type" / ":subtype" / ":contenttype" /
"mime" test will examine only the outer headers of the message. ":param" <param-list: string-list>
If :anychild IS specified, the "mime" test will examine all MIME body When the ":mime" tagged argument is present in the "header" test, it
parts and return true if any of them satisfies the test. will parse the MIME header lines in a message so that tests can be
performed on specific elements.
The "mime" test has all of the options available from the header If the ":anychild" tagged argument is NOT specified:
test, [5] section 5.7. In addition, these options are available:
:filename examines the "Content-Disposition:" header field for its o If used within the context of a "for_every_part" iterator, the
"filename" parameter. If there is no "Content-Disposition:" "header" test will examine the headers associated with the current
header field, then it will look at the "Content-Type:" header MIME part context from the loop.
field for the "name" parameter.
:type examines the "Content-Type:" header field type parameter. o If used outside the context of a "for_every_part" iterator, the
"header" test will examine only the outer, top-level, headers of
the message.
:subtype examines the "Content-Type:" header field subtype parameter. If the ":anychild" tagged argument IS specified, the "header" test
will examine all MIME body parts and return true if any of them
satisfies the test.
NOTE: We need to add some way to look at parameter lists, ala The "header" test with the ":mime" tagged argument can test various
http://www.imc.org/ietf-mta-filters/mail-archive/msg01655.html and aspects of certain structed MIME headers. These options are
related messages: Content-Type: text/plain; charset="foo" available:
4. Action Replace :type parses the header assuming it has the format of a "Content-
Type:" MIME header field, and tests the value of the MIME type
specified in the header.
Usage: replace ["mime"] [":subject" string] [":from" string] :subtype parses the header assuming it has the format of a "Content-
Type:" MIME header field, and tests the value of the MIME subtype
specified in the header.
:contenttype parses the header assuming it has the format of a
"Content-Type:" MIME header field, and tests the combined value of
the MIME type and subtype specified in the header.
:param parses the header looking for MIME parameters in the header.
The supplied string-list lists the names of any parameters to be
tested. If any one named parameter value matches the test string
value, the test will return true.
Example:
require ["mime", "fileinto"];
if header :mime :type :comparator "Content-Type" "image"
{
fileinto "INBOX.images";
}
In this example, any message that contains a MIME image type part at
the top-level is saved to the mailbox "INBOX.images".
Example:
require ["mime", "fileinto"];
if header :mime :anychild :contenttype :comparator
"Content-Type" "text/html"
{
fileinto "INBOX.html";
}
In this example, any message that contains any MIME part with a
content-type of "text/html" is saved to the mailbox "INBOX.html".
Example:
require ["mime", "for_every_part", "fileinto"];
for_every_part
{
if header :mime :param "filename" :comparator
"Content-Disposition" "important"
{
fileinto "INBOX.important";
break;
}
In this example, any message that contains any MIME part with a
content-disposition with a filename parameter containing the text
"important" is saved to the mailbox "INBOX.important".
4.2. Test "address"
The "address" test is extended with the addition of a new ":mime"
tagged argument, which takes a number of other arguments.
Usage: address [:mime] [:anychild] [COMPARATOR]
[ADDRESS-PART] [MATCH-TYPE]
<header-list: string-list> <key-list: string-list>
When the ":mime" tagged argument is present in the "address" test, it
will parse the MIME header lines as if they were standard address
header lines in a message so that tests can be performed on specific
elements.
The behavior of the ":anychild" tagged argument and the interaction
with the "for_every_part" iterator is the same as for the extended
"header" test Section 4.1.
Example:
require ["mime", "fileinto"];
if address :mime :is :all "content-from" "tim@example.com"
{
fileinto "INBOX.part-from-tim";
}
In this example, any message that contains a MIME Content-From header
at the top-level matching the text "tim@example.com" is saved to the
mailbox "INBOX.part-from-time".
4.3. Test "exists"
The "exists" test is extended with the addition of a new ":mime"
tagged argument, which takes one other argument.
Usage: exists [:mime] [:anychild] <header-names: string-list>
When the ":mime" tagged argument is present in the "exists" test, the
test is extended to check for the existence of MIME headers in MIME
parts.
The behavior of the ":anychild" tagged argument and the interaction
with the "for_every_part" iterator is the same as for the extended
"header" test Section 4.1.
Example:
require ["mime", "fileinto"];
if exists :mime :anychild "content-md5"
{
fileinto "INBOX.md5";
}
In this example, any message that contains a MIME Content-MD5 header
in any MIME part is saved to the mailbox "INBOX.md5".
5. Action Replace
Usage: replace [:mime] [:subject string] [:from string]
<replacement: string> <replacement: string>
A new sieve action command is defined to allow the MIME part to be The "replace" command is defined to allow a MIME part to be replaced
replaced by a text message. The "replace" command causes a MIME part with the text supplied in the command.
to be removed and replaced with the text supplied by the command.
When used in the context of a "for_every_part" loop, the MIME part to When used in the context of a "for_every_part" iterator, the MIME
be replaced is the "current" MIME part. If the current MIME context part to be replaced is the "current" MIME part. If the current MIME
is a multipart MIME part, the entire multipart MIME part is replaced, context is a multipart MIME part, the entire multipart MIME part is
which would alter the MIME structure of the message by eliminating replaced, which would alter the MIME structure of the message by
all of the children of the multipart part. (Replacing a non- eliminating all of the children of the multipart part. (Replacing a
multipart MIME part within a "for_every_part" loop context does not non-multipart MIME part within a "for_every_part" loop context does
alter the overall message structure.) not alter the overall message structure.)
When used outside the context of a "for_every_part" loop, the MIME When used outside the context of a "for_every_part" loop, the MIME
part to be replaced is the entire message. part to be replaced is the entire message.
If the :mime parameter is not specified, the replacement string is a If the :mime parameter is not specified, the replacement string is a
text/plain part. text/plain part.
If the :mime parameter is specified, then the replacement string is, If the :mime parameter is specified, then the replacement string is,
in fact, a MIME entity as defined in [1] section 2.4, including both in fact, a MIME entity as defined in [RFC2045] section 2.4, including
MIME headers and content. If the optional :mime parameter is not both MIME headers and content. If the optional :mime parameter is
supplied, the reason string is considered to be a UTF-8 string. not supplied, the reason string is considered to be a UTF-8 string.
If the entire message is being replaced, a ":subject" parameter If the entire message is being replaced, a ":subject" parameter
specifies a subject line to attach to the message that is generated. specifies a subject line to attach to the message that is generated.
UTF-8 characters can be used in the string argument; implementations UTF-8 characters can be used in the string argument; implementations
MUST convert the string to [2] encoded words if and only if non-ASCII MUST convert the string to [RFC2047] encoded words if and only if
characters are present. Implementations MUST preserve the previous non-ASCII characters are present. Implementations MUST preserve the
Subject header as an Original-Subject header. previous Subject header as an Original-Subject header.
If the entire message is being replaced, a ":from" parameter may be If the entire message is being replaced, a ":from" parameter may be
used to specify an alternate address to use in the From field of the used to specify an alternate address to use in the From field of the
message that is generated. The string must specify a valid [4] message that is generated. The string must specify a valid [RFC2822]
mailbox-list. Implementations SHOULD check the syntax and generate mailbox-list. Implementations SHOULD check the syntax and generate
an error when a syntactically invalid ":from" parameter is specified. an error when a syntactically invalid ":from" parameter is specified.
Implementations MAY also impose restrictions on what addresses can Implementations MAY also impose restrictions on what addresses can be
specified in a ":from" parameter; it is suggested that values which specified in a ":from" parameter; it is suggested that values that
fail such a validity check simply be ignored rather than causing the fail such a validity check simply be ignored rather than causing the
vacation action to fail. Implementations MUST preserve the previous vacation action to fail. Implementations MUST preserve the previous
From header as an Original-From header. From header as an Original-From header.
5. Action Enclose 6. Action Enclose
Usage: enclose <:subject string> <:headers string-list> string Usage: enclose <:subject string> <:headers string-list> string
A new sieve action command is defined to allow an entire message to A new SIEVE action command is defined to allow an entire message to
be enclosed as an attachment to a new message. This enclose action be enclosed as an attachment to a new message. This enclose action
takes precedance over all other message modifications, such as takes precedence over all other message modifications, such as
"replace". If multiple "enclose" actions are executed by a script, "replace". If multiple "enclose" actions are executed by a script,
only the text specified on the last one is used when creating the only the text specified on the last one is used when creating the
enclosed message. This action does not affect messages that are enclosed message. This action does not affect messages that are
forwarded via a "redirect" action. forwarded via a "redirect" action.
Specifically, the original message becomes a multipart/mixed message Specifically, the original message becomes a multipart/mixed message
with two parts: a text/plain portion with the string argument as its with two parts: a text/plain portion with the string argument as its
body, and a message/rfc822 portion with the original message body, and a message/rfc822 portion with the original message
enclosed. The Content-Type: header field becomes multipart/mixed. enclosed. The Content-Type: header field becomes multipart/mixed.
The Subject: header is specified by the :subject argument. Any The Subject: header is specified by the :subject argument. Any
headers specified by :headers are copied from the old message into headers specified by :headers are copied from the old message into
the new message. the new message.
6. Sieve Capability Strings 7. SIEVE Capability Strings
A Sieve implementation that defines the "for_every_part" and "break" A SIEVE implementation that defines the "for_every_part" and "break"
actions will advertise the capability string "for_every_part". actions will advertise the capability string "for_every_part".
A Sieve implementation that defines the "mime" test will advertise A SIEVE implementation that defines the ":mime" tagged arguments to
the capability string "mime". the "header", "address" and "exists" commands will advertise the
capability string "mime".
A Sieve implementation that defines the "replace" action will A SIEVE implementation that defines the "replace" action will
advertise the capability string "replace". advertise the capability string "replace".
A Sieve implementation that defines the "enclose" action will A SIEVE implementation that defines the "enclose" action will
advertise the capability string "enclose". advertise the capability string "enclose".
7. Examples 8. Examples
7.1. Example 1 8.1. Example 1
A Sieve script to replace all the Windows executable attachments in a A SIEVE script to replace all the Windows executable attachments in a
message would be: message would be:
require [ "for_every_part", "mime", "replace" ]; require [ "for_every_part", "mime", "replace" ];
for_every_part { for_every_part
if ( anyof ( mime :subtype :is "exe", mime :filename :matches "*.com" ) { {
if ( anyof ( header :mime :subtype :is "Content-Type" "exe",
header :mime :param "filename"
["Content-Type" "Content-Disposition"] :matches "*.com" )
{
replace "Executable attachment removed by user filter"; replace "Executable attachment removed by user filter";
} }
} }
7.2. Example 2 8.2. Example 2
A Sieve script to warn the user about executable attachment types A SIEVE script to warn the user about executable attachment types
would be: would be:
require [ "for_every_part", "mime", "enclose" ]; require [ "for_every_part", "mime", "enclose" ];
for_every_part { for_every_part
if mime :filename :matches ["*.com", "*.exe", "*.vbs", "*.scr", {
"*.pif", "*.hta", "*.bat", "*.zip" ] { if header :mime :param "filename"
["Content-Type" "Content-Disposition"] :matches
["*.com", "*.exe", "*.vbs", "*.scr",
"*.pif", "*.hta", "*.bat", "*.zip" ]
{
# these attachment types are executable # these attachment types are executable
enclose :subject "Warning" " enclose :subject "Warning" "
WARNING! The enclosed message contains executable attachments. WARNING! The enclosed message contains executable attachments.
These attachments types may contain a computer virus program These attachments types may contain a computer virus program
that can infect your computer and potentently damage your data that can infect your computer and potentently damage your data
Before clicking on these message attachments, you should verify with Before clicking on these message attachments, you should verify
the sender that this message was sent by them and not a computer virus. with the sender that this message was sent by them and not a
computer virus.
"; ";
break; break;
} }
} }
8. Acknowledgements 9. Acknowledgements
Comments from members of the MTA Filters Working Group, in particular Comments from members of the MTA Filters Working Group, in particular
Ned Freed, Nigel Swinson and Mark Mallett, are gratefully Ned Freed, Nigel Swinson and Mark Mallett, are gratefully
acknowledged. acknowledged.
9. Security Considerations 10. Security Considerations
To be provided To be provided
10. IANA Considerations 11. IANA Considerations
To be provided To be provided
11. Change History 12. Change History (to be removed prior to publication as an RFC)
11.1. draft-ietf-sieve-mime-00 12.1. draft-ietf-sieve-mime-01
Changed title to emphasize MIME Tests. what happens when nested for_every_loop's
a "mime" shorthand for testing the type/subtype, without requiring
interactions with variables notifications notifications to calendar
service address tests, exists tests mimeheader, mimeparameter tests
12.2. draft-ietf-sieve-mime-00
Changed title and text to emphasize MIME Tests.
Changed for.every.part to for_every_part. Changed for.every.part to for_every_part.
Added :anychild to mime test. Default is to use the current context Added :anychild to mime test. Default is to use the current context
or outer envelope; specifying :anychild will look at all children. or outer envelope; specifying :anychild will look at all children.
Added clarifications to replacing parts affecting the structure. Added clarifications to replacing parts affecting the structure.
Added :mime option to replace, ala draft-ietf-sieve-vacation-06. Added :mime option to replace, ala draft-ietf-sieve-vacation-06.
Various other minor nit fixes. Various other minor nit fixes.
11.2. draft-hansen-sieve-loop-01 12.3. draft-hansen-sieve-loop-01
Merged with draft-daboo-sieve-mime-00.txt. Merged with draft-daboo-sieve-mime-00.txt.
12. Normative References 12.4. draft-hansen-sieve-loop-02
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Update to 3028bis reference.
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Added 2119 conventions section.
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Terminology/title tweaks.
Levels", BCP 14, RFC 2119, March 1997.
[4] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Added informative references to body and editheader extensions.
[5] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, Added description of nested loops.
January 2001.
Replaced mime test by extensions to header, address and exists
tests.
13. References
13.1. Normative References
[I-D.ietf-sieve-3028bis]
Showalter, T. and P. Guenther, "Sieve: An Email Filtering
Language", draft-ietf-sieve-3028bis-09 (work in progress),
August 2006.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
13.2. Informative References
[I-D.ietf-sieve-body]
Guenther, P. and J. Degener, "Sieve Email Filtering: Body
Extension", draft-ietf-sieve-body-04 (work in progress),
August 2006.
[I-D.ietf-sieve-editheader]
Guenther, P. and J. Degener, "Sieve Email Filtering:
Editheader Extension", draft-ietf-sieve-editheader-06
(work in progress), August 2006.
Authors' Addresses Authors' Addresses
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. 200 Laurel Ave.
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+sieveloop@maillennium.att.com Email: tony+sieveloop@maillennium.att.com
Cyrus Daboo Cyrus Daboo
Cyrusoft International, Inc. Apple Computer, Inc.
5001 Baum Blvd. 1 Infinite Loop
Suite 780 Cupertino, CA 95014
Pittsburgh, PA 15213
USA USA
Email: daboo@cyrusoft.com Email: cyrus@daboo.name
URI: http://www.apple.com/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 9, line 29 skipping to change at page 12, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 (2006). 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 69 change blocks. 
157 lines changed or deleted 329 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/