draft-ietf-imapext-sort-13.txt   draft-ietf-imapext-sort-14.txt 
IMAP Extensions Working Group M. Crispin IMAP Extensions Working Group M. Crispin
INTERNET-DRAFT: IMAP SORT K. Murchison INTERNET-DRAFT: IMAP SORT K. Murchison
Document: internet-drafts/draft-ietf-imapext-sort-13.txt May 2003 Document: internet-drafts/draft-ietf-imapext-sort-14.txt December 2003
INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
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 line 35
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A revised version of this document will be submitted to the RFC A revised version of this document will be submitted to the RFC
editor as an Informational Document for the Internet Community. editor as an Informational Document for the Internet Community.
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to and suggestions for improvement are requested, and should be sent to
ietf-imapext@IMC.ORG. This document will expire before 14 November ietf-imapext@IMC.ORG. This document will expire before 1 June 2004.
2003. Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Abstract Abstract
This document describes the base-level server-based sorting and This document describes the base-level server-based sorting and
threading extensions to the [IMAP] protocol. These extensions threading extensions to the [IMAP] protocol. These extensions
provide substantial performance improvements for IMAP clients which provide substantial performance improvements for IMAP clients which
offer sorted and threaded views. offer sorted and threaded views.
1. Introduction
The SORT and THREAD extensions to the [IMAP] protocol provide a means
of server-based sorting and threading of messages, without requiring
that the client download the necessary data to do so itself. This is
particularly useful for online clients as described in [IMAP-MODELS].
A server which supports the base-level SORT extension indicates this A server which supports the base-level SORT extension indicates this
with a capability name which starts with "SORT". Future, with a capability name which starts with "SORT". Future,
upwards-compatible extensions to the SORT extension will all start upwards-compatible extensions to the SORT extension will all start
with "SORT", indicating support for this base level. with "SORT", indicating support for this base level.
A server which supports the THREAD extension indicates this with one A server which supports the THREAD extension indicates this with one
or more capability names consisting of "THREAD=" followed by a or more capability names consisting of "THREAD=" followed by a
supported threading algorithm name as described in this document. supported threading algorithm name as described in this document.
This provides for future upwards-compatible extensions. This provides for future upwards-compatible extensions.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [KEYWORDS]. be interpreted as described in [KEYWORDS].
Base Subject Text The word "can" (not "may") is used to refer to a possible
circumstance or situation, as opposed to an optional facility of the
protocol.
"User" is used to refer to a human user, whereas "client" refers to
the software being run by the user.
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
2.1 Base Subject
Subject sorting and threading use the "base subject," which has Subject sorting and threading use the "base subject," which has
specific subject artifacts of deployed Internet mail software specific subject artifacts of deployed Internet mail software
removed. Due to the complexity of these artifacts, the formal syntax removed. Due to the complexity of these artifacts, the formal syntax
for the subject extraction rules is ambiguous. The following for the subject extraction rules is ambiguous. The following
procedure is followed to determine the actual "base subject" which is procedure is followed to determine the actual "base subject" which is
used to sort by subject: used to sort by subject:
(1) Convert any RFC 2047 encoded-words in the subject to (1) Convert any RFC 2047 encoded-words in the subject to
UTF-8 as described in "internationalization UTF-8 as described in "internationalization
skipping to change at page 3, line 42 skipping to change at line 115
Note: it is possible to defer step (2) until step (6), but this Note: it is possible to defer step (2) until step (6), but this
requires checking for subj-trailer in step (4). requires checking for subj-trailer in step (4).
(6) If the resulting text begins with the subj-fwd-hdr ABNF (6) If the resulting text begins with the subj-fwd-hdr ABNF
and ends with the subj-fwd-trl ABNF, remove the and ends with the subj-fwd-trl ABNF, remove the
subj-fwd-hdr and subj-fwd-trl and repeat from step (2). subj-fwd-hdr and subj-fwd-trl and repeat from step (2).
(7) The resulting text is the "base subject" used in the (7) The resulting text is the "base subject" used in the
SORT. SORT.
All servers and disconnected clients MUST use exactly this algorithm All servers and disconnected (as described in [IMAP-MODEL] clients
when sorting by subject. Otherwise there is potential for a user to MUST use exactly this algorithm when sorting by subject. Otherwise
get inconsistent results based on whether they are running in there is potential for a user to get inconsistent results based on
connected or disconnected IMAP mode. whether they are running in connected or disconnected IMAP mode.
Sent Date 2.2 Sent Date
As used in this document, the term "sent date" refers to the date and As used in this document, the term "sent date" refers to the date and
time from the Date: header, adjusted by time zone. This differs from time from the Date: header, adjusted by time zone to normalize to UTC.
date-related criteria in SEARCH, which use just the date and not the For example, "31 Dec 2000 16:01:33 -0800" is equivalent to the UTC
time, nor adjusts by time zone. date and time of "1 Jan 2001 00:01:33 +0000".
Additional Commands If the time zone is invalid, the date and time SHOULD be treated as UTC.
If the time is also invalid, the time SHOULD be treated as 00:00:00. If
there is no valid date or time, the date and time SHOULD be treated as
00:00:00 on the earliest possible date.
These commands are extension to the IMAP4rev1 base protocol. This differs from the date-related criteria in SEARCH, which use just
the date and not the time, and are not adjusted by time zone.
3. Additional Commands
These commands are extension to the [IMAP] base protocol.
The section headings are intended to correspond with where they would The section headings are intended to correspond with where they would
be located in the main document if they were part of the base be located in the main document if they were part of the base
specification. specification.
6.4.SORT. SORT Command BASE.6.4.SORT. SORT Command
Arguments: sort program Arguments: sort program
charset specification charset specification
searching criteria (one or more) searching criteria (one or more)
Data: untagged responses: SORT Data: untagged responses: SORT
Result: OK - sort completed Result: OK - sort completed
NO - sort error: can't sort that charset or NO - sort error: can't sort that charset or
criteria criteria
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The SORT command is a variant of SEARCH with sorting semantics for The SORT command is a variant of SEARCH with sorting semantics for
the results. Sort has two arguments before the searching criteria the results. Sort has two arguments before the searching criteria
argument; a parenthesized list of sort criteria, and the searching argument; a parenthesized list of sort criteria, and the searching
charset. charset.
Note that unlike SEARCH, the searching charset argument is The charset argument is mandatory (unlike SEARCH) and indicates
mandatory. The US-ASCII and UTF-8 charsets MUST be implemented. the [CHARSET] of the strings that appear in the searching criteria.
All other charsets are optional. The US-ASCII and UTF-8 charsets MUST be implemented. All other
charsets are optional.
There is also a UID SORT command which corresponds to SORT the way There is also a UID SORT command which corresponds to SORT the way
that UID SEARCH corresponds to SEARCH. that UID SEARCH corresponds to SEARCH.
The SORT command first searches the mailbox for messages that The SORT command first searches the mailbox for messages that
match the given searching criteria using the charset argument for match the given searching criteria using the charset argument for
the interpretation of strings in the searching criteria. It then the interpretation of strings in the searching criteria. It then
returns the matching messages in an untagged SORT response, sorted returns the matching messages in an untagged SORT response, sorted
according to one or more sort criteria. according to one or more sort criteria.
skipping to change at page 6, line 24 skipping to change at line 249
Example: C: A282 SORT (SUBJECT) UTF-8 SINCE 1-Feb-1994 Example: C: A282 SORT (SUBJECT) UTF-8 SINCE 1-Feb-1994
S: * SORT 2 84 882 S: * SORT 2 84 882
S: A282 OK SORT completed S: A282 OK SORT completed
C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 ALL C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 ALL
S: * SORT 5 3 4 1 2 S: * SORT 5 3 4 1 2
S: A283 OK SORT completed S: A283 OK SORT completed
C: A284 SORT (SUBJECT) US-ASCII TEXT "not in mailbox" C: A284 SORT (SUBJECT) US-ASCII TEXT "not in mailbox"
S: * SORT S: * SORT
S: A284 OK SORT completed S: A284 OK SORT completed
6.4.THREAD. THREAD Command BASE.6.4.THREAD. THREAD Command
Arguments: threading algorithm Arguments: threading algorithm
charset specification charset specification
searching criteria (one or more) searching criteria (one or more)
Data: untagged responses: THREAD Data: untagged responses: THREAD
Result: OK - thread completed Result: OK - thread completed
NO - thread error: can't thread that charset or NO - thread error: can't thread that charset or
criteria criteria
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The THREAD command is a variant of SEARCH with threading semantics The THREAD command is a variant of SEARCH with threading semantics
for the results. Thread has two arguments before the searching for the results. Thread has two arguments before the searching
criteria argument; a threading algorithm, and the searching criteria argument; a threading algorithm, and the searching
charset. charset.
Note that unlike SEARCH, the searching charset argument is The charset argument is mandatory (unlike SEARCH) and indicates
mandatory. The US-ASCII and UTF-8 charsets MUST be implemented. the [CHARSET] of the strings that appear in the searching criteria.
All other charsets are optional. The US-ASCII and UTF-8 charsets MUST be implemented. All other
charsets are optional.
There is also a UID THREAD command which corresponds to THREAD the There is also a UID THREAD command which corresponds to THREAD the
way that UID SEARCH corresponds to SEARCH. way that UID SEARCH corresponds to SEARCH.
The THREAD command first searches the mailbox for messages that The THREAD command first searches the mailbox for messages that
match the given searching criteria using the charset argument for match the given searching criteria using the charset argument for
the interpretation of strings in the searching criteria. It then the interpretation of strings in the searching criteria. It then
returns the matching messages in an untagged THREAD response, returns the matching messages in an untagged THREAD response,
threaded according to the specified threading algorithm. threaded according to the specified threading algorithm.
skipping to change at page 7, line 30 skipping to change at line 304
messages with the same base subject text. Finally, the threads messages with the same base subject text. Finally, the threads
are sorted by the sent date of the first message in the thread. are sorted by the sent date of the first message in the thread.
The first message of each thread are siblings of each other The first message of each thread are siblings of each other
(the "root"). The second message of a thread is the child of (the "root"). The second message of a thread is the child of
the first message, and subsequent messages of the thread are the first message, and subsequent messages of the thread are
siblings of the second message and hence children of the siblings of the second message and hence children of the
message at the root. Hence, there are no grandchildren in message at the root. Hence, there are no grandchildren in
ORDEREDSUBJECT threading. ORDEREDSUBJECT threading.
Note: earlier versions of this specification specified Note: early drafts of this specification specified
that each message in an ORDEREDSUBJECT thread is a child that each message in an ORDEREDSUBJECT thread is a child
(as opposed to a sibling) of the previous message. This (as opposed to a sibling) of the previous message. This
is now deprecated. For compatibility with servers which is now deprecated. For compatibility with servers which
may still use the old definition, client implementations may still use the old definition, client implementations
SHOULD treat descendents of a child as being siblings of SHOULD treat descendents of a child as being siblings of
that child. that child.
This is because the old definition mistakenly indicated This is because the old definition mistakenly indicated
that there was a parent/child relationship between that there was a parent/child relationship between
successive messages in a thread; when in fact there was successive messages in a thread; when in fact there was
skipping to change at page 14, line 5 skipping to change at line 566
(171)(173)((174)(175)(176)(178)(181)(180)) (171)(173)((174)(175)(176)(178)(181)(180))
((177)(183)(182)(188 (184)(189))(185 186)(187)) ((177)(183)(182)(188 (184)(189))(185 186)(187))
(190)(191)(192)(193)((194)(195 196))(197 198) (190)(191)(192)(193)((194)(195 196))(197 198)
(199)(200 202)(201)(203)(204)(205 206 207)(208) (199)(200 202)(201)(203)(204)(205 206 207)(208)
S: A285 OK THREAD completed S: A285 OK THREAD completed
Note: The line breaks in the first and third client Note: The line breaks in the first and third client
responses are for editorial clarity and do not appear in responses are for editorial clarity and do not appear in
real THREAD responses. real THREAD responses.
Additional Responses 4. Additional Responses
These responses are extensions to the IMAP4rev1 base protocol. These responses are extensions to the [IMAP] base protocol.
The section headings of these responses are intended to correspond The section headings of these responses are intended to correspond
with where they would be located in the main document. with where they would be located in the main document.
7.2.SORT. SORT Response BASE.7.2.SORT. SORT Response
Data: zero or more numbers Data: zero or more numbers
The SORT response occurs as a result of a SORT or UID SORT The SORT response occurs as a result of a SORT or UID SORT
command. The number(s) refer to those messages that match the command. The number(s) refer to those messages that match the
search criteria. For SORT, these are message sequence numbers; search criteria. For SORT, these are message sequence numbers;
for UID SORT, these are unique identifiers. Each number is for UID SORT, these are unique identifiers. Each number is
delimited by a space. delimited by a space.
Example: S: * SORT 2 3 6 Example: S: * SORT 2 3 6
7.2.THREAD. THREAD Response BASE.7.2.THREAD. THREAD Response
Data: zero or more threads Data: zero or more threads
The THREAD response occurs as a result of a THREAD or UID THREAD The THREAD response occurs as a result of a THREAD or UID THREAD
command. It contains zero or more threads. A thread consists of command. It contains zero or more threads. A thread consists of
a parenthesized list of thread members. a parenthesized list of thread members.
Thread members consist of zero or more message numbers, delimited Thread members consist of zero or more message numbers, delimited
by spaces, indicating successive parent and child. This continues by spaces, indicating successive parent and child. This continues
until the thread splits into multiple sub-threads, at which point until the thread splits into multiple sub-threads, at which point
skipping to change at page 16, line 5 skipping to change at line 632
\-- 44 \-- 44
\-- 7 \-- 7
\-- 96 \-- 96
Example: S: * THREAD ((3)(5)) Example: S: * THREAD ((3)(5))
In this example, 3 and 5 are siblings of a parent which does not In this example, 3 and 5 are siblings of a parent which does not
match the search criteria (and/or does not exist in the mailbox); match the search criteria (and/or does not exist in the mailbox);
however they are members of the same thread. however they are members of the same thread.
Formal Syntax of SORT and THREAD commands and Responses 5. Formal Syntax of SORT and THREAD Commands and Responses
sort = ["UID" SP] "SORT" SP The following syntax specification uses the Augmented Backus-Naur
"(" sort-criterion *(SP sort-criterion) ")" Form (ABNF) notation as specified in [ABNF]. It also uses [ABNF]
SP charset 1*(SP search-key) rules defined in [IMAP].
sort = ["UID" SP] "SORT" SP sort-criteria SP search-criteria
sort-criteria = "(" sort-criterion *(SP sort-criterion) ")"
sort-criterion = ["REVERSE" SP] sort-key sort-criterion = ["REVERSE" SP] sort-key
sort-key = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" / sort-key = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" /
"SUBJECT" / "TO" "SUBJECT" / "TO"
thread = ["UID" SP] "THREAD" SP thread-algorithm
SP charset 1*(SP search-key)
thread-algorithm = "ORDEREDSUBJECT" / "REFERENCES" / atom thread = ["UID" SP] "THREAD" SP thread-alg SP search-criteria
thread-alg = "ORDEREDSUBJECT" / "REFERENCES" / thread-alg-ext
thread-alg-ext = atom
; New algorithms MUST be registered with IANA
; as standard or standards-track
search-criteria = charset 1*(SP search-key)
charset = astring charset = astring
; CHARSET argument to MUST be registered with IANA ; CHARSET values MUST be registered with IANA
sort-data = "SORT" *(SP nz-number) sort-data = "SORT" *(SP nz-number)
thread-data = "THREAD" [SP 1*thread-list] thread-data = "THREAD" [SP 1*thread-list]
thread-list = "(" thread-members / thread-nested ")" thread-list = "(" thread-members / thread-nested ")"
thread-members = nz-number *(SP nz-number) [SP thread-nested] thread-members = nz-number *(SP nz-number) [SP thread-nested]
thread-nested = 2*thread-list thread-nested = 2*thread-list
skipping to change at page 17, line 19 skipping to change at line 701
subj-base = NONWSP *([*WSP] NONWSP) subj-base = NONWSP *([*WSP] NONWSP)
; can be a subj-blob ; can be a subj-blob
BLOBCHAR = %x01-5a / %x5c / %x5e-7f BLOBCHAR = %x01-5a / %x5c / %x5e-7f
; any CHAR except '[' and ']' ; any CHAR except '[' and ']'
NONWSP = %x01-08 / %x0a-1f / %x21-7f NONWSP = %x01-08 / %x0a-1f / %x21-7f
; any CHAR other than WSP ; any CHAR other than WSP
Security Considerations 6. Security Considerations
The SORT and THREAD extensions do not raise any security The SORT and THREAD extensions do not raise any security
considerations that are not present in the base [IMAP] protocol, and considerations that are not present in the base [IMAP] protocol, and
these issues are discussed in [IMAP]. Nevertheless, it is important these issues are discussed in [IMAP]. Nevertheless, it is important
to remember that IMAP4rev1 protocol transactions, including to remember that [IMAP] protocol transactions, including
electronic mail data, are sent in the clear over the network unless electronic mail data, are sent in the clear over the network unless
protection from snooping is negotiated, either by the use of protection from snooping is negotiated, either by the use of
STARTTLS, privacy protection is negotiated in the AUTHENTICATE STARTTLS, privacy protection is negotiated in the AUTHENTICATE
command, or some other protection mechanism is in effect. command, or some other protection mechanism is in effect.
Internationalization Considerations 7. Internationalization Considerations
Strings in charsets other than US-ASCII and UTF-8 must be converted Strings in charsets other than US-ASCII and UTF-8 must be converted
to UTF-8 prior to any comparisons. String comparisons used in SORT to UTF-8 prior to any comparisons. String comparisons used in SORT
and THREAD collations are performed as described in [IMAP-I18N]. and THREAD collations are performed as described in [IMAP-I18N].
Non-English translations of "Re" or "Fw"/"Fwd" are not specified for Non-English translations of "Re" or "Fw"/"Fwd" are not specified for
removal in the base subject extraction process. By specifying that removal in the base subject extraction process. By specifying that
only the English forms of the prefixes are used, it becomes a simple only the English forms of the prefixes are used, it becomes a simple
display time task to localize the prefix language for the user. If, display time task to localize the prefix language for the user. If,
on the other hand, prefixes in multiple languages are permitted, the on the other hand, prefixes in multiple languages are permitted, the
result is a geometrically complex, and ultimately unimplementable, result is a geometrically complex, and ultimately unimplementable,
task. In order to improve the ability to support non-English display task. In order to improve the ability to support non-English display
in Internet mail clients, only the English form of these prefixes in Internet mail clients, only the English form of these prefixes
should be transmitted in Internet mail messages. should be transmitted in Internet mail messages.
12. IANA Considerations 8. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or [IMAP] capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located IESG approved experimental RFC. The registry is currently located
at: at:
http://www.iana.org/assignments/imap4-capabilities http://www.iana.org/assignments/imap4-capabilities
This document consitutes registration of the SORT and THREAD IMAP Threading algorithms are registered by publishing a standards track or
capabilities, as well as the ORDEREDSUBJECT and REFERENCES IMAP IESG approved experimental RFC. The registry is currently located at:
threading algorithms.
A. References [to be defined by IANA]
This document consitutes registration of the SORT and THREAD
capabilities in the [IMAP] capabilities registry, as well as the
ORDEREDSUBJECT and REFERENCES algorithms in the [IMAP] threading
algorithms registry.
Appendices
A. Normative References
The following documents are normative to this document: The following documents are normative to this document:
[ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax [ABNF] Crocker, D., and Overell, P. "Augmented BNF
Specifications: ABNF", RFC 2234, November 1997. for Syntax Specifications: ABNF", RFC 2234,
November 1997.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version [CHARSET] Freed, N. and J. Postel, "IANA Character Set
4rev1", RFC 3501, March 2003. Registration Procedures", RFC 2978, October
2000.
[IMAP] Crispin, M., "Internet Message Access Protocol -
Version 4rev1", RFC 3501, March 2003.
[IMAP-I18N] Newman, C. "Internet Message Access Protocol [IMAP-I18N] Newman, C. "Internet Message Access Protocol
Internationalization", Work in Progress. Internationalization", Work in Progress.
[KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S. "Key words for use in RFCs to
Requirement Levels", RFC 2119, Harvard University, March 1997. Indicate Requirement Levels", RFC 2119, Harvard
University, March 1997.
[RFC-2822] Resnick, P. "Internet Message Format", RFC 2822, April [RFC-2822] Resnick, P. "Internet Message Format", RFC 2822,
2001. April 2001.
B. Informative References
The following documents are informative to this document: The following documents are informative to this document:
[THREADING] Zawinski, J. "message threading", [IMAP-MODELS] Crispin, M., "Distributed Electronic Mail Models
in IMAP4", RFC 1733, December 1994.
[THREADING] Zawinski, J. "Message Threading",
http://www.jwz.org/doc/threading.html, 1997-2002. http://www.jwz.org/doc/threading.html, 1997-2002.
Author's Address Author's Address
Mark R. Crispin Mark R. Crispin
Networks and Distributed Computing Networks and Distributed Computing
University of Washington University of Washington
4545 15th Avenue NE 4545 15th Avenue NE
Seattle, WA 98105-4527 Seattle, WA 98105-4527
skipping to change at line 741 skipping to change at line 803
EMail: MRC@CAC.Washington.EDU EMail: MRC@CAC.Washington.EDU
Kenneth Murchison Kenneth Murchison
Oceana Matrix Ltd. Oceana Matrix Ltd.
21 Princeton Place 21 Princeton Place
Orchard Park, NY 14127 Orchard Park, NY 14127
Phone: (716) 662-8973 x26 Phone: (716) 662-8973 x26
EMail: ken@oceana.com EMail: ken@oceana.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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