remove draft-* but refer www.fml.org if needed

85 files changed, 1 insertions, 39007 deletions

diff --git a/Documentation/en/I-D/.htaccess b/Documentation/en/I-D/.htaccess
new file mode 100644
index 00000000..117d92e8
--- /dev/null
+++ b/Documentation/en/I-D/.htaccess
@@ -0,0 +1 @@
+Redirect /software/fml-devel/Documentation/en/I-D/ http://www.fml.org/home/fukachan/tech/IETF/I-D/
diff --git a/Documentation/en/I-D/00_COMMIT_LIST b/Documentation/en/I-D/00_COMMIT_LIST
deleted file mode 100644
index 6de5968c..00000000
--- a/Documentation/en/I-D/00_COMMIT_LIST
+++ /dev/null
@@ -1,128 +0,0 @@
-draft-bernstein-eplf-02.txt
-draft-bernstein-hcmssc-02.txt
-draft-bernstein-mail-loops-war-02.txt
-draft-bernstein-mpls-sonet-00.txt
-draft-bernstein-netstrings-02.txt
-draft-bernstein-nrudt-02.txt
-draft-bernstein-owner-hack-01.txt
-draft-bernstein-pirp-02.txt
-draft-bernstein-qmtp-01.txt
-draft-bernstein-qsbmf-02.txt
-draft-bose-smtp-integrity-00.txt
-draft-burger-vpim-cc-00.txt
-draft-burger-vpim-cc-01.txt
-draft-burger-vpim-pc-00.txt
-draft-burger-vpim-pc-01.txt
-draft-earhart-url-smtp-00.txt
-draft-ema-vpim-pndn-03.txt
-draft-freed-bsmtp-00.txt
-draft-freed-bsmtp-01.txt
-draft-freed-bsmtp-02.txt
-draft-freed-smtp-pipe-00.txt
-draft-freed-smtp-pipe-01.txt
-draft-freed-smtp-pipeline-02.txt
-draft-hoffman-legis-smtp-banner-00.txt
-draft-hoffman-legis-smtp-banner-01.txt
-draft-hoffman-legis-smtp-banner-02.txt
-draft-hoffman-legis-smtp-banner-03.txt
-draft-hoffman-rfc2487bis-00.txt
-draft-hoffman-rfc2487bis-02.txt
-draft-hoffman-rfc2487bis-03.txt
-draft-hoffman-rfc2487bis-04.txt
-draft-hoffman-rfc2487bis-05.txt
-draft-hoffman-smtp-ssl-05.txt
-draft-hoffman-smtp-ssl-06.txt
-draft-hoffman-smtp-ssl-07.txt
-draft-hoffman-smtp-ssl-08.txt
-draft-hoffman-smtp-ssl-09.txt
-draft-hoffman-smtp-ssl-10.txt
-draft-huitema-shipworm-00.txt
-draft-ietf-drums-smtpupd-06.txt
-draft-ietf-drums-smtpupd-07.txt
-draft-ietf-drums-smtpupd-08.txt
-draft-ietf-drums-smtpupd-09.txt
-draft-ietf-drums-smtpupd-10.txt
-draft-ietf-drums-smtpupd-11.txt
-draft-ietf-drums-smtpupd-12.txt
-draft-ietf-drums-smtpupd-13.txt
-draft-ietf-fax-esmtp-conneg-00.txt
-draft-ietf-fax-smtp-capabilities-00.txt
-draft-ietf-fax-smtp-capabilities-01.txt
-draft-ietf-fax-smtp-session-02.txt
-draft-ietf-fax-smtp-session-03.txt
-draft-ietf-fax-smtp-session-04.txt
-draft-ietf-impp-datetime-00.txt
-draft-ietf-ipngwg-dns-discovery-analysis-00.txt
-draft-ietf-ldapbis-url-00.txt
-draft-ietf-mailext-mail-attributes-07.txt
-draft-ietf-msgtrk-model-00.txt
-draft-ietf-msgtrk-model-01.txt
-draft-ietf-msgtrk-model-02.txt
-draft-ietf-msgtrk-model-03.txt
-draft-ietf-msgtrk-mtqp-00.txt
-draft-ietf-msgtrk-mtqp-01.txt
-draft-ietf-msgtrk-mtqp-02.txt
-draft-ietf-msgtrk-protocol-00.txt
-draft-ietf-msgtrk-protocol-05.txt
-draft-ietf-msgtrk-smtpext-00.txt
-draft-ietf-msgtrk-smtpext-01.txt
-draft-ietf-msgtrk-trkstat-00.txt
-draft-ietf-msgtrk-trkstat-01.txt
-draft-ietf-ngtrans-ipv6-smtp-requirement-00.txt
-draft-ietf-ngtrans-ipv6-smtp-requirement-01.txt
-draft-ietf-palme-select-00.txt
-draft-ietf-vpim-cc-00.txt
-draft-ietf-vpim-cc-01.txt
-draft-ietf-vpim-cc-02.txt
-draft-ietf-vpim-cc-03.txt
-draft-ietf-vpim-cc-04.txt
-draft-ietf-vpim-hint-00.txt
-draft-ietf-vpim-hint-00.txt.gz
-draft-ietf-vpim-hint-01.txt
-draft-ietf-vpim-hint-01.txt.gz
-draft-ietf-vpim-hint-02.txt
-draft-ietf-vpim-hint-02.txt.gz
-draft-ietf-vpim-hint-03.txt
-draft-ietf-vpim-hint-03.txt.gz
-draft-ietf-vpim-hint-04.txt
-draft-ietf-vpim-hint-04.txt.gz
-draft-ietf-vpim-pndn-00.txt
-draft-ietf-vpim-pndn-01.txt
-draft-jones-msgtrk-def-00.txt
-draft-jones-msgtrk-def-01.txt
-draft-jones-msgtrk-def-02.txt
-draft-khanna-smtp-mail-transfer-reliability-00.txt
-draft-melnikov-esmtp-lang-00.txt
-draft-melnikov-smtp-lang-00.txt
-draft-melnikov-smtp-lang-01.txt
-draft-melnikov-smtp-lang-02.txt
-draft-melnikov-smtp-lang-03.txt
-draft-motonori-ipv6-smtp-requirement-00.txt
-draft-myers-smtp-auth-11.txt
-draft-myers-smtp-auth-12.txt
-draft-newman-datetime-01.txt
-draft-onions-priority-smtpext-00.txt
-draft-palme-MHRegistry-00.txt
-draft-palme-autosub-03.txt
-draft-palme-e-mail-translation-00.txt
-draft-palme-int-print-04.txt
-draft-palme-mailext-headers-03.txt
-draft-palme-maillist-00.txt
-draft-palme-newfields-info-02.txt
-draft-palme-newsmail-00.txt
-draft-palme-select-00.txt
-draft-palme-supersedes-00.txt
-draft-varshavchik-data-smtpext-01.txt
-draft-varshavchik-data-smtpext-02.txt
-draft-varshavchik-verp-smtpext-01.txt
-draft-varshavchik-verp-smtpext-02.txt
-draft-vaudreuil-esmtp-binary2-00.txt
-draft-vaudreuil-esmtp-binary2-01.txt
-draft-vaudreuil-esmtp-binary2-02.txt
-draft-vaudreuil-esmtp-binary2-03.txt
-draft-ward-esmtp-slide-00.txt
-draft-ward-esmtp-slide-01.txt
-draft-ward-esmtp-slide-02.txt
-draft-ward-esmtp-slide-03.txt
-draft-ward-esmtp-slide-04.txt
-draft-wing-smtp-capabilities-00.txt
diff --git a/Documentation/en/I-D/draft-bernstein-eplf-02.txt b/Documentation/en/I-D/draft-bernstein-eplf-02.txt
deleted file mode 100644
index 59f9621d..00000000
--- a/Documentation/en/I-D/draft-bernstein-eplf-02.txt
+++ /dev/null
@@ -1,258 +0,0 @@
-
-Easily Parsed LIST Format (EPLF)
-
-INTERNET-DRAFT   draft-bernstein-eplf-02.txt   (expires 1 August 1997)
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups. Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-Status of this memo
-
-   This memo provides information for the Internet community. This memo
-   does not specify an Internet standard of any kind. Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   The File Transfer Protocol (FTP) supports two commands that list
-   files: NLST and LIST. The NLST response is easy to parse but provides
-   very little information. The LIST response provides more information,
-   but in a format that varies from system to system. The most common
-   LIST formats are undocumented and impossible to parse reliably.
-
-   This document defines Easily Parsed LIST Format (EPLF), a format
-   for the LIST response that is usable by humans yet easy for programs
-   to handle. This format is supported by anonftpd, a secure FTP server.
-
-   One visible advantage of EPLF is that a browser can easily display
-   dates in the viewer's time zone and native language. EPLF also makes
-   it straightforward for an indexing program to automatically traverse
-   an FTP area and for a mirroring program to avoid downloading the same
-   file twice.
-
-
-Easily Parsed LIST Format (EPLF)
-D. J. Bernstein, djb@pobox.com
-19970201
-
-
-1. Introduction
-
-   The File Transfer Protocol (FTP) supports two commands that list
-   files: NLST and LIST. The NLST response is easy to parse but provides
-   very little information. The LIST response provides more information,
-   but in a format that varies from system to system. The most common
-   LIST formats are undocumented and impossible to parse reliably.
-
-   This document defines Easily Parsed LIST Format (EPLF), a format
-   for the LIST response that is usable by humans yet easy for programs
-   to handle. This format is supported by anonftpd, a secure FTP server.
-
-   One visible advantage of EPLF is that a browser can easily display
-   dates in the viewer's time zone and native language. EPLF also makes
-   it straightforward for an indexing program to automatically traverse
-   an FTP area and for a mirroring program to avoid downloading the same
-   file twice.
-
-   EPLF also corrects a design flaw in FTP's handling of LIST arguments.
-   An EPLF server must respond to ``LIST filename'' with information
-   about that file and no others, even if that file is a directory. A
-   client that wants an EPLF list of the contents of a directory must
-   first CWD to that directory. A client that merely wants a list of
-   file names in a different directory may use NLST.
-
-   In this document, a string of 8-bit bytes may be written in two
-   different forms: as a series of hexadecimal numbers between angle
-   brackets, or as a sequence of ASCII characters between double quotes.
-   For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of
-   length 12; it is the same as the string "hello world!".
-
-
-2. Format
-
-   An EPLF response to LIST is a series of lines, each line specifying a
-   different file. Each line begins with "+", continues with a series of
-   facts about the file, and ends with <09> followed by the file name.
-   Each fact is zero or more bytes of information, terminated by "," and
-   not containing <09>.
-
-   There are several possible facts, each of which appears at most once,
-   in any order:
-
-      "r"
-         If this file name is supplied in a RETR command, the RETR
-         should succeed. The server must supply this fact unless it is
-         aware of file type problems, permission problems, or other
-         reasons that RETR will fail. The presence of "r" does not
-         guarantee success: for example, the file may be removed or
-         renamed, or the RETR may suffer a temporary failure.
-
-      "/"
-         If this file name is supplied in a CWD command, the CWD should
-         succeed. As with "r", the server must supply this fact unless
-         it is aware of reasons that CWD will fail. The presence of "/"
-         does not guarantee success.
-
-      "i"[ident]
-         This file has identifier [ident]. [ident] is a sequence of
-         bytes not including "," or <09>. If two files on the same FTP
-	 server (not necessarily in the same LIST response) have the
-	 same [ident], those files have the same contents; a successful
-         RETR of each file should produce the same results, and a
-         successful CWD to each file should lead to the same working
-         directory. (Under UNIX, for example, [dev].[ino] could be used
-	 as [ident], where [dev] and [ino] are the device number and
-	 inode number of the file.)
-
-      "s"[size]
-         The size of this file is [size]. [size] is a sequence of ASCII
-         digits specifying a number. If the file is retrieved in TYPE I
-         and is not modified, it will contain exactly [size] bytes. This
-         fact should not be supplied if "r" is not supplied.
-
-      "m"[time]
-         This file was last modified at [time]. [time] is a sequence of
-         ASCII digits specifying a number of seconds, real time, since
-         the beginning of 1970 GMT. This fact cannot be used for files
-         modified before 1970 GMT.
-
-   Further facts may be defined in the future. Pieces of the fact-space
-   beginning with "x" will be parcelled out to organizations that would
-   like to define their own facts. Facts beginning with "X" are reserved
-   for experimental use.
-
-   All facts other than "/" and "r" are optional. Any statement of
-   adherence to EPLF by a server FTP implementation must include a list
-   of facts supported by that implementation other than "/" and "r".
-
-   The server is under no obligation to ensure that LISTs in different
-   directories produce disjoint lists of targets. For example, some
-   servers may list a special ".." name that refers to the parent
-   directory, or a "/" name that refers to the top directory. To avoid
-   loops, a client attempting to traverse the FTP area must notice that
-   the identifiers of these directories are the same as identifiers of
-   directories already traversed.
-
-   The server is also under no obligation to list all possible targets
-   of RETR or CWD in a LIST command. Some servers may avoid listing
-   special names such as ".." or "/". A client that wishes to return to
-   a directory must use PWD and record the reply rather than relying on
-   any useful meaning of CDUP, CWD .., or CWD /.
-
-   Operating systems support a wide variety of means for obtaining the
-   contents of a file from its name. For example, many systems support
-   symbolic links: if ONE is a link to TWO, any reference to ONE is
-   first replaced by a reference to TWO. Such information is irrelevant
-   to FTP and is not displayed by any of the above facts. (Under UNIX
-   this means that the server should use stat(), not lstat().)
-
-   Servers are permitted to use arbitrary characters in file names,
-   except for <0a> and <0d>. Beware that the characters <00>, <09>,
-   <20>, and <ff> cause all sorts of trouble, ranging from inadequacies
-   in the syntax of FTP commands to misinterpretation by some clients.
-
-
-3. Examples
-
-   Here is a typical EPLF response:
-
-      "+i8388621.48594,m825718503,r,s280," <09> "djb.html" <0d 0a>
-      "+i8388621.50690,m824255907,/," <09> "514" <0d 0a>
-      "+i8388621.48598,m824253270,r,s612," <09> "514.html" <0d 0a>
-
-   A typical EPLF-ignorant client will show the response to the user:
-
-      ftp> dir
-      200 Okay.
-      150 I'm looking through the directory. Trying to connect...
-      +i8388621.48594,m825718503,r,s280,      djb.html
-      +i8388621.50690,m824255907,/,   514
-      +i8388621.48598,m824253270,r,s612,      514.html
-      226 Finished transferring 127 bytes.
-      ftp> 
-
-   A more sophisticated client (in the Pacific timezone) might instead
-   display the following human-readable listing:
-
-                         Tue Feb 13 15:58:27 1996   514/
-             612 bytes   Tue Feb 13 15:14:30 1996   514.html
-             280 bytes   Fri Mar  1 14:15:03 1996   djb.html
-
-
-4. Sample code
-
-   The following C function takes a pointer to a string containing one
-   line of an EPLF response. It assumes that the original response did
-   not contain <00>, and that the trailing <0d 0a> has been replaced by
-   <00>. It returns a pointer to the filename, or 0 if the line does not
-   appear to be an EPLF response.
-
-      char *eplf_name(line) char *line;
-      {
-       if (*line != 43) return 0;
-       while (*line) if (*line++ == 9) return line;
-       return 0;
-      }
-
-   The following C function takes a pointer as above, and prints a
-   human-readable listing as shown in section 3. It assumes that the
-   local character set is ASCII, that file modification times fit into a
-   local time_t, and that file sizes fit into a local unsigned long. It
-   also assumes that time_t is interpreted as a number of seconds since
-   the beginning of 1970 GMT. (A more portable function could use
-   mktime() to discover the time_t representation of 1970 GMT.) Note
-   that its output is not machine-readable, since the file name might
-   contain the local newline sequence.
-
-      #include <time.h>
-      int eplf_readable(line) char *line;
-      {
-       int flagcwd = 0; time_t when = 0;
-       int flagsize = 0; unsigned long size;
-       if (*line++ != '+') return 0;
-       while (*line)
-         switch (*line)
-          {
-           case '\t':
-             if (flagsize) printf("%10lu bytes   ",size);
-             else printf("                   ");
-             if (when) printf("%24.24s",ctime(&when));
-             else printf("                        ");
-             printf("   %s%s\n",line + 1,flagcwd ? "/" : "");
-             return 1;
-           case 's':
-             flagsize = 1; size = 0;
-             while (*++line && (*line != ','))
-               size = size * 10 + (*line - '0');
-             break;
-           case 'm':
-             while (*++line && (*line != ','))
-               when = when * 10 + (*line - '0');
-             break;
-           case '/':
-             flagcwd = 1;
-           default:
-             while (*line) if (*line++ == ',') break;
-          }
-       return 0;
-      }
-
-
-5. Acknowledgments
-
-   Thanks to Scott Schwartz for pointing out that "i"[ident] was
-   originally overspecified. Thanks to Benjamin Riefenstahl for
-   several helpful suggestions.
diff --git a/Documentation/en/I-D/draft-bernstein-eplf-06.txt b/Documentation/en/I-D/draft-bernstein-eplf-06.txt
deleted file mode 100644
index 21103c84..00000000
--- a/Documentation/en/I-D/draft-bernstein-eplf-06.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-D. Bernstein: djb@pobox.com                                                           

-

-

diff --git a/Documentation/en/I-D/draft-bernstein-hcmssc-02.txt b/Documentation/en/I-D/draft-bernstein-hcmssc-02.txt
deleted file mode 100644
index 2c598afb..00000000
--- a/Documentation/en/I-D/draft-bernstein-hcmssc-02.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-
-The Hash Convention For Mail System Status Codes (HCMSSC)
-
-INTERNET-DRAFT   draft-bernstein-hcmssc-02.txt   (expires 1 August 1997)
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups. Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-Status of this memo
-
-   This memo provides information for the Internet community. This memo
-   does not specify an Internet standard of any kind. Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   RFC 1893 defines codes for mail delivery failures. For example,
-   code 5.1.1 means that the specified mailbox does not exist.
-
-   The qmail package sprays these codes all over the place, by adding a
-   code to the text of every error message, preceded by a hash mark and
-   surrounded by parentheses. It avoids using hash marks elsewhere.
-
-
-The Hash Convention For Mail System Status Codes (HCMSSC)
-D. J. Bernstein, djb@pobox.com
-19970201
-
-
-1. Introduction
-
-   RFC 1893 defines codes for mail delivery failures. For example,
-   code 5.1.1 means that the specified mailbox does not exist.
-
-   The qmail package sprays these codes all over the place, by adding a
-   code to the text of every error message, preceded by a hash mark and
-   surrounded by parentheses. It avoids using hash marks elsewhere.
-
-
-2. Examples
-
-   Here is a typical HCMSSC SMTP error message:
-
-      421 load average too high, please come back later (#4.3.2)
-
-   Here is part of a typical HCMSSC bounce message:
-
-      <mail-loop@silverton.berkeley.edu>:
-      This is looping; it already has my Delivered-To line. (#5.7.1)
-
-   But qmail doesn't use HCMSSC when it repeats another MTA's error
-   message:
-
-      <foo@heaven.af.mil>:
-      127.3.4.5 does not like recipient.
-      Remote host said: 550 <foo>... User unknown (#5.1.1)
-
-
-3. Security considerations
-
-   Don't take drastic action upon seeing "(#"; it might not be HCMSSC.
diff --git a/Documentation/en/I-D/draft-bernstein-hcmssc-06.txt b/Documentation/en/I-D/draft-bernstein-hcmssc-06.txt
deleted file mode 100644
index 21103c84..00000000
--- a/Documentation/en/I-D/draft-bernstein-hcmssc-06.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-D. Bernstein: djb@pobox.com                                                           

-

-

diff --git a/Documentation/en/I-D/draft-bernstein-mail-loops-war-02.txt b/Documentation/en/I-D/draft-bernstein-mail-loops-war-02.txt
deleted file mode 100644
index 4a7035a2..00000000
--- a/Documentation/en/I-D/draft-bernstein-mail-loops-war-02.txt
+++ /dev/null
@@ -1,385 +0,0 @@
-
-Tools in the War on Mail Loops
-
-INTERNET-DRAFT  draft-bernstein-mail-loops-war-02.txt  (expires 1 August 1997)
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups. Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-Status of this memo
-
-   This memo provides information for the Internet community. This memo
-   does not specify an Internet standard of any kind. Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   An automailer means any program that receives a mail message and
-   automatically sends one or more mail messages. This term is meant to
-   include not only a mail-based server, such as a mailing list exploder
-   or a vacation program, but also an SMTP server, which receives a
-   message from the network and relays it to a local or remote user.
-
-   In a network full of automailers, any mistake can cause a mail loop.
-   Since some automailers generate several outputs in response to a
-   single input, a loop can produce an exponential explosion of mail.
-
-   All the automailers in the qmail package follow a general philosophy
-   designed to prevent mail loops and limit the damage from any loops
-   that do occur. These automailers have been repeatedly observed to
-   fail safe: they stop loops in the face of typical failures by other
-   hosts. This document explains the philosophy and describes the
-   automailers.
-
-
-Tools in the war on mail loops
-D. J. Bernstein, djb@pobox.com
-19970201
-
-
-1. Introduction
-
-   An automailer means any program that receives a mail message and
-   automatically sends one or more mail messages. This term is meant to
-   include not only a mail-based server, such as a mailing list exploder
-   or a vacation program, but also an SMTP server, which receives a
-   message from the network and relays it to a local or remote user.
-
-   In a network full of automailers, any mistake can cause a mail loop.
-   Since some automailers generate several outputs in response to a
-   single input, a loop can produce an exponential explosion of mail.
-
-   All the automailers in the qmail package follow a general philosophy
-   designed to prevent mail loops and limit the damage from any loops
-   that do occur. These automailers have been repeatedly observed to
-   fail safe: they stop loops in the face of typical failures by other
-   hosts. This document explains the philosophy and describes the
-   automailers.
-
-   To some extent the philosophy here simply repeats and amplifies
-   standard practice as codified in RFC 974 and RFC 1123. Unfortunately,
-   the standards do not adequately control bounce loops, since they do
-   not recognize that postmasters want to see double bounces; they do
-   not adequately control relaying loops; and they do not prevent
-   cross-host forwarding loops.
-
-   Terminology: The mail message received by an automailer is called
-   input. The mail messages sent by an automailer are called outputs.
-   For simplicity, this document focuses on the case that the input has
-   just one envelope recipient.
-
-   REMINDER: This document describes the automailers in the qmail
-   package. Other packages include automailers that do not fit the
-   descriptions given here.
-
-   Beware that the war on mail loops can never be won: any method of
-   preventing mail loops can be subverted by other hosts. I welcome
-   further development of techniques that work well in practice.
-
-
-2. Basics
-
-   The output from an automailer is always further down the following
-   list than the input.
-
-      0 hops, <sender> is neither <> nor <#@[]>  normal messages
-      1 hop, <sender> is neither <> nor <#@[]>
-      2 hops, <sender> is neither <> nor <#@[]>
-      etc.
-      0 hops, <sender> is <>                     bounces
-      1 hop, <sender> is <>
-      2 hops, <sender> is <>
-      etc.
-      0 hops, <sender> is <#@[]>                 double bounces
-      1 hop, <sender> is <#@[]>
-      2 hops, <sender> is <#@[]>
-      etc.
-
-   Here sender means the envelope sender address. Hops means the number
-   of Received and Delivered-To fields in the header. See sections 3.3
-   and 3.4 for an explanation of <> and <#@[]>.
-
-   Consequently, no automailer ever generates an entirely new normal
-   message in response to a normal message. If the output is a normal
-   message, it always has more hops than the input.
-
-   When input and output are both normal messages, both bounces, or both
-   double bounces, the output header is essentially the same as the
-   input header. However, when an automailer moves from a normal message
-   to a bounce, or from a bounce to a double bounce, it generates an
-   entirely new header.
-
-   An automailer may refuse to operate if the input has too many hops.
-   The definition of too many hops depends on the automailer. This
-   practice is called hop counting. Note that some existing messages
-   legitimately take as many as 20 hops. One automailer uses a limit of
-   100 hops; this will be adequate for all messages in the foreseeable
-   future.
-
-   Hop counting is a weapon of last resort. It will, if correctly
-   implemented, prevent all infinite loops; however, even a finite loop
-   can do practically infinite damage, as illustrated in section 4.3.
-
-
-3. Pre-delivery automailers
-
-   Conceptually: The input is a message that has not yet reached its
-   envelope recipient address. It is fed to a relay, which attempts to
-   deliver the message directly to, or at least closer to, that address;
-   if the relay fails permanently, the message is fed to a bouncer or a
-   double-bouncer. Relays, bouncers, and double-bouncers are examples of
-   pre-delivery automailers.
-
-   A pre-delivery automailer produces at most one output.
-
-   The basic weapon against pre-delivery mail loops is gravity. A normal
-   message always moves closer to its envelope recipient, according to a
-   notion of distance defined in section 3.1. If it bounces before
-   reaching the recipient, it turns into a bounce message, which always
-   moves closer to the original envelope sender. If that in turn
-   bounces, it turns into a double bounce, which always moves closer to
-   a local postmaster. (Triple bounces do not exist.)
-
-
-3.1. Distance
-
-   The distance from a DNS domain D to a recipient U@R is defined as
-   follows, when R has an MX list: the minimum preference of D in the
-   MX list, or 100000 if D does not appear in the list.
-
-   When R has no MX records, the distance from R to U@R is defined as 0,
-   and the distance from any other domain to U@R is defined as 100000.
-
-   Exception: If R is an alias, i.e., if R has a CNAME record, the
-   distance from any domain to U@R is defined as 500000.
-
-   The distance from a host H to U@R is defined as the minimum distance
-   to U@R from any domain that touches H. (``D touches H'' means ``D has
-   an A record listing one of H's IP addresses.'')
-
-   Exception: If H does not accept mail from the network, its distance
-   to any recipient is defined as 999999.
-
-
-3.2. Relays
-
-   A relay is a pre-delivery automailer that sends the output towards
-   the envelope recipient. What this means for intra-host relays is not
-   discussed here. What this means for cross-host relays is the
-   following: if the relay is at host H, and it sends its output to host
-   T, then the distance from T to the output envelope recipient is
-   always smaller than the distance from H to the input envelope
-   recipient.
-
-   The following facts guarantee that certain cross-host relay behavior
-   is safe. For proofs of these facts, see Appendix A.
-
-      Fact 1: If R is an alias for X, X is not an alias, D touches T,
-      and T accepts mail from the network, then the distance from T to
-      U@X is smaller than the distance from H to U@R.
-
-      Fact 2: If R is not an alias, R has no MX records, H is not
-      touched by R, T is touched by R, and T accepts mail from the
-      network, then T is closer to U@R than H is.
-
-      Fact 3: If R is not an alias, R has an MX record with domain X and
-      preference p, H is not touched by any of the domains in the MX
-      list for R with preference <= p, T is touched by X, and T accepts
-      mail from the network, then T is closer to U@R than H is.
-
-   Also, a host that does not accept mail from the network can relay
-   messages to a nearby hub.
-
-   A relay adds a new Received header field to the top of the output.
-   Other than this, the output header, body, and envelope are exactly
-   the same as the input header, body, and envelope. Exception: If the
-   input envelope recipient is U@R, R is an alias for X, and X is not
-   an alias, the output envelope recipient is U@X.
-
-
-3.3. Bouncers
-
-   A bouncer is a pre-delivery automailer that lets the envelope sender
-   know what happened to a message. Most bouncers send failure notices.
-   Some bouncers, such as vacation servers and echo servers, send
-   success notices.
-
-   In a bouncer's output, the envelope sender is <>, and the envelope
-   recipient is the input envelope sender. A bouncer refuses to operate
-   if the input envelope sender is <> or <#@[]>.
-
-   Some mailers on the Internet do not understand the <> convention. In
-   fact, some mailers will rewrite <> as <@host>. So any message with an
-   envelope recipient of <> or <@host> is discarded upon local delivery.
-
-   Unlike a relay, a bouncer produces output with a new header, not
-   simply a copy of the input header. For example:
-
-      (envelope) from <> to <djb@silverton.berkeley.edu>
-      Date: 2 Jan 1996 03:38:25 GMT
-      From: DELIVERY NOTICE SYSTEM <MAILER-DAEMON@heaven.af.mil>
-      To: djb@silverton.berkeley.edu
-      Subject: failure notice
-
-   However, the body of the bounce indicates the relevant input envelope
-   recipient, as well as the Message-ID of the input, if the input had a
-   Message-ID. The body of a failure notice includes a copy of the
-   entire input message.
-
-
-3.4. Double-bouncers
-
-   A double-bouncer is a pre-delivery automailer that informs a local
-   postmaster of permanent failures to deliver bounce messages. Such
-   failures are generally caused by poorly configured hosts that produce
-   normal messages with faulty envelope sender addresses.
-
-   A double-bouncer refuses to operate unless the input envelope sender
-   is <>. The output envelope sender from a double-bouncer is <#@[]>;
-   note that <#@[]> cannot be used as an SMTP envelope sender under
-   RFC 821. The output envelope recipient is predetermined.
-
-   Note that double bounces are not suggested by RFC 1123. However,
-   faulty envelope sender addresses are usually configuration errors
-   that can and should be fixed. Some postmasters, faced with mail
-   software that throws away double bounces, resort to keeping copies of
-   all bounces; but single bounces are rarely the postmaster's problem.
-
-
-4. Post-delivery automailers
-
-   Conceptually: The input is a message that has reached its envelope
-   recipient address. It is fed to a post-delivery automailer at that
-   address.
-
-   The basic weapon against post-delivery loops is a new header field,
-   Delivered-To, tracing all the forwarders and mailing lists that a
-   message has been through. This field has the side benefit of making
-   it much easier for a user (or for a postmaster seeing a bounce) to
-   figure out the path that the message took. Delivered-To is similar to
-   RFC 1327's DL-Expansion-History, but (1) it omits the time stamp,
-   removing any need for parsing, and (2) it has a much better name.
-
-
-4.1. Exploders and repliers
-
-   There are two basic types of post-delivery automailers: exploders,
-   where the output envelope recipients are predetermined; and repliers,
-   where there is just one output, with envelope recipient determined
-   from the input.
-
-   Repliers normally determine the output envelope recipient as either
-   the input Reply-To header field, if it exists; or else the input
-   From header field, if it exists; or else the envelope sender. A
-   replier never produces an output to <> or <#@[]>.
-
-   Exploders are classified into mailing lists, where the output
-   envelope senders are predetermined, and forwarders, where every
-   output has envelope sender equal to the original envelope sender.
-
-   Exception: if the input envelope sender is <> or <#@[]>, then the
-   output envelope senders are equal to the input envelope sender, even
-   for a mailing list.
-
-   Note that, if the envelope sender of a mailing list with M bad
-   addresses is another exploder with E bad addresses, the local
-   postmaster will receive EM double bounces for each message to the
-   mailing list.
-
-
-4.2. Delivered-To
-
-   Every post-delivery automailer adds a new Delivered-To header field
-   to the top of each output.
-
-   The contents of the Delivered-To field are typically the address of
-   the automailer, i.e., the input envelope recipient, conventionally
-   without any quoting. The contents of the Delivered-To field are in
-   any case entirely predetermined. The automailer checks if exactly the
-   same Delivered-To field already appears in the header; if so, it
-   refuses to operate. 
-
-   A post-delivery automailer preserves existing Delivered-To and
-   Received fields. In fact, a post-delivery automailer generally
-   preserves all header fields. The exceptions are limited to known
-   fields that are not used for loop detection and that must be removed
-   for correct operation. For example, a replier generally changes the
-   body of a message and thus should not preserve the SVR4
-   Content-Length field.
-
-
-4.3. An example
-
-   Aliases and mailing lists are highly dangerous, because they can
-   generate several outputs for each input.
-
-   Here is an extreme example. A user has three accounts, and wants any
-   message to any of the accounts to be delivered to all three. So he
-   forwards luser@host1 to luser@host2 and luser@host3, forwards
-   luser@host2 to luser@host1 and luser@host3, and forwards luser@host3
-   to luser@host1 and luser@host2.
-
-   Without Delivered-To, someone who sends a message to luser@host1 will
-   receive a practically infinite series of bounces. For example, with a
-   hop count limit of 50, the sender will receive 1125899906842624
-   bounces.
-
-   If all the hosts, or two out of the three, support Delivered-To, the
-   message will bounce just a few times. If just one of the hosts
-   supports Delivered-To, it will be the unfortunate victim of a loop
-   between the other two hosts---although the total number of bounces
-   will drop from practically infinite down to a few hundred, with
-   typical hop count limits.
-
-
-Appendix A. Proofs of correctness for MX handling
-
-   Section 3.2 states three facts about the notion of distance defined
-   in section 3.1. Here are mathematical proofs of those facts.
-
-   Symbols: D, E, R, and X are domains; H and T are hosts; p and q are
-   nonnegative integers. {} is the empty set.
-
-   Hypotheses: M(R), the ``MX list for R,'' is a set of pairs (p,D)
-   where p <= 65535. There is a set A of domains, called ``aliases.''
-   There is a relation D->H, called ``D touches H.'' There is a set N of
-   hosts, called ``hosts that accept mail from the network.''
-
-   Definitions: m(D,R) = min { p: p = 100000 or (p,D) in M(R) } when
-   M(R) is nonempty. When M(R) is empty, m(D,R) is 0 if D = R, 100000
-   otherwise. f(D,R) is defined as 500000 if R is in A, m(D,R)
-   otherwise; this is the ``distance from D to U@R,'' for any U. g(H,R)
-   is defined as min { f(D,R): D->H } if H is in N, 999999 otherwise;
-   this is the ``distance from H to U@R,'' for any U.
-
-   Fact 1 (generalized): If R is in A, X is not in A, D->T, and T is in
-   N, then g(T,X) < g(H,R). Proof: R is in A, so f(E,R) = 500000 for any
-   E; thus g(H,R) >= 500000. X is not in A, so f(D,X) = m(D,X) <=
-   100000; hence g(T,X) <= f(D,X) <= 100000 < g(H,R).
-
-   Fact 2: If R is not in A, M(R) = {}, R->T, T is in N, and not R->H,
-   then g(T,R) < g(H,R). Proof: f(R,R) = m(R,R) = 0 since R is not in A
-   and M(R) = {}. T is in N so g(T,R) <= f(R,R) = 0 so g(T,R) = 0.
-   Suppose that g(H,R) <= g(T,R). Then g(H,R) = 0, so f(D,R) = 0 for
-   some D with D->H, so m(D,R) = 0. But then D = R by definition of m,
-   so R->H. Contradiction. Thus g(T,R) < g(H,R).
-
-   Fact 3: If R is not in A, (p,X) is in M(R), X->T, T is in N, and
-   (q,D) is not in M(R) whenever D->H and q <= p, then g(T,R) < g(H,R).
-   Proof: First m(X,R) <= p. R is not in A, so f(X,R) = m(X,R). T is in
-   N, so g(T,R) <= f(X,R). Thus g(T,R) <= p. Suppose that g(H,R) <= p.
-   Then f(D,R) <= p for some D with D->H, so m(D,R) <= p. But then
-   (m(D,R),D) is in M(R). Contradiction. Thus g(T,R) <= p < g(H,R).
diff --git a/Documentation/en/I-D/draft-bernstein-mail-loops-war-06.txt b/Documentation/en/I-D/draft-bernstein-mail-loops-war-06.txt
deleted file mode 100644
index 21103c84..00000000
--- a/Documentation/en/I-D/draft-bernstein-mail-loops-war-06.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-D. Bernstein: djb@pobox.com                                                           

-

-

diff --git a/Documentation/en/I-D/draft-bernstein-mpls-sonet-01.txt b/Documentation/en/I-D/draft-bernstein-mpls-sonet-01.txt
deleted file mode 100644
index ad6ae6ff..00000000
--- a/Documentation/en/I-D/draft-bernstein-mpls-sonet-01.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-G. Bernstein: creg@ciena.com                                                          

-

-

diff --git a/Documentation/en/I-D/draft-bernstein-netstrings-02.txt b/Documentation/en/I-D/draft-bernstein-netstrings-02.txt
deleted file mode 100644
index 402c91d9..00000000
--- a/Documentation/en/I-D/draft-bernstein-netstrings-02.txt
+++ /dev/null
@@ -1,131 +0,0 @@
-
-Netstrings
-
-INTERNET-DRAFT   draft-bernstein-netstrings-02.txt   (expires 1 August 1997)
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups. Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-Status of this memo
-
-   This memo provides information for the Internet community. This memo
-   does not specify an Internet standard of any kind. Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   A netstring is a self-delimiting encoding of a string. Netstrings are
-   very easy to generate and to parse. Any string may be encoded as a
-   netstring; there are no restrictions on length or on allowed bytes.
-   Another virtue of a netstring is that it declares the string size up
-   front. Thus an application can check in advance whether it has enough
-   space to store the entire string.
-
-   Netstrings may be used as a basic building block for reliable network
-   protocols. Most high-level protocols, in effect, transmit a sequence
-   of strings; those strings may be encoded as netstrings and then
-   concatenated into a sequence of characters, which in turn may be
-   transmitted over a reliable stream protocol such as TCP.
-
-
-Netstrings
-D. J. Bernstein, djb@pobox.com
-19970201
-
-
-1. Introduction
-
-   A netstring is a self-delimiting encoding of a string. Netstrings are
-   very easy to generate and to parse. Any string may be encoded as a
-   netstring; there are no restrictions on length or on allowed bytes.
-   Another virtue of a netstring is that it declares the string size up
-   front. Thus an application can check in advance whether it has enough
-   space to store the entire string.
-
-   Netstrings may be used as a basic building block for reliable network
-   protocols. Most high-level protocols, in effect, transmit a sequence
-   of strings; those strings may be encoded as netstrings and then
-   concatenated into a sequence of characters, which in turn may be
-   transmitted over a reliable stream protocol such as TCP.
-
-   Note that netstrings can be used recursively. The result of encoding
-   a sequence of strings is a single string. A series of those encoded
-   strings may in turn be encoded into a single string. And so on.
-
-   In this document, a string of 8-bit bytes may be written in two
-   different forms: as a series of hexadecimal numbers between angle
-   brackets, or as a sequence of ASCII characters between double quotes.
-   For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of
-   length 12; it is the same as the string "hello world!".
-
-   Although this document restricts attention to strings of 8-bit bytes,
-   netstrings could be used with any 6-bit-or-larger character set.
-
-
-2. Definition
-
-   Any string of 8-bit bytes may be encoded as [len]":"[string]",".
-   Here [string] is the string and [len] is a nonempty sequence of ASCII
-   digits giving the length of [string] in decimal. The ASCII digits are
-   <30> for 0, <31> for 1, and so on up through <39> for 9. Extra zeros
-   at the front of [len] are prohibited: [len] begins with <30> exactly
-   when [string] is empty.
-
-   For example, the string "hello world!" is encoded as <31 32 3a 68
-   65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The
-   empty string is encoded as "0:,".
-
-   [len]":"[string]"," is called a netstring. [string] is called the
-   interpretation of the netstring.
-
-
-3. Sample code
-
-   The following C code starts with a buffer buf of length len and
-   prints it as a netstring.
-
-      if (printf("%lu:",len) < 0) barf();
-      if (fwrite(buf,1,len,stdout) < len) barf();
-      if (putchar(',') < 0) barf();
-
-   The following C code reads a netstring and decodes it into a
-   dynamically allocated buffer buf of length len.
-
-      if (scanf("%9lu",&len) < 1) barf();  /* >999999999 bytes is bad */
-      if (getchar() != ':') barf();
-      buf = malloc(len + 1);       /* malloc(0) is not portable */
-      if (!buf) barf();
-      if (fread(buf,1,len,stdin) < len) barf();
-      if (getchar() != ',') barf();
-
-   Both of these code fragments assume that the local character set is
-   ASCII, and that the relevant stdio streams are in binary mode.
-
-
-4. Security considerations
-
-   The famous Finger security hole may be blamed on Finger's use of the
-   CRLF encoding. In that encoding, each string is simply terminated by
-   CRLF. This encoding has several problems. Most importantly, it does
-   not declare the string size in advance. This means that a correct
-   CRLF parser must be prepared to ask for more and more memory as it is
-   reading the string. In the case of Finger, a lazy implementor found
-   this to be too much trouble; instead he simply declared a fixed-size
-   buffer and used C's gets() function. The rest is history.
-
-   In contrast, as the above sample code shows, it is very easy to
-   handle netstrings without risking buffer overflow. Thus widespread
-   use of netstrings may improve network security.
diff --git a/Documentation/en/I-D/draft-bernstein-netstrings-06.txt b/Documentation/en/I-D/draft-bernstein-netstrings-06.txt
deleted file mode 100644
index 21103c84..00000000
--- a/Documentation/en/I-D/draft-bernstein-netstrings-06.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-D. Bernstein: djb@pobox.com                                                           

-

-

diff --git a/Documentation/en/I-D/draft-bernstein-nrudt-02.txt b/Documentation/en/I-D/draft-bernstein-nrudt-02.txt
deleted file mode 100644
index 949d3fb5..00000000
--- a/Documentation/en/I-D/draft-bernstein-nrudt-02.txt
+++ /dev/null
@@ -1,139 +0,0 @@
-
-Notice-Requested-Upon-Delivery-To (NRUDT)
-
-INTERNET-DRAFT   draft-bernstein-nrudt-02.txt   (expires 1 August 1997)
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups. Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-Status of this memo
-
-   This memo provides information for the Internet community. This memo
-   does not specify an Internet standard of any kind. Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   The UNIX sendmail program has for many years supported a
-   Return-Receipt-To (RRT) header field that requests a notice of
-   successful final delivery.
-
-   Notice-Requested-Upon-Delivery-To (NRUDT) has the same basic
-   function. The big difference is that RRT lists the sender's address,
-   while NRUDT lists the recipient's address.
-
-   This change is critical. RRT works poorly for messages to multiple
-   recipients, because it requests a notice from every recipient. RRT in
-   a message to a large mailing list produces a giant, usually
-   unintentional, flood of mail. This problem is so severe that RRT has
-   been disabled in recent versions of sendmail.
-
-   NRUDT is designed to be adopted immediately, with minimal disruption,
-   as a solution to the problems of RRT. Note that NRUDT is merely a
-   request for notification; unlike the link-level Delivery Status
-   Notification SMTP extension, NRUDT does not provide a guarantee of
-   notification.
-
-
-Notice-Requested-Upon-Delivery-To (NRUDT)
-D. J. Bernstein, djb@pobox.com
-19970201
-
-
-1. Introduction
-
-   The UNIX sendmail program has for many years supported a
-   Return-Receipt-To (RRT) header field that requests a notice of
-   successful final delivery.
-
-   Notice-Requested-Upon-Delivery-To (NRUDT) has the same basic
-   function. The big difference is that RRT lists the sender's address,
-   while NRUDT lists the recipient's address.
-
-   This change is critical. RRT works poorly for messages to multiple
-   recipients, because it requests a notice from every recipient. RRT in
-   a message to a large mailing list produces a giant, usually
-   unintentional, flood of mail. This problem is so severe that RRT has
-   been disabled in recent versions of sendmail.
-
-   NRUDT is designed to be adopted immediately, with minimal disruption,
-   as a solution to the problems of RRT. Note that NRUDT is merely a
-   request for notification; unlike the link-level Delivery Status
-   Notification SMTP extension, NRUDT does not provide a guarantee of
-   notification.
-
-   NRUDT is supported by the qreceipt program in the qmail package.
-
-
-2. Syntax
-
-   NRUDT is a field in the header of an RFC 822 mail message. It has the
-   following syntax:
-
-      "Notice-Requested-Upon-Delivery-To" ":" 1#address
-
-   See RFC 822 for more information about header fields and addresses.
-
-   NRUDT requests that, upon final delivery of the message to any of the
-   specified addresses, the sender be notified. Note that more than one
-   address can appear in a single NRUDT header field. Multiple NRUDT
-   header fields should not appear in a single message.
-
-
-3. Response
-
-   Upon successful final delivery of a message to any address listed in
-   an NRUDT header field, the host performing delivery may, if desired,
-   generate a success notice.
-
-   The success notice is similar to a failure notice as described in RFC
-   1123. Its envelope sender is <>. Its envelope recipient is the
-   envelope sender of the original message; however, if the envelope
-   sender of the original message is <>, a success notice is not sent.
-
-   The body of the success notice does not contain a copy of the
-   original message, but it does indicate the Message-ID of the original
-   message, as well as the relevant recipient address.
-
-   A success notice may indicate delivery to several addresses. For
-   example, given the following message:
-
-      (envelope) from djb@silverton.berkeley.edu 
-      (envelope) to god@heaven.af.mil, angels@heaven.af.mil
-      Date: 1 Jan 1996 21:43:34 GMT
-      From: "D. J. Bernstein" <djb@silverton.berkeley.edu>
-      Message-Id: <19960101214334.8529.qmail@silverton.berkeley.edu>
-      Notice-Requested-Upon-Delivery-To: God <god@heaven.af.mil>,
-        angels@heaven.af.mil (You Know Who You Are)
-      ...
-
-   a host may respond as follows:
-
-      (envelope) from <> to djb@silverton.berkeley.edu
-      Date: 1 Jan 1996 21:43:37 GMT
-      From: DELIVERY NOTICE SYSTEM <MAILER-DAEMON@heaven.af.mil>
-      To: djb@silverton.berkeley.edu
-      Subject: success notice
-
-      I delivered <19960101214334.8529.qmail@silverton.berkeley.edu>
-      to the following local mailboxes:
-
-         god@heaven.af.mil
-         angels@heaven.af.mil
-
-      Thanks for asking.
-
-   However, a success notice is never merged with a failure notice.
diff --git a/Documentation/en/I-D/draft-bernstein-nrudt-06.txt b/Documentation/en/I-D/draft-bernstein-nrudt-06.txt
deleted file mode 100644
index 21103c84..00000000
--- a/Documentation/en/I-D/draft-bernstein-nrudt-06.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-D. Bernstein: djb@pobox.com                                                           

-

-

diff --git a/Documentation/en/I-D/draft-bernstein-owner-hack-01.txt b/Documentation/en/I-D/draft-bernstein-owner-hack-01.txt
deleted file mode 100644
index 558638a5..00000000
--- a/Documentation/en/I-D/draft-bernstein-owner-hack-01.txt
+++ /dev/null
@@ -1,133 +0,0 @@
-
-The Owner Hack
-
-INTERNET-DRAFT   draft-bernstein-owner-hack-01.txt   (expires 1 August 1997)
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups. Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-Status of this memo
-
-   This memo provides information for the Internet community. This memo
-   does not specify an Internet standard of any kind. Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   The fundamental problem in managing a large mailing list is matching
-   bounce messages to subscription addresses.
-
-   Often a bounce message refers to a failing address that does not
-   appear on the mailing list. One of the mailing list subscribers is
-   forwarding messages to that address. Which subscriber? As the list
-   grows, this question becomes more and more difficult to answer.
-
-   The owner hack completely eliminates this problem _right now_. It
-   automatically and reliably identifies the subscription address
-   relevant to each bounce message. It provides the address in a form
-   that is trivial for automated bounce handlers to parse. It requires
-   support from the local mailer, but it does not require support from
-   any other hosts.
-
-
-The owner hack
-D. J. Bernstein
-19970201
-
-
-1. Introduction
-
-   The fundamental problem in managing a large mailing list is matching
-   bounce messages to subscription addresses.
-
-   Often a bounce message refers to a failing address that does not
-   appear on the mailing list. One of the mailing list subscribers is
-   forwarding messages to that address. Which subscriber? As the list
-   grows, this question becomes more and more difficult to answer.
-
-   Sometimes a bounce message doesn't identify the address that failed.
-   On occasion it doesn't even include a copy of the original message.
-   See RFC 1211 for an extensive collection of horror stories.
-
-   In theory, one could solve this problem with the DSN option and DSN
-   format described in RFC 1891, RFC 1892, and RFC 1894. Unfortunately,
-   the DSN option is useless unless it is supported by every
-   intermediate MTA. The complexity of RFC 1891 means that it will be
-   many years, perhaps infinitely many, before DSNs are universally
-   supported. Furthermore, the complexity of RFC 1894 means that parsing
-   the subscriber address is difficult even on the occasions that the
-   address is available.
-
-   The owner hack completely eliminates this problem _right now_. It
-   automatically and reliably identifies the subscription address
-   relevant to each bounce message. It provides the address in a form
-   that is trivial for automated bounce handlers to parse. It requires
-   support from the local mailer, but it does not require support from
-   any other hosts.
-
-
-2. The owner hack
-
-   Here is the owner hack: each recipient of the message sees a
-   different envelope sender address. When a message to the
-   djb-sos@silverton.berkeley.edu mailing list is sent to
-   God@heaven.af.mil, for example, it has the following envelope sender:
-
-      djb-sos-owner-God=heaven.af.mil@silverton.berkeley.edu
-
-   If the message bounces, the bounce message will be sent back to
-   djb-sos-owner-God=heaven.af.mil@silverton.berkeley.edu.
-
-   If God is forwarding His mail, the bounce message will still go to
-   djb-sos-owner-God=heaven.af.mil@silverton.berkeley.edu. No matter how
-   uninformative the bounce message is, it will display God's
-   subscription address in its envelope.
-
-   Another benefit of the owner hack is that God Himself can see what
-   address He used to subscribe.
-
-   Making the owner hack work requires two pieces of local software
-   support. First: it must be easy to modify the outgoing sender address
-   separately for each envelope recipient. For example, with one mailer,
-   qmail, a user can simply touch ~/.qmail-list-owner and
-   ~/.qmail-list-owner-default to apply the owner hack to user-list.
-
-   Second, and more important: it must be easy to identify a collection
-   of addresses, such as djb-sos-owner-*, and send all mail for those
-   addresses to one place, while preserving the * information. Under
-   qmail, all user-list-owner-* mail will be sent to the user once he
-   touches ~/.qmail-list-owner-default. Sending the mail through an
-   automated bounce-handling program is just as easy.
-
-   With older mailers, applying the owner hack would require setting up
-   a new user-list-owner-recipient alias for each new recipient. This 
-   inconvenience has prevented the owner hack from being widely
-   exploited, even though the idea is not new.
-
-
-3. The per-message owner hack
-
-   The owner hack is not restricted to distinguishing mailing list
-   subscribers; it can also be used to distinguish messages.
-
-   For example, a user can send one message with an envelope sender
-   address of user-dsn-1, the next message with user-dsn-2, and so on.
-   As long as the local mailer gives all user-dsn-* back to that user,
-   he can reliably match up incoming bounces with outgoing messages.
-
-   The per-message owner hack can be combined with the per-recipient
-   owner hack. Every application of RFC 1891's ORCPT and ENVID can be
-   handled with the owner hack---easily, reliably, and right now.
diff --git a/Documentation/en/I-D/draft-bernstein-owner-hack-05.txt b/Documentation/en/I-D/draft-bernstein-owner-hack-05.txt
deleted file mode 100644
index 21103c84..00000000
--- a/Documentation/en/I-D/draft-bernstein-owner-hack-05.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-D. Bernstein: djb@pobox.com                                                           

-

-

diff --git a/Documentation/en/I-D/draft-bernstein-pirp-02.txt b/Documentation/en/I-D/draft-bernstein-pirp-02.txt
deleted file mode 100644
index 122822ba..00000000
--- a/Documentation/en/I-D/draft-bernstein-pirp-02.txt
+++ /dev/null
@@ -1,174 +0,0 @@
-
-Public Information Retrieval Protocol (PIRP)
-
-INTERNET-DRAFT   draft-bernstein-pirp-02.txt   (expires 1 August 1997)
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups. Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-Status of this memo
-
-   This memo provides information for the Internet community. This memo
-   does not specify an Internet standard of any kind. Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   The Public Information Retrieval Protocol (PIRP) gives Internet hosts
-   a simple, uniform, efficient, extensible, easily implemented method
-   of publishing information. This document defines PIRP and outlines
-   the structure of PIRP names.
-
-   Unlike FTP and HTTP, PIRP is dedicated to publication. Implementing
-   PIRP ought to be a small and trivial task.
-
-
-Public Information Retrieval Protocol (PIRP)
-D. J. Bernstein, djb@pobox.com
-19970201
-
-
-1. Introduction
-
-   The Public Information Retrieval Protocol (PIRP) gives Internet hosts
-   a simple, uniform, efficient, extensible, easily implemented method
-   of publishing information. This document defines PIRP and outlines
-   the structure of PIRP names.
-
-   Unlike FTP and HTTP, PIRP is dedicated to publication. Implementing
-   PIRP ought to be a small and trivial task.
-
-   In this document, a string of 8-bit bytes may be written in two
-   different forms: as a series of hexadecimal numbers between angle
-   brackets, or as a sequence of ASCII characters between double quotes.
-   For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of
-   length 12; it is the same as the string "hello world!".
-
-
-2. Protocol
-
-   A PIRP client connects to a PIRP server, as discussed in section 5,
-   over a reliable stream protocol allowing transmission of 8-bit bytes.
-
-   The client sends a PIRP name. A PIRP name is a sequence of
-   components. Each component is a string of 8-bit bytes. The final
-   component is the empty string. Each previous component is nonempty.
-
-   A PIRP name is encoded as the concatenation of the encodings of its
-   components. Each component is encoded as a netstring, as discussed in
-   section 4.
-
-   Here are three examples of encoded PIRP names:
-
-      "6:finger,3:djb,0:,"
-      "3:ftp,3:pub,8:software,17:qmail-0.90.tar.gz,0:,"
-      "0:,"
-
-   The reader should not conclude from these examples that PIRP names
-   are required to be printable ASCII codes. The server must be prepared
-   to accept arbitrary bytes from the client.
-
-   After receiving the PIRP name from the client, the server normally
-   returns information associated with the name. This information is a
-   string of 8-bit bytes, encoded as a netstring. The server then closes
-   the connection.
-
-   Instead of returning an encoded component, the server may send the
-   string "!", which may mean either ``There is no information
-   associated with that name'' or ``I refuse to give you the information
-   associated with that name.''
-
-   Further server responses, beginning with a byte different from "!"
-   and from the ASCII digits, may be defined in the future. Any server
-   response beginning with "x" is reserved for experimental use.
-
-   The server may indicate temporary failure by closing the connection
-   before sending a complete response, or even before reading everything
-   from the client. However, the server must not begin a response before
-   reading everything from the client.
-
-   The client may close the connection before reading everything from
-   the server.
-
-   A PIRP session should take at most 1 hour. Both sides are expected to
-   close the connection after this time.
-
-
-3. Name interpretation
-
-   It is natural to divide PIRP names into categories based on the first
-   component. A document may identify a particular component---for
-   example, "finger"---and supply rules for the use of names with that
-   first component, as well as for the information conveyed by the
-   server's response. The first-level PIRP namespace will always have
-   lots of room for future extensions. Lower-level namespaces might also
-   leave room for growth.
-
-   The first component "experimental" is reserved for experimental use.
-
-   This document does not require that servers support any particular
-   portion of the PIRP namespace. However, PIRP-over-TCP servers
-   accessible through the Internet (see section 5) should not use any
-   non-experimental portion of the PIRP namespace in any non-standard
-   way.
-
-   The server's response to a single PIRP name may be fixed for long
-   periods of time, or it may change without human intervention. The
-   server may give the same response to all clients or different
-   responses to different clients.
-
-
-4. Netstrings
-
-   Any string of 8-bit bytes may be encoded as [len]":"[string]",".
-   Here [string] is the string and [len] is a nonempty sequence of ASCII
-   digits giving the length of [string] in decimal. The ASCII digits are
-   <30> for 0, <31> for 1, and so on up through <39> for 9. Extra zeros
-   at the front of [len] are prohibited: [len] begins with <30> exactly
-   when [string] is empty.
-
-   For example, the string "hello world!" is encoded as <31 32 3a 68
-   65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The
-   empty string is encoded as "0:,".
-
-   [len]":"[string]"," is called a netstring. [string] is called the
-   interpretation of the netstring.
-
-
-5. Encapsulation
-
-   PIRP may be used on top of TCP. A PIRP-over-TCP server listens for
-   TCP connections on port 553.
-
-
-6. Security considerations
-
-   Is the name received by a PIRP server the same as the name sent by
-   the client? Is the information received by the client the same as the
-   information sent by the server? The answers depend on the security
-   and reliability of the underlying communications mechanism. It is
-   easy to subvert TCP, for example, so if PIRP is used over TCP, an
-   attacker can subvert the client's request or the server's response.
-
-   It is a good idea to use a secure link instead of TCP. Note, however,
-   that one can safely transmit public information through an insecure
-   link, if in the meantime a cryptographic hash of the information is
-   sent through a secure link.
-
-   If PIRP is used over a secure, reliable communications link, the
-   client will correctly receive the server's response to its request.
-   Further security considerations depend on the client's use of this
-   response, and are not addressed in this document.
diff --git a/Documentation/en/I-D/draft-bernstein-pirp-06.txt b/Documentation/en/I-D/draft-bernstein-pirp-06.txt
deleted file mode 100644
index 21103c84..00000000
--- a/Documentation/en/I-D/draft-bernstein-pirp-06.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-D. Bernstein: djb@pobox.com                                                           

-

-

diff --git a/Documentation/en/I-D/draft-bernstein-qmtp-01.txt b/Documentation/en/I-D/draft-bernstein-qmtp-01.txt
deleted file mode 100644
index 9f3ce00c..00000000
--- a/Documentation/en/I-D/draft-bernstein-qmtp-01.txt
+++ /dev/null
@@ -1,266 +0,0 @@
-
-Quick Mail Transfer Protocol (QMTP)
-
-INTERNET-DRAFT   draft-bernstein-qmtp-01.txt   (expires 1 August 1997)
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups. Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-Status of this memo
-
-   This memo provides information for the Internet community. This memo
-   does not specify an Internet standard of any kind. Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   The Quick Mail Transfer Protocol (QMTP) is a replacement for the
-   Simple Mail Transfer Protocol (SMTP). QMTP eliminates any need for
-   end-of-line scanning between hosts with the same end-of-line
-   convention. It features automatic pipelining and chunking, 8-bit
-   transmission, prior declaration of the message size, and efficient
-   batching. It is designed to be very easy to implement.
-
-
-Quick Mail Transfer Protocol (QMTP)
-D. J. Bernstein, djb@pobox.com
-19970201
-
-
-1. Introduction
-
-   The Quick Mail Transfer Protocol (QMTP) is a replacement for the
-   Simple Mail Transfer Protocol (SMTP). QMTP eliminates any need for
-   end-of-line scanning between hosts with the same end-of-line
-   convention. It features automatic pipelining and chunking, 8-bit
-   transmission, prior declaration of the message size, and efficient
-   batching. It is designed to be very easy to implement.
-
-   QMTP is supported by the qmail-qmtpd and maildir2qmtp programs in the
-   qmail package.
-
-   In this document, a string of 8-bit bytes may be written in two
-   different forms: as a series of hexadecimal numbers between angle
-   brackets, or as a sequence of ASCII characters between double quotes.
-   For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of
-   length 12; it is the same as the string "hello world!". Note that
-   these notations are part of this document, not part of the protocol.
-
-
-2. Protocol
-
-   A QMTP client connects to a QMTP server, as discussed in section 7,
-   over a reliable stream protocol allowing transmission of 8-bit bytes.
-
-   Protocol outline: the client sends one or more packages; after each
-   package, the server sends back some responses.
-
-   The client begins by sending a package. A package contains a mail
-   message, an envelope sender address, and one or more envelope
-   recipient addresses. See section 4 for the format of a package.
-
-   When the server sees the end of the package, it sends back a series
-   of responses, one response for each envelope recipient address, in
-   the same order as given by the client. The server is not permitted to
-   change the order under any circumstances, even if two addresses are
-   the same. See section 5 for the format of a response.
-
-   The server is not permitted to send any portion of its responses to a
-   package until the client has sent the final byte of the package. The
-   client is permitted to close the connection before sending the final
-   byte of the package; in this case, the server must throw away the
-   package without attempting to deliver the message. However, the
-   server must not throw away previously accepted messages.
-
-   The client does NOT need to wait for a server response before sending
-   another package. The server must NOT throw away incoming data when it
-   sends a response. It is the client's responsibility to avoid
-   deadlock: if it sends a package before receiving all expected server
-   responses, it must continuously watch for those responses. The server
-   is permitted to delay its responses if further data has already shown
-   up from the client; while it is delaying responses, it must not pause
-   to wait for further data for the client.
-
-   The server is permitted to close the connection at any time, although
-   high-quality servers will try to avoid doing so. Any response not
-   received by the client indicates a temporary failure.
-
-   A QMTP session should take at most 1 hour. Both sides are expected
-   to close the connection after this time.
-
-
-3. Messages
-
-   In this document, an ``8-bit mail message'' means a sequence of
-   lines. Each line is a string of zero or more 8-bit bytes.
-
-   A message is called ``safe'' if none of its bytes are <0a>.
-
-   Implementation note: Here is the intended interpretation of text
-   files as messages under some current operating systems. Under DOS, a
-   message is stored on disk as
-
-      first line, <0d 0a>, second line, <0d 0a> ... <0d 0a>, last line.
-
-   Under UNIX, a message is stored on disk as
-
-      first line, <0a>, second line, <0a> ... <0a>, last line.
-
-   Notice that both of these encodings are reversible for safe messages.
-
-   In practice, it is very common for the last line to be empty. Many
-   existing utilities refer to the last line as a ``partial line'' and
-   ignore it whether or not it is empty.
-
-
-4. Packages
-
-   A package is the concatenation of three strings:
-
-      first, an encoded 8-bit mail message;
-      second, an encoded envelope sender address;
-      third, an encoded series of encoded envelope recipient addresses.
-
-   Each envelope address is a string of 8-bit bytes. The interpretation
-   of addresses depends on the environment in which QMTP is used and is
-   outside the scope of this document. Each address is encoded as a
-   netstring, as discussed in section 6. The series of encoded recipient
-   addresses is in turn encoded as a netstring.
-
-   A message is encoded as a string of 8-bit bytes in one of two ways:
-
-      Encoding #1 is <0d>, the first line, <0d 0a>, the second line,
-      <0d 0a>, the third line, ..., <0d 0a>, the last line.
-
-      Encoding #2 is <0a>, the first line, <0a>, the second line, <0a>,
-      the third line, ..., <0a>, the last line.
-
-   This string of 8-bit bytes is in turn encoded as a netstring, as
-   discussed in section 6.
-
-   Every server must be prepared to handle encoding #1 and encoding #2.
-   A server must not reject a message merely because of its encoding.
-
-   Implementation note: The intent of encoding #1 and encoding #2 is to
-   allow very straightforward handling of text files under DOS and UNIX
-   respectively. The programmer can print <0d> or <0a> and then simply
-   copy the file.
-
-
-
-5. Responses
-
-   Each response is a nonempty string of 8-bit bytes, encoded as a
-   netstring. The first byte of the string is one of the following:
-
-      "K" The message has been accepted for delivery to this envelope
-          recipient. This is morally equivalent to the 250 response to
-          DATA in SMTP; it is subject to the reliability requirements
-          of RFC 1123, section 5.3.3.
-
-      "Z" Temporary failure. The client should try again later.
-
-      "D" Permanent failure.
-
-   The remaining bytes should be between <20> and <7e> inclusive; the
-   client is permitted to discard bytes outside this range. It is
-   expected that these bytes will, when interpreted as ASCII characters,
-   be a human-readable description of what happened. The description
-   need not repeat the envelope recipient address.
-
-   Descriptions beginning with <20> are reserved for future extensions.
-   In descriptions not beginning with <20>, the character "#" must not
-   appear except in HCMSSC codes.
-
-   A server must NOT accept a safe message unless it can store the
-   message without corruption. More precisely: if the encoded message
-   sent by the client matches the encoding of some safe message M, then
-   acceptance means that the server is accepting responsibility to
-   deliver M to the envelope recipient. (There is at most one
-   possibility for M, since encodings are reversible on safe messages.)
-   Deletion of nulls is NOT permissible; a server that deletes nulls
-   must reject any message containing nulls. Folding of long lines and
-   high-bit stripping are also NOT permissible.
-
-   Servers are permitted to change unsafe messages.
-
-
-6. Netstrings
-
-   Any string of 8-bit bytes may be encoded as [len]":"[string]",".
-   Here [string] is the string and [len] is a nonempty sequence of ASCII
-   digits giving the length of [string] in decimal. The ASCII digits are
-   <30> for 0, <31> for 1, and so on up through <39> for 9. Extra zeros
-   at the front of [len] are prohibited: [len] begins with <30> exactly
-   when [string] is empty.
-
-   For example, the string "hello world!" is encoded as <31 32 3a 68
-   65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The
-   empty string is encoded as "0:,".
-
-   [len]":"[string]"," is called a netstring. [string] is called the
-   interpretation of the netstring.
-
-
-7. Encapsulation
-
-   QMTP may be used on top of TCP. A QMTP-over-TCP server listens for
-   TCP connections on port 209.
-
-
-8. Examples
-
-   A client opens a connection and sends the concatenation of the
-   following strings:
-
-      "246:" <0a>
-         "Received: (qmail-queue invoked by uid 0);"
-         " 29 Jul 1996 09:36:40 -0000" <0a>
-         "Date: 29 Jul 1996 11:35:35 -0000" <0a>
-         "Message-ID: <19960729113535.375.qmail@heaven.af.mil>" <0a>
-         "From: God@heaven.af.mil" <0a>
-         "To: djb@silverton.berkeley.edu (D. J. Bernstein)" <0a>
-         <0a>
-         "This is a test." <0a> ","
-      "24:" "God-DSN-37@heaven.af.mil" ","
-      "30:" "26:djb@silverton.berkeley.edu," ","
-
-      "356:" <0d>
-         "From: MAILER-DAEMON@heaven.af.mil" <0d 0a>
-         "To:" <0d 0a>
-         "   Hate." <22> "The Quoting" <22>
-	 "@SILVERTON.berkeley.edu," <0d 0a>
-         "   " <22> "\\Backslashes!" <22>
-	 "@silverton.BERKELEY.edu" <0d 0a>
-         <0d 0a>
-         "The recipient addresses here could"
-	 " have been encoded in SMTP as" <0d 0a>
-         "" <0d 0a>
-         "   RCPT TO:<Hate.The\ Quoting@silverton.berkeley.EDU>" <0d 0a>
-         "   RCPT TO:<\\Backslashes!@silverton.berkeley.edu>" <0d 0a>
-         <0d 0a>
-         "This ends with a partial last line, right here" ","
-      "0:" ","
-      "83:" "39:Hate.The Quoting@silverton.berkeley.edu,"
-         "36:\Backslashes!@silverton.berkeley.EDU," ","
-      
-   The server sends the following response, indicating acceptance:
-
-      "21:Kok 838640135 qp 1390,"
-      "21:Kok 838640135 qp 1391,"
-      "21:Kok 838640135 qp 1391,"
-
-   The client closes the connection.
diff --git a/Documentation/en/I-D/draft-bernstein-qmtp-05.txt b/Documentation/en/I-D/draft-bernstein-qmtp-05.txt
deleted file mode 100644
index 21103c84..00000000
--- a/Documentation/en/I-D/draft-bernstein-qmtp-05.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-D. Bernstein: djb@pobox.com                                                           

-

-

diff --git a/Documentation/en/I-D/draft-bernstein-qsbmf-02.txt b/Documentation/en/I-D/draft-bernstein-qsbmf-02.txt
deleted file mode 100644
index 108fde82..00000000
--- a/Documentation/en/I-D/draft-bernstein-qsbmf-02.txt
+++ /dev/null
@@ -1,193 +0,0 @@
-
-The qmail-send Bounce Message Format (QSBMF)
-
-INTERNET-DRAFT   draft-bernstein-qsbmf-02.txt   (expires 1 August 1997)
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups. Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-Status of this memo
-
-   This memo provides information for the Internet community. This memo
-   does not specify an Internet standard of any kind. Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   When a message transport agent (MTA) finds itself permanently unable
-   to deliver a mail message, it generates a new message, generally
-   known as a bounce message, back to the envelope sender.
-
-   Bounce messages produced by the qmail-send program display the list
-   of failed recipient addresses, an explanation for each address, and a
-   copy of the original message, in a format that is easy for both
-   humans and programs to read. This document defines the format.
-
-
-The qmail-send Bounce Message Format (QSBMF)
-D. J. Bernstein, djb@pobox.com
-19970201
-
-
-1. Introduction
-
-   When a message transport agent (MTA) finds itself permanently unable
-   to deliver a mail message, it generates a new message, generally
-   known as a bounce message, back to the envelope sender.
-
-   Bounce messages produced by the qmail-send program display the list
-   of failed recipient addresses, an explanation for each address, and a
-   copy of the original message, in a format that is easy for both
-   humans and programs to read. For example:
-
-      Date: 17 Mar 1996 03:54:40 GMT
-      From: MAILER-DAEMON@silverton.berkeley.edu
-      To: djb@silverton.berkeley.edu
-      
-      Hi. This is the qmail-send program at silverton.berkeley.edu.
-      I'm afraid I wasn't able to deliver your message to the
-      following addresses. This is a permanent error; I've given up.
-      Sorry it didn't work out.
-      
-      <god@heaven.af.mil>:
-      Sorry, I couldn't find any host by that name.
-      
-      --- Below this line is a copy of the message.
-      
-      Return-Path: <djb@silverton.berkeley.edu>
-      Received: (qmail-queue invoked by uid 7); 17 Mar 1996 03:54:38 GMT
-      Date: 17 Mar 1996 03:54:38 GMT
-      Message-ID: <19960317035438.26563.qmail@silverton.berkeley.edu>
-      From: djb@silverton.berkeley.edu (D. J. Bernstein)
-      To: god@heaven.af.mil
-      Subject: are you there?
-      
-      Just checking.
-
-   This document defines qmail-send's format for bounce messages.
-
-   In this document, a string of 8-bit bytes may be written in two
-   different forms: as a series of hexadecimal numbers between angle
-   brackets, or as a sequence of ASCII characters between double quotes.
-   For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of
-   length 12; it is the same as the string "hello world!".
-
-
-2. Format
-
-   A bounce message may be recognized as QSBMF as follows: its body
-   begins with the characters "Hi. This is the" exactly as shown.
-
-   The body of the message has four pieces: an introductory paragraph,
-   zero or more recipient paragraphs, a break paragraph, and the
-   original message.
-
-   Each paragraph is a series of non-blank lines followed by a single
-   blank line. The break paragraph begins with the character "-". All
-   other paragraphs begin with characters other than "-". The break
-   paragraph is human-readable but provides no interesting information.
-
-   The introductory paragraph is human-readable. It gives the name and
-   human-comprehensible location of the MTA, but parsers should not
-   attempt to use this information.
-
-   The only type of recipient paragraph described here is a failure
-   paragraph, which begins with the character "<". Paragraphs beginning
-   with other characters are reserved for future extensions.
-
-   The first line of a failure paragraph ends with the characters ">:".
-   Everything between the leading "<" and the trailing ">:" is an
-   (unquoted) Internet mail address.
-
-   A failure paragraph asserts that the MTA was permanently unable to
-   deliver the message to the mail address shown on the first line; the
-   MTA will not attempt further deliveries to that address. The
-   remaining lines of the paragraph give a human-readable description of
-   the reason for failure. Descriptions beginning with <20>, and
-   descriptions containing "#", are reserved for future extensions.
-
-   The envelope sender might not have sent his message to the address
-   shown. There are two reasons for this. First, the MTA may freely
-   replace unprintable characters with "_". Second, the original 
-   recipient address may have been an alias for the address shown.
-
-   The original message is an exact copy of the message received by the
-   MTA, including both header and body, preceded by a Return-Path field
-   showing the envelope sender.
-
-
-3. Comparison with 1892/1894
-
-   RFC 1892 and RFC 1894 together describe a format for delivery status
-   notifications. I have decided not to use that format, because I
-   believe that its complexity will prevent wide implementation and
-   increase the burden on people who manage mailing lists.
-
-   QSBMF is dedicated to failure reports, whereas RFC 1894 allows
-   success reports and deferral reports. Although it would be possible
-   to add deferral paragraphs and success paragraphs to QSBMF, it would
-   be even easier to design separate formats for such notices. I have
-   trouble reading mixed failure/deferral reports.
-
-   QSBMF always returns the entire original message. RFC 1892 allows
-   the MTA to return nothing or to return just the headers; it states
-   ``Return of content may be wasteful of network bandwidth.'' However,
-   failure notices are very rare, so the overall loss of bandwidth in
-   this case is insignificant. A much more important issue is storage
-   space: someone who manages a big mailing list does not want to have
-   to store several copies of each message in the form of bounces. The
-   best solution is to have each bounce automatically fed through a
-   program that stores only the critical information. I expect such
-   programs to spring up quickly for QSBMF.
-
-   RFC 1894 provides language-independent error messages, as described
-   by RFC 1893. One can achieve the same results more easily by adding
-   structure to the human-readable failure descriptions, for example
-   with HCMSSC.
-
-   RFC 1894 is able to communicate an ``envelope ID'' and the original
-   envelope recipient address specified by the sender. Unfortunately,
-   this information will almost never be available, since it requires
-   support by every intermediate MTA. All of the applications of this
-   information can be handled reliably, right now, with the owner hack;
-   this requires support from the sender's MTA but not from other hosts.
-
-   RFC 1894 includes several pieces of information that might be of
-   human interest but can be seen just as easily from Received lines:
-   the name of the MTA where delivery failed, the name of the previous
-   MTA, timestamps, etc.
-
-   All of these RFC 1894 features have a cost: complexity. A program
-   cannot parse an 1894 report without parsing RFC 822 header fields
-   and understanding quite a bit of MIME. This will limit the
-   availability of parsing software. In the meantime, such reports are
-   annoying to mailing list maintainers, since they are full of
-   uninteresting information and are difficult to parse visually.
-
-
-4. Security considerations
-
-   Bounce messages may be forged. Never remove someone from a mailing
-   list without sending him a message stating that you are doing so,
-   even if the reason for removal is a series of apparent bounce
-   messages from his address.
-
-   If you send a message along a secret path, you should change the
-   envelope sender address of the message to yourself, so that a bounce
-   will not reveal anything to the original sender. In other words: for
-   secret forwarding, use a mailing list, not a forwarder.
-
-   See RFC 1894 for further discussion of these points.
diff --git a/Documentation/en/I-D/draft-bernstein-qsbmf-06.txt b/Documentation/en/I-D/draft-bernstein-qsbmf-06.txt
deleted file mode 100644
index 21103c84..00000000
--- a/Documentation/en/I-D/draft-bernstein-qsbmf-06.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-D. Bernstein: djb@pobox.com                                                           

-

-

diff --git a/Documentation/en/I-D/draft-bose-smtp-integrity-00.txt b/Documentation/en/I-D/draft-bose-smtp-integrity-00.txt
deleted file mode 100644
index 83381ea3..00000000
--- a/Documentation/en/I-D/draft-bose-smtp-integrity-00.txt
+++ /dev/null
@@ -1,286 +0,0 @@
-                                                                [Page 1]
-
-INTERNET-DRAFT
-File Name: draft-bose-smtp-integrity-00.txt              Author: R. Bose
-Expires on: 4th October,2001
-
-
-        CHECKING OF MESSAGE INTEGRITY DURING SMTP TRANSACTIONS
-
-   Status of this memo:
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC 2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.
-   Note that other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents 
-   at any time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Abstract:
-
-   This Internet Draft describes an extension to the SMTP Services which
-   will enable an SMTP Server/Client to check the Integrity of Mails
-   received by it and immediately request for the Mail to be resent if
-   it is found to be corrupted during that particular transaction.
-
-   This extension is meant to apply to both SMTP Clients and Servers as
-   described in detail below.
-
-1. INTRODUCTION
-   
-   As of now there is NO provision in the Simple Mail Transfer Protocol
-   for error checking of messages while they are being transported from
-   client to server OR server to server.This sometimes results in the
-   recipient getting corrupted or truncated messages.And inspite of the
-   speed of the E-Mail delivery system a lot of time is wasted while the
-   recipient informs the original sender about the corruption of the
-   message and waits for the receipt of the uncorrupted message.
-
-   This time delay becomes even more prominent when attachments of
-   significant size (binary or otherwise) are included in the message.
-
-   Hence, an Error Checking provision like the one described below is
-   necessary.An effort has been made so that if the features described
-   below are implemented then only a minimum amount of change has to be
-   done to the current SMTP Server/Client softwares.
-
-
-draft-bose-smtp-integrity-00.txt                                [Page 2]
-
-
-2. INCLUSION OF CHECKSUM IN MESSAGE BODY OF MAIL
-   
-   In order to check the integrity of a message (including any
-   attachments in it) the checksum of the message should be calculated
-   and appended to the beginning of the message.The message then will
-   look like as follows:
-
-   <CHECKSUM TYPE=XX>checksum_string_here<CHECKSUM>
-   ................................................
-   ................................................ 
-   ................................................
-   .......[MESSAGE BODY IS CONTAINED HERE].........
-   ................................................
-   ................................................
-   ................................................
-   ................................................
-
-   The Dotted lines indicate the original message body
-   as inputted by user of Mail Client.
-
-   The Checksum as seen above is stored in the Checksum Header:
-   <CHECKSUM TYPE=XX>checksum_string_here<CHECKSUM>
-   The Checksum Header should be stored as the first line of the mail
-   body with the original mail message starting from the second line.
-
-   The Tag "TYPE" indicates the type of checksum used.Therefore, if:
-
-   Checksum Type     XX
-       16 bit        16
-       32 bit        32   
- 
-   This will enable the SMTP Server/Client to calculate the appropriate
-   Checksum value in order to compare it with the Original Value stored 
-   in the Checksum Header.But, it is proposed that a 32 bit checksum be
-   used by all SMTP Servers/Clients to check Mail Integrity.
-
-3. CALCULATION/VERIFICATION OF CHECKSUM BY SMTP CLIENT/SERVER
-   
-NOTE: In Sections 3 and beyond, the term "Sender Server" is used for 
-      the SMTP Server which initiates the connection and
-      "Recipient Server" for the SMTP Server to which the mail is being
-      relayed at that stage.
-      "Sender Client" is the SMTP Client who sends the original message 
-      and "Original Recipient Client" is the SMTP Client to whom the 
-      "Sender Client" is sending the Mail.
- 
-   In this section, the entire process of sending a mail, calculation
-   of it's checksum & it's verification during each stage of transport
-   till it reaches the intended recipient is described.
-
-
-
-
-
-
-draft-bose-smtp-integrity-00.txt                                [Page 3]
-
-                  DIAGRAM OF AN EXAMPLE SMTP TRANSACTION
-
-+------+      +-------------+      +---------+     +------------------+
-|Sender|----->|Sender Server|----->|Recipient|---->|Original Recipient|
-|Client| (a)  |             | (b)  | Server  | (c) |    Client        | 
-+------+      +-------------+      +---------+     +------------------+
-      
- a)When the Sender of a Mail has inputted his/her message, the Sender
-   Client will calculate it's checksum and append it to the beginning of
-   the message in the format described in Section 2 above.Then it will
-   send the message in the usual way to the SMTP Server by using the
-   "DATA" command.
-
- b)When a Recipient Server receives the message body of a Mail from 
-   Sender Client or Server it will immediately extract the first line 
-   from the message body and parse it to extract the values of the 
-   Checksum and the Checksum Type(given by the Tag TYPE).Then it will 
-   calculate the checksum accordingly and compare it to the Original 
-   Checksum which was extracted from the message body.
-   
-   Possible Numeric Replies by the Recipient Server:
-
-   250 OK, Requested mail action okay, completed
-   453 Checksum does not match, resend data
-
-   453 is a new proposed Numerical Error Reply.For maintaining
-   compatibility and dealing with Servers without the checksum 
-   features (which will not be supporting this New numerical reply) 
-   refer to Section 4 (b).
-
-
-   On receiving the 453 numeric reply,the Sender client/server should
-   resend the message body again.If the number of requests to resend
-   message exceeds a user specified number of times(ideally 2-4 times)
-   i.e. if the checksum error occurs persistently then the Sender
-   client/server should simply remove the Checksum Header and then send
-   the message body allowing the Recipient SMTP Server to act in the
-   manner described in Section 4 (a).
-  
- c)When the Original Recipient Client downloads the message from the
-   Mail Server (for e.g., it is a POP3 Server) it will also immediately
-   extract the first line from the message body and parse it to extract
-   the values of the Checksum and the Checksum Type  (given by the
-   Tag TYPE).Then it will calculate the checksum accordingly and compare
-   it to the Original Checksum which was extracted from message body.
-
-   Possible Actions of the Recipient Client:
-
-    (i)If the Checksum matches then no further action is required.
-
-   (ii)If the Checksum DOES NOT match then the Client should again try
-       to download the message.If Checksum error occurs persistently
-       then it will be prudent for the client to try downloading the
-       message only a user specified number of times(ideally 2-4 times).
-
-
-draft-bose-smtp-integrity-00.txt                                [Page 4]
-
-NOTE: The Concepts mentioned in the Sections 4(b),4(c) and 5 should
-      eventually lose their relevance if the features mentioned in this
-      document are widely accepted and implemented.
-    
-4. MAINTAINING COMPATIBILITY WITH OLDER VERSIONS OF SMTP SERVERS/CLIENTS
- 
-   In order to maintain backwards compatibility with older versions of
-   SMTP Servers and Clients the procedures described in this section
-   should be used.
-
-(a)If a Recipient Server on receiving a Message Body from the Sender
-   Server/Client tries to extract the Checksum and Checksum Type but
-   fails then the reason for failure can be attributed to the fact that
-   the Sender Server/Client does not have the Checksum facility
-   implemented or a situation has occured like the one described in
-   Section 3 (b).
-
-   If this is the case, then the Recipient Server itself should simply
-   calculate the Checksum and append it to the beginning of the Message
-   Body in the manner described in Section 2 above, so that atleast the
-   integrity of the message can be checked in subsequent transactions.
-
-(b)It is quite possible that during the relaying of a Mail, one of the
-   servers in the middle of the link may not have the checksum features
-   so if the recipient server encounters a Checksum Error during such
-   kinds of transaction it should act in the manner described in 
-   Section 5.
-
-(c)If the Original Recipient Client on receiving a Message Body from 
-   the Mail Server tries to extract the Checksum and Checksum Type but
-   fails then it should simply accept the message download without
-   any comments on it's checksum.
-   
-5. CHECKSUM COMMAND
-
-   It is proposed that a new command be added to the SMTP Commands
-   list to enable the Sender Server to inform the Recipient Server 
-   whether the Sender Server supports the checksum features described 
-   in this document or not.Therefore, every Sender Server **must** send
-   the CHECKSUM Command to the Recipient Server before sending the Mail
-   data by invoking the DATA Command.
-
-   Command Name: CHECKSUM
-   Usage Syntax: CHECKSUM
-   Possible Replies:  250 OK, Requested mail action okay, completed
-                      502 Command not implemented
-
-   Example:
-
-   (1)    Sender Server: CHECKSUM
-       Recipient Server: 250 OK, Requested mail action okay, completed
-
-   (2)    Sender Server: CHECKSUM
-       Recipient Server: 502 Command not implemented         
- 
-
-draft-bose-smtp-integrity-00.txt                                [Page 5]
-
-   Unlike most SMTP commands, the reply for this command sent by the
-   Recipient Server to the Sender Server is immaterial since this 
-   command is for the benefit of the Recipient Server only, as 
-   given below.
-
-   If the Recipient Server receives the CHECKSUM Command before the 
-   DATA command then only it should send the 453 Numerical Error Reply,
-   when a Checksum Error is encountered.
-
-   If the Recipient Server does not receive the CHECKSUM Command during
-   an SMTP Transaction then it should assume that the Sender Server 
-   does not support the Checksum features mentioned in this document.
-   Therefore, on encountering a Checksum Error,it should simply 
-   recalculate the Checksum of the Mail and replace the old value of the
-   checksum in the Checksum Header which is already present as the first
-   line of the Message Body.
-
-   If the Recipient Server itself does not support the Checksum features
-   mentioned in this document it will simply send a 502 Error to the
-   Sender Server. But the receipt of this Numerical Error Reply does not
-   require any action on the part of the Sender Server.
-
-
-6. REFERENCES
-  
-   1) RFC 821: Simple Mail Transfer Protocol
-      Jonathan B. Postel,
-      Information Sciences Institute,
-      University of Southern California,
-      August 1982.
-    
-   2) RFC 822: Standard for the Format of ARPA Internet Text Messages
-      D. Crocker,
-      Department of Electrical Engineering,
-      University of Delaware,
-      August 1982.
-
-
-7. CONTACT ADDRESS OF AUTHOR
-
-Postal Address: Raja Bose
-                D-4/3,Vasant Vihar,
-                New Delhi - 110057,
-                India.
-
-E-Mail: alokebose@bol.net.in
-
-Telephone: (+91) (011) 614-4638 & 615-1930
-                                                                    
-
-This Internet Draft expires on: 4th October,2001
-
diff --git a/Documentation/en/I-D/draft-burger-vpim-pc-01.txt b/Documentation/en/I-D/draft-burger-vpim-pc-01.txt
deleted file mode 100644
index df31a17b..00000000
--- a/Documentation/en/I-D/draft-burger-vpim-pc-01.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-

-This document has been replaced by draft-ietf-vpim-hint-00.txt.

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-E. Burger: e.burger@ieee.org                                                       

-E. Candell: emily@comversens.com                                                    

-

-

diff --git a/Documentation/en/I-D/draft-earhart-url-smtp-00.txt b/Documentation/en/I-D/draft-earhart-url-smtp-00.txt
deleted file mode 100644
index 1b98cb68..00000000
--- a/Documentation/en/I-D/draft-earhart-url-smtp-00.txt
+++ /dev/null
@@ -1,281 +0,0 @@
-
-
-
-
-Network Working Group                                         R. Earhart
-Internet Draft: URL-SMTP                                 Carnegie Mellon
-Document: draft-earhart-url-smtp-00.txt                    December 1997
-Expires June 1997
-
-
-                         An SMTP URL Interface
-
-Status of this Memo
-
-   This document is an Internet-Draft.  Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups.  Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months.  and may be updated, replaced, or obsoleted by other
-   documents at any time.  It is not appropriate to use Internet-Drafts
-   as reference material or to cite them other than as "work in
-   progress".
-
-   To learn the current status of any Internet-Draft, please check the
-   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
-   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-   This document suggests a proposed protocol for the Internet
-   community, and requests discussion and suggestions for improvements.
-   Distribution of this draft is unlimited.
-
-   The protocol discussed in this document is experimental and subject
-   to change.  Persons planning on either implementing or using this
-   protocol are STRONGLY URGED to get in touch with the author before
-   embarking on such a project.
-
-
-Abstract
-
-   It is occasionally useful to be able to reference a generic server to
-   be used for message submission.  URLs provide a good mechanism for
-   refering to arbitrary network resources.  The SMTP URL scheme allows
-   a URL to specify an SMTP server, thus allowing other protocols to use
-   a general ''URL to be used for message delivery'' in place of an
-   explicit reference to SMTP.
-
-
-
-
-
-
-Earhart                                                         [Page 1]
-
-Internet DRAFT           An SMTP URL Interface         December 15, 1997
-
-
-1.   Conventions Used in this Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [KEYWORDS].
-
-
-2.   SMTP URL Scheme
-
-   The SMTP URL follows the common Internet scheme syntax as defined in
-   [BASIC-URL] except that plaintext passwords are not permitted.  If
-   :<port> is omitted, the port defaults to 25.
-
-   The specified server should not be assumed to have any services
-   available other than SMTP.  Other than authentication, no protocol
-   actions are implied by an SMTP URL; an SMTP URL only specifies the
-   location of an SMTP service, not what to do with it (common actions
-   are to use the SMTP server to verify an address, and to submit
-   Internet mail).
-
-   An SMTP URL has the following general form:
-
-      url-smtp  = "smtp://" url-server
-
-   "smtp" refers to the URL scheme; "://" is used to indicate a
-   reference to an Internet host address.  The <url-server> element
-   includes the hostname, and optional user name, authentication
-   mechanism and port number.
-
-   Note that unsafe or reserved characters such as " " or "?" MUST be
-   hex encoded as described in the URL specification [BASIC-URL].  Hex
-   encoded octets are interpreted according to UTF-8 [UTF8].
-
-
-3.   SMTP URL User Name and Authentication Mechanism
-
-   A user name and/or authentication mechanism may be supplied.  They
-   are used to perform SASL [SASL] authentication after making the
-   connection to the SMTP server.  If no user name or authentication
-   mechanism is supplied, then the SASL ANONYMOUS [SASL-ANON] mechanism
-   is used by default.  If an authentication mechanism is supplied
-   without a user name, then one SHOULD be obtained from the specified
-   mechanism or requested from the user as appropriate.  If a user name
-   is supplied without an authentication mechanism then ";AUTH=*" is
-   assumed.
-
-   The ";AUTH=" authentication parameter is interpreted as described in
-   the IMAP URL Scheme [IMAP-URL].
-
-
-
-Earhart                                                         [Page 2]
-
-Internet DRAFT           An SMTP URL Interface         December 15, 1997
-
-
-   Note that if unsafe or reserved characters such as " " or ";" are
-   present in the user name or authentication mechanism, they MUST be
-   encoded as described in the URL specification [BASIC-URL].
-
-
-4.   Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) notation as specified in [ABNF].  This uses the ABNF core
-   rules as specified in Appendix A of the ABNF specification [ABNF].
-
-   Except as noted otherwise, all alphabetic characters are case-
-   insensitive.  The use of upper or lower case characters to define
-   token strings is for editorial clarity only.  Implementations MUST
-   accept these strings in a case-insensitive fashion.
-
-      url-auth           = ";AUTH=" ("*" / url-enc-auth)
-
-      url-achar          = uchar / "&" / "=" / "~"
-                           ;; See [BASIC-URL] for definition of "uchar"
-
-      url-enc-auth       = 1*url-achar
-                           ;; encoded version of auth-type-name above
-
-      url-enc-user       = *url-achar
-                           ;; encoded version of login userid
-
-      url-server         = [url-enc-user [url-auth] "@"] hostport
-                           ;; See [BASIC-URL] for definition of "hostport"
-
-      url-smtp           = "smtp://" url-server
-
-
-5.   Security Considerations
-
-   SMTP URLs have the same security considerations as IMAP URLs [IMAP-
-   URL].
-
-   Clients SHOULD make the SMTP URL being used obvious to the user, as
-   using an undesireable server may compromise the security of the
-   user's message.
-
-
-
-
-
-
-
-
-
-
-Earhart                                                         [Page 3]
-
-Internet DRAFT           An SMTP URL Interface         December 15, 1997
-
-
-6.   Copyright
-
-   Copyright (C) The Internet Society 1997. 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.
-
-
-7.   References
-
-   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
-   ABNF", RFC 2234, November 1997.
-
-      <url:ftp://ds.internic.net/rfc/rfc2234.txt>
-
-   [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource
-   Locators (URL)", RFC 1738, December 1994.
-
-      <url:ftp://ds.internic.net/rfc/rfc1738.txt>
-
-   [IMAP-URL] Newman, "IMAP URL Scheme", RFC 2192, July 1997.
-
-      <url:ftp://ds.internic.net/rfc/rfc2192.txt>
-
-
-
-
-
-
-
-Earhart                                                         [Page 4]
-
-Internet DRAFT           An SMTP URL Interface         December 15, 1997
-
-
-   [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
-   Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-      <url:ftp://ds.internic.net/rfc/rfc2119.txt>
-
-   [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC
-   2222, October 1997.
-
-      <url:ftp://ds.internic.net/rfc/rfc2222.txt>
-
-   [SASL-ANON] Newman, "Anonymous SASL Mechanism", RFC 2245, November
-   1997.
-
-      <url:ftp://ds.internic.net/rfc/rfc2245.txt>
-
-   [UTF8] Yergeau, "UTF-8, a transformation format of Unicode and ISO
-   10646", RFC 2044, October 1996.
-
-      <url:ftp://ds.internic.net/rfc/rfc2044.txt>
-
-
-8.   Author's Address
-
-   Robert H. Earhart
-   Carnegie Mellon
-   5000 Forbes Ave.
-   Pittsburgh PA, 15213-3890
-
-   Email: earhart+@cmu.edu
-
-
-Expires June 1997
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Earhart                                                         [Page 5]
-
diff --git a/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt b/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt
deleted file mode 100644
index 61bd16a3..00000000
--- a/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-
-This Internet-Draft has been deleted. Unrevised documents placed in the
-Internet-Drafts directories have a maximum life of six months. After
-that time, they are deleted. This Internet-Draft was not published as
-an RFC.
-
-Internet-Drafts are not an archival document series, and expired
-drafts, such as this one, are not available; please do not ask for
-copies... they are not available. The Secretariat does not have
-information as to future plans of the authors or working groups WRT the
-deleted Internet-Draft.
-
-For more information or a copy of the document, contact the author directly.
-
-Draft Author(s):
-
-E. Burger: e.burger@ieee.org                                                       
-
-
diff --git a/Documentation/en/I-D/draft-freed-bsmtp-02.txt b/Documentation/en/I-D/draft-freed-bsmtp-02.txt
deleted file mode 100644
index c99ef789..00000000
--- a/Documentation/en/I-D/draft-freed-bsmtp-02.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-
-
-A new Request for Comments is now available in online RFC libraries.
-
-
-        RFC 2442:
-
-        Title:	    The Batch SMTP Media Type
-	Author(s):  N. Freed, D. Newman, J. Belissen, M. Hoy
-	Status:     Informational
-	Date:       November 1998
-        Mailbox:    ned.freed@innosoft.com, dan.newman@innosoft.com,
-		    jacques.belissent@eng.sun.com,
-		    mark.hoy@mainbrace.com
-	Pages:      9
-        Characters: 18384
-        Updates/Obsoletes/See Also: None
-        I-D Tag:    draft-freed-bsmtp-01.txt
-
-
-        URL:        ftp://ftp.isi.edu/in-notes/rfc2442.txt
-
-
-This document defines a MIME content type suitable for tunneling an
-ESMTP [RFC-821, RFC-1869] transaction through any MIME-capable
-transport.  This type can be used for a variety of purposes,
-including: Extending end-to-end MIME-based security services (e.g.,
-[RFC-1847]) to cover message envelope information as well as message
-content.  Making it possible to use specific SMTP extensions such as
-NOTARY [RFC-1891] over unextended SMTP transport infrastructure.
-Enabling the transfer of multiple separate messages in a single
-transactional unit.
-
-This memo provides information for the Internet community.  It does
-not specify an Internet standard of any kind.  Distribution of this
-memo is unlimited.
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
-help: ways_to_get_rfcs.  For example:
-
-        To: rfc-info@RFC-EDITOR.ORG
-        Subject: getting rfcs
-
-        help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.echo 
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
-Authors, for further information.
-
-
-Joyce K. Reynolds and Alegre Ramos
-USC/Information Sciences Institute
-
-
diff --git a/Documentation/en/I-D/draft-freed-smtp-pipe-01.txt b/Documentation/en/I-D/draft-freed-smtp-pipe-01.txt
deleted file mode 100644
index 9dfd57bb..00000000
--- a/Documentation/en/I-D/draft-freed-smtp-pipe-01.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-A new Request for Comments is now available in online RFC libraries.

-

-

-        STD 60 

-        RFC 2920

-

-        Title:      SMTP Service Extension for Command Pipelining

-        Author(s):  N. Freed

-        Status:     Standards Track 

-        Date:       September 2000

-        Mailbox:    ned.freed@innosoft.com

-        Pages:      9

-        Characters: 17065

-        Obsoletes:  2197

-

-        I-D Tag:    draft-freed-smtp-pipe-01.txt

-

-        URL:        ftp://ftp.isi.edu/in-notes/rfc2920.txt

-

-

-This memo defines an extension to the Simple Mail Transfer Protocol

-(SMTP) service whereby a server can indicate the extent of its ability

-to accept multiple commands in a single Transmission Control Protocol

-(TCP) send operation. Using a single TCP send operation for multiple

-commands can improve SMTP performance significantly.

-

-This is now a Standard Protocol.

-

-This document specifies an Internet standards track protocol for

-the Internet community, and requests discussion and suggestions

-for improvements.  Please refer to the current edition of the

-"Internet Official Protocol Standards" (STD 1) for the

-standardization state and status of this protocol.  Distribution

-of this memo is unlimited.

-

-This announcement is sent to the IETF list and the RFC-DIST list.

-Requests to be added to or deleted from the IETF distribution list

-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be

-added to or deleted from the RFC-DIST distribution list should

-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

-

-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

-help: ways_to_get_rfcs.  For example:

-

-        To: rfc-info@RFC-EDITOR.ORG

-        Subject: getting rfcs

-

-        help: ways_to_get_rfcs

-

-Requests for special distribution should be addressed to either the

-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless

-specifically noted otherwise on the RFC itself, all RFCs are for

-unlimited distribution.echo 

-Submissions for Requests for Comments should be sent to

-RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC

-Authors, for further information.

-

-

diff --git a/Documentation/en/I-D/draft-freed-smtp-pipeline-02.txt b/Documentation/en/I-D/draft-freed-smtp-pipeline-02.txt
deleted file mode 100644
index db08d2b1..00000000
--- a/Documentation/en/I-D/draft-freed-smtp-pipeline-02.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-
-
-A new Request for Comments is now available in online RFC libraries.
-
-
-        RFC 2197:  
-
-        Title:      SMTP Service Extension for Command Pipelining
-	Author:     N. Freed
-        Category:   Draft Standard Protocol		
-	Date:       September 1997
-        Mailbox:    ned.freed@innosoft.com
-        Pages:      8
-        Characters: 15003
-        Obsoletes:  1854
-
-
-        URL:        ftp://ds.internic.net/rfc/rfc2197.txt
-
-
-This memo defines an extension to the SMTP service whereby a
-server can indicate the extent of its ability to accept
-multiple commands in a single TCP send operation. Using a
-single TCP send operation for multiple commands can improve
-SMTP performance significantly.
-
-This document is a product of the Messaging Extensions Working Group
-of the IETF.
-
-This is now a Draft Standard Protocol.
-
-This document specifies an Internet standards track protocol for
-the Internet community, and requests discussion and suggestions
-for improvements.  Please refer to the current edition of the
-"Internet Official Protocol Standards" (STD 1) for the
-standardization state and status of this protocol.  Distribution
-of this memo is unlimited.
-
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@ISI.EDU.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@ISI.EDU with the message body 
-help: ways_to_get_rfcs.  For example:
-
-        To: rfc-info@ISI.EDU
-        Subject: getting rfcs
-
-        help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to admin@DS.INTERNIC.NET.  Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.
-
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@ISI.EDU.  Please consult RFC 1543, Instructions to RFC
-Authors, for further information.
-
-
-Joyce K. Reynolds and Alegre Ramos
-USC/Information Sciences Institute
-
diff --git a/Documentation/en/I-D/draft-hall-dm-idns-00.txt b/Documentation/en/I-D/draft-hall-dm-idns-00.txt
deleted file mode 100644
index 9b183be5..00000000
--- a/Documentation/en/I-D/draft-hall-dm-idns-00.txt
+++ /dev/null
@@ -1,2739 +0,0 @@
-
-
-  INTERNET-DRAFT                                      Eric A. Hall, Editor 
-  Document: draft-hall-dm-idns-00.txt                           Consultant 
-  Expires: May 2002                                          November 2001 
-      
-      
-                  The Internationalized Domain Name System 
-      
-      
-     Status of this Memo 
-      
-     This document is an Internet-Draft and is in full conformance with 
-     all provisions of Section 10 of RFC2026. 
-      
-     Internet-Drafts are working documents of the Internet Engineering 
-     Task Force (IETF), its areas, and its working groups. Note that 
-     other groups may also distribute working documents as Internet-
-     Drafts. 
-      
-     Internet-Drafts are draft documents valid for a maximum of six 
-     months and may be updated, replaced, or obsoleted by other 
-     documents at any time. It is inappropriate to use Internet-Drafts 
-     as reference material or to cite them other than as "work in 
-     progress." 
-      
-     The list of current Internet-Drafts can be accessed at 
-     http://www.ietf.org/ietf/1id-abstracts.txt. 
-      
-     The list of Internet-Draft Shadow Directories can be accessed at 
-     http://www.ietf.org/shadow.html. 
-      
-      
-  1.      Abstract 
-      
-     The principle intention of this specification is to facilitate the 
-     deployment of a completely internationalized domain name syntax 
-     and service which new protocols, applications and host systems can 
-     use, but without disrupting the existing infrastructure. Towards 
-     that end, this document describes a series of elective 
-     encapsulation services and protocol extensions which cumulatively 
-     allow internationalized domain names to be stored and transmitted 
-     in the existing DNS message and within application data streams, 
-     according to the compliance level of the participating systems. 
-      
-   
-   
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-      
-     Table of Contents 
-      
-     1.   Abstract..................................................1 
-     2.   Definitions and Terminology...............................3 
-     3.   Introduction..............................................4 
-       3.1.  Background.............................................4 
-       3.2.  Objectives.............................................5 
-       3.3.  Common Usage Scenarios.................................7 
-       3.4.  User Audiences.........................................9 
-       3.5.  Service Overview......................................11 
-       3.6.  Process Example.......................................13 
-     4.   The Internationalized Namespace..........................19 
-       4.1.  Internationalized Domain Names and Labels.............20 
-       4.2.  Internationalized Host Identifiers....................27 
-       4.3.  STD13 Domain Names....................................28 
-       4.4.  STD13 Host Identifiers................................29 
-     5.   Transfer Encodings and Label Types.......................30 
-       5.1.  The EDNS/UTF-8 Label Type.............................31 
-       5.2.  The STD13 Legacy Label Type...........................33 
-     6.   Application Guidelines...................................36 
-       6.1.  Input and Output Charsets.............................37 
-       6.2.  Protocol and Application Data.........................38 
-       6.3.  DNS Lookups and Resolver Calls........................40 
-     7.   Resolver Guidelines......................................42 
-       7.1.  Resolver APIs.........................................42 
-       7.2.  Query Processing Services.............................44 
-       7.3.  The Hosts Database....................................48 
-     8.   Server Guidelines........................................49 
-       8.1.  Internationalized Zones...............................50 
-       8.2.  Namespace Visibility Restrictions.....................51 
-       8.3.  The Master File Format................................52 
-     9.   Caching Guidelines.......................................53 
-     10.  Security Considerations..................................53 
-     11.  IANA Considerations......................................54 
-     12.  References...............................................54 
-     13.  Acknowledgements.........................................55 
-     14.  Editor's Address.........................................55 
-      
-   
-  Hall                    I-D Expires: May 2002               [page 2] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-      
-  2.      Definitions and Terminology 
-      
-     This document unites, enhances and clarifies several pre-existing 
-     technologies. Readers are expected to be familiar with the 
-     following specifications: 
-      
-          [AMC-ACE-Z] <draft-ietf-idn-amc-ace-z>, "AMC-ACE-Z version 
-            0.3.1" 
-      
-          [NAMEPREP] <draft-ietf-idn-nameprep>, "Preparation of 
-            Internationalized Host Names" 
-      
-          [STD13] (RFC 1034) "Domain names - concepts and facilities", 
-            (RFC 1035) "Domain names - implementation and 
-            specification" 
-      
-          [STD3] (RFC 1122) "Requirements for Internet Hosts -- 
-            Communication Layers", (RFC1123) "Requirements for Internet 
-            Hosts -- Application and Support" 
-      
-          [BCP18] (RFC 2277) "IETF Policy on Character Sets and 
-            Languages" 
-      
-          [RFC2279] "UTF-8, a transformation format of ISO 10646" 
-      
-          [RFC2671] "Extension Mechanisms for DNS (EDNS0)" 
-      
-      
-     The following abbreviations are used throughout this document: 
-      
-          UCS (Universal Character Set) - The ISO/IEC 10646 character 
-            set repertoire, as represented by the Unicode 3.1 
-            specification. 
-      
-          ACE (ASCII-Compatible Encoding) - A transfer encoding which 
-            encodes UCS character codes into a seven-bit codespace 
-            which is compatible with US-ASCII. 
-      
-          UTF-8 (UCS Transformation Format, Eight-Bit) - A transfer 
-            encoding which encodes UCS characters into an eight-bit 
-            codespace which is compatible with DNS message formats. 
-      
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
-     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
-     in this document are to be interpreted as described in RFC 2119. 
-   
-  Hall                    I-D Expires: May 2002               [page 3] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-      
-      
-  3.      Introduction 
-      
-     The domain name system (DNS) [STD13] currently defines a message, 
-     namespace and protocol. Although the DNS message is capable of 
-     transferring eight-bit character codes as protocol data, 
-     applications are currently limited to a subset of US-ASCII when 
-     they interact with the DNS namespace, and this restricted syntax 
-     is enforced by almost every TCP/IP application and protocol which 
-     utilizes domain names as embedded data (including, surprisingly, 
-     the DNS protocol). 
-      
-     In order to allow for the use of a larger range of characters in 
-     the namespace, this document extends and clarifies a variety of 
-     Internet specifications so that characters from the Universal 
-     Character Set (UCS) [ISO10646] may be used in domain names. This 
-     document also extends the DNS message structure to allow for the 
-     use of UTF-8 [RFC2279] encoded characters for the purpose of 
-     transferring these domain names, but also provides an ASCII-
-     compatible encoding (ACE) [AMC-ACE-Z] of these character codes 
-     which existing protocols and applications can use to access the 
-     internationalized domain names, and also provides identification 
-     mechanisms which allow the end-point systems to downwardly 
-     negotiate when needed. Finally, this document defines behavior for 
-     DNS systems which implement this architecture, including the end-
-     point applications which generate and store DNS domain names, and 
-     the resolvers, caches and servers which process them. 
-      
-     The mechanisms presented here are elective. Developers, zone 
-     administrators and network operators who wish to make use of the 
-     internationalized domain names may do so according to their own 
-     schedule. Those developers, administrators and operators who 
-     cannot or prefer not to implement the specified extensions can 
-     continue to use their legacy systems, and will still be able to 
-     access resources from the internationalized domain name system. 
-      
-      
-  3.1.    Background 
-      
-     From one perspective, DNS is already an "eight-bit clean" system, 
-     in that the structured DNS message is capable of storing and 
-     transmitting eight-bit data without any additional effort. 
-     However, this perspective only considers one particular facet of 
-     the domain name system, and ignores the more critical aspect of 
-   
-  Hall                    I-D Expires: May 2002               [page 4] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     the DNS namespace, which has rules that are entirely different 
-     from those which govern the message format. 
-      
-     The DNS namespace (or more appropriately, the view of the 
-     namespace which applications use and enforce) is governed by rules 
-     set forth in RFC952 [RFC952], STD3 [STD3], and STD13, which 
-     collectively define the characters that are eligible for use with 
-     host names. These rules are meant to provide a common template 
-     which may be applied to either the DNS namespace or a local hosts 
-     database, such that a query for "host.example.com" can be 
-     processed through either system. The range of valid characters 
-     currently defined are the letters, numbers and hyphen characters 
-     from US-ASCII [ASCII] (additional rules also govern the valid 
-     order and length of a host name). Character code values outside of 
-     this range are valid in domain name messages, but are undefined 
-     when used in the namespace, and are subject to interpretation by 
-     the applications which generate them. 
-      
-     The host name rules are enforced by almost every application and 
-     protocol which uses DNS to identify a host or system. This 
-     includes network utilities such as ping and traceroute which 
-     simply identify systems by name, and complex protocols such as 
-     SMTP which use domain names to determine message-routing paths. 
-     Portions of the DNS protocol itself are also affected by these 
-     restrictions, such as the domain names which may be used for NS 
-     resource records with sub-domain delegation operations (since 
-     these servers are connection targets, they are also required to be 
-     compliant with the host name rules). 
-      
-     Because these domain names are so pervasive throughout the 
-     Internet (and even within proprietary applications that run on 
-     private networks), it is not possible to declare a "flag day" at 
-     which eight-bit domain names will be considered valid encodings of 
-     a particular character set. Instead, an extended namespace with a 
-     larger set of charset rules must be defined, an extended DNS 
-     protocol capable of supporting these domain names must be 
-     deployed, and a transitional mechanism which allows the old and 
-     new systems to interact must be established. This document 
-     attempts to meet these objectives. 
-      
-      
-  3.2.    Objectives 
-      
-     In broad terms, this document has one overall goal, which is to 
-     facilitate the creation and use of an internationalized domain 
-     name system around a UCS namespace, a collection of UTF-8 and 
-   
-  Hall                    I-D Expires: May 2002               [page 5] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     legacy-compatible encodings which are suitable for transferring 
-     internationalized domain names within DNS and the affected 
-     application data streams, and a negotiation mechanism which allows 
-     end-point systems to identify the encoding that they will use for 
-     a particular operation. 
-      
-     One of the objectives stated above is to internationalize the 
-     existing DNS namespace, by allowing UCS characters to be used in 
-     host names and sub-domain delegations in old and new zones 
-     equally. As such, this document does not define a new namespace, 
-     but instead defines mechanisms by which leaf-nodes and sub-domains 
-     may be created within the existing hierarchy. 
-      
-     UTF-8 was chosen as the primary transfer encoding of these domain 
-     names for several reasons. For one, there is a wide availability 
-     of tools and expertise surrounding UTF-8, and it is already widely 
-     deployed within development environments, operating systems and 
-     applications. Furthermore, BCP18 [BCP18] requires that new 
-     application protocols be able to use UTF-8 as application data, 
-     and for many applications, this specifically means domain names 
-     which are passed as data. All signs indicate that UTF-8 is 
-     currently and will continue to be the preferred eight-bit encoding 
-     on the Internet, and this specification embraces this position in 
-     its design. 
-      
-     However, most of the network services currently in use are bound 
-     by the legacy host naming restrictions, and those applications and 
-     protocols will also need to be able to interact with resources 
-     from the internationalized namespace, even though they will not be 
-     compliant with the UTF-8 encoding mechanisms defined in this 
-     document. In order to allow these systems to participate, this 
-     specification also embraces the use of ACE as a seven-bit 
-     backwards-compatible encoding for legacy systems to use. 
-      
-     Note that even though a single encoding could have been specified 
-     by this document, past and present requirements would not have 
-     been satisfied by a single choice. For example, supporting UTF-8 
-     alone would mean isolating legacy systems from resources in the 
-     UCS namespace, while supporting ACE alone would not have provided 
-     a truly internationalized namespace (the ACE encoded domain names 
-     still appear in user data quite frequently). By allowing the UTF-8 
-     and ACE encodings to coexist, the existing and emerging 
-     communities can both be served. 
-      
-     Because both encodings will be active during the same time period, 
-     this document also defines DNS protocol extensions which allow the 
-   
-  Hall                    I-D Expires: May 2002               [page 6] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     end-point systems to detect the encoding that is in use for a 
-     particular query/response pair. Note that these negotiation 
-     mechanisms not only allow new and legacy systems to interoperate, 
-     but they also provide a transition service for developers, zone 
-     administrators and end-users, in that ACE encoded domain names can 
-     be initially deployed within existing applications and DNS 
-     systems, while individual elements of the infrastructure can be 
-     upgraded without disturbing other components. 
-      
-      
-  3.3.    Common Usage Scenarios 
-      
-     Discussion of the mechanism provided by this document depends upon 
-     the usage context of the domain names themselves. Domain names are 
-     extremely pervasive, and are used by almost every TCP/IP protocol 
-     and application in one form or another. However, most usages fall 
-     under one or more of the following scenarios: 
-      
-        *   Connection identifiers. Domain names are most commonly 
-            used as host-specific identifiers for outbound connection 
-            requests, whether this be for a command-line application 
-            such as ping, or as a host name which is stored in an 
-            application's configuration file. Another common usage 
-            scenario for connection identifiers is with reverse 
-            lookups, where a server is logging incoming connections by 
-            the corresponding domain name, or where a program such as 
-            netstat is displaying all of the application sessions which 
-            are currently active on a host. In both of these cases, 
-            domain names are passed through applications to a resolver, 
-            resulting in DNS queries and responses which eventually 
-            provide the requested DNS data. 
-      
-            A related use (but one which does not generate DNS 
-            messages) is determining the host name of the local system. 
-            This is commonly found with applications and protocols that 
-            need to display the domain name of the local system as part 
-            of a protocol operation (such as an SMTP greeting banner) 
-            or as application data. 
-      
-            Connection identifiers (and lookups in general) are 
-            probably the largest single use of domain names today, and 
-            this is likely to be the case with internationalized domain 
-            names as well. This document fully supports the use of 
-            internationalized domain names for lookup operations, as 
-            long as the calling application, the stub resolver, the 
-            local caching servers, and the authoritative servers for 
-   
-  Hall                    I-D Expires: May 2002               [page 7] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            the specified domain name are compliant with this 
-            specification. If any of these components are not capable 
-            of supporting internationalized domain names in this 
-            manner, the ACE equivalent domain name will be negotiated 
-            for the operation at hand. 
-      
-        *   Protocol data. Some application protocols exchange domain 
-            names as protocol data, with those domain names either 
-            determining or altering a service-specific operation. 
-            Examples of this usage include SMTP envelopes ("RCPT TO 
-            <user@domain.dom>") where the domain name is used to 
-            determine whether or not a particular email message should 
-            be accepted for delivery, the HTTP HOST header field which 
-            identifies a specific document tree on a shared server, 
-            BOOTP/DHCP options, WHOIS input, and more. 
-      
-            Because these protocols treat domain names as protocol 
-            data, most of these protocols also have specific formatting 
-            requirements which must be addressed before UTF-8 domain 
-            names can be used by these protocols directly. This 
-            document is intended to facilitate the use of UTF-8 encoded 
-            domain names in this manner, although it is expected that 
-            most of the protocol development groups will need to 
-            develop negotiation mechanisms before these protocols can 
-            use internationalized domain names directly. Until such 
-            work is completed, ACE equivalent domain names can be used 
-            to provide these protocols with access to the 
-            internationalized namespace. 
-      
-        *   Structured application data. Structured application data 
-            is similar to protocol data in that it can trigger or 
-            affect some protocol action, although this will not always 
-            occur. For example, a web browser can process an embedded 
-            IMG link which may be present in a web page, while a user 
-            can manually follow an embedded email link which is also 
-            stored in the same web page; even though both usage models 
-            share the same structured data format (URLs), they are 
-            processed differently by the application. Similarly, email 
-            messages typically contain multiple domain names as 
-            structured data in the message headers, and some of these 
-            domain names will directly affect subsequent protocol 
-            operations, while others will not. 
-      
-            Because of this ambiguity, this document defines no 
-            specific treatment for structured application data. In some 
-            cases, no additional mechanisms will be required, while 
-   
-  Hall                    I-D Expires: May 2002               [page 8] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            other scenarios will require negotiation mechanisms before 
-            an internationalized domain name can be used in the 
-            structured data (with ACE being required as the interim 
-            format). Each protocol development group is encouraged to 
-            analyze each usage independently, to classify the usage as 
-            a connection identifier, protocol data, or unstructured 
-            application data, and to determine the appropriate course 
-            of action for each usage accordingly. 
-      
-        *   Unstructured application data. Many application protocols 
-            provide free-text data which can contain domain names, but 
-            with those domain names existing as unstructured data. For 
-            example, an email message which is provided as a text/plain 
-            MIME body part may contain a domain name which identifies a 
-            system or service in the context of a specific application, 
-            but in an unstructured form ("your files were moved from 
-            server1 to server2"). Similarly, an email address may be 
-            provided in WHOIS output, but as unstructured data which 
-            does not affect the protocol. 
-      
-            Given the application-specific nature of this data, it 
-            cannot be managed by any global protocol or process. Where 
-            a protocol has rules or restrictions on the data itself, 
-            then those rules are maintained, but some formatting rules 
-            may need to be extended before internationalized domain 
-            names (or their equivalents) can be encoded in the 
-            application data. For example, internationalized domain 
-            names in email messages may need to be converted to a 
-            preferred display charset, while ACE equivalents may be 
-            necessary for protocols which only support US-ASCII. 
-      
-     Each of the above scenarios represent distinct handling cases 
-     where internationalized domain names may or may not be used 
-     directly. In some cases, the internationalized domain names may be 
-     used as soon as the applications and resolvers are configured to 
-     use them, while in other cases, measured and cautious deployment 
-     is required in order to prevent undue breakage. In the latter 
-     cases, however, the backwards-compatible ACE encoding is available 
-     so that the internationalized domain names can be used. 
-      
-      
-  3.4.    User Audiences 
-      
-     Another perspective on the changes which will result from 
-     deploying the mechanisms described in this document can be seen by 
-     analyzing how any such changes will affect the different 
-   
-  Hall                    I-D Expires: May 2002               [page 9] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     "audiences" who work with domain names, and who have their own 
-     unique context-specific usage requirements and objectives. The 
-     three main audiences discussed in this document are: 
-      
-        *   Developers. Protocol and application developers need to be 
-            able to incorporate internationalized domain names into 
-            their systems as easily as possible, although there are 
-            many factors which will affect such usage, including the 
-            input and output charsets and encodings which are available 
-            to the applications and protocols. Where feasible, this 
-            specification allows developers to choose any charset or 
-            encoding which may be required and suitable for use, 
-            although in most cases, a recommendation is also made for 
-            the use of UTF-8 in particular. 
-      
-            Developers may adopt internationalized domain names for 
-            connection identifiers and lookup operations fairly 
-            quickly, such that users can use those system as soon as 
-            they have compliant systems (and they have a target domain 
-            name to communicate with). Implementing support for 
-            internationalized domain names in protocols and application 
-            data will require additional effort by the affected 
-            development groups. 
-      
-            Support for ACE will be harder to implement, since it is a 
-            relatively new and untested encoding syntax, with no 
-            existing developer tools. This will likely be the largest 
-            hurdle to overcome when developing applications for use 
-            with this service. 
-      
-        *   Zone administrators. Organizations that wish to deploy 
-            internationalized domain names should be able to do so 
-            easily, at a reasonable cost, and without suffering 
-            excessive pre-conditions. Towards this objective, the 
-            mechanisms described by this document allow organizations 
-            to deploy and use internationalized domain names within any 
-            zone immediately, without requiring any other zone to have 
-            been updated beforehand (although there are specific and 
-            strong suggestions for upgrading the Internet's high-load 
-            servers as soon as possible). 
-      
-            If an organization wishes to publish internationalized 
-            domain names for users to access and utilize, the 
-            authoritative servers for the affected zone must be 
-            compliant with the naming rules and message formats 
-            described by this document, which will almost certainly 
-   
-  Hall                    I-D Expires: May 2002              [page 10] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            require the administrators of that zone to upgrade their 
-            servers. However, organizations may also choose to only 
-            deploy ACE encoded domain names if an immediate migration 
-            is not feasible, with the caveat that internationalized 
-            domain names in their native form will not be available 
-            from those zones. 
-      
-        *   Network operators. The systems and human users which 
-            generate DNS lookups are another area of concern, as these 
-            protocols, programs and users will expect these lookups to 
-            succeed, and will also expect that the visible namespace 
-            will be compatible with the capabilities of the requesting 
-            system at a minimum investment. This is a broad range of 
-            requirements. 
-      
-            At a minimum, applications must be capable of generating 
-            and accepting the internationalized domain names if they 
-            are to use those domain names (see the "Developers" 
-            discussion above for the application requirements). 
-            Similarly, the local resolvers, caches and forwarders on 
-            the user's network must also support the message formats if 
-            they are to relay internationalized domain names between 
-            their local applications and the remote zones being 
-            queried. If the applications, resolvers and caches do not 
-            support these requirements, intermediary systems will 
-            perform the down-level negotiation automatically on their 
-            behalf such that additional effort is not required on the 
-            user's part. 
-      
-     In summary, the developers, zone administrators and end-users can 
-     immediately participate in the internationalized namespace at no 
-     additional expense if they are content with using ACE encoded 
-     domain names, and can use internationalized domain names in their 
-     native form if they are willing to make the necessary investments. 
-     Furthermore, since the native and backwards-compatible encodings 
-     are not mutually exclusive, implementers of this specification 
-     have the option of adopting ACE for immediate use and then 
-     transitioning to internationalized domain names on a per-system, 
-     per-zone, or per-application basis, according to their schedule. 
-      
-      
-  3.5.    Service Overview 
-      
-     This document specifies a variety of extensions to several 
-     different protocols and services in order to facilitate the use of 
-     internationalized domain names anywhere this support exists or can 
-   
-  Hall                    I-D Expires: May 2002              [page 11] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     be implemented, and to provide a legacy-compatible domain name in 
-     all other situations. 
-      
-     More specifically, this document defines or clarifies behavior for 
-     the following elements: 
-      
-        *   Host name character restrictions. Legacy protocols and 
-            applications are currently restricted to the legacy host 
-            naming rules, which only allow for a subset of US-ASCII 
-            characters (letters, digits and the hyphen character). This 
-            document redefines the characters which are valid within a 
-            host name so that system identifiers, domain name parts of 
-            host names, and new network services can use most of the 
-            characters from the UCS. 
-      
-        *   DNS message format. This document defines an extended label 
-            format based on the extended label services provided by 
-            RFC2671 (Extension Mechanisms for DNS - EDNS0) [RFC2671], 
-            with this label format being used to encapsulate UTF-8 
-            encoded internationalized domain names in DNS messages. Any 
-            DNS message which carries the UTF-8 encoded domain names is 
-            required to use the EDNS/UTF-8 label type defined in this 
-            document. Any DNS message which carries legacy domain names 
-            (including the ACE encoded equivalent domain names) is 
-            required to use the traditional message format. 
-      
-        *   Application handling rules. Applications can use 
-            internationalized domain names immediately for lookup 
-            operations that do not directly affect external services or 
-            protocols, and can use ACE encoding sequences to specify 
-            internationalized domain names in legacy protocol 
-            operations, and can use them both at the same time. 
-      
-        *   Stub resolvers. Stub resolvers will most likely need to 
-            provide a series of internationalized APIs in order to 
-            fully support applications that generate internationalized 
-            domain name lookups. For example, these APIs will almost 
-            certainly be required in order for the resolver to 
-            determine that the calling application is compliant with 
-            the host name requirements defined by this document, and 
-            that the domain names should be encoded in the proper label 
-            format. Although this specification does not dictate these 
-            APIs, it encourages their use, and provides some guidance 
-            on the issues surrounding their use. 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 12] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-        *   Forwarders, resolving servers and caches. The user-side 
-            servers which process internationalized domain names have 
-            several protocol-specific requirements, including the 
-            negotiated fall-back service when UTF-8 queries fail. 
-      
-        *   Authoritative servers. A key part of this specification is 
-            the simultaneous support for internationalized and legacy 
-            compatible domain names in the UCS namespace, thereby 
-            allowing a domain name to be entered into an authoritative 
-            zone database once, and for the appropriate response to be 
-            generated by a server according to the label encoding from 
-            the associated query. In order for this to work, this 
-            specification requires authoritative servers which serve 
-            internationalized domain names to comply with specific 
-            conditions. This specification also allows existing servers 
-            to serve ACE equivalent domain names when the authoritative 
-            servers cannot be upgraded, although this typically results 
-            in lower levels of functionality. 
-      
-     The elements listed above collectively define a completely 
-     internationalized domain name system, which is capable of 
-     servicing internationalized domain names in all compliant systems, 
-     and which is also capable of providing ACE encoded equivalent 
-     domain names when any component from the internationalized service 
-     is not available. 
-      
-      
-  3.6.    Process Example 
-      
-     This section illustrates a series of query/response transactions 
-     under which the processes and protocols defined in this document 
-     function. This example uses a reverse lookup for the PTR resource 
-     record associated with the "14.2.0.192.in-addr.arpa." domain name 
-     (forward lookups work similarly, but the issues are more fully 
-     demonstrated by PTR lookups). Each of the various technologies 
-     shown below are described in later sections of this document. The 
-     sole purpose of this example is to provide an illustration of 
-     these mechanisms in order to facilitate better discussion. 
-      
-     Note that this illustration represents a worst-case scenario 
-     (thereby exercising most of the functionality provided by this 
-     specification), and does not represent a typical scenario. 
-      
-        a.  First, a PTR resource record for 14.2.0.192.in-addr.arpa. 
-            is added to the internationalized zone database on the 
-            replication master server for the 2.0.192.in-addr.arpa. 
-   
-  Hall                    I-D Expires: May 2002              [page 13] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            zone, with the resource record data value of 
-            "host.<idn>.example.com." (where <idn> is an 
-            internationalized domain name compliant with the host 
-            naming rules provided in this document). Both of these 
-            domain names have a primary representation consisting of 
-            UCS characters in some local encoding, but are also 
-            available as UTF-8 and ACE encoded data so they can be 
-            encapsulated within DNS queries and responses. 
-      
-            Once the zone is reloaded and is replicated by the other 
-            authoritative servers for that zone, the domain names can 
-            be processed. 
-      
-        b.  An application on a remote system generates a DNS lookup 
-            for the PTR resource record associated with the 
-            14.2.0.192.in-addr.arpa. domain name. 
-      
-            If this is a legacy application, it issues the lookup using 
-            the only method it knows, which is to pass the domain name 
-            to the legacy resolver API. This would result in the 
-            resolver issuing a legacy DNS query for the PTR resource 
-            record associated with the specified domain name. 
-      
-            If this application is compliant with this specification, 
-            it performs the following steps: 
-      
-            1.   Verify that the resolver is capable of processing 
-                 queries for UTF-8 domain names by probing for an 
-                 internationalized API. If this step failed, then the 
-                 domain name would be converted to the legacy STD13 
-                 octet encoding in step 3.6.b.3 and passed to the 
-                 resolver's legacy API. 
-      
-            2.   Convert the domain name from its generated encoding to 
-                 the canonical UCS characters, and then normalize and 
-                 case-convert the UCS characters. 
-      
-            3.   Convert the normalized and lowercased UCS characters 
-                 to the charset or encoding used by the resolver's 
-                 internationalized API. 
-      
-            4.   Issue a lookup for the PTR resource record associated 
-                 with the internationalized domain name, via the 
-                 resolver's internationalized API. 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 14] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-                 Note that even though the domain name is compatible 
-                 with the legacy host name rules, the domain name is 
-                 passed through the internationalized API so that 
-                 servers can tell whether or not the original 
-                 application is UTF-8 compliant, and can determine the 
-                 format of any internationalized domain names which are 
-                 to be returned in the response messages. This is 
-                 required in case the queried resource record includes 
-                 internationalized domain names as resource record data 
-                 (as would be the case with PTR resource records), and 
-                 is also required for the proper handling of any SOA or 
-                 NS resource records which may be returned as 
-                 additional data in the response. 
-      
-            For the purpose of this example, we will assume that each 
-            of these steps were successfully performed. 
-      
-        c.  The client's stub resolver generates the query, with the 
-            Question Section of the query containing the UTF-8 encoded 
-            domain name encapsulated in an EDNS/UTF-8 extended label. 
-      
-        d.  The stub resolver sends the query to one of its configured 
-            resolving servers. 
-      
-        e.  The resolving server will either answer the query from its 
-            cache or forward the query to a name server which is 
-            authoritative for the namespace hierarchy, as per the 
-            normal query-resolution procedure. For the purpose of this 
-            example, we will assume that the server has no information 
-            about the specified domain name, so it forwards the query 
-            to one of the root zone's authoritative servers in order to 
-            begin the iterative resolution process. 
-      
-        f.  The queried server responds with a referral, providing 
-            delegation data for a zone in the path to the queried 
-            domain name. For the purposes of this example, we will use 
-            192.in-addr.arpa. as the delegation domain specified in the 
-            referral message. 
-      
-            The specific format of the referral will depend on whether 
-            or not the queried server understands the EDNS/UTF-8 label 
-            encoding. If the server is compliant with this 
-            specification (which it is, or else it wouldn't have 
-            answered with a referral), then the referral will also 
-            provide ENDS/UTF-8 encoded domain names in the Authority 
-            and Additional-Data Sections of the referral. If the server 
-   
-  Hall                    I-D Expires: May 2002              [page 15] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            was not compliant with this specification, it would return 
-            an error upon seeing the extended label type, which would 
-            cause the resolving server to restart the query using the 
-            legacy label type. 
-      
-        g.  The resolving server decodes the UTF-8 encoded domain names 
-            to their UCS character representation, caches the resource 
-            records in their UCS form, and sends the query to one of 
-            the authoritative servers for the referral zone. Note that 
-            the cache did not normalize or case-convert the UCS 
-            characters; only the end-systems perform this work. 
-      
-        h.  In this case, the queried server does not understand the 
-            EDNS/UTF-8 label format, and has returned a FORMERR 
-            response code. 
-      
-        i.  When these errors are encountered, the current resolver 
-            (whether this is the client's stub resolver or a caching 
-            server in the query path) must convert the query domain 
-            name from its current form to a legacy-compatible encoding 
-            (either ACE or STD13 octet sequences, depending on the UCS 
-            characters which have been encoded), and then has to 
-            reissue the query in that format. 
-      
-            In this case, the domain name only contains printable 
-            characters from US-ASCII, so the STD13 octet encoding is 
-            used for the fall-back query. Because the UCS domain name 
-            was normalized and lowercased before it was passed to the 
-            client's stub resolver, the legacy domain name will also be 
-            in this format (although it will be compared in a case-
-            neutral form by the recipient server). 
-      
-            Note that once this conversion takes place, the legacy 
-            label format is used for the remainder of the current query 
-            chain (this prevents excessive delays from multiple fall-
-            back operations, which could result in timeouts at the 
-            original resolver or application).  
-      
-   
-  Hall                    I-D Expires: May 2002              [page 16] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-        j.  The queried server returns a delegation referral for the 
-            2.0.192.in-addr.arpa. zone. Since the query arrived in the 
-            STD13 octet encoding, the server has no indicator of the 
-            client's capabilities, so the referral NS resource records 
-            will also be returned in legacy compatible form (either as 
-            STD13 octet sequences or as ACE encoded data, depending on 
-            the character codes provided in each label from each of the 
-            associated domain names). 
-      
-            Note that even though these NS resource records will be 
-            restricted to legacy-compatible host names and label types, 
-            they may contain and reference ACE domain names. In this 
-            regard, a legacy server in the delegation path does not 
-            prevent internationalized domain names from being delegated 
-            or resolved, but only prevents them from being processed as 
-            EDNS/UTF-8 extended labels. 
-      
-            Also note that once the authoritative servers for a zone 
-            have been discovered and cached, any subsequent UTF-8 
-            queries which are generated for the resources in that zone 
-            will be sent directly to one of those servers, bypassing 
-            the delegation hierarchy. As such, subsequent queries which 
-            are provided in EDNS/UTF-8 labels can be processed directly 
-            by the zone's authoritative servers, without the delegation 
-            servers disrupting the process. 
-      
-        k.  The resolving server decodes the STD13 octet sequences and 
-            ACE encoded domain names to their UCS character 
-            representations, caches the resource records, and resends 
-            the query to one of the authoritative servers for the 
-            referral zone. 
-      
-        l.  The queried server processes the request. Since this query 
-            arrived as an STD13 octet sequence, the server must compare 
-            the seven-bit characters from the domain name (which is all 
-            of them, in this example) in a case-neutral form. Note that 
-            if the query had arrived as ACE or UTF-8 encoded domain 
-            names, the server would have decoded the specified domain 
-            name to its canonical UCS characters and performed a case-
-            exact match against the resulting characters. 
-      
-        m.  The queried server responds with the requested data. Note 
-            that the query was submitted in the legacy label form due 
-            to the fall-back processing which occurred in step 3.6.i, 
-            so the server will only respond to this query with STD13 
-   
-  Hall                    I-D Expires: May 2002              [page 17] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            octet sequences or ACE encoded domain names, using the 
-            STD13 legacy label. 
-      
-        n.  The resolving server decodes the STD13 octet sequences and 
-            ACE encoded domain names to their UCS character 
-            representations, and caches the resource records. Since the 
-            query was originally received as an internationalized 
-            domain name (as indicated by the EDNS/UTF-8 extended label 
-            from the original query), the resolving server has to 
-            encode the answer data as UTF-8 before passing it back to 
-            the client's stub resolver. However, since the input was 
-            not provided in an encoded UCS form, the server has to 
-            normalize and case-convert the STD13 octet sequence in 
-            order to provide a valid internationalized domain name. 
-      
-        o.  The stub resolver decodes the UTF-8 encoded domain names 
-            which have been provided in the response message to their 
-            UCS character representation, and passes the data to the 
-            original calling application using the charset or encoding 
-            favored by the resolver. 
-      
-        p.  The application validates the received domain name by 
-            decoding the internationalized domain name to its canonical 
-            UCS characters, normalizing and down-casing the resulting 
-            domain name, and comparing the results with the answer data 
-            which was provided by the resolver. 
-      
-     As can be seen, the UTF-8 name resolution process is identical to 
-     the current resolution process, with the addition of a single 
-     fall-back query in step 3.6.i which resulted in one extra 
-     query/response pair (roughly equivalent to adding one extra 
-     delegation referral into the query path), and with several 
-     different encoding conversions, as required by the participating 
-     systems and services. This example also illustrates the 
-     requirements which are placed on developers, zone administrators, 
-     and network operators in order for typical connection identifier 
-     services to function with UTF-8 domain names. 
-      
-     However, if each system and service had used UTF-8 for encoding 
-     purposes (including everything between the stub resolver's APIs 
-     and the authoritative servers for the target zone), then no 
-     additional queries or conversions would have been required (other 
-     than the direct UCS conversions required for validation and 
-     caching, the latter of which can be performed separately without 
-     affecting the processing path). In this regard, the example above 
-     illustrates how this system can function even when only a portion 
-   
-  Hall                    I-D Expires: May 2002              [page 18] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     of the participating systems utilize UTF-8, and also illustrates 
-     how effective the entire operation would be if all of the 
-     recommendations and requirements provided in this specification 
-     were adopted. 
-      
-     It is also important to reiterate here that any such costs 
-     associated with this compliance are entirely elective by the 
-     affected parties. If they want to streamline the process, the 
-     option is available to them, although the system also works when 
-     very few optimizations are implemented. 
-      
-      
-  4.      The Internationalized Namespace 
-      
-     In simple terms, this specification defines an internationalized 
-     namespace which consists of domain names and labels that contain 
-     UCS character codes, and also specifies a series of encoding 
-     formats which may be used whenever the UCS values need to be 
-     encapsulated for transmission within DNS messages or application 
-     data streams. 
-      
-     In this regard, the internationalized namespace is the UCS 
-     representation of the domain names and labels as they are used for 
-     comparison operations once a domain name arrives for processing, 
-     while the transfer encodings ensure that a domain name arrives at 
-     the destination system intact, so that it may be processed in its 
-     canonical form. 
-      
-     There are four conceptual elements to this model: 
-      
-        *   Character codes. Labels from internationalized domain names 
-            have a single logical canonical representation as sequences 
-            of UCS code point values. The UCS characters are used when 
-            a particular label from a domain name is created by an 
-            application, stored in a zone, hosts or cache database, and 
-            is used whenever two sets of domain names or labels need to 
-            be compared. However, different kinds of domain names have 
-            different rules which govern the character codes that may 
-            be used. 
-      
-        *   Storage encodings. Whenever a domain name is created or 
-            copied from the network, it must be stored in a format that 
-            is reversible to the canonical UCS character representation 
-            of that domain name. This specification does not mandate or 
-            require any particular storage encoding, and allows this 
-            decision to be made on a per-implementation basis, as long 
-   
-  Hall                    I-D Expires: May 2002              [page 19] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            as the storage encoding supports character codes which can 
-            be converted to UCS equivalent values for comparison 
-            purposes. However, the use of UTF-8 for this purpose is 
-            encouraged, since it is the most common. 
-      
-        *   Transfer encodings. Whenever a domain name needs to be sent 
-            over the network, it must be packaged in a form which is 
-            compliant with the capabilities of the transfer protocol in 
-            use. This document specifies three transfer encodings which 
-            may be used to encode canonical UCS character codes in DNS 
-            messages or application streams, which are: the octet 
-            encoding from STD13, the ACE encoding from <ACE-Z>, and the 
-            UTF-8 encoding from RFC2279. Each encoding has different 
-            costs and benefits in different usage scenarios. 
-      
-        *   Comparison operations. When two domain names need to be 
-            compared, they also follow rules which are appropriate to 
-            the type of domain name being provided, and the transfer 
-            encoding which may have been used to provide the domain 
-            name to the system. 
-      
-     This document defines four distinct types of internationalized 
-     domain names which may exist in the internationalized namespace, 
-     and also describes how each of the above considerations affect 
-     those domain names and their labels. These domain name types are 
-     described throughout the remainder of this section. 
-      
-      
-  4.1.    Internationalized Domain Names and Labels 
-      
-     This section describes the master template rules for all domain 
-     names and labels which may be used in the internationalized 
-     namespace, although subordinate rules and restrictions are also 
-     applied as secondary filters, depending on the intended usage of 
-     the domain name. 
-      
-     For example, domain names and labels which are to be used as 
-     internationalized host identifiers (either as host names, or as 
-     domain names which are used to specify a host) are restricted to a 
-     specific subset of UCS characters. Meanwhile, domain names and 
-     labels which are compliant with STD13's global rules are 
-     restricted to eight-bit code values, while the domain names and 
-     labels which are used as STD13 host identifiers are restricted to 
-     a specific subset of US-ASCII. 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 20] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-      
-     The following diagram illustrates how the subordinate rules are 
-     applied and interpreted against the master restrictions: 
-      
-                      +-----------------------+ 
-                      | Internationalized DNs | 
-                      +-----------------------+ 
-                       any UCS character codes 
-                          /       | 
-                         /        | 
-                        /         | 
-                       /          | 
-          +-----------+     +-----------+     +------------+ 
-          | Int. Host |     | STD13 DNs +-----+ STD13 Host | 
-          +-----------+     +-----------+     +------------+ 
-          normalized        character         ASCII letters, 
-          subset of         codes 0x00        numbers, and 
-          UCS chars         through 0xFF      hyphen char 
-      
-     As can be seen, the internationalized domain names and labels 
-     rules allow any UCS character code to be stored, although each 
-     particular usage of the domain names and labels will have their 
-     own secondary rules and restrictions. 
-      
-     In order to allow future documents to define additional rules as 
-     required for their usage, this document defines very few global 
-     rules on the core internationalized domain names and labels. 
-      
-      
-  4.1.1.  IDN syntax and structure 
-      
-     In this specification, an internationalized domain name consists 
-     of a variable number of labels, each of which contain a variable 
-     number of UCS character codes, not all of which will have defined 
-     UCS character interpretations. 
-      
-     Furthermore, the encoding system which is used to store and 
-     interpret those values on a system is not relevant to this 
-     specification, and is therefore not defined. The characters in a 
-     label can be stored in memory or on disk as UTF-8, UCS-4, ACE, or 
-     any other storage encoding which is desired by the operators and 
-     implementers of the affected system, as long as that encoding 
-     system is reversible to the canonical UCS character code values, 
-     and is able to represent the necessary range of UCS characters 
-     (the "necessary range" varies by operation). 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 21] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     The only universal restrictions which apply to internationalized 
-     domain names and labels are those which govern length. This 
-     specification requires that labels from internationalized domain 
-     names MUST be restricted to a minimum length of two characters and 
-     a maximum length of 63 characters, inclusive. The exception to 
-     this rule is the root domain, which is always represented by a 
-     zero-length label. Note that this rule specifically refers to the 
-     canonical UCS characters, rather than any encoded form (encoding 
-     will often result in labels and domain names with fewer actual 
-     characters, due to overhead from the encoding algorithm). 
-      
-     A fully-qualified internationalized domain name is formed by 
-     joining a series of labels together, with the most-contextually 
-     specific label in the left-most position of the label sequence, 
-     and with the root domain occupying the right-most position. The 
-     sum total of all labels in an internationalized domain name MUST 
-     NOT exceed 255 characters, inclusive. Any number of labels MAY be 
-     stored in the domain name, but the sum total of their lengths MUST 
-     NOT exceed this limit. 
-      
-     However, labels which contain UCS character codes greater than 
-     U+007F will result in multi-byte UTF-8 and ACE encodings, so the 
-     maximum length of a label or an internationalized domain name is 
-     governed by their UTF-8 and ACE encoded lengths. Both encodings 
-     MUST result in an encoded length of 63 octets or less in order to 
-     be usable, with a maximum cumulative length of 255 octets. 
-      
-      
-  4.1.2.  IDN transfer encodings 
-      
-     The UCS is currently occupies a 21-bit range of character code 
-     values, containing tens of thousands of assigned characters, and 
-     hundreds of thousands of unassigned characters. Due to the multi-
-     byte nature of the code point values, UCS characters cannot be 
-     passed as protocol or application data in most of the existing 
-     Internet protocols (including DNS messages), at least not without 
-     the help of some kind of encoding scheme. At the very least, the 
-     UCS character values have to be encoded as eight-bit sequences if 
-     they are to fit within existing eight-bit data structures, and 
-     have to be encoded as a subset of US-ASCII characters if they are 
-     to be usable with legacy protocols and applications which only use 
-     STD13's host identifier rules for their structured domain name 
-     data types. 
-      
-     With this objective in mind, this document defines three different 
-     transfer encoding systems which can be used to convert 
-   
-  Hall                    I-D Expires: May 2002              [page 22] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     internationalized domain names and labels into a form which is 
-     suitable for transfer in different data streams. These are the 
-     legacy STD13 octet encoding, ACE, and UTF-8. Each of these 
-     encoding schemes provide different benefits and capabilities to 
-     the internationalized DNS effort. 
-      
-        *   STD13 octets. The STD13 octet encoding scheme provides a 
-            direct one-to-one mapping between eight-bit characters and 
-            their eight-bit values, but it is only capable of storing 
-            character codes in the range of U+0000 through U+00FF, 
-            which severely restricts its usefulness. 
-      
-        *   ACE. The ACE encoding scheme is capable of storing UCS 
-            character code value as seven-bit sequences in STD13 legacy 
-            labels. While this makes it practically compatible with the 
-            legacy host identifier rules, the resulting data imposes 
-            additional labor on the Internet community, and the reuse 
-            of the legacy label also results in certain amounts of 
-            ambiguity with some DNS domain names and labels. 
-      
-        *   UTF-8. The UTF-8 encoding scheme is capable of encoding all 
-            UCS character code values as sequences of eight-bit data 
-            which are compatible with legacy DNS message restrictions, 
-            but the encoded output requires explicit support from 
-            internationalized applications and protocols. UTF-8 output 
-            uses a new label type in order to prevent additional 
-            ambiguity problems from arising. 
-      
-     The table below illustrates the UCS character code sequences which 
-     are supported by each of the different encoding schemes. 
-      
-                          STD13 
-                          Octets   ACE    UTF-8 
-                        +-------+-------+-------- 
-                        |       |       | 
-               US-ASCII |   Y   |       |   Y 
-                        |       |       | 
-              Eight-Bit |   Y   |   Y   |   Y 
-                        |       |       | 
-          Any UCS Chars |       |   Y   |   Y 
-                        |       |       | 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 23] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     More specifically, the character code sequence ranges and their 
-     valid encodings are: 
-      
-        *   US-ASCII. If a label only contains character codes from the 
-            range of U+0000 through U+007F, then it MAY be encoded as a 
-            legacy STD13 octet sequence or UTF-8, but MUST NOT be 
-            encoded as ACE. 
-      
-            Note that this specification explicitly prohibits seven-bit 
-            labels from being encoded as ACE data, since such an action 
-            would be redundant, results in greater processing overhead 
-            for those labels, and multiple representations introduce 
-            problems with caches on legacy systems. Furthermore, 
-            certain security risks would be introduced if this were 
-            allowed. For example, a malicious user could register or 
-            purposefully create an ACE encoded representation of the 
-            "example.com" label sequence such that users mistakenly 
-            sent sensitive data to malicious systems. 
-      
-            In order to prevent these problems from occurring, this 
-            specification requires that any ACE-encoded label which 
-            consists entirely of seven-bit characters MUST be 
-            immediately discarded with extreme prejudice. This rule 
-            applies to every implementation of this specification, 
-            including any applications, resolvers, caches or servers 
-            which process labels. 
-      
-        *   Eight-bit codes. If a label contains character codes from 
-            the eight-bit range of U+0000 through U+00FF, then it MAY 
-            be encoded as STD13 octet sequences, ACE, or UTF-8. This 
-            rule specifically requires that the label MUST contain at 
-            least one character from the eight-bit range, MAY contain 
-            any number of characters from the seven-bit range, but MUST 
-            NOT contain characters with code values which are greater 
-            than U+00FF. 
-      
-            Since the STD13 octet encoding and ACE both use the legacy 
-            STD13 label type, this specification relies on the input 
-            encoding of a domain name in order to determine the output 
-            encoding. In some cases, however, the input encoding will 
-            not be clear, or will not be specified, and this can result 
-            in some ambiguity with label sequences from this range. 
-      
-            For example, if the domain name provided in a query 
-            consists of seven-bit labels, then the STD13 octet sequence 
-            is the only valid encoding for the legacy STD13 label, 
-   
-  Hall                    I-D Expires: May 2002              [page 24] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            meaning that ACE could not have been used in the query. If 
-            the specified domain name exists as a CNAME resource record 
-            which refers to a domain name that contains eight-bit 
-            character codes, then the proper output encoding for that 
-            domain name will not be clearly discernable. Moreover, the 
-            STD13 and ACE encodings will generate different results, 
-            since the STD13 octet sequence will only contain a single 
-            octet for the eight-bit character, while the ACE encoding 
-            will contain multiple octets of encoded data. 
-      
-            When this situation arises, systems MUST give preference to 
-            the ACE encoding, on the assumption that the referenced 
-            character is more likely to represent a UCS character than 
-            an eight-bit code value (the UCS characters in this range 
-            are Latin-1, which are the most common characters after the 
-            legacy US-ASCII set). Furthermore, the ACE encoded 
-            representation of these characters allow for a broader 
-            range of subsequent operations (since it complies with the 
-            legacy host naming restrictions, it can be used with CNAME 
-            resource records that refer to hosts), while the STD13 
-            octet encoded representation does not. 
-      
-            It is possible to avoid this scenario on authoritative zone 
-            servers (and thus the affected caches) by allowing the 
-            operator to specify whether or not the input is Latin-1 UCS 
-            character data or binary data, with the server generating 
-            the proper output accordingly. Also note that the default 
-            encoding specified by this document is UTF-8, which does 
-            not suffer from the ambiguity problems described above. 
-      
-        *   Any UCS character codes. If a label consists of any 
-            character codes greater than U+00FF, then it MAY be encoded 
-            as ACE or UTF-8, but MUST NOT be encoded as STD13 octet 
-            sequences. STD13 is not capable of representing character 
-            codes greater than U+00FF, so it cannot be used with any 
-            UCS characters beyond the eight-bit range. 
-      
-     Encodings are performed on a per-label basis. Each label MUST NOT 
-     be encoded more than once. Also note that recursive encodings 
-     result in applications discarding the domain name. 
-      
-     When the STD13 octet encoding is used to encode labels for 
-     transmission, the labels are encoded according to the rules 
-     specified in STD13, and are encapsulated in STD13 legacy labels. 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 25] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     When ACE is used to encode labels for transmission, the labels are 
-     encoded according to the rules specified in <ACE-Z>, and are 
-     encapsulated in STD13 legacy labels (this process is described in 
-     section 5.2). 
-      
-     When UTF-8 is used to encode labels for transmission, the labels 
-     are encoded according to the rules specified in RFC2279, and are 
-     encapsulated in EDNS/UTF-8 extended labels (the format of this 
-     label is described in section 5.1). 
-      
-     Note that a domain name MAY contain any combination of STD13 octet 
-     encoded labels and ACE encoded labels. However, if a domain name 
-     contains any UTF-8 encoded labels, then ALL of the labels from 
-     that domain name MUST be encoded as UTF-8 data. This rule 
-     primarily exists so that DNS compression services can be 
-     maintained consistently, but it also prevents mixed referrals 
-     which can trigger unnecessary fall-back processing, and also 
-     provides a single encoding representation to internationalized 
-     systems which benefits efficiency. 
-      
-     The root domain (as specified by the zero-length label at the 
-     right edge of the domain name) MUST NOT be encoded with ACE. More 
-     specifically, zero-length labels MUST NOT contain any character 
-     data of any kind, and since ACE labels have prefix strings, they 
-     are explicitly forbidden from being used for the root domain. 
-      
-      
-  4.1.3.  IDN comparison operations 
-      
-     When an internationalized domain name label is received from the 
-     network as ACE or UTF-8 encoded data, the labels MUST be decoded 
-     to their canonical UCS character representation, and the resulting 
-     UCS characters MUST be compared as case-exact sequences to their 
-     stored equivalents. Except where specifically required in this 
-     specification (EG, validity tests which are performed by 
-     applications), normalization and case-conversion MUST NOT be 
-     performed against the resulting UCS character codes prior to any 
-     comparison operations being performed. 
-      
-     However, internationalized domain name labels which are received 
-     as STD13 octet sequences MUST be given special treatment, as these 
-     domain names could have originated from legacy systems operating 
-     under STD13's rules. In this case, the seven-bit US-ASCII 
-     alphabetic characters (U+0041 through U+005A, and U+0061 through 
-     U+007A) from those labels MUST be compared in a case-neutral form. 
-     All other code values MUST be compared as case-exact code values 
-   
-  Hall                    I-D Expires: May 2002              [page 26] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     (this particularly includes eight-bit characters, which were not 
-     defined by STD13). 
-      
-      
-  4.2.    Internationalized Host Identifiers 
-      
-     Internationalized host identifiers are a subset of the 
-     internationalized domain names described in section 4.1, which 
-     only use a subset of the allowable UCS characters, but which reuse 
-     the global transfer encodings and comparison routines. 
-      
-     Most of the displayable characters from the UCS can be used in 
-     host identifiers, and there are no additional rules governing the 
-     ordering or length of their labels. However, the characters which 
-     are used in internationalized host identifiers MUST be normalized 
-     and case-converted before they are encoded for storage or 
-     transfer. This requires more effort on the part of applications 
-     and servers when the internationalized domain names are initially 
-     created, but results in less ambiguity and lower processing 
-     requirements for servers, caches and resolvers during subsequent 
-     comparison operations. 
-      
-     The restrictions which govern the creation of internationalized 
-     host identifiers are as follows: 
-      
-        a.  Labels MUST be restricted to the subset of characters which 
-            are permitted by <nameprep> [nameprep]. Characters which 
-            are prohibited by <nameprep> MUST NOT appear in any label 
-            of any internationalized host identifier. 
-      
-        b.  Labels MUST be normalized through <nameprep> before they 
-            are stored or encoded for transfer. Internationalized host 
-            identifiers will not be normalized as part of any 
-            comparison operation, so systems MUST normalize the labels 
-            before they are stored or transmitted. 
-      
-        c.  Labels MUST be converted to lowercase according to the 
-            case-mappings rules specified in <nameprep> before they are 
-            stored or encoded for transfer. Internationalized host 
-            identifiers will not be converted to lowercase as part of 
-            any comparison operation, so systems MUST normalize the 
-            labels before they are stored or transmitted. 
-      
-     According to the rules above, a label from an internationalized 
-     host identifier which was originally created with the UCS 
-     character sequence of <LATIN CAPITAL LETTER A><COMBINING ACUTE 
-   
-  Hall                    I-D Expires: May 2002              [page 27] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     ACCENT><LATIN CAPITAL LETTER B> (U+0041 U+0301 U+0042) would be 
-     normalized and lowercased to <LATIN SMALL LETTER A WITH 
-     ACUTE><LATIN SMALL LETTER B> (U+00E1 U+0062). The normalized, 
-     lowercase form would be used as the canonical UCS character 
-     representation of that label when it was encoded for storage and 
-     transmission purposes, and would be the form which was used for 
-     comparison operations on any resolvers, caches and servers. 
-      
-     Internationalized host identifiers which are received from the 
-     network can contain labels which have been encoded as STD13 octet 
-     sequences, ACE or UTF-8. In all of these cases, the comparison 
-     rules defined in section 4.1.3 MUST be applied. 
-      
-      
-  4.3.    STD13 Domain Names 
-      
-     STD13 allows any eight-bit code values to be used in domain name 
-     labels. However, STD13 host identifiers (as described in section 
-     4.4 of this specification) are the most common form of STD13 
-     domain names, and have much tighter restrictions. 
-      
-     There are common uses of STD13 domain names which do not comply 
-     with the STD13 host identifier subset, however. One common example 
-     of this is SRV identifiers, which use an underscore character 
-     (U+005F) as part of their label syntax. Another common example is 
-     found when email addresses are provided in SOA and RP resource 
-     records, and where the left-hand side of the email address is 
-     stored as an STD13 domain name label which does not represent a 
-     host identifier. Furthermore, email addresses often contain extra 
-     characters which are not legal in STD13 host identifiers, such as 
-     a full-stop character (U+002E). For example, "joe.admin" could be 
-     stored as an STD13 domain name label in the fully-qualified domain 
-     name of "joe.admin.example.com.", which would represent the email 
-     address of "joe.admin@example.com" when that domain name was 
-     extracted from the SOA or RP resource record and processed. 
-      
-     Implementations of this specification MUST allow STD13 domain 
-     names to be created and stored, using the following rules: 
-      
-        a.  Labels MUST be restricted to the code values of U+0000 
-            through U+00FF. Restrictions on character content MUST NOT 
-            be applied (note that if this domain name will be used as 
-            part of an STD13 host identifier, the rules specified in 
-            section 4.4 MUST be used instead). 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 28] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-        b.  Labels MUST NOT be normalized or lowercased before they are 
-            stored or encoded for transfer. 
-      
-        c.  Systems MUST allow STD13 domain names to be specified as 
-            exact sequences of eight-bit octet values, and MUST NOT 
-            treat these sequences as canonical UCS characters which are 
-            normalized or lowercased. STD13 defines an escaping 
-            mechanism whereby the decimal value of the octet is 
-            prefaced with a reverse-solidus (such as "\193"), which is 
-            suggested for this usage. 
-      
-     STD13 domain names which are received from the network can contain 
-     labels which have been encoded as STD13 octet sequences, ACE or 
-     UTF-8. In all of these cases, the comparison rules defined in 
-     section 4.1.3 MUST be applied. Note that some of these sequences 
-     can contain octet code values which have not been normalized or 
-     lowercased by the originating system, since these values can be 
-     used to specify binary domain names. 
-      
-      
-  4.4.    STD13 Host Identifiers 
-      
-     This document does not deprecate, replace or modify the host name 
-     rules defined by RFC952, STD3 or STD13 as they apply to legacy 
-     host identifiers. However, there are several issues which affect 
-     the usage of these domain names and their labels in this system. 
-      
-     The range of characters which are currently defined as valid in 
-     STD13 host identifiers are the uppercase and lowercase letters, 
-     numbers and hyphen character from US-ASCII. No other characters 
-     are allowed to be used. Furthermore, the current rules also 
-     prohibit the use of the hyphen character in the first or last 
-     character position of a host identifier label. 
-      
-     Implementations of this specification MUST allow STD13 host 
-     identifiers to be created and stored, using the following rules: 
-      
-        a.  Labels MUST be restricted to the code values of U+002D, 
-            U+0031 through U+0039, U+0041 through U+005A, and U+0061 
-            through U+007A. 
-      
-        b.  Labels MUST NOT contain the code value of U+002D in either 
-            the first or last character position of the label. 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 29] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-        c.  The alphabetic characters MUST be converted to lowercase 
-            before they are stored or transmitted. STD13 host 
-            identifiers are always compared in a case-neutral form. 
-      
-     STD13 host identifiers which are received from the network can 
-     contain labels which have been encoded as STD13 octet sequences 
-     UTF-8. In both cases, the comparison rules defined in section 
-     4.1.3 MUST be applied. 
-      
-      
-  5.      Transfer Encodings and Label Types 
-      
-     As was discussed in section 4.1.2, internationalized domain names 
-     and labels are required to be encoded as either eight-bit or 
-     seven-bit data whenever they are transmitted as protocol or 
-     application data. 
-      
-     The particular output encoding format which will be used for any 
-     given label will be primarily determined by the capabilities of 
-     the participating end-point systems. If the application or 
-     protocol which is relaying the domain name labels supports 
-     internationalized domain names directly then UTF-8 encoded labels 
-     can be used, but if the protocol or application is only capable of 
-     supporting STD13 host identifiers as domain name data, then the 
-     STD13 octet and/or ACE encoded labels will have to be used. 
-      
-     With DNS messages in particular, the "data type" is the label 
-     encapsulation in use. Although STD13 legacy labels allow for the 
-     use of eight-bit codes, multiple encodings for the same basic 
-     character data result in interpretation problems without some form 
-     of ancillary tagging service. For this reason, each encoding is 
-     represented differently by this specification. When the STD13 
-     legacy label contains STD13 octet sequences then no tagging is 
-     provided, but if the STD13 legacy label contains ACE encoded data 
-     then the encoded sequence is tagged with an ACE identifier (a 
-     character prefix which does not normally appear in labels). When 
-     UTF-8 domain names are provided, an EDNS/UTF-8 extended label is 
-     used to encapsulate the internationalized domain name. 
-      
-     Furthermore, the encoding which is used for any label in the 
-     message will also determine the label type which is used to 
-     encapsulate and transfer the entire domain name. If any label 
-     contains EDNS/UTF-8 extended labels, then all of the labels from 
-     that domain name are required to be encapsulated for transfer in 
-     EDNS/UTF-8 extended labels. Conversely, if a domain name contains 
-     ACE or STD13 octet encoded labels, then all of the labels from 
-   
-  Hall                    I-D Expires: May 2002              [page 30] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     that domain name are required to be encapsulated for transfer 
-     using the STD13 legacy label format. 
-      
-     Note that other legacy applications and protocols will most likely 
-     be required to provide extended encodings or negotiation features 
-     before they can exchange internationalized domain names directly. 
-     However, new applications and protocols which are subsequently 
-     written to comply with BCP18 and this specification should not 
-     require any such effort, as they should be capable of transferring 
-     UTF-8 domain names from the beginning. 
-      
-      
-  5.1.    The EDNS/UTF-8 Label Type 
-      
-     Any internationalized domain name label which has been encoded as 
-     UTF-8 for transmission in a DNS message MUST be encapsulated as a 
-     EDNS/UTF-8 label. 
-      
-     The EDNS/UTF-8 extended label is an instance of EDNS extended 
-     label types (as defined by RFC2671). Extended labels are indicated 
-     by the leading bit pattern of 0b01 in the label type field (the 
-     first two bits from the "label length" octet of the STD13 legacy 
-     label type), with the remaining six bits of this octet indicating 
-     the extended label type in use. The EDNS/UTF-8 label type uses the 
-     binary value of 0b000011 for this indication (note that IANA may 
-     change this assignment). 
-      
-     EDNS/UTF-8 labels contain two subordinate units of data. The first 
-     octet contains a length indicator which works exactly the same as 
-     the length octet as used by STD13 legacy labels: if the first two 
-     bits of this octet are 0b00 then the rest of that octet provides 
-     the length of the label data field, but if the first two bits of 
-     this octet are 0b11 then the label is a pointer to some other 
-     label, and the remainder of the length octet provides an off-set 
-     which points to the length octet of the referenced label, as per 
-     the rules provided in section 4.1.4 of RFC 1035 (STD13, part 2). 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 31] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     The structure of the EDNS/UTF-8 extended label is illustrated by 
-     the following figure. 
-      
-                              1 1 1 1 1 1 1 1 1 1 
-          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-         |0 1|0 0 0 0 1 1|    length     |  label data  ///  | 
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-      
-          0b01 - The extended label identifier. 
-      
-          0b000011 - The EDNS/UTF-8 extended label type identifier. 
-      
-          Length - The number of octets in the label data, or the off-
-            set to the length octet of another EDNS/UTF-8 label. 
-      
-          Label data - The label data, encoded as UTF-8 octets. 
-      
-     The following example shows the domain name of me.com, where the 
-     "e" in "me" is the UCS character <LATIN SMALL LETTER E WITH ACUTE> 
-     (U+00E9), which has the UTF-8 encoded octet sequence of 0xC3A9. 
-      
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
-         20 | 0  1  0  0  0  0  1  1|          0x03         | 
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
-         22 |        0x6D (m)       |      0xC3 (e')        | 
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
-         24 |      0xA9 (e')        | 0  1  0  0  0  0  1  1| 
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
-         26 |         0x03          |        0x63 (c)       | 
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
-         28 |        0x6F (o)       |        0x6D (m)       | 
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
-         30 | 0  1  0  0  0  0  1  1|         0x00          | 
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
-      
-     Octet 20 identifies the EDNS/UTF-8 extended label type, while 
-     octet 21 indicates that the label is three octets long. Octet 22 
-     contains the UTF-8 value for lowercase "m", while octets 23 and 24 
-     contain the UTF-8 value for the UCS character <LATIN SMALL LETTER 
-     E WITH ACUTE> (encoded as 0xC3A9). 
-      
-     Similarly, octet 25 identifies another EDNS/UTF-8 extended label 
-     type, while octet 26 indicates that the label is three octets 
-     long, while octets 27 through 29 contain the UTF-8 values for the 
-     lowercase alphabetic sequence of "com". 
-   
-  Hall                    I-D Expires: May 2002              [page 32] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-      
-     Finally, octet 30 identifies another EDNS/UTF-8 extended label 
-     type, while octet 31 indicates that the label is zero octets in 
-     length, thereby signifying the root zone (the end of the queried 
-     domain name). 
-      
-     Note that the use of the EDNS/UTF-8 extended label type serves 
-     multiple purposes. On the one hand, it provides a method of 
-     signaling the resolver's capabilities to the server, so that the 
-     server can determine which format it needs to use when returning 
-     answers, referrals or errors. Moreover, using an encapsulation 
-     format which is not backwards compatible prevents certain 
-     ambiguity problems which can result from overloading the STD13 
-     legacy label with multiple encodings. These problems are seen in 
-     certain situations with STD13 octet encoding and ACE, where a 
-     server cannot adequately determine which encoding a resolver 
-     desires. By using a separate extended label type for UT-8, these 
-     kinds of ambiguities are avoided. 
-      
-     There are additional benefits which come from using EDNS extended 
-     label types, which are best expressed as "future possibilities". 
-     Once the EDNS extended label mechanisms are widely deployed, it 
-     becomes feasible to specify additional encoding mechanisms as soon 
-     as the Internet community deems it desirable. In this regard, 
-     defining alternative encodings is much easier the second time. 
-      
-      
-  5.2.    The STD13 Legacy Label Type 
-      
-     Any internationalized domain name label which has been encoded as 
-     ACE or STD13 octet sequences for transmission in a DNS message 
-     MUST be encapsulated within an STD13 legacy label. 
-      
-     This document does not deprecate, replace or extend the STD13 
-     octet encoding or label encapsulation rules defined by STD13. 
-     However, this document does provide some guidance on the creation 
-     and interpretation of ACE encoded labels when they are stored in 
-     legacy labels, which is necessary in order for recipient systems 
-     to properly detect and decode the label contents. 
-      
-     Note that STD13 octet sequences and ACE data MAY both be provided 
-     the same domain name. As such, each STD13 legacy label from a DNS 
-     message must be examined and processed independently. 
-      
-      
-   
-  Hall                    I-D Expires: May 2002              [page 33] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-  5.2.1.  ACE encoded labels 
-      
-     ACE encoded labels always begin with the character sequence of 
-     <TBD> (this document uses "zz--" as a placeholder sequence until a 
-     formal assignment is made). Any label which contains ACE encoded 
-     data MUST begin with this character sequence prefix. Similarly, 
-     any label which begins with this character sequence MUST be 
-     recognized and processed as an ACE encoded label, according to the 
-     rules defined in this specification. 
-      
-     Encoding and encapsulating a label as ACE data is a three-part 
-     process, as follows: 
-      
-        a.  Encode the canonical UCS character data from the 
-            internationalized domain name label into ACE using the 
-            procedure defined in <ACE-Z> 
-      
-        b.  Preface the encoded output with the "zz--" prefix sequence, 
-            thereby indicating that this label contains ACE encoded UCS 
-            character data. 
-      
-        c.  Determine the length of the encoded data and store this 
-            value in the STD13 legacy label's length octet. 
-      
-     Decoding an ACE label is the opposite of that process. 
-      
-     Note that whenever the ACE algorithm encounters a seven-bit 
-     character code in the input, it is passed through unmodified to 
-     the encoded output. If a label only contains seven-bit character 
-     codes, the label MUST NOT be encoded as ACE, and MUST be encoded 
-     as either STD13 octet sequences or UTF-8. Forcing a seven-bit 
-     label to be encoded as ACE serves no benefit, incurs additional 
-     processing on the end-point systems, and can also expose certain 
-     security risks. Any system which is capable of generating and 
-     deciphering ACE encoded labels is required to treat such sequences 
-     as hostile, and MUST dispose of them immediately without any 
-     further processing immediately; systems are forbidden to even 
-     return these labels in DNS error messages. 
-      
-     Similarly, ACE MUST NOT be used to encode any zero-length labels 
-     (including but not specifically limited to the root domain), since 
-     the presence of prefix characters in these labels can invalidate 
-     their protocol-specific interpretations. 
-      
-     When an STD13 legacy label is received which has "zz--" in the 
-     first four character positions, the label MUST be treated as an 
-   
-  Hall                    I-D Expires: May 2002              [page 34] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     ACE-encoded internationalized domain name, and MUST be decoded to 
-     its canonical UCS character values for further processing. 
-      
-     Note that STD13 legacy labels MUST be verified before the ACE 
-     encoded data is extracted (as per the rules defined in STD13 which 
-     govern the STD13 legacy label type), but systems which are 
-     compliant with this specification MUST perform all subsequent 
-     comparison, caching, or storage operations against the canonical 
-     UCS characters, and MUST NOT use the ACE encoded label sequence 
-     for any of these operations. 
-      
-     Note that the legacy systems which are not compliant with this 
-     specification will treat ACE encoded labels as any other STD13 
-     legacy label. 
-      
-      
-  5.2.2.  STD13 octet encoded labels 
-      
-     Any STD13 legacy labels which do not begin with the ACE prefix 
-     MUST be treated as STD13 octet encoding sequences. The rules for 
-     this process are defined by STD13's default label encapsulation 
-     services, although this document also provides some clarifications 
-     on the use of this encoding with internationalized domain names 
-     and labels. 
-      
-     Whenever the STD13 octet sequence is used to encode the labels 
-     from an internationalized domain name, the octet values of the 
-     canonical UCS characters are stored directly in the label. Because 
-     the DNS message is limited to octets, the range of UCS character 
-     codes which are eligible for use with STD13 octet sequences is 
-     limited to U+0000 through U+00FF. If any UCS character codes 
-     outside this range need to be transferred, the internationalized 
-     domain name label will have to be encoded as ACE or UTF-8. 
-      
-     Note that comparison operations for the seven-bit range of 
-     alphabetic character values MUST be performed in a case-neutral 
-     form, although eight-bit code values MUST NOT be normalized or 
-     case-converted as part of a comparison operation. These rules are 
-     required in order to ensure backwards compatibility with the STD13 
-     compliant systems which may be generating these labels as parts of 
-     an STD13 domain name while also supporting the normalization and 
-     case-conversion which may have been applied to the UCS characters 
-     in the storage or transfer encoding systems. 
-      
-      
-   
-  Hall                    I-D Expires: May 2002              [page 35] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-  6.      Application Guidelines 
-      
-     As was discussed in section 3.3, there are multiple scenarios in 
-     which an application can make use of internationalized domain 
-     names, ranging from simple lookups of connection identifiers to 
-     abstract encapsulations of unstructured application data. This is 
-     an extremely broad range of uses, which is complicated by the 
-     extreme pervasiveness of applications and protocols that use 
-     domain names for one or more of these purposes. 
-      
-     Furthermore, network applications face a complex array of input 
-     and output operations which will cumulatively affect the ability 
-     of that application to make use of the internationalized domain 
-     name system for various services and functions. These issues are 
-     illustrated by the figure below: 
-      
-                       [IDNs]              [IDNs] 
-                         |                   ^ 
-                         |                   | 
-                  +------V------+     +------+------+ 
-                  |    input    |     |   output    | 
-                  |   charset   |     |   charset   | 
-                  +-----------+-+     +-+-----------+ 
-                               \       / 
-                            +---+-----+---+ 
-                            | Application | 
-                            +---+-----+---+ 
-                               /       \ 
-                  +-----------+-+     +-+-----------+ 
-                  |   lookups   |     |   app data  <---> [IDNs] 
-                  +------+------+     +-------------+ 
-                         | 
-                  +------+------+ 
-                  |   resolver  <---> [IDNs] 
-                  +-------------+ 
-      
-     As can be seen, the ability for an applications to complete adopt 
-     internationalized domain names will be determined by many factors, 
-     any one of which could prevent the application from completely 
-     incorporating the restrictions and recommendations prescribed by 
-     this specification. 
-      
-     In order to allow for a flexible adoption schedule, this 
-     specification defines very few mandates that applications must 
-     adopt, but instead focuses on recommendations which applications 
-     should comply with whenever they need to use internationalized 
-   
-  Hall                    I-D Expires: May 2002              [page 36] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     domain names, and also provides recommendations for situations 
-     where the preferred behavior is not feasible. Applications which 
-     are compliant with all of the recommendations provided in this 
-     specification will be able to generate, store, transfer and 
-     resolve internationalized domain names throughout all of their 
-     operations, using UTF-8 as a common encoding for all of these 
-     operations. Meanwhile, applications which are not in complete 
-     compliance with this specification will still be able to make use 
-     of the internationalized domain names in these operations, 
-     although such access may be limited to using backwards-compatible 
-     encodings which require greater amounts of effort to implement and 
-     which provide fewer benefits. 
-      
-      
-  6.1.    Input and Output Charsets 
-      
-     If an application is unable to accept, process, store or display 
-     characters from the complete UCS repertoire, that application's 
-     support for internationalized domain names will be somewhat 
-     limited, by definition. 
-      
-     Although this document does not mandate any particular charset or 
-     encoding which all applications must use for all operations, 
-     applications SHOULD use coded character sets or encodings which 
-     can handle characters from a reasonable number of scripts. 
-      
-     In particular, the following areas have specific requirements: 
-      
-        *   Input charsets and encodings. Since UTF-8 is used as the 
-            default encoding for internationalized domain names 
-            throughout this specification (and others, such as BCP18), 
-            UTF-8 is also RECOMMENDED for use with input encodings of 
-            internationalized domain names in particular, although this 
-            is not required. Many platforms and development 
-            environments support UTF-8 as a local encoding of the UCS 
-            and it can be reasonably used with many types of input 
-            (such as configuration files), although many systems will 
-            require a specific encoding (such as UCS-2, or ISO/IEC 
-            8859-1) in situations which require memory access or 
-            keyboard input. 
-      
-            Regardless of the input encodings used, implementations 
-            MUST map domain names and labels to their canonical UCS 
-            characters for any normalization and case-conversion work 
-            which is subsequently required by any DNS lookups (see 
-            section 6.3). 
-   
-  Hall                    I-D Expires: May 2002              [page 37] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-      
-        *   Output choices will likely be limited to a system-preferred 
-            charset or encoding. In general, this document RECOMMENDS 
-            that output systems choose an output charset or encoding 
-            which reflects the data being provided. However, 
-            applications MUST NOT display unknown characters with 
-            generic replacement characters (such as boxes or circles) 
-            if it is known that the original characters are not 
-            available for display with the specified charset, as such 
-            characters will almost certainly trigger failure conditions 
-            in subsequent protocol operations. 
-      
-     In those situations where adequate input or output charsets or 
-     encodings are unavailable, applications MAY use ACE to encode 
-     internationalized domain names for the purpose of ensuring that 
-     the data is provided intact. Since ACE is capable of representing 
-     UCS characters as sequences of seven-bit characters, it is 
-     functionally usable as a last line of defense in almost any 
-     environment, with the caveat that ACE encoding sequences are 
-     extremely cryptic and will likely result in lower levels of 
-     usability and functionality. 
-      
-      
-  6.2.    Protocol and Application Data 
-      
-     There are several interrelated issues which will determine an 
-     application's ability to provide or accept internationalized 
-     domain names as protocol or application data, although the 
-     principle determining factors for any such usage will generally be 
-     the capabilities of the underlying protocol itself. 
-      
-     If a protocol allows negotiation or tagging services in order to 
-     distinguish between different encodings, that protocol can likely 
-     be extended to support the use of UTF-8 as protocol or application 
-     data through command/response negotiation options or through data-
-     type tags. Older protocols which do not provide any negotiation 
-     services or which mandate the use of US-ASCII in all data will 
-     likely require the use of ACE encoded domain names as a short-term 
-     measure until the protocol is made compliant with BCP18. 
-      
-        *   Protocol data. If the protocol supports UTF-8 encoded 
-            internationalized domain names in commands or responses, 
-            then that encoding SHOULD be used wherever it is allowed. 
-            If UTF-8 is not supported by the protocol, STD13 octet 
-            sequences and/or ACE encoded equivalents of the 
-            internationalized domain name MUST be used. 
-   
-  Hall                    I-D Expires: May 2002              [page 38] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-      
-            In some cases, this negotiation can be performed on a per-
-            session basis, while in other cases this work will need to 
-            be performed for each transaction within the session, while 
-            in other cases the internationalized domain names will have 
-            to be tagged whenever they are provided as protocol or 
-            application data. 
-      
-            The DNS protocol is itself an example of a protocol which 
-            requires tagging in order for internationalized domain 
-            names to be exchanged within the existing DNS message (with 
-            these indicators taking the form of ACE encoding prefixes 
-            and EDNS/UTF-8 extended label type codes). Meanwhile, a 
-            protocol such as WHOIS can theoretically support a session-
-            wide negotiation option that allowed the use of 
-            internationalized domain names as protocol and application 
-            data for the duration of that session. Conversely, a 
-            protocol such as SMTP will likely require the use of 
-            session-specific identifiers for some operations, while 
-            other operations may be able to use label tags (similar to 
-            the existing support for domain literals, which are 
-            identified by a pair of surrounding square brackets). 
-      
-            Regardless of the encodings which are used, implementations 
-            MUST map domain names and labels to their canonical UCS 
-            characters for any normalization and case-conversion work 
-            which is subsequently required as part of a DNS lookup (see 
-            section 6.3). 
-      
-        *   Structured application data. Structured application data 
-            such as URLs and email addresses MUST be processed 
-            according to the rules which govern those data formats. 
-            Applications MUST NOT perform any conversion or 
-            transliteration which is not explicitly prescribed by the 
-            governing documents, since non-standard usages are likely 
-            to result in misinterpreted data. 
-      
-        *   Unstructured application data. Domain names which appear as 
-            unstructured data in application content are beyond the 
-            control of this specification, and are generally subject to 
-            the encoding and formatting desires of the end-users who 
-            created the data. Generally speaking, it is RECOMMENDED 
-            that applications allow users to enter or view documents in 
-            whatever format they prefer, but that any conversion 
-            between multiple source and destination charsets and 
-            encodings use UCS as the translation intermediary, such 
-   
-  Hall                    I-D Expires: May 2002              [page 39] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            that internationalized domain names are properly converted 
-            along with the rest of the application data. 
-      
-     In some cases, the application will need to probe the resolver 
-     before it can use internationalized domain names as data. For 
-     example, a participating system may need to determine the 
-     internationalized domain name of the local system so that it can 
-     provide this data in a protocol-specific banner message, and in 
-     these cases, the application will have to communicate with the 
-     resolver before this data can be provided. 
-      
-     Due to the usage-specific nature of internationalized domain names 
-     within protocol and application data streams, each development 
-     group will have to analyze the restrictions and capabilities which 
-     affect their specific services independently. 
-      
-      
-  6.3.    DNS Lookups and Resolver Calls 
-      
-     One of the most frequent uses for domain names is for lookup 
-     operations, such as for locating the IP addresses associated with 
-     a specified domain name, determining the domain name associated 
-     with a specified IP address, or performing a protocol-specific 
-     lookup operation for a specific resource record (such as the MX or 
-     SOA resource records associated with a specific domain). 
-      
-     Since these lookup operations do not directly affect external 
-     protocols or data, internationalized domain names can be used for 
-     lookup operations at the application's discretion. For example, 
-     applications such as ping and netstat only use domain names for 
-     display purposes, and can therefore make immediate use of 
-     internationalized domain names within their protocol operations. 
-     Similarly, a protocol can be limited to STD13 host identifiers as 
-     protocol identifiers which will require the application to provide 
-     internationalized domain names as ACE encoded sequences, but any 
-     lookup operations which are necessary for the internationalized 
-     domain names can still be performed in their native form. In these 
-     cases, the protocol operations and lookup operations are separate 
-     tasks with separate rules. 
-      
-     Similarly, applications are not required to use internationalized 
-     domain names and internationalized resolver APIs for every lookup. 
-     In some cases, it may be more efficient for an application to only 
-     use internationalized domain names for lookup operations against 
-     connection identifiers, and to use STD13 octet sequences or ACE 
-     encoded legacy lookups for domain names which were obtained as 
-   
-  Hall                    I-D Expires: May 2002              [page 40] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     protocol or application data (this will be especially true in 
-     those cases where the protocol does not yet provide an 
-     internationalized domain name data-type). In those cases where an 
-     application prefers to use the legacy resolution path, the 
-     application MUST use the resolver's legacy APIs. For lookups 
-     against internationalized domain names, the application MUST use 
-     the resolver's internationalized APIs. 
-      
-     Note that this specification does not define a mandatory encoding 
-     which must be used between the applications and the local 
-     resolver. However, resolvers MUST provide at least one encoding 
-     which is capable of supporting the entire UCS repertoire of 
-     character codes, including character codes which are currently 
-     unassigned. Since UTF-8 is the default encoding which is used 
-     throughout this specification, it is also RECOMMENDED for use with 
-     resolver APIs, although this is not required. Resolvers MAY 
-     dictate a local encoding, with the only requirement being support 
-     for the entire range of UCS character codes. 
-      
-     Regardless of the data being provided or the charset or encoding 
-     which is used to provide that data, applications MUST normalize 
-     and case-convert any internationalized host identifiers which it 
-     generates or receives from a lookup operation. This process MUST 
-     use the canonical UCS characters of the domain name according to 
-     the rules specified in <nameprep> for every host identifier which 
-     is sent to or received from a resolver. 
-      
-     If the application knows that the requested data specifically 
-     refers to a host identifier, then the domain name data which is 
-     returned by the resolver MUST be normalized and case-converted, 
-     and the resulting domain name MUST be compared to the original 
-     domain name which was received prior to the normalization and 
-     case-conversion steps. If the processed domain name does not match 
-     the domain name which was received, the domain name MUST be 
-     discarded as malformed. 
-      
-     This step is necessary in order to ensure the integrity and 
-     veracity of internationalized domain names which are processed by 
-     applications, since there are multiple opportunities for errors to 
-     be introduced (such as mistyped entries in the resolver's hosts 
-     database, or malicious data which has been purposefully provided 
-     in a zone), and these errors can result in sensitive data being 
-     directed to the wrong network. Note that the above rule 
-     specifically applies to host identifiers and not to all 
-     internationalized domain names as a whole; applications MUST NOT 
-     arbitrarily normalize and case-convert any and all domain names, 
-   
-  Hall                    I-D Expires: May 2002              [page 41] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     but MUST apply these steps to any and all domain names which are 
-     known to be used as host identifiers. 
-      
-     As part of the processing rules for DNS lookups, it is expected 
-     that an application can exchange internationalized domain names 
-     with the resolver using a charset or encoding which is capable of 
-     representing the entire UCS character code range. Towards this 
-     objective, applications SHOULD test the capabilities of the 
-     resolver prior to transferring internationalized domain names. In 
-     those situations where the resolver is unable to support this 
-     usage, the application MUST encode the internationalized domain 
-     name as STD13 octet sequences or ACE, and pass the resulting STD13 
-     host identifier to the resolver. 
-      
-      
-  7.      Resolver Guidelines 
-      
-     Resolvers play a crucial role in the use of internationalized 
-     domain names, in that they provide the internationalized namespace 
-     which applications work with. As part of this service, resolvers 
-     provide encapsulation services for the internationalized domain 
-     names which are exchanged with the applications, resolve queries 
-     in the internationalized namespace on behalf of the applications, 
-     and provide lookup matching for entries which are stored in a 
-     local hosts database. Note that resolvers which cache answer data 
-     for subsequent operations are also governed by the caching 
-     restrictions provided in section 9. 
-      
-      
-  7.1.    Resolver APIs 
-      
-     Stub resolvers which communicate directly with applications that 
-     are compliant with this specification are strongly encouraged to 
-     provide a separate set of APIs for those applications to use 
-     whenever internationalized domain names need to be provided in 
-     queries or response messages. 
-      
-     The use of an internationalized API will generally facilitate 
-     smoother operations for the applications, in that it will allow 
-     the application to determine the capabilities of the resolver, to 
-     obtain the internationalized domain name of the local system, and 
-     to process queries for internationalized domain names as special 
-     data types. 
-      
-     Furthermore, the use of internationalized versus legacy APIs 
-     provides a way for resolvers to separate internationalized and 
-   
-  Hall                    I-D Expires: May 2002              [page 42] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     legacy application query paths, such that the legacy APIs only 
-     result in STD13 legacy labels, while the internationalized APIs 
-     generate and trigger EDNS/UTF-8 extended labels. The output 
-     formatting of the DNS messages are controlled by tight 
-     restrictions, and the use of alternative APIs will likely result 
-     in simpler resolver implementations. 
-      
-     For example, it is suggested that applications use the 
-     internationalized APIs for all of the DNS lookups they generate, 
-     even if the domain name only contains seven-bit characters. This 
-     is required in case the queried domain name only exists with a 
-     CNAME or PTR resource record which references an internationalized 
-     domain name, and the server has to know which encoding to use for 
-     that query. If the client had not used the internationalized API 
-     for the original lookup of the domain name, the resolver may have 
-     chosen the wrong label type, and thus the response data would only 
-     be returned as ACE encoded data. 
-      
-     Conversely, older applications which generate malformed eight-bit 
-     queries through the legacy APIs will result in those queries being 
-     properly rejected by the DNS servers, preventing undue problems 
-     with these applications from occurring. For example, an older 
-     application may process an internationalized domain name through 
-     the system-default charset or encoding (such as MacRoman), which 
-     would result in the domain name being malformed when the 
-     application tried to do something important with that domain name 
-     (such as send an email message over SMTP). The use of multiple 
-     APIs causes these malformed applications to break, and the invalid 
-     domain names are kept out of the application protocol space. 
-      
-     Internationalized APIs are optional to the extent that an 
-     application MAY use an embedded resolver which is known to be 
-     capable of generating and processing internationalized domain 
-     names through the existing function calls. However, the use of 
-     separate APIs for internationalized domain names is encouraged. 
-      
-     Although this document does not mandate any specific APIs, the 
-     following functions SHOULD be provided for in some form: 
-      
-        *   Test Wide. Applications MUST be able to test the resolver 
-            for compliance with this specification. In those cases 
-            where this function is performed by some other function 
-            (such as one of the following), the capabilities of the 
-            resolver MUST be detectable even if the requested operation 
-            fails. For example, if an application issues a call for the 
-            internationalized domain name of the local system, the 
-   
-  Hall                    I-D Expires: May 2002              [page 43] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            capability of the resolver to handle internationalized 
-            domain names MUST be uniquely represented even if the local 
-            host name cannot be determined. 
-      
-        *   Get Wide X-By-Y. Applications SHOULD be able to specify any 
-            resource record associated with any internationalized 
-            domain name as part of a lookup operation. Whether this 
-            service is provided as a series of lookup-specific APIs or 
-            as a general purpose API is up to the resolver. 
-      
-        *   Get Wide Local Name. Applications which utilize 
-            internationalized domain names as data will need to be able 
-            to determine the internationalized form of their local 
-            system name for some operations (such as a protocol-
-            specific welcome banner). When this function is called, the 
-            resulting data MUST be provided as the canonical UCS 
-            character code values, or their equivalent as represented 
-            by a locally mandated charset or encoding. 
-      
-            Note that an ACE equivalent of the system name SHOULD be 
-            returned when the relevant legacy API is queried. In those 
-            cases where the legacy and internationalized domain names 
-            both contain seven-bit character codes (possibly because 
-            the host name is only available in US-ASCII, or because the 
-            host name was assigned as ACE by an external configuration 
-            service), the internationalized host name MUST still be 
-            accessible through the internationalized function. 
-      
-     Note that this application does not specify a charset or encoding 
-     which must be used by the resolver APIs. However, wherever an 
-     internationalized API is presented, the resolver MUST utilize a 
-     charset or encoding which supports the entire UCS repertoire of 
-     character codes, including character codes which are currently 
-     unassigned. Since UTF-8 is the default charset for most of the 
-     operations specified in this document, it is also RECOMMENDED for 
-     this service, but is not required. 
-      
-      
-  7.2.    Query Processing Services 
-      
-     Resolvers which are compliant with the recommendations provided in 
-     this specification will provide two query paths, one of which 
-     supports STD13 domain names and another which supports 
-     internationalized domain names. Technically, there is no 
-     requirement for two processing paths, although these paths will 
-   
-  Hall                    I-D Expires: May 2002              [page 44] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     likely exist as conceptual paths even if they are not represented 
-     or implemented uniquely in all resolvers. 
-      
-     The legacy processing path is defined by STD13. This document does 
-     not update, modify or extend the rules that resolvers operate 
-     under when an STD13 compliant domain name is received by a legacy 
-     application through any legacy APIs which may exist. However, when 
-     an internationalized domain name is received from an 
-     internationalized application through any internationalized APIs, 
-     the processing rules defined in this section MUST be followed. 
-     Note that these rules apply to all resolvers, whether they are 
-     stub resolvers, forwarders or caching servers. 
-      
-     Generally speaking, the internationalized domain name resolution 
-     process has two major components: processing internationalized 
-     domain names as queries, and performing fall-back processing if an 
-     EDNS/UTF-8 query is rejected by an authoritative server. 
-      
-      
-  7.2.1.  Internationalized queries 
-      
-     Queries for internationalized domain names which are received 
-     through internationalized APIs can be expected to have originated 
-     at an application which is capable of accepting and processing 
-     internationalized domain names in the response messages. 
-      
-     Resolvers MUST encode the labels from the queried domain name as 
-     UTF-8 and encapsulate the resulting encoded labels into EDNS/UTF-8 
-     extended labels for transfer within DNS messages, per the 
-     instructions provided in section 5.1. 
-      
-     Any and all responses to these queries will also be encoded as 
-     UTF-8 and encapsulated in EDNS/UTF-8 extended labels. Resolvers 
-     MUST decode the provided response data, convert the labels to 
-     their canonical UCS character codes, and return the requested data 
-     to the calling application. 
-      
-     The resolver MUST NOT normalize or case convert internationalized 
-     domain names which may be received in queries or response 
-     messages. Since the queries have originated from applications 
-     which have indicated that they are compliant with this 
-     specification (via the API) while the responses will have 
-     originated from caches or servers which indicate that they are 
-     also compliant (via the EDNS/UTF-8 extended labels), those systems 
-     are assumed to have normalized and case-converted the domain names 
-     before they were generated or stored. Also note that applications 
-   
-  Hall                    I-D Expires: May 2002              [page 45] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     will validate the host identifiers that they receive in response 
-     messages, so an additional check is expected to be performed on 
-     the answer data by those systems. 
-      
-      
-  7.2.2.  Fall-back processing 
-      
-     If a queried server is unable to process EDNS/UTF-8 extended 
-     labels, then it is required by STD13 to generate an error 
-     signifying the problem. Resolvers MUST interpret these errors, 
-     decode the UTF-8 queried domain name, re-encode it as STD13 octets 
-     and/or ACE per the instructions provided in section 5.2, and then 
-     reissue the query as an STD13 legacy label sequence. 
-      
-     The legacy DNS error responses which will trigger this series of 
-     events are FORMERR and NOTIMPL. Any other errors indicate that the 
-     EDNS/UTF-8 extended label was successfully processed but that the 
-     query was not matched, and those errors MUST be returned to the 
-     application. If the fallback processing results in any error 
-     responses whatsoever, then the resolver MUST return those errors 
-     to the calling application. 
-      
-     Any servers which subsequently receive the fall-back queries and 
-     which are compliant with this specification will process the 
-     queries as internationalized domain names, and will return the 
-     answer data as STD13 octet sequences or ACE encoded data, using 
-     the STD13 legacy label. 
-      
-     Generally speaking, fall-back processing serves two purposes: 
-      
-        *   Answering the initial query. If a UTF-8 domain name cannot 
-            be resolved because a server in the delegation path does 
-            not understand the EDNS/UTF-8 label type, the resolver can 
-            reissue the query as an ACE encoded legacy label type so 
-            that the query proceeds past the problematic server. 
-      
-        *   Seeding the resolver's cache. As a result of the above, the 
-            resolver will learn about the authoritative name servers 
-            for the target zone, and this information can be used for 
-            any subsequent queries for domain names within the 
-            specified zone (for as long as the data is cached, anyway). 
-            As such, any subsequent EDNS/UTF-8 queries which are issued 
-            for the portion of the namespace served by that zone will 
-            be sent directly to one of those authoritative servers 
-            where they can be answered directly. In this regard, 
-   
-  Hall                    I-D Expires: May 2002              [page 46] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-            subsequent lookups do not require fall-back processing if 
-            they are received during the cache window. 
-      
-     Regardless of whether or not fall-back processing has been 
-     performed, if the calling application issued the original query as 
-     an internationalized domain name, then the resolver MUST respond 
-     to the query in that form as well. This means that the resolver 
-     MUST convert any STD13 octet sequences or ACE encoded labels into 
-     their canonical UCS characters, convert the answer data into the 
-     resolver's native charset or encoding, and return the data to the 
-     calling process. The resolver MUST NOT perform any normalization 
-     or case-conversion during this process, as such an action can 
-     corrupt domain names which are not used for host identifiers. 
-      
-     If the original query was received through the resolver's legacy 
-     APIs, then the query MUST be generated and returned in the legacy 
-     format, and MUST NOT be converted to an internationalized domain 
-     name prior to the query or response being passed through. 
-      
-     Once fall-back processing occurs, the process MUST NOT be repeated 
-     for any additional queries in the current lookup operation. No 
-     other queries from the current lookup operations MUST NOT be sent 
-     as EDNS/UTF-8 extended labels, since multiple fall-back operations 
-     can result in time-outs on the client systems. 
-      
-     Because the fall-back process results in two lookups being issued 
-     against the rejecting zone, eliminating the fall-back processing 
-     as soon as possible will be an operational requirement for many 
-     organizations. Any caches or forwarders which are used by stub 
-     resolvers within an end-user network are practically required to 
-     be able to process the EDNS/UTF-8 queries, since those servers 
-     will receive every query which is issued by the stub resolvers. 
-     While this isn't a technical requirement (fall-back processing 
-     will get around the problematic servers), it will likely prove to 
-     be a consideration for network operators looking to support 
-     internationalized domain names on their local networks. 
-      
-     This document also strongly encourages the root and TLD servers to 
-     be upgraded as soon as possible (even if they do not intend to 
-     directly provide UTF-8 domain name delegations), in order to allow 
-     those servers to read and process the EDNS/UTF-8 extended labels, 
-     thereby reducing the number of fall-back queries which are sent to 
-     those servers. 
-      
-      
-   
-  Hall                    I-D Expires: May 2002              [page 47] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-  7.3.    The Hosts Database 
-      
-     Generally speaking, there are two areas of consideration for stub 
-     resolvers that provide local hosts databases for name resolution 
-     services. These are the input requirements for internationalized 
-     domain names which will be added to the hosts database, and the 
-     requirements which govern how queries will be compared to the 
-     entries in the hosts database. 
-      
-     Note that resolvers are not required to implement a hosts database 
-     or local lookup services (STD3 says "a host MAY also implement a 
-     host name translation mechanism that searches a local Internet 
-     host table"). However, wherever a hosts database is provided with 
-     an internationalized resolver, compliance with the rules specified 
-     in this section is required. 
-      
-     If a stub resolver offers the capability to compare 
-     internationalized domain names against a local hosts database, 
-     that database MUST be compatible with the internationalized domain 
-     name rules specified in section 4 of this document. 
-      
-     In particular, the resolver SHOULD allow internationalized domain 
-     names with any code values to be stored, even if the canonical UCS 
-     characters for those values are undefined or are illegal for use 
-     with internationalized host identifiers (this is required to 
-     support domain names which are not host identifiers). In those 
-     cases where an internationalized domain name specifies an exact 
-     sequence of octets for binary comparison, the hosts database MUST 
-     provide a mechanism for tagging the eight-bit characters so that 
-     they are not interpreted, processed or compared as the canonical 
-     UCS character equivalents of those codes. 
-      
-     However, entries which explicitly provide host identifiers MUST be 
-     normalized and case-converted prior to being stored. In order to 
-     satisfy both of these requirements, it is RECOMMENDED that hosts 
-     databases store internationalized host identifiers as untagged 
-     data, but that they also provide some sort of tagging service for 
-     character code values which are to be returned as-is. STD13 
-     defines an escaping mechanism whereby the decimal value of the 
-     octet is prefaced with a reverse-solidus (such as "\193"), which 
-     is suggested for this usage. 
-      
-     The storage format of the hosts database MAY use any charset or 
-     encoding the resolver deems most suitable for that platform, as 
-     long as the rules and restrictions provided above are followed. 
-     Since UTF-8 is used as the default encoding throughout this 
-   
-  Hall                    I-D Expires: May 2002              [page 48] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     specification, it is RECOMMENDED as the default encoding for hosts 
-     databases as well, although this is not required. 
-      
-     Not all of the applications which use a resolver are likely to be 
-     compliant with this specification, so resolvers MUST ensure that 
-     they are able to interpret and process any queries from the legacy 
-     APIs which provide the ACE equivalent of an internationalized 
-     domain name that is stored in the hosts database. When such a 
-     query arrives, the domain name MUST be converted to the canonical 
-     UCS character codes represented by the ACE encoded sequence and 
-     compared to entries in the hosts database in that form (tagged 
-     octets excluded). Any internationalized domain names which are 
-     required to be returned through the legacy APIs MUST be converted 
-     to STD13 octet sequences and/or ACE before they are returned. 
-      
-      
-  8.      Server Guidelines 
-      
-     When a zone administrator desires to provide internationalized 
-     domain names in a zone, they are presented with two options: they 
-     can add the STD13 octets or ACE encoded internationalized domain 
-     names to an existing zone, or they can use internationalized zone 
-     databases directly. Both of these usage scenarios have their own 
-     benefits and restrictions. 
-      
-     Using STD13 octet sequences and ACE with legacy servers allows for 
-     the immediate deployment of internationalized domain names on 
-     existing servers, and within hierarchies which include 
-     internationalized domain names. However, any such queries which 
-     originate at applications that are compliant with this 
-     specification will always initially fail, guaranteeing that fall-
-     back processing will always occur for those zones. 
-      
-     Conversely, using internationalized zones directly allows servers 
-     to process legacy, ACE and EDNS/UTF-8 queries equally, thereby 
-     providing greater value to the applications and resolvers which 
-     have been made compliant with this specification. However, 
-     internationalized zones have additional requirements (most 
-     notably, they are required to be upgraded simultaneously), and 
-     these will prove burdensome to some zone operators. 
-      
-     This specification focuses on the processing requirements for 
-     internationalized zones which support the use of internationalized 
-     domain names as explicit data, and which also support the 
-     necessary subordinate mechanisms such as EDNS/UTF-8 queries. When 
-     STD13 octet sequences or ACE encoded domain names are used with 
-   
-  Hall                    I-D Expires: May 2002              [page 49] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     legacy servers, the rules defined in STD13 for those servers MUST 
-     be used. 
-      
-     Note that each zone SHOULD be configurable independently. If a 
-     server hosts multiple zones, each of those zones SHOULD be 
-     operable as independent entities, with any of them using ACE or 
-     internationalized domain names as necessary. This rule is 
-     necessary since each zone is likely to have different replication 
-     partners and configuration rules which will require different 
-     migration strategies. 
-      
-      
-  8.1.    Internationalized Zones 
-      
-     All domain names which are published by an internationalized zone 
-     MUST be compatible with the restrictions specified in section 4 of 
-     this document. In particular, the zone database MUST allow binary 
-     domain names to be stored as any octet value, but MUST also comply 
-     with the normalization and case-mapping rules when a domain name 
-     represents a host identifier. These restrictions MUST be applied 
-     as part of the process in which the domain name is being added to 
-     the zone database. In those cases where an internationalized 
-     domain name specifies an exact sequence of octets for binary 
-     comparison, the hosts database MUST provide a mechanism for 
-     tagging the eight-bit characters so that they are not interpreted, 
-     processed or compared as the canonical UCS character equivalents 
-     of those codes. STD13 defines an escaping mechanism whereby the 
-     decimal value of the octet is prefaced with a reverse-solidus 
-     (such as "\193"), which is suggested for this usage. 
-      
-     Servers which are compliant with this specification MUST be 
-     capable of providing UTF-8 and ACE encoded representations of the 
-     UCS domain names which are stored in the zone, and servers MUST 
-     restrict output to only one label type for any protocol operation, 
-     such that queries containing STD13 legacy labels MUST be answered 
-     with STD13 octet sequences and/or ACE encoded domain names, while 
-     EDNS/UTF-8 queries MUST only be answered with UTF-8 encoded domain 
-     names (this not only includes basic operations such as simple 
-     queries, but also includes advanced operations such as zone 
-     transfers; see section 8.2). Similarly, external operations such 
-     as exporting the contents of the zone to a master file (as 
-     discussed in section 8.3) MUST result in a single encoding form 
-     being used for that specific operation. 
-      
-     Note that the underlying zone database technology which may be 
-     employed by any particular server is beyond the scope of this 
-   
-  Hall                    I-D Expires: May 2002              [page 50] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     document. Servers MAY use any database technology, charset or 
-     encoding deemed appropriate for the local environment, although 
-     the contents of the zone MUST be mapped to the canonical UCS 
-     character codes for all comparison operations (octet values 
-     excluded). Since UTF-8 is used as the default encoding throughout 
-     this specification, it is RECOMMENDED for use as the default 
-     encoding with zone databases as well, but is not required. 
-      
-     Servers MUST NOT normalize or case-map any UCS characters which 
-     are decoded from UTF-8 or ACE encoded labels, and MUST restrict 
-     comparison operations of these labels to precise matches of the 
-     UCS domain names which are stored in the zone database. However, 
-     the seven bit character codes from any labels which are received 
-     as STD13 octet sequences MUST be compared in a case-neutral form, 
-     and MUST NOT be normalized as part of the comparison operation. 
-      
-     When a zone is converted to support internationalized domain 
-     names, all of the servers which replicate that zone MUST be 
-     upgraded. This is required due to ambiguities that can occur with 
-     labels which may be encoded as either STD13 octet sequences or ACE 
-     data, and where the label only uses character codes from the 
-     eight-bit range of character codes (this problem is described in 
-     detail in section 4.1.2). In order to ensure that all of the 
-     servers for a zone respond to one of those queries correctly, all 
-     of the servers which replicate the zone MUST fully support this 
-     document and its requirements. 
-      
-      
-  8.2.    Namespace Visibility Restrictions 
-      
-     In all cases, the encoding format of the domain names which are 
-     returned in response to a query MUST be the same as the encoding 
-     format which was used by the query. If the query was provided as a 
-     sequence of legacy labels, then all of the domain names which are 
-     provided in the response message MUST be provided as legacy labels 
-     (containing either ACE or STD13 octet encoded values). 
-      
-     Similarly, if a query is provided as EDNS/UTF-8 encoded data, all 
-     domain names which are provided in the response message MUST be 
-     provided as UTF-8 encoded data in EDNS/UTF-8 extended labels. In 
-     some situations, this process may require the server to perform an 
-     extra conversion. 
-      
-     For example, assume that the <idn>.example.com. domain name has 
-     two associated MX resource records, one of which points to the UCS 
-     domain name of mail.<idn>.example.com, while the other points to 
-   
-  Hall                    I-D Expires: May 2002              [page 51] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     the ACE encoded domain name of mail.<ace>.example.net. (where the 
-     "<ace>" label is the ACE equivalent of an internationalized sub-
-     domain in the example.net. zone). If a UTF-8 query arrives for the 
-     MX resource records associated with the <idn>.example.com. domain 
-     name, both resource records MUST be returned as EDNS/UTF-8 data. 
-     In order for this requirement to be satisfied, the server will 
-     have to decode the <ace> label to its UCS canonical form for zone 
-     storage purposes, and encode the domain name as UTF-8 for 
-     transmission whenever an EDNS/UTF-8 answer set is required. 
-      
-     The visibility rules specified in this section are mandatory for 
-     every domain name which is provided in any message. If a system 
-     requests a zone transfer and uses the EDNS/UTF-8 extended label 
-     type in the request, all of the domain names in all of the 
-     messages which are sent as part of the zone transfer MUST be 
-     provided in their UTF-8 encoded form. Similarly, if a zone 
-     transfer is requested and uses the legacy label type, then all of 
-     the domain names from all of the messages which are sent as part 
-     of the zone transfer MUST be provided as either STD13 octet 
-     sequences or ACE encoded data, using the legacy label type. 
-      
-      
-  8.3.    The Master File Format 
-      
-     STD13 specifies a "master file" format which is used as a 
-     platform-neutral storage and transfer format for importing and 
-     exporting the contents of a particular zone. Note that the master 
-     file is not the same as the operating database for a zone; the 
-     master file format is used (or is useful) for copying a zone to 
-     another server, storing a copy of the zone database off-line, 
-     emailing a copy of the zone to another user or system, and 
-     performing other off-line actions against the database' contents. 
-     Once a zone is loaded on a server, however, any database 
-     technology can be used for managing the zones and generating 
-     response messages. 
-      
-     In order to facilitate the continued use of master files, any zone 
-     which is compliant with this specification MUST support the use of 
-     UTF-8 as an import and export encoding format for the master file 
-     associated with that zone. 
-      
-     Furthermore, compliant versions of a master file are required to 
-     have the "$UTF-8" control literal at the beginning of the first 
-     line of text in the master file if it contains UTF-8 encoded data. 
-     Master files from zones which do not contain UTF-8 encoded domain 
-   
-  Hall                    I-D Expires: May 2002              [page 52] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     names MUST NOT contain the "$UTF-8" control literal in the first 
-     print position of any line. 
-      
-     If the master file contains the "$UTF-8" control literal, all of 
-     the data within the master file MUST be encoded in UTF-8 as 
-     specified by RFC2279, and SHOULD be managed with UTF-8 compliant 
-     tools (such as UTF-8 text editors, mailers that support UTF-8 MIME 
-     encodings, and so forth). 
-      
-      
-  9.      Caching Guidelines 
-      
-     Whenever an internationalized domain name is stored in a cache, it 
-     MUST be stored in its canonical UCS character code form, 
-     regardless of whether the domain name was received as STD13 octet 
-     encoding sequences, UTF-8, or ACE data. Caches MUST NOT normalize 
-     or case convert any domain names that they store, as such a 
-     process could invalidate domain names that are not used for host 
-     identifiers. 
-      
-     Any subsequent queries which are processed through the cache MUST 
-     be compared against the stored UCS characters. Internationalized 
-     domain name labels which are decoded from UTF-8 or ACE labels MUST 
-     NOT be normalized or case-converted as part of the comparison 
-     operation, although labels which are provided as STD13 octet 
-     sequences MUST be compared as case-neutral octet values. 
-      
-     Caches MUST be capable of providing UTF-8 and ACE encoded 
-     representations of the UCS domain names which are stored in the 
-     cache, with the appropriate format determined by the format used 
-     in the corresponding query. However, answer data MUST be 
-     restricted to only one encoding form for any protocol operation, 
-     meaning that queries containing legacy labels MUST only be 
-     answered with STD13 octet sequences and/or ACE encoded labels, 
-     while UTF-8 queries MUST only be answered with UTF-8 encoded 
-     domain names. 
-      
-      
-  10.     Security Considerations 
-      
-     This document defines an extension to the domain name system, and 
-     as such, it inherits the weaknesses which already exist in DNS. 
-     Where possible, this specification strengthens DNS with multiple 
-     checks. For example, this specification requires that domain names 
-     be validated three times before they are used by applications: 
-     once on specification, once on entry at the authoritative zone or 
-   
-  Hall                    I-D Expires: May 2002              [page 53] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-     hosts database, and once again when the answer data is received by 
-     the requesting application. Despite these checks, the root 
-     weaknesses inherent in DNS are still present. 
-      
-     This document uses multiple encoding algorithms, although boundary 
-     conditions from the existing DNS are preserved for both the source 
-     and encoded representations. 
-      
-      
-  11.     IANA Considerations 
-      
-     This document requires the use of an EDNS extended label type 
-     identification code. This document uses the b000011 ELT code. 
-      
-      
-  12.     References 
-      
-          [AMC-ACE-Z] <draft-ietf-idn-amc-ace-z>, "AMC-ACE-Z version 
-            0.3.1" 
-      
-          [NAMEPREP] <draft-ietf-idn-nameprep>, "Preparation of 
-            Internationalized Host Names" 
-      
-          [RFC2119] "Key words for use in RFCs to Indicate Requirement 
-            Levels" 
-      
-          [RFC952] "DoD Internet host table specification" 
-      
-          [STD13] (RFC 1034) "Domain names - concepts and facilities", 
-            (RFC 1035) "Domain names - implementation and 
-            specification" 
-      
-          [STD3] (RFC 1122) "Requirements for Internet Hosts -- 
-            Communication Layers", (RFC1123) "Requirements for Internet 
-            Hosts -- Application and Support" 
-      
-          [BCP18] (RFC 2277) "IETF Policy on Character Sets and 
-            Languages" 
-      
-          [RFC2279] "UTF-8, a transformation format of ISO 10646" 
-      
-          [RFC2671] "Extension Mechanisms for DNS (EDNS0)" 
-      
-          [ASCII] "ANSI X3.4-1968. USA Standard Code for Information 
-            Interchange" 
-      
-   
-  Hall                    I-D Expires: May 2002              [page 54] 
-  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
-   
-   
-          [ISO10646] "ISO/IEC 10646-1:2000. International Standard -- 
-            Information technology -- Universal Multiple-Octet Coded 
-            Character Set (UCS) -- Part 1: Architecture and Basic 
-            Multilingual Plane" 
-      
-      
-  13.     Acknowledgements 
-      
-     This document is an assembly of multiple ideas and proposals which 
-     have been made on the IDN working group mailing list. Many of the 
-     ideas presented here have been proposed by multiple parties in one 
-     form or another, although Dan Oscarsson is credited for proposing 
-     a dual-mode operation which is capable of simultaneously 
-     supporting UTF-8 and legacy mode encodings. Other contributors to 
-     key elements from this specification (some of them unknowingly or 
-     unwillingly) include (alphabetically) Marc Blanchett, Adam 
-     Costello, Mark Davis, Martin Duerst, Patrik Faltstrom, Paul 
-     Hoffman, David Hopwood, and many others. 
-      
-      
-  14.     Editor's Address 
-      
-     Eric A. Hall 
-     ehall@ehsco.com 
-      
-      
-      
-   
-  Hall                    I-D Expires: May 2002              [page 55] 
diff --git a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-03.txt b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-03.txt
deleted file mode 100644
index c4948ace..00000000
--- a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-03.txt
+++ /dev/null
@@ -1,169 +0,0 @@
-
-Internet Draft                              Paul Hoffman
-draft-hoffman-legis-smtp-banner-03.txt      Internet Mail Consortium
-November 12, 1998                           John Levine
-Expires in six months                       IECC
-
-                Anti-UBE and Anti-UCE Keywords in SMTP Banners
-
-Status of this memo
-
-This document is an Internet-Draft. Internet-Drafts are working documents
-of the Internet Engineering Task Force (IETF), its areas, and its working
-groups. Note that other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months and
-may be updated, replaced, or obsoleted by other documents at any time. It
-is inappropriate to use Internet-Drafts as reference material or to cite
-them other than as "work in progress."
-
-To learn the current status of any Internet-Draft, please check the
-"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
-(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
-Coast).
-
-1. Introduction
-
-Legislators writing laws that would limit or prohibit the sending of
-unsolicited bulk email (UBE) or unsolicited commercial email (UCE) have
-begun to include rules that require mail servers to include particular
-wording in the SMTP banner. To date, this wording has had two distinct
-purposes: to warn senders that they may not send UBE or UCE to that SMTP
-host, and to state the physical location of the host so that the sender may
-know which laws apply.
-
-This document is meant to help clarify how such legislation might be
-worded, and to help increase interoperability of various laws. It is not
-meant to be a standard of any kind, but is meant only for its informational
-value.
-
-2. The SMTP Banner
-
-SMTP, as defined in [RFC821], is a client-server protocol that runs over
-TCP/IP. When the SMTP client connects to the SMTP server, the server TCP
-immediately emits a banner, also called an "opening message" or "connection
-greeting". The contents of this banner must be in the ASCII character
-set, and the banner must be no longer than 512 characters, including the
-response code, separator, and <CRLF> at the end of the banner.
-
-The banner normally contains software and version information, and often
-contains other useful debugging information. Most SMTP server products
-allow the system administrator to specify the contents of the banner. The
-banner must start with a three-digit status code followed by a space, but
-the rest of banner is not specified by any existing standard.
-
-3. Rationale for Using the SMTP Banner for Anti-UBE and Anti-UCE Messages
-
-There has been some debate about whether or not the SMTP banner is the best
-place to put notices to UBE senders.
-
-The arguments in favor of using the SMTP banner include:
-
-- A potential UBE sender uses almost no resources on the part of the SMTP
-  server to find out that UBE is not allowed.
-
-- It is very easy to describe in legislation, and thus is most likely to be
-  upheld in courts if challenged.
-
-- An SMTP client who wants to send UBE does not need to identify itself
-  before determining if the SMTP server will accept such mail.
-
-- It is easy for a mail system administrator to configure and check the
-  SMTP banner.
-
-- Existing banners are typically much shorter than 512 characters, so the
-  addition of a short phrase is unlikely to violate any standard limits.
-
-The arguments against using the SMTP banner include:
-
-- This overloads the semantics of the banner contents.
-
-- This could instead be done with an ESMTP extension.
-
-- Even though the load on the recipient's mail server is low, any type of
-banner still represents an admission that the sender is allowed to try to
-send mail that they know is most likely unwanted to the recipient at the
-recipient's expense.
-
-4. Suggested Wording for Legislation Restricting UBE and UCE
-
-Legislation that requires wording in the SMTP banner to indicate that UBE
-or UCE is not allowed or is restricted on the server should include the
-exact phrase used. That phrase should be short, succinct, and must not be
-required to be in a particular position in the SMTP banner. We recommend
-the phrase "NO UBE" or "NO UCE", in all uppercase characters. Legislation
-mandating either phrase should specify that the phrase must be preceded by
-a non-alphanumeric character, and followed by non-alphanumeric character or
-the end of the banner.
-
-Note that such a phrase will be human-readable, but it is also easily
-machine-readable if the exact phrase is specified in the legislation. Using
-such a machine-readable phrase makes it easier for potential UBE senders to
-avoid problems by having a program check whether or not the mail server
-accepts UBE before sending the mail. Although the banner phrase should be
-in uppercase characters, clients should recognize the phrase in any
-combination of upper- and lowercase characters.
-
-SMTP banners are rarely seen by humans. The additional wording in the SMTP
-banner described here is not meant to be seen by the person who is sending
-mail, only by their mail system.
-
-It should also be noted that most languages around the world require
-characters outside the ASCII character set, but these characters must not
-be used in an SMTP banner. In such cases, the legislation might choose a
-phrase for the SMTP banner which does not make sense in the native language
-of the area in question but is unlikely to appear in a banner for other
-reasons. 
-
-5. Suggested wording for Legislation Stating Server Location
-
-Legislation that requires a server administrator to state the location of
-the server should use standardized abbreviations for countries and local
-states or provinces. These locations should be easy to pick out from other
-information in the SMTP banner.
-
-Legislation that requires that the server identify the country that it is
-in should use "C=" followed by the official two-letter country code defined
-in [ISO3166-1]. Legislation that requires the server identify the state or
-province that it is in should use "L=" followed by an officially-accepted
-abbreviation (if any) for the state or province name. Codes for locations
-are discussed in [ISO3166-2]. Legislation mandating either type of location
-should specify that the "C=" or "L=" must be preceded by a non-alphanumeric
-character, and followed by non-alphanumeric character or the end of the
-banner.
-
-For instance, in the state of California, such legislation might require
-the phrase "C=US L=CA" to be included in the banner. (The "C" for country
-and "L" for location come from the widely-used X.500 directory standard.)
-
-6. Security Considerations
-
-Forcing a mail server to state its location can possibly cause an attacker
-to gain valuable information about the server or its characteristics.
-
-7. References
-
-[RFC821] RFC 821, Simple Mail Transport Protocol.
-
-[ISO3166-1] ISO 3166-1:1997 Codes for the representation of names of
-countries and their subdivisions -- Part 1: Country codes.
-
-[ISO3166-2] ISO/DIS 3166-2 Codes for the representation of names of
-countries and their subdivisions -- Part 2: Country subdivision code.
-
-8. Authors' Addresses
-
-Paul Hoffman
-Internet Mail Consortium
-127 Segre Place
-Santa Cruz, CA  95060
-phoffman@imc.org
-
-John Levine
-IECC
-PO Box 727
-Trumansburg, NY 14886
-johnl@iecc.com
-
diff --git a/Documentation/en/I-D/draft-hoffman-rfc2487bis-00.txt b/Documentation/en/I-D/draft-hoffman-rfc2487bis-00.txt
deleted file mode 100644
index 45245afd..00000000
--- a/Documentation/en/I-D/draft-hoffman-rfc2487bis-00.txt
+++ /dev/null
@@ -1,364 +0,0 @@
-Internet Draft                                          Paul Hoffman
-<draft-hoffman-rfc2487bis-00.txt>           Internet Mail Consortium
-April 15, 1999
-Expires in six months
-
-            SMTP Service Extension for Secure SMTP over TLS
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet- Drafts as reference
-material or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-1. Abstract
-
-   This document describes an extension to the SMTP service that allows
-   an SMTP server and client to use transport-layer security to provide
-   private, authenticated communication over the Internet. This gives
-   SMTP agents the ability to protect some or all of their
-   communications from eavesdroppers and attackers.
-
-   This document is a revision of RFC 2487, which is currently a Proposed
-   Standard. The changes that this draft propose are:
-
-   - Additional discussion of when a server should and should not
-     advertise the STARTTLS extension (section 4)
-   - More discussion of the man-in-the-middle attacks (sections
-     5 and 7)
-   - Bugfix in the example in section 6 to indicate that the client
-     needs to issue a new EHLO command, as already is described in
-     section 5.2.
-
-2. Introduction
-
-   SMTP [RFC-821] servers and clients normally communicate in the clear
-   over the Internet. In many cases, this communication goes through one
-   or more router that is not controlled or trusted by either entity.
-   Such an untrusted router might allow a third party to monitor or
-   alter the communications between the server and client.
-
-   Further, there is often a desire for two SMTP agents to be able to
-   authenticate each others' identities. For example, a secure SMTP
-   server might only allow communications from other SMTP agents it
-   knows, or it might act differently for messages received from an
-   agent it knows than from one it doesn't know.
-
-   TLS [TLS], more commonly known as SSL, is a popular mechanism for
-   enhancing TCP communications with privacy and authentication. TLS is
-   in wide use with the HTTP protocol, and is also being used for adding
-   security to many other common protocols that run over TCP.
-
-2.1 Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC-2119].
-
-3. STARTTLS Extension
-
-   The STARTTLS extension to SMTP is laid out as follows:
-
-   (1) the name of the SMTP service defined here is STARTTLS;
-
-   (2) the EHLO keyword value associated with the extension is STARTTLS;
-
-   (3) the STARTTLS keyword has no parameters;
-
-   (4) a new SMTP verb, "STARTTLS", is defined;
-
-   (5) no additional parameters are added to any SMTP command.
-
-4. The STARTTLS Keyword
-
-    The STARTTLS keyword is used to tell the SMTP client that the SMTP
-    server is currently able to negotiate the use of TLS. It takes no
-    parameters.
-
-5. The STARTTLS Command
-
-   The format for the STARTTLS command is:
-
-   STARTTLS
-
-   with no parameters.
-
-   After the client gives the STARTTLS command, the server responds with
-   one of the following reply codes:
-
-   220 Ready to start TLS
-   501 Syntax error (no parameters allowed)
-   454 TLS not available due to temporary reason
-
-   If the client receives the 454 response, the client must decide
-   whether or not to continue the SMTP session. Such a decision is
-   based on local policy. For instance, if TLS was being used for
-   client authentication, the client might try to continue the
-   session, in case the server allows it even with no authentication.
-   However, if TLS was being negotiated for encryption, a client
-   that gets a 454 response needs to decide whether to send the
-   message anyway with no TLS encryption, whether to wait and try
-   again later, or whether to give up and notify the sender of the
-   error.
-
-   A publicly-referenced SMTP server MUST NOT require use of the
-   STARTTLS extension in order to deliver mail locally. This rule
-   prevents the STARTTLS extension from damaging the interoperability of
-   the Internet's SMTP infrastructure. A publicly-referenced SMTP server
-   is an SMTP server which runs on port 25 of an Internet host listed in
-   the MX record (or A record if an MX record is not present) for the
-   domain name on the right hand side of an Internet mail address.
-
-   Any SMTP server may refuse to accept messages for relay based on
-   authentication supplied during the TLS negotiation. An SMTP server
-   that is not publicly referenced may refuse to accept any messages for
-   relay or local delivery based on authentication supplied during the
-   TLS negotiation.
-
-   A SMTP server that is not publicly referenced may choose to require
-   that the client perform a TLS negotiation before accepting any
-   commands. In this case, the server SHOULD return the reply code:
-
-   530 Must issue a STARTTLS command first
-
-   to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
-   client and server are using the ENHANCEDSTATUSCODES ESMTP extension
-   [RFC-2034], the status code to be returned SHOULD be 5.7.0.
-
-   After receiving a 220 response to a STARTTLS command, the client
-   SHOULD start the TLS negotiation before giving any other SMTP
-   commands.
-
-   If the SMTP client is using pipelining as defined in RFC 1854, the
-   STARTTLS command must be the last command in a group.
-
-5.1 Processing After the STARTTLS Command
-
-   After the TLS handshake has been completed, both parties MUST
-   immediately decide whether or not to continue based on the
-   authentication and privacy achieved. The SMTP client and server may
-   decide to move ahead even if the TLS negotiation ended with no
-   authentication and/or no privacy because most SMTP services are
-   performed with no authentication and no privacy, but some SMTP
-   clients or servers may want to continue only if a particular level of
-   authentication and/or privacy was achieved.
-
-   If the SMTP client decides that the level of authentication or
-   privacy is not high enough for it to continue, it SHOULD issue an
-   SMTP QUIT command immediately after the TLS negotiation is complete.
-   If the SMTP server decides that the level of authentication or
-   privacy is not high enough for it to continue, it SHOULD reply to
-   every SMTP command from the client (other than a QUIT command) with
-   the 554 reply code (with a possible text string such as "Command
-   refused due to lack of security").
-
-   The decision of whether or not to believe the authenticity of the
-   other party in a TLS negotiation is a local matter. However, some
-   general rules for the decisions are:
-
-    - A SMTP client would probably only want to authenticate an SMTP
-      server whose server certificate has a domain name that is the
-      domain name that the client thought it was connecting to.
-    - A publicly-referenced  SMTP server would probably want to accept
-      any certificate from an SMTP client, and would possibly want to
-      put distinguishing information about the certificate in the
-      Received header of messages that were relayed or submitted from
-      the client.
-
-5.2 Result of the STARTTLS Command
-
-   Upon completion of the TLS handshake, the SMTP protocol is reset to
-   the initial state (the state in SMTP after a server issues a 220
-   service ready greeting). The server MUST discard any knowledge
-   obtained from the client, such as the argument to the EHLO command,
-   which was not obtained from the TLS negotiation itself. The client
-   MUST discard any knowledge obtained from the server, such as the list
-   of SMTP service extensions, which was not obtained from the TLS
-   negotiation itself. The client SHOULD send an EHLO command as the
-   first command after a successful TLS negotiation.
-
-   The list of SMTP service extensions returned in response to an EHLO
-   command received after the TLS handshake MAY be different than the
-   list returned before the TLS handshake. For example, an SMTP server
-   might not want to advertise support for a particular SASL mechanism
-   [SASL] unless a client has sent an appropriate client certificate
-   during a TLS handshake.
-
-   Both the client and the server MUST know if there is a TLS session
-   active.  A client MUST NOT attempt to start a TLS session if a TLS
-   session is already active. A server MUST NOT return the TLS extension
-   in response to an EHLO command received after a TLS handshake has
-   completed.
-
-6. Usage Example
-
-   The following dialog illustrates how a client and server can start a
-   TLS session:
-
-   S: <waits for connection on TCP port 25>
-   C: <opens connection>
-   S: 220 mail.imc.org SMTP service ready
-   C: EHLO mail.ietf.org
-   S: 250-mail.imc.org offers a warm hug of welcome
-   S: 250 STARTTLS
-   C: STARTTLS
-   S: 220 Go ahead
-   C: <starts TLS negotiation>
-
-   C & S: <negotiate a TLS session>
-   C & S: <check result of negotiation>
-   C: EHLO mail.ietf.org
-   S: 250-mail.imc.org touches your hand gently for a moment
-   S: 250 STARTTLS
-   . . .
-
-7. Security Considerations
-
-   It should be noted that SMTP is not an end-to-end mechanism. Thus, if
-   an SMTP client/server pair decide to add TLS privacy, they are not
-   securing the transport from the originating mail user agent to the
-   recipient.  Further, because delivery of a single piece of mail may
-   go between more than two SMTP servers, adding TLS privacy to one pair
-   of servers does not mean that the entire SMTP chain has been made
-   private. Further, just because an SMTP server can authenticate an
-   SMTP client, it does not mean that the mail from the SMTP client was
-   authenticated by the SMTP client when the client received it.
-
-   Both the STMP client and server must check the result of the TLS
-   negotiation to see whether acceptable authentication or privacy was
-   achieved. Ignoring this step completely invalidates using TLS for
-   security.  The decision about whether acceptable authentication or
-   privacy was achieved is made locally, is implementation-dependant,
-   and is beyond the scope of this document.
-
-   The SMTP client and server should note carefully the result of the
-   TLS negotiation. If the negotiation results in no privacy, or if it
-   results in privacy using algorithms or key lengths that are deemed
-   not strong enough, or if the authentication is not good enough for
-   either party, the client may choose to end the SMTP session with an
-   immediate QUIT command, or the server may choose to not accept any
-   more SMTP commands.
-
-   A server announcing in an EHLO response that it uses a particular TLS
-   protocol should not pose any security issues, since any use of TLS
-   will be at least as secure as no use of TLS.
-
-   A man-in-the-middle attack can be launched by deleting the "250
-   STARTTLS" response from the server. This would cause the client not
-   to try to start a TLS session. Another man-in-the-middle attack is
-   to allow the server to announce its STARTTLS capability, but to
-   alter the client's request to start TLS and the server's response.
-   An SMTP client can partially protect against these attacks by
-   recording the fact that a particular SMTP server offers TLS during
-   one session and generating an alarm if it does not appear in the
-   EHLO response for a later session. The lack of TLS during a session
-   SHOULD NOT result in the bouncing of email, although it could result
-   in delayed processing.
-
-   If the TLS negotiation fails or if the client receives a 454
-   response, the client has to decide what to do next. There are three
-   main choices: go ahead with the rest of the SMTP session, retry TLS
-   at a later time, or give up and return the mail to the sender. If a
-   failure or error occurs, the client can assume that the server may
-   be able to negotiate TLS in the future, and should try negotiate TLS
-   in a later session, until some locally-chosen timeout occurs, at
-   which point, the client should return the mail to the sender.
-   However, if the client and server were only using TLS for
-   authentication, the client may want to procede with the SMTP
-   session, in case some of the operations the client wanted to perform
-   are accepted by the server even if the client is unauthenticated.
-
-   Before the TLS handshake has begun, any protocol interactions are
-   performed in the clear and may be modified by an active attacker. For
-   this reason, clients and servers MUST discard any knowledge obtained
-   prior to the start of the TLS handshake upon completion of the TLS
-   handshake.
-
-   The STARTTLS extension is not suitable for authenticating the author
-   of an email message unless every hop in the delivery chain, including
-   the submission to the first SMTP server, is authenticated. Another
-   proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
-   security multiparts [MIME-SEC] can be used to authenticate the author
-   of an email message. In addition, the [SMTP-AUTH] proposal offers
-   simpler and more flexible options to authenticate an SMTP client and
-   the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with
-   the STARTTLS command to provide an authorization identity.
-
-A. References
-
-   [RFC-821]   Postel, J., "Simple Mail Transfer Protocol", RFC 821,
-               August 1982.
-
-   [RFC-1869]  Klensin, J., Freed, N, Rose, M, Stefferud, E. and D.
-               Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
-               November 1995.
-
-   [RFC-2034]  Freed, N., "SMTP Service Extension for Returning Enhanced
-               Error Codes", RFC 2034, October 1996.
-
-   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [SASL]      Myers, J., "Simple Authentication and Security Layer
-               (SASL)", RFC 2222, October 1997.
-
-   [SMTP-AUTH] "SMTP Service Extension for Authentication", Work in
-               Progress.
-
-   [TLS]       Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-               RFC 2246, January 1999.
-
-B. Author's Address
-
-   Paul Hoffman
-   Internet Mail Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060
-
-   Phone: (831) 426-9827
-   EMail: phoffman@imc.org
-
-C.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  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.
-
diff --git a/Documentation/en/I-D/draft-hoffman-rfc2487bis-06.txt b/Documentation/en/I-D/draft-hoffman-rfc2487bis-06.txt
deleted file mode 100644
index 4a9bb62d..00000000
--- a/Documentation/en/I-D/draft-hoffman-rfc2487bis-06.txt
+++ /dev/null
@@ -1,356 +0,0 @@
-Internet Draft                                          Paul Hoffman
-draft-hoffman-rfc2487bis-06.txt             Internet Mail Consortium
-November 4, 2001
-Expires in six months
-
-            SMTP Service Extension for Secure SMTP over TLS
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet- Drafts as reference
-material or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-1. Abstract
-
-   This document describes an extension to the SMTP service that allows
-   an SMTP server and client to use transport-layer security to provide
-   private, authenticated communication over the Internet. This gives
-   SMTP agents the ability to protect some or all of their
-   communications from eavesdroppers and attackers.
-
-   This document obsoletes RFC 2487, as described in Appendix B.
-
-2. Introduction
-
-   SMTP [RFC-2821] servers and clients normally communicate in the clear
-   over the Internet. In many cases, this communication goes through one
-   or more router that is not controlled or trusted by either entity.
-   Such an untrusted router might allow a third party to monitor or
-   alter the communications between the server and client.
-
-   Further, there is often a desire for two SMTP agents to be able to
-   authenticate each others' identities. For example, a secure SMTP
-   server might only allow communications from other SMTP agents it
-   knows, or it might act differently for messages received from an
-   agent it knows than from one it doesn't know.
-
-   TLS [TLS], more commonly known as SSL, is a popular mechanism for
-   enhancing TCP communications with privacy and authentication. TLS is
-   in wide use with the HTTP protocol, and is also being used for adding
-   security to many other common protocols that run over TCP.
-
-2.1 Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC-2119].
-
-3. STARTTLS Extension
-
-   The STARTTLS extension to SMTP is laid out as follows:
-
-   (1) the name of the SMTP service defined here is STARTTLS;
-
-   (2) the EHLO keyword value associated with the extension is STARTTLS;
-
-   (3) the STARTTLS keyword has no parameters;
-
-   (4) a new SMTP verb, "STARTTLS", is defined;
-
-   (5) no additional parameters are added to any SMTP command.
-
-4. The STARTTLS Keyword
-
-    The STARTTLS keyword is used to tell the SMTP client that the SMTP
-    server is currently able to negotiate the use of TLS. It takes no
-    parameters.
-
-5. The STARTTLS Command
-
-   The format for the STARTTLS command is:
-
-   STARTTLS
-
-   with no parameters.
-
-   After the client gives the STARTTLS command, the server responds with
-   one of the following reply codes:
-
-   220 Ready to start TLS
-   501 Syntax error (no parameters allowed)
-   454 TLS not available due to temporary reason
-
-   If the client receives the 454 response, the client must decide
-   whether or not to continue the SMTP session. Such a decision is
-   based on local policy. For instance, if TLS was being used for
-   client authentication, the client might try to continue the
-   session, in case the server allows it even with no authentication.
-   However, if TLS was being negotiated for encryption, a client
-   that gets a 454 response needs to decide whether to send the
-   message anyway with no TLS encryption, whether to wait and try
-   again later, or whether to give up and notify the sender of the
-   error.
-
-   A publicly-referenced SMTP server MUST NOT require use of the
-   STARTTLS extension in order to deliver mail locally. This rule
-   prevents the STARTTLS extension from damaging the interoperability of
-   the Internet's SMTP infrastructure. A publicly-referenced SMTP server
-   is an SMTP server which runs on port 25 of an Internet host listed in
-   the MX record (or A record if an MX record is not present) for the
-   domain name on the right hand side of an Internet mail address.
-
-   Any SMTP server may refuse to accept messages for relay based on
-   authentication supplied during the TLS negotiation. An SMTP server
-   that is not publicly referenced may refuse to accept any messages for
-   relay or local delivery based on authentication supplied during the
-   TLS negotiation.
-
-   A SMTP server that is not publicly referenced may choose to require
-   that the client perform a TLS negotiation before accepting any
-   commands. In this case, the server SHOULD return the reply code:
-
-   530 Must issue a STARTTLS command first
-
-   to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
-   client and server are using the ENHANCEDSTATUSCODES ESMTP extension
-   [RFC-2034], the status code to be returned SHOULD be 5.7.0.
-
-   After receiving a 220 response to a STARTTLS command, the client MUST
-   start the TLS negotiation before giving any other SMTP commands. If,
-   after having issued the STARTTLS command, the client finds out that
-   some failure prevents it from actually starting a TLS handshake, then
-   it SHOULD abort the connection.
-
-   If the SMTP client is using pipelining as defined in RFC 2920, the
-   STARTTLS command must be the last command in a group.
-
-5.1 Processing After the STARTTLS Command
-
-   After the TLS handshake has been completed, both parties MUST
-   immediately decide whether or not to continue based on the
-   authentication and privacy achieved. The SMTP client and server may
-   decide to move ahead even if the TLS negotiation ended with no
-   authentication and/or no privacy because most SMTP services are
-   performed with no authentication and no privacy, but some SMTP
-   clients or servers may want to continue only if a particular level of
-   authentication and/or privacy was achieved.
-
-   If the SMTP client decides that the level of authentication or
-   privacy is not high enough for it to continue, it SHOULD issue an
-   SMTP QUIT command immediately after the TLS negotiation is complete.
-   If the SMTP server decides that the level of authentication or
-   privacy is not high enough for it to continue, it SHOULD reply to
-   every SMTP command from the client (other than a QUIT command) with
-   the 554 reply code (with a possible text string such as "Command
-   refused due to lack of security").
-
-   The decision of whether or not to believe the authenticity of the
-   other party in a TLS negotiation is a local matter. However, some
-   general rules for the decisions are:
-
-    - A SMTP client would probably only want to authenticate an SMTP
-      server whose server certificate has a domain name that is the
-      domain name that the client thought it was connecting to.
-    - A publicly-referenced  SMTP server would probably want to accept
-	  any verifiable certificate from an SMTP client, and would
-	  possibly want to put distinguishing information about the
-	  certificate in the Received header of messages that were relayed
-	  or submitted from the client.
-
-5.2 Result of the STARTTLS Command
-
-   Upon completion of the TLS handshake, the SMTP protocol is reset to
-   the initial state (the state in SMTP after a server issues a 220
-   service ready greeting). The server MUST discard any knowledge
-   obtained from the client, such as the argument to the EHLO command,
-   which was not obtained from the TLS negotiation itself. The client
-   MUST discard any knowledge obtained from the server, such as the list
-   of SMTP service extensions, which was not obtained from the TLS
-   negotiation itself. The client SHOULD send an EHLO command as the
-   first command after a successful TLS negotiation.
-
-   The list of SMTP service extensions returned in response to an EHLO
-   command received after the TLS handshake MAY be different than the
-   list returned before the TLS handshake. For example, an SMTP server
-   might not want to advertise support for a particular SASL mechanism
-   [SASL] unless a client has sent an appropriate client certificate
-   during a TLS handshake.
-
-   Both the client and the server MUST know if there is a TLS session
-   active.  A client MUST NOT attempt to start a TLS session if a TLS
-   session is already active. A server MUST NOT return the STARTTLS
-   extension in response to an EHLO command received after a TLS
-   handshake has completed.
-   
-5.3 STARTTLS on the Submission Port
-
-   STARTTLS is a valid ESMTP extension when used on the Submission
-   port, as defined in [RFC-2476]. In fact, since the submission port
-   is by definition not a publicly referenced SMTP server, the STARTTLS
-   extension can be particularly useful by providing security and
-   authentication for this service.
-
-6. Usage Example
-
-   The following dialog illustrates how a client and server can start a
-   TLS session:
-
-   S: <waits for connection on TCP port 25>
-   C: <opens connection>
-   S: 220 mail.imc.org SMTP service ready
-   C: EHLO mail.example.com
-   S: 250-mail.imc.org offers a warm hug of welcome
-   S: 250-8BITMIME
-   S: 250-STARTTLS
-   S: 250 DSN
-   C: STARTTLS
-   S: 220 Go ahead
-   C: <starts TLS negotiation>
-   C & S: <negotiate a TLS session>
-   C & S: <check result of negotiation>
-   C: EHLO mail.exmaple.com
-   S: 250-mail.imc.org touches your hand gently for a moment
-   S: 250-8BITMIME
-   S: 250 DSN
-   . . .
-
-7. Security Considerations
-
-   It should be noted that SMTP is not an end-to-end mechanism. Thus, if
-   an SMTP client/server pair decide to add TLS privacy, they are not
-   securing the transport from the originating mail user agent to the
-   recipient. Further, because delivery of a single piece of mail may
-   go between more than two SMTP servers, adding TLS privacy to one pair
-   of servers does not mean that the entire SMTP chain has been made
-   private. Further, just because an SMTP server can authenticate an
-   SMTP client, it does not mean that the mail from the SMTP client was
-   authenticated by the SMTP client when the client received it.
-
-   Both the SMTP client and server must check the result of the TLS
-   negotiation to see whether an acceptable degree of authentication
-   and privacy was achieved. Ignoring this step completely invalidates
-   using TLS for security. The decision about whether acceptable
-   authentication or privacy was achieved is made locally, is
-   implementation-dependant, and is beyond the scope of this document.
-
-   The SMTP client and server should note carefully the result of the
-   TLS negotiation. If the negotiation results in no privacy, or if it
-   results in privacy using algorithms or key lengths that are deemed
-   not strong enough, or if the authentication is not good enough for
-   either party, the client may choose to end the SMTP session with an
-   immediate QUIT command, or the server may choose to not accept any
-   more SMTP commands.
-
-   A man-in-the-middle attack can be launched by deleting the "250
-   STARTTLS" response from the server. This would cause the client not
-   to try to start a TLS session. Another man-in-the-middle attack is to
-   allow the server to announce its STARTTLS capability, but to alter
-   the client's request to start TLS and the server's response. In order
-   to defend against such attacks both clients and servers MUST be able
-   to be configured to require successful TLS negotiation of an
-   appropriate cipher suite for selected hosts before messages can be
-   successfully transferred. The additional option of using TLS when
-   possible SHOULD also be provided. An implementation MAY provide the
-   ability to record that TLS was used in communicating with a given
-   peer and generating a warning if it is not used in a later session.
-
-   If the TLS negotiation fails or if the client receives a 454
-   response, the client has to decide what to do next. There are three
-   main choices: go ahead with the rest of the SMTP session, retry TLS
-   at a later time, or give up and return the mail to the sender. If a
-   failure or error occurs, the client can assume that the server may
-   be able to negotiate TLS in the future, and should try negotiate TLS
-   in a later session, until some locally-chosen timeout occurs, at
-   which point, the client should return the mail to the sender.
-   However, if the client and server were only using TLS for
-   authentication, the client may want to proceed with the SMTP
-   session, in case some of the operations the client wanted to perform
-   are accepted by the server even if the client is unauthenticated.
-
-   Before the TLS handshake has begun, any protocol interactions are
-   performed in the clear and may be modified by an active attacker. For
-   this reason, clients and servers MUST discard any knowledge obtained
-   prior to the start of the TLS handshake upon completion of the TLS
-   handshake.
-
-   The STARTTLS extension is not suitable for authenticating the author
-   of an email message unless every hop in the delivery chain, including
-   the submission to the first SMTP server, is authenticated. Another
-   proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
-   security multiparts [MIME-SEC] can be used to authenticate the author
-   of an email message. In addition, the [SMTP-AUTH] proposal offers
-   simpler and more flexible options to authenticate an SMTP client and
-   the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with
-   the STARTTLS command to provide an authorization identity.
-
-A. References
-
-   [RFC-2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-               April 2001.
-
-   [RFC-1869]  Klensin, J., Freed, N, Rose, M, Stefferud, E. and D.
-               Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
-               November 1995.
-
-   [RFC-2034]  Freed, N., "SMTP Service Extension for Returning Enhanced
-               Error Codes", RFC 2034, October 1996.
-
-   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC-2476]  Gellens, R. and Klensin, J., "Message Submission",
-               RFC 2476, December 1998.
-
-   [SASL]      Myers, J., "Simple Authentication and Security Layer
-               (SASL)", RFC 2222, October 1997.
-
-   [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
-			   RFC 2554, March 1999.
-
-   [TLS]       Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-               RFC 2246, January 1999.
-
-B. Changes from RFC 2487
-
-   This document is a revision of RFC 2487, which is a Proposed
-   Standard. The changes from that document are:
-
-   - Section 5 and 7: More discussion of the man-in-the-middle attacks
-   - Section 5: Additional discussion of when a server should and should
-     not advertise the STARTTLS extension
-   - Section 5: Changed the requirements on SMTP clients after receiving
-     a 220 response.
-   - Section 5.1: Clarified description of verifying certificates.
-   - Section 5.3: Added the section on "STARTTLS on the Submission Port"
-   - Section 6: Bug fix in the example to indicate that the client needs
-     to issue a new EHLO command, as already is described in section 5.2.
-   - Section 7: Clarification of the paragraph on acceptable degree of
-     privacy. Significant change to the discussion of how to avoid a
-     man-in-the-middle attack.
-   - Section A: Update reference from RFC 821 to RFC 2821.
-
-
-C. Author's Address
-
-   Paul Hoffman
-   Internet Mail Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060
-
-   Phone: (831) 426-9827
-   EMail: phoffman@imc.org
diff --git a/Documentation/en/I-D/draft-hoffman-smtp-ssl-09.txt b/Documentation/en/I-D/draft-hoffman-smtp-ssl-09.txt
deleted file mode 100644
index f9fb3be3..00000000
--- a/Documentation/en/I-D/draft-hoffman-smtp-ssl-09.txt
+++ /dev/null
@@ -1,290 +0,0 @@
-
-Internet Draft                              Paul Hoffman
-draft-hoffman-smtp-ssl-09.txt               Internet Mail Consortium
-October 25, 1998
-Expires in six months
-
-         SMTP Service Extension for Secure SMTP over TLS
-
-Status of this memo
-
-This document is an Internet-Draft. Internet-Drafts are working documents
-of the Internet Engineering Task Force (IETF), its areas, and its working
-groups. Note that other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months and
-may be updated, replaced, or obsoleted by other documents at any time. It
-is inappropriate to use Internet-Drafts as reference material or to cite
-them other than as "work in progress."
-
-To learn the current status of any Internet-Draft, please check the
-"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
-(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
-Coast).
-
-
-1. Abstract
-
-This document describes an extension to the SMTP service that allows an
-SMTP server and client to use transport-layer security to provide private,
-authenticated communication over the Internet. This gives SMTP agents the
-ability to protect some or all of their communications from eavesdroppers
-and attackers.
-
-
-2. Introduction
-
-SMTP [RFC-821] servers and clients normally communicate in the clear over
-the Internet. In many cases, this communication goes through one or more
-router that is not controlled or trusted by either entity. Such an
-untrusted router might allow a third party to monitor or alter the
-communications between the server and client.
-
-Further, there is often a desire for two SMTP agents to be able to
-authenticate each others' identities. For example, a secure SMTP server
-might only allow communications from other SMTP agents it knows, or it
-might act differently for messages received from an agent it knows than
-from one it doesn't know.
-
-TLS [TLS], more commonly known as SSL, is a popular mechanism for enhancing
-TCP communications with privacy and authentication. TLS is in wide use with
-the HTTP protocol, and is also being used for adding security to many other
-common protocols that run over TCP.
-
-2.1 Discussion of this Draft
-
-This draft is being discussed on the "ietf-apps-tls" mailing list. To
-subscribe, send a message to:
-     ietf-apps-tls-request@imc.org
-with the single word
-     subscribe
-in the body of the message. There is a Web site for the mailing list at
-<http://www.imc.org/ietf-apps-tls/>.
-
-
-3. STARTTLS Extension
-
-The STARTTLS extension to SMTP is laid out as follows:
-
-(1) the name of the SMTP service defined here is STARTTLS;
-
-(2) the EHLO keyword value associated with the extension is STARTTLS;
-
-(3) the STARTTLS keyword has no parameters;
-
-(4) a new SMTP verb, "STARTTLS", is defined;
-
-(5) no additional parameters are added to any SMTP command.
-
-
-4. The STARTTLS Keyword
-
-The STARTTLS keyword is used to tell the SMTP client that the SMTP server
-allows use of TLS. It takes no parameters.
-
-
-5. The STARTTLS Command
-
-The format for the STARTTLS command is:
-
-STARTTLS
-
-with no parameters.
-
-After the client gives the STARTTLS command, the server responds with one
-of the following reply codes:
-
-220 Ready to start TLS
-501 Syntax error (no parameters allowed)
-454 TLS not available due to temporary reason
-
-A publicly-referenced SMTP server MUST NOT require use of the STARTTLS
-extension in order to deliver mail locally. This rule prevents the STARTTLS
-extension from damaging the interoperability of the Internet's SMTP
-infrastructure. A publicly-referenced SMTP server is an SMTP server which
-runs on port 25 of an Internet host listed in the MX record (or A record if
-an MX record is not present) for the domain name on the right hand side of
-an Internet mail address.
-
-Any SMTP server may refuse to accept messages for relay based on
-authentication supplied during the TLS negotiation. An SMTP server that is
-not publicly referenced may refuse to accept any messages for relay or
-local delivery based on authentication supplied during the TLS negotiation.
-
-A SMTP server that is not publicly referenced may choose to require that
-the client perform a TLS negotiation before accepting any commands. In this
-case, the server SHOULD return the reply code:
-
-530 Must issue a STARTTLS command first
-
-to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the client
-and server are using the ENHANCEDSTATUSCODES ESMTP extension [RFC-2034],
-the status code to be returned SHOULD be 5.7.0.
-
-After receiving a 220 response to a STARTTLS command, the client SHOULD
-start the TLS negotiation before giving any other SMTP commands.
-
-If the SMTP client is using pipelining as defined in RFC 1854, the STARTTLS
-command must be the last command in a group.
-
-5.1 Processing After the STARTTLS Command
-
-After the TLS handshake has been completed, both parties MUST immediately
-decide whether or not to continue based on the authentication and privacy
-achieved. The SMTP client and server may decide to move ahead even if the
-TLS negotiation ended with no authentication and/or no privacy because most
-SMTP services are performed with no authentication and no privacy, but some
-SMTP clients or servers may want to continue only if a particular level of
-authentication and/or privacy was achieved.
-
-If the SMTP client decides that the level of authentication or privacy is
-not high enough for it to continue, it SHOULD issue an SMTP QUIT command
-immediately after the TLS negotiation is complete. If the SMTP server
-decides that the level of authentication or privacy is not high enough for
-it to continue, it SHOULD reply to every SMTP command from the client
-(other than a QUIT command) with the 554 reply code (with a possible text
-string such as "Command refused due to lack of security").
-
-The decision of whether or not to believe the authenticity of the other
-party in a TLS negotiation is a local matter. However, some general rules
-for the decisions are:
- - A SMTP client would probably only want to authenticate an SMTP
-   server whose server certificate has a domain name that is the
-   domain name that the client thought it was connecting to.
- - A publicly-referenced  SMTP server would probably want to accept
-   any certificate from an SMTP client, and would possibly want to
-   put distinguishing information about the certificate in the
-   Received header of messages that were relayed or submitted from
-   the client.
-
-5.2 Result of the STARTTLS Command
-
-Upon completion of the TLS handshake, the SMTP protocol is reset to the
-initial state (the state in SMTP after a server issues a 220 service ready
-greeting). The server MUST discard any knowledge obtained from the client,
-such as the argument to the EHLO command, which was not obtained from the
-TLS negotiation itself. The client MUST discard any knowledge obtained from
-the server, such as the list of SMTP service extensions, which was not
-obtained from the TLS negotiation itself. The client SHOULD send an EHLO
-command as the first command after a successful TLS negotiation.
-
-The list of SMTP service extensions returned in response to an EHLO command
-received after the TLS handshake MAY be different than the list returned
-before the TLS handshake. For example, an SMTP server might not want to
-advertise support for a particular SASL mechanism [SASL] unless a client
-has sent an appropriate client certificate during a TLS handshake.
-
-Both the client and the server MUST know if there is a TLS session active.
-A client MUST NOT attempt to start a TLS session if a TLS session is
-already active. A server MUST NOT return the TLS extension in response to
-an EHLO command received after a TLS handshake has completed.
-
-
-6. Usage Example
-
-The following dialog illustrates how a client and server can start a TLS
-session:
-
-S: <waits for connection on TCP port 25>
-C: <opens connection>
-S: 220 mail.imc.org SMTP service ready
-C: EHLO mail.ietf.org
-S: 250-mail.imc.org offers a warm hug of welcome
-S: 250 STARTTLS
-C: STARTTLS
-S: 220 Go ahead
-C: <starts TLS negotiation>
-C & S: <negotiate a TLS session>
-C & S: <check result of negotiation>
-C: <continues by sending an SMTP command>
-. . .
-
-
-7. Security Considerations
-
-It should be noted that SMTP is not an end-to-end mechanism. Thus, if an
-SMTP client/server pair decide to add TLS privacy, they are not securing
-the transport from the originating mail user agent to the recipient.
-Further, because delivery of a single piece of mail may go between more
-than two SMTP servers, adding TLS privacy to one pair of servers does not
-mean that the entire SMTP chain has been made private. Further, just
-because an SMTP server can authenticate an SMTP client, it does not mean
-that the mail from the SMTP client was authenticated by the SMTP client
-when the client received it.
-
-Both the STMP client and server must check the result of the TLS
-negotiation to see whether acceptable authentication or privacy was
-achieved. Ignoring this step completely invalidates using TLS for security.
-The decision about whether acceptable authentication or privacy was
-achieved is made locally, is implementation-dependant, and is beyond the
-scope of this document.
-
-The SMTP client and server should note carefully the result of the TLS
-negotiation. If the negotiation results in no privacy, or if it results in
-privacy using algorithms or key lengths that are deemed not strong
-enough, or if the authentication is not good enough for either party, the
-client may choose to end the SMTP session with an immediate QUIT command,
-or the server may choose to not accept any more SMTP commands.
-
-A server announcing in an EHLO response that it uses a particular TLS
-protocol should not pose any security issues, since any use of TLS will be
-at least as secure as no use of TLS.
-
-A man-in-the-middle attack can be launched by deleting the "250 STARTTLS"
-response from the server. This would cause the client not to try to start a
-TLS session. An SMTP client can protect against this attack by recording
-the fact that a particular SMTP server offers TLS during one session and
-generating an alarm if it does not appear in the EHLO response for a later
-session. The lack of TLS during a session SHOULD NOT result in the bouncing
-of email, although it could result in delayed processing.
-
-Before the TLS handshake has begun, any protocol interactions are performed
-in the clear and may be modified by an active attacker. For this reason,
-clients and servers MUST discard any knowledge obtained prior to the start
-of the TLS handshake upon completion of the TLS handshake.
-
-The STARTTLS extension is not suitable for authenticating the author of an
-email message unless every hop in the delivery chain, including the
-submission to the first SMTP server, is authenticated. Another proposal
-[SMTP-AUTH] can be used to authenticate delivery and MIME security
-multiparts [MIME-SEC] can be used to authenticate the author of an email
-message. In addition, the [SMTP-AUTH] proposal offers simpler and more
-flexible options to authenticate an SMTP client and the SASL EXTERNAL
-mechanism [SASL] MAY be used in conjunction with the STARTTLS command to
-provide an authorization identity.
-
-
-A. References
-
-[RFC-821] "Simple Mail Transfer Protocol", RFC 821
-
-[RFC-1869] "SMTP Service Extensions", RFC 1869
-
-[RFC-2034] "SMTP Service Extension for Returning Enhanced Error Codes", RFC
-2034
-
-[SASL] "Simple Authentication and Security Layer (SASL)", RFC 2222
-
-[SMTP-AUTH] "SMTP Service Extension for Authentication",
-Internet Draft draft-myers-smtp-auth-xx.txt
-
-[TLS] "The TLS Protocol Version 1.0", draft-ietf-tls-protocol-xx.txt
-
-
-B. Changes from -08 to -09
-
-Removed previous appendix C about smtps port. A separate draft will cover
-that topic.
-
-C. Author's Address
-
-Paul Hoffman
-Internet Mail Consortium
-127 Segre Place
-Santa Cruz, CA  95060
-(408) 426-9827
-phoffman@imc.org
-
-
diff --git a/Documentation/en/I-D/draft-hoffman-smtp-ssl-10.txt b/Documentation/en/I-D/draft-hoffman-smtp-ssl-10.txt
deleted file mode 100644
index 9442e135..00000000
--- a/Documentation/en/I-D/draft-hoffman-smtp-ssl-10.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-A new Request for Comments is now available in online RFC libraries.
-
-
-        RFC 2487:
-
-        Title:	    SMTP Service Extension for Secure SMTP over TLS
-	Author(s):  P. Hoffman
-	Status:     Proposed Standard
-	Date:       January 1999
-        Mailbox:    phoffman@imc.org
-	Pages:      8
-        Characters: 15120
-        Updates/Obsoletes/See Also: None    
-        I-D Tag:    draft-hoffman-smtp-ssl-10.txt
-
-
-        URL:        ftp://ftp.isi.edu/in-notes/rfc2487.txt
-
-
-This document describes an extension to the SMTP service that allows
-an SMTP server and client to use transport-layer security to provide
-private, authenticated communication over the Internet. This gives
-SMTP agents the ability to protect some or all of their communications
-from eavesdroppers and attackers.
-
-This is now a Proposed Standard Protocol.
-
-This document specifies an Internet standards track protocol for
-the Internet community, and requests discussion and suggestions
-for improvements.  Please refer to the current edition of the
-"Internet Official Protocol Standards" (STD 1) for the
-standardization state and status of this protocol.  Distribution
-of this memo is unlimited.
- 
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
-help: ways_to_get_rfcs.  For example:
-
-        To: rfc-info@RFC-EDITOR.ORG
-        Subject: getting rfcs
-
-        help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.echo 
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
-Authors, for further information.
-
-
-Joyce K. Reynolds and Alegre Ramos
-USC/Information Sciences Institute
-
-
diff --git a/Documentation/en/I-D/draft-hoffman-stringprep-03.txt b/Documentation/en/I-D/draft-hoffman-stringprep-03.txt
deleted file mode 100644
index dff01f3e..00000000
--- a/Documentation/en/I-D/draft-hoffman-stringprep-03.txt
+++ /dev/null
@@ -1,3570 +0,0 @@
-Internet Draft                                          Paul Hoffman
-draft-hoffman-stringprep-03.txt                           IMC & VPNC
-May 17, 2002                                           Marc Blanchet
-Expires in six months                                       ViaGenie
-
-        Preparation of Internationalized Strings ("stringprep")
-
-Status of this memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-This document describes a framework for preparing text strings in order
-to increase the likelihood that string input and string comparison work
-in ways that make sense for typical users throughout the world. The
-stringprep protocol is useful for protocol identifier values, company
-and personal names, internationalized domain names, and other text
-strings.
-
-This document does not specify how protocols should prepare text
-strings. Protocols must create profiles of stringprep in order to fully
-specify the processing options.
-
-Table of contents
-
-1. Introduction
-  1.1 Terminology
-  1.2 Using stringprep in protocols
-2. Preparation Overview
-3. Mapping
-  3.1 Commonly mapped to nothing
-  3.2 Case folding
-4. Normalization
-5. Prohibited Output
-  5.1 Space characters
-  5.2 Control characters
-  5.3 Private use and replacement characters
-  5.4 Non-character code points
-  5.5 Surrogate codes
-  5.6 Inappropriate for plain text
-  5.7 Inappropriate for canonical representation
-  5.8 Change display properties
-  5.9 Tagging characters
-6. Unassigned Code Points in Stringprep Profiles
-  6.1 Categories of code points
-  6.2 Reasons for difference between stored strings and queries
-  6.3 Versions of applications and stored strings
-7. Security Considerations
-8. References
-A. Unicode repertoires
-  A.1 Unassigned code points in Unicode 3.1
-B. Mapping Tables
-  B.1 Commonly mapped to nothing
-  B.2 Mapping for lowercase used with NFKC
-  B.3 Mapping for lowercase used with no normalization
-C. Prohibition tables
-  C.1 Space characters
-  C.2 Control characters
-  C.3 Private use and replacement characters
-  C.4 Non-character code points
-  C.5 Surrogate codes
-  C.6 Inappropriate for plain text
-  C.7 Inappropriate for canonical representation
-  C.8 Change display properties
-  C.9 Tagging characters
-D. Acknowledgements
-E. IANA Considerations
-F. Author Contact Information
-
-
-1. Introduction
-
-Application programs can display text in many different ways. Similarly,
-a user can enter text into an application program in a myriad of
-fashions. Internationalized text (that is, text that is not restricted
-to the narrow set of US-ASCII characters) has many input and display
-behaviors that make it difficult to compare text in a consistent
-fashion.
-
-This document specifies a framework of text processing rules. Other
-protocols can create profiles of these rules; these profiles will
-allow users to enter internationalized text strings in applications and
-have the highest chance of getting the content of the strings correct.
-In this case, "correct" means that if two different people enter what
-they think is the same string into two different input mechanisms, the
-strings should match on a character-by-character basis.
-
-In addition to helping string matching, profiles of stringprep can also
-exclude characters that should not normally appear in text that is used
-in the protocol. The profile can prevent such characters by changing the
-characters to be excluded to other characters, by removing those
-characters, or by causing an error if the characters would appear in the
-output. For example, because the backspace character can cause
-unpredictable display results, a profile can specify that a string that
-would have a backspace character in it would cause an error.
-
-A profile of stringprep converts a single string of input characters to
-a string of output characters, or returns an error if the output string
-would contain a prohibited character. Stringprep profiles cannot both
-emit a string and return an error.
-
-Stringprep profiles cannot account for all of the variations that might
-occur or that a user might expect. In particular, a profile will not be
-able to account for choice of spellings in all languages for all scripts
-because the number of alternative spellings of words and phrases is
-immense. Users would probably expect all spelling equivalents to be made
-equivalent, or none of them to be. Examples of spelling equivalents
-include "theater" vs. "theatre", and "hemoglobin" vs.
-"h<U+00E6>moglobin" in American vs. British English. Other examples are
-simplified Chinese spellings of names (for example,
-"<U+7EDF><U+4E00><U+7801>") vs. the equivalent traditional Chinese
-spelling (for example, "<U+7D71><U+4E00><U+78BC>"). Language-specific
-equivalences such as "Aepfel" vs. "<U+00C4>pfel", which are sometimes
-considered equivalent in German, may not be considered equivalent in
-other languages.
-
-1.1 Terminology
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119.
-
-Note: A glossary of terms used in Unicode and ISO/IEC 10646 can be found
-in [Glossary]. Information on the 10646/Unicode character encoding model
-can be found in [CharModel].
-
-Character names in this document use the notation for code points and
-names from the Unicode Standard [Unicode3.1] and ISO/IEC 10646
-[ISO10646]. For example, the letter "a" may be represented as either
-"U+0061" or "LATIN SMALL LETTER A". In the lists of mappings and the
-prohibited characters, the "U+" is left off to make the lists easier to
-read. The comments for character ranges are shown in square brackets
-(such as "[CONTROL CHARACTERS]") and do not come from the standards.
-
-1.2 Using stringprep in protocols
-
-The stringprep protocol does not stand on its own; it has to be used by
-other protocols at precisely-defined places in those other protocols.
-For example, a protocol that has names that come from the entire ISO/IEC
-10646 [ISO10646] character repertoire might specify that only names that
-have been processed with a particular profile of stringprep are legal.
-Another example would be a protocol that does string comparison as a
-step in the protocol; that protocol might specify that such comparison
-is done only after processing the strings with a specific profile of
-stringprep.
-
-When developers wish to allow users as wide of a range of characters as
-possible in input text strings, they should, where possible, cause
-stringprep to convert characters from the input string to a canonical
-form instead of prohibiting them.
-
-Although it would be easy to use the stringprep process to "correct"
-perceived mis-features or bugs in the current character standards,
-stringprep profiles SHOULD NOT do so.
-
-A profile of stringprep can create tables different from those in the
-appendixes of this document, but it will be an exception when they do.
-The intention of stringprep is to define the tables and have the
-profiles of stringprep select among those defined tables.
-
-A profile of stringprep MUST include all of the following:
-
-- The intended applicability of the profile
-
-- The character repertoire that is the input and output to stringprep
-
-- The mapping tables from this document used (as described in Section 3)
-
-- Any additional mapping tables specific to the profile
-
-- The Unicode normalization used, if any (as described in Section 4)
-
-- The tables from this document of characters that are prohibited as
-output (as described in Section 5)
-
-- Any additional characters that are prohibited as output specific to
-the profile
-
-Each profile MUST state the character repertoire on which the profile
-will operate. Appendix A lists the Unicode repertoires that can be
-selected. No repertoire is ever complete, and it is expected that
-characters will be added to the Unicode repertoire for the foreseeable
-future. Section 6 of this document describes how to handle characters
-that are assigned in later versions of the Unicode repertories.
-Subsections of Appendix A also list unassigned code points for each
-repertoire.
-
-This profile lists the unassigned code points in the range 0 to 10FFFF
-for Unicode 3.1 in Appendix A. The list in Appendix A MUST be used by
-implementations of this specification. If there are any discrepancies
-between the list in Appendix A and the Unicode 3.1 specification, the
-list in Appendix A always takes precedence.
-
-Each profile of stringprep MUST be registered with IANA. The
-registration procedure is described in the IANA Considerations appendix;
-basically, the IESG must review each profile of stringprep. Protocol
-developers are strongly encouraged to look through the IANA profile
-registry when creating new profiles for stringprep, and to re-use logic
-from earlier profiles where possible in new profiles. In some cases, an
-existing profile can be reused by a different protocol.
-
-
-2. Preparation Overview
-
-The steps for preparing strings are:
-
-1) Map -- For each character in the input, check if it has a mapping
-and, if so, replace it with its mapping. This is described in Section 3.
-
-2) Normalize -- Possibly normalize the result of step 1 using Unicode
-normalization. This is described in Section 4.
-
-3) Look for prohibited output -- Check for any characters that are not
-allowed in the output. If any are found, return an error. This is
-described in Section 5.
-
-The above steps MUST be performed in the order given to comply with this
-specification.
-
-The mappings described in Section 3, and the optional Unicode
-normalization described in Section 4, can be one-to-none, one-to-one, or
-one-to-many. That is, some characters might be eliminated or replaced by
-more than one character, and the output of this step might be shorter or
-longer than the input. Because of this, the system using stringprep MUST
-be prepared to receive a longer or shorter string than the one input in
-the stringprep algorithm.
-
-
-3. Mapping
-
-Each character in the input stream MUST be checked against a mapping
-table. The mapping table SHOULD come from this document, although the
-mapping table MAY be added to or altered by the profile. The mapping
-tables are subsections of Appendix B.
-
-The lists in Appendix B MUST be used by implementations of this
-specification. If there are any discrepancies between the lists in
-Appendix B and subsections below, the lists in Appendix B always takes
-precedence.
-
-For any individual character, the mapping table MAY specify that a
-character be mapped to nothing, or mapped to one other character, or
-mapped to a string of other characters.
-
-Mapped characters are not re-scanned during the mapping step. That is,
-if character A at position X is mapped to character B, character B which
-is now at position X is not checked against the mapping table.
-
-3.1 Commonly mapped to nothing
-
-The following characters are simply deleted from the input (that is,
-they are mapped to nothing) because their presence or absence
-in protocol identifiers should not
-make two strings different. They are listed in Table B.1.
-
-Some characters are only useful in line-based text, and are otherwise
-invisible and ignored.
-
-00AD; SOFT HYPHEN
-1806; MONGOLIAN TODO SOFT HYPHEN
-200B; ZERO WIDTH SPACE
-FEFF; ZERO WIDTH NO-BREAK SPACE
-
-Variation selectors and cursive connectors select different glyphs, but
-do not bear semantics.
-
-180B; MONGOLIAN FREE VARIATION SELECTOR ONE
-180C; MONGOLIAN FREE VARIATION SELECTOR TWO
-180D; MONGOLIAN FREE VARIATION SELECTOR THREE
-200C; ZERO WIDTH NON-JOINER
-200D; ZERO WIDTH JOINER
-
-3.2 Case folding
-
-If a profile is going to map characters for case-insensitive comparison,
-that profile SHOULD map using either Appendix B.2 or Appendix B.3.
-Appendix B.2 is for profiles that also use Unicode normalization form
-KC, while Appendix  B.3 is for profiles that do not use Unicode
-normalization. These tables map from uppercase to lowercase character.
-Note that this could have been "change all lowercase characters into
-uppercase characters". However, the upper-to-lower folding was chosen
-because there is a tradition of using lowercase in current Internet
-applications and protocols.
-
-If a profile creates its own mapping tables for case folding, they
-SHOULD based on [UTR21], and SHOULD map from uppercase characters to
-lowercase. The "CaseFolding.txt" file from the Unicode database SHOULD
-be used to prepare the mapping table. The profile SHOULD do full case
-mapping (that is, using statuses C, F, and I).
-
-If the profile is using Unicode normalization form KC (as described in
-Section 4 of this document), it is important to note that there are some
-characters that do not have mappings in [UTR21] but still need
-processing. These characters include a few Greek characters and many
-symbols that contain Latin characters. The list of characters to add to
-the mapping table can determined by the following algorithm:
-
-b = NormalizeWithKC(Fold(a));
-c = NormalizeWithKC(Fold(b));
-if c is not the same as b, add a mapping for "a to c".
-
-Because NormalizeWithKC(Fold(c)) always equals c, the table is stable
-from that point on.
-
-Appendix B.3 is derived from the CaseFolding-3.txt file associated with
-Unicode 3.1; Appendix B.2 is based on Appendix B.3 with the additional
-characters added from the algorithm above.
-
-Authors of profiles of this document need to consider the effects of
-changing the mapping of any currently-assigned character when updating
-their profiles. Adding a new mapping for a currently-assigned character,
-or changing an existing mapping, could change the behavior that users
-see in both systems that have been updated and systems that have not
-been updated.
-
-4. Normalization
-
-The output of the mapping step is optionally normalized using one of the
-Unicode normalization forms, as described in [UAX15]. A profile can
-specify one of two options for Unicode normalization:
-
-- no normalization
-
-- Unicode normalization with form KC
-
-A profile MAY choose to do no normalization. However, such a profile can
-easily yield results that will be surprising to typical users, depending
-on the input mechanism they use. For example, some input mechanisms
-enter compatibility characters that look exactly like the underlying
-characters, but have different code points. Another example of where
-Unicode normalization helps create predictable results is with
-characters that have multiple combining diacritics: normalization orders
-those diacritics in a predictable fashion.
-
-On the other hand, Unicode normalization requires fairly large tables
-and somewhat complicated character reordering logic. The size and
-complexity should not be considered daunting except in the most
-restricted of environments, and needs to be weighed against the problems
-of user surprise from comparing unnormalized strings.
-Note that the tables used for normalization are not given in this
-document, but instead must be derived from the Unicode database, as
-described in [UAX15].
-
-There is a third form of normalization, Unicode normalization with form
-C. If a profile is going to use a Unicode normalization, it MUST use
-Unicode normalization form KC. Form KC maps many "compatibility
-characters" to their equivalents. Some user interface systems make it
-possible to enter compatibility characters instead of the base
-equivalents. Thus, using form KC instead of form C will cause more
-strings that users would expect to match to actually match.
-
-A profile that specifies Unicode normalization MUST use the
-normalization in [UAX15] that is associated with the version of the
-Unicode character set specified for the protocol.
-
-The composition process described in [UAX15] requires a fixed
-composition version of Unicode to ensure that strings normalized under
-one version of Unicode remain normalized under all future versions of
-Unicode.
-
-The IETF is relying on Unicode not to change the normalization of
-currently-assigned characters in future versions of normalization. If a
-future version of the normalization tables changes the normalized value
-of an existing character, authors of profiles of this document have to
-look at the changes very carefully before they update their
-normalization tables. Such a change could change the behavior that users
-see in both systems that have been updated and systems that have not
-been updated.
-
-5. Prohibited Output
-
-Before the text can be emitted, it MUST be checked for prohibited code
-points. There is a variety of prohibited code points, as described in
-this section. A profile of this document MAY use all or some of the
-tables in Appendix C.
-
-The stringprep process never emits both an error and a string. If an
-error is detected during the checking for prohibited code points, only
-an error is returned.
-
-Note that the subsections below describe how the tables in Appendix C
-were formed. They are here for people who want to understand more, but
-they should be ignored by implementors. Implementations that use tables
-MUST map based on the tables themselves, not based on the descriptions
-in this section of how the tables were created.
-
-The lists in Appendix C MUST be used by implementations of this
-specification. If there are any discrepancies between the lists in
-Appendix C and subsections below, the lists in Appendix C always takes
-precedence.
-
-Some code points listed in one section would also appear in other
-sections.
-
-It is important to note that a profile of this document MAY prohibit
-additional characters. For example, a protocol might treat an ASCII
-character as special and therefore not allow it in names. Specifically,
-the tables in Appendix C do not contain any ASCII characters, so it is
-very likely that profiles will either add those characters to the tables
-as they are used in the profile, or that the protocols themselves will
-prohibit the characters.
-
-Each subsection of this section has a matching subsection in Appendix
-C. For example, the characters listed in section 5.1 are listed in
-Appendix C.1.
-
-5.1 Space characters
-
-Space characters can make accurate visual transcription of names nearly
-impossible and could lead to user entry errors in many ways. Note that
-the ASCII space character (U+0020) is not included in the list below.
-
-00A0; NO-BREAK SPACE
-1680; OGHAM SPACE MARK
-2000; EN QUAD
-2001; EM QUAD
-2002; EN SPACE
-2003; EM SPACE
-2004; THREE-PER-EM SPACE
-2005; FOUR-PER-EM SPACE
-2006; SIX-PER-EM SPACE
-2007; FIGURE SPACE
-2008; PUNCTUATION SPACE
-2009; THIN SPACE
-200A; HAIR SPACE
-202F; NARROW NO-BREAK SPACE
-3000; IDEOGRAPHIC SPACE
-
-5.2 Control characters
-
-Control characters (or characters with control function) cannot be seen
-and can cause unpredictable results when displayed. Note that additional
-control characters (U+0000 through U+001F, and U+007F) are not listed
-below.
-
-0080-009F; [CONTROL CHARACTERS]
-070F; SYRIAC ABBREVIATION MARK
-180E; MONGOLIAN VOWEL SEPARATOR
-2028; LINE SEPARATOR
-2029; PARAGRAPH SEPARATOR
-206A-206F; [CONTROL CHARACTERS]
-FFF9-FFFC; [CONTROL CHARACTERS]
-1D173-1D17A; [MUSICAL CONTROL CHARACTERS]
-
-5.3 Private use and replacement characters
-
-Because private-use characters do not have defined meanings, they are
-likely to be prohibited. The private-use characters are:
-
-E000-F8FF; [PRIVATE USE, PLANE 0]
-F0000-FFFFD; [PRIVATE USE, PLANE 15]
-100000-10FFFD; [PRIVATE USE, PLANE 16]
-
-Although the replacement character (U+FFFD) might be used when a name is
-displayed,  it doesn't make sense for it to be part of the name itself.
-It is often displayed by renderers to indicate "there would be
-some character here, but it cannot be rendered". For example, on a
-computer with no Asian fonts, a name with three ideographs might be
-rendered with three replacement characters.
-
-
-FFFD; REPLACEMENT CHARACTER
-
-5.4 Non-character code points
-
-Non-character code points are code points that have been allocated in
-ISO/IEC 10646 but are not characters. Because they are already assigned,
-they are guaranteed not to later change into characters.
-
-FDD0-FDEF; [NONCHARACTER CODE POINTS]
-FFFE-FFFF; [NONCHARACTER CODE POINTS]
-1FFFE-1FFFF; [NONCHARACTER CODE POINTS]
-2FFFE-2FFFF; [NONCHARACTER CODE POINTS]
-3FFFE-3FFFF; [NONCHARACTER CODE POINTS]
-4FFFE-4FFFF; [NONCHARACTER CODE POINTS]
-5FFFE-5FFFF; [NONCHARACTER CODE POINTS]
-6FFFE-6FFFF; [NONCHARACTER CODE POINTS]
-7FFFE-7FFFF; [NONCHARACTER CODE POINTS]
-8FFFE-8FFFF; [NONCHARACTER CODE POINTS]
-9FFFE-9FFFF; [NONCHARACTER CODE POINTS]
-AFFFE-AFFFF; [NONCHARACTER CODE POINTS]
-BFFFE-BFFFF; [NONCHARACTER CODE POINTS]
-CFFFE-CFFFF; [NONCHARACTER CODE POINTS]
-DFFFE-DFFFF; [NONCHARACTER CODE POINTS]
-EFFFE-EFFFF; [NONCHARACTER CODE POINTS]
-FFFFE-FFFFF; [NONCHARACTER CODE POINTS]
-10FFFE-10FFFF; [NONCHARACTER CODE POINTS]
-
-The non-character code points are listed in the PropList.txt file from the
-Unicode database.
-
-5.5 Surrogate codes
-
-The following code points are permanently reserved for use as surrogate
-code values in the UTF-16 encoding, will never be assigned to
-characters in the Unicode repertoire, and are therefore prohibited:
-
-D800-DFFF; [SURROGATE CODES]
-
-5.6 Inappropriate for plain text
-
-The following characters do not appear in regular text.
-
-FFF9; INTERLINEAR ANNOTATION ANCHOR
-FFFA; INTERLINEAR ANNOTATION SEPARATOR
-FFFB; INTERLINEAR ANNOTATION TERMINATOR
-FFFC; OBJECT REPLACEMENT CHARACTER
-
-5.7 Inappropriate for canonical representation
-
-The ideographic description characters allow different sequences of
-characters to be rendered the same way, which makes them inappropriate
-for names that have to have a single canonical representation.
-
-2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS]
-
-5.8 Change display properties
-
-The following characters, some of which are deprecated in Unicode,
-can cause changes in display or the order in which characters appear
-when rendered.
-
-200E; LEFT-TO-RIGHT MARK
-200F; RIGHT-TO-LEFT MARK
-202A; LEFT-TO-RIGHT EMBEDDING
-202B; RIGHT-TO-LEFT EMBEDDING
-202C; POP DIRECTIONAL FORMATTING
-202D; LEFT-TO-RIGHT OVERRIDE
-202E; RIGHT-TO-LEFT OVERRIDE
-206A; INHIBIT SYMMETRIC SWAPPING
-206B; ACTIVATE SYMMETRIC SWAPPING
-206C; INHIBIT ARABIC FORM SHAPING
-206D; ACTIVATE ARABIC FORM SHAPING
-206E; NATIONAL DIGIT SHAPES
-206F; NOMINAL DIGIT SHAPES
-
-5.9 Tagging characters
-
-The following characters are used for tagging text and are invisible.
-
-E0001; LANGUAGE TAG
-E0020-E007F; [TAGGING CHARACTERS]
-
-
-6. Unassigned Code Points in Stringprep Profiles
-
-This section describes two different types of strings in typical
-protocols where internationalized strings are used: "stored strings" and
-"queries". Of course, different Internet protocols use strings very
-differently, so these terms cannot be used exactly in every protocol
-that needs to use stringprep. In general, "stored strings" are strings
-that are used in protocol identifiers and named entities, such as names
-in digital certificates and DNS domain name parts.
-"Queries" are strings that are used to match against strings that are
-stored identifiers, such as user-entered names for digital certificate
-authorities and DNS lookups.
-
-All code points not assigned in the character repertoire named in a
-stringprep profile are called "unassigned code points". Stored strings
-using the profile MUST NOT contain any unassigned code points. Queries
-for matching strings MAY contain unassigned code points. Note that this
-is the only part of this document where the requirements for queries
-differs from the requirements for stored strings.
-
-Using two different policies for where unassigned code points can appear
-removes the need for versioning in protocols that use stringprep
-profiles. This is very useful since it makes the overall processing
-simpler and does not impose a "protocol" to handle versioning. It is
-expected that the ISO/IEC 10646 and Unicode repertoires will be updated
-fairly frequently; at the time that this document is being written, it
-has happened approximately once a year. Each time a new version of a
-repertoire appears, a new version of a profile MAY be created. Some end
-users will want to use the new code points as soon as they are defined.
-
-The list of unassigned code points MUST be given in a profile, and that
-list MUST be used by implementations of the profile.
-
-The goal of the requirements in this section is to prevent comparisons
-between two strings that were both permitted to contain unassigned code
-points. When two strings X and Y are compared and string X was prepared
-in a way that permits unassigned code points, a negative result to the
-comparison is not definitive; it's possible that the strings don't match
-even though they would match if a more recent version of the profile
-were used for Y. However, if both X and Y were prepared in a way that
-permits unassigned code points, something worse can happen: even a
-positive result for the comparison is not definitive. It is possible
-that the strings do match even though they would not match if a more
-recent version of the profile were used (one that prohibits a code point
-appearing in both X and Y).
-
-Due to the way that versioning is handled in this section, stored
-strings that are embedded in structures that cannot be changed (such as
-the signed parts of digital certificates) MUST NOT contain any
-unassigned code points.
-
-6.1 Categories of code points
-
-Each code point in a repertoire named by a profile of stringprep can be
-categorized by how it acts in the process described in earlier sections
-of this document:
-
-AO      Code points that can be in the output
-
-MN      Code points that cannot be in the output because they never
-        appear as output from mapping or normalization
-
-D       Code points that cannot be in the output because they are
-        disallowed in the prohibition step
-
-U       Unassigned code points
-
-A subsequent version of a profile that references a newer version of a
-repertoire with new code points will inherently have some code points
-move from category U to either D, MN, or AO. For backwards
-compatibility, a subsequent version of a profile MUST NOT move code
-points from any other category. That is, current AO, MN, or D code
-points MUST NOT ever change to a different category.
-
-Stored strings MUST NOT contain any code points outside of
-AO for the latest version of a profile. That is, they are forbidden to
-contain code points from the MN, D, or U categories.
-
-Applications creating queries MUST treat U code points as if they were
-AO when preparing the query to be entered in the process described by a
-profile of stringprep. Those applications MAY optionally have a
-preprocessor that provide stricter checks: treating unassigned code
-points in the input as errors, or warning the user about the fact that
-the code point is unassigned in the version of a profile that the
-software is based on; such a choice is a local matter for the software.
-
-6.2 Reasons for difference between stored strings and queries
-
-Different software using different versions of a stringprep profile need
-to interoperate with maximal compatibility. The scheme described in this
-section (stored strings MUST NOT contain unassigned code points,
-queries MAY include unassigned code points) allows that compatibility
-without introducing any known security or interoperability issues.
-
-The list below shows what happens if a query contains a code point
-from category U that is allowed in a newer version of a profile. The
-query either matches the string that was intended, or matches no
-string at all. In this list, the query comes from an application using
-version "oldVersion" of a profile, the stored string was created using
-version "newVersion" of the same profile, and the code point X was in
-category U in oldVersion, and has changed category to AO, MN, or D.
-There are 3 possible scenarios:
-
-1. X is assigned to AO -- In newVersion, X is in category AO. Because
-the application passed X through, it gets back a positive match with the
-stored string. There is one exceptional case, where X is a combining
-mark.
-
-The order of combining marks is normalized, so if another combining mark
-Y has a lower combining class than X then XY will be put in the
-canonical order YX. (Unassigned code points are never reordered, so this
-doesn't happen in oldVersion). If the query contains YX, the query
-will get positive match with the stored string. However, no string can be
-stored with XY, so a query with XY will get a negative
-answer to the test for matching.
-
-2. X is assigned to MN -- In newVersion, X is normalized to code point
-"nX" and therefore X is now put in category MN. This cannot exist in any
-stored string, so any query containing X will get a negative
-answer to the test for matching. Note, however, if the query had
-contained the letter nX, it would have positively matched.
-
-3. X is assigned to D -- In newVersion, X is in category D. This cannot
-exist in any stored string, so any query containing X will
-get a negative answer to the test for matching.
-
-In none of the cases does the query get data for a stored string other
-than the one it actually tried to match against.
-
-The processing in this document is always stable. If a string S is the
-result of processing on newVersion, then it will remain the same when
-processed on oldVersion.
-
-6.3 Versions of applications and stored strings
-
-Another way to see that this versioning system works is to compare what
-happens when an application uses a newer or older version of this
-document.
-
-Newer query application -- Suppose that a querying application is
-using version newVersion and the stored string was created using version
-oldVersion. This case is simple: there will be no characters in the
-stored string that cannot be queried by the application because the
-new profile uses a superset of the code points used for making the
-stored string.
-
-Newer stored string -- Suppose that an querying application is using
-oldVersion and the stored string was created using a profile that uses
-newVersion. Because the querying application passed through any
-unassigned code points, the user can query on stored strings that use
-code points in newVersion. No stored strings can have code points that
-are unassigned in newVersion, since that is illegal. In this case, the
-querying application has to enter the unassigned code points in the
-proper order, and has to use unassigned code points that would make it
-through both the mapping and the normalization steps.
-
-
-7. References
-
-7.1 Normative references
-
-[UAX15] Mark Davis and Martin Duerst. Unicode Standard Annex #15:
-Unicode Normalization Forms, Version 3.1.0.
-<http://www.unicode.org/unicode/reports/tr15/tr15-21.html>.
-
-7.2 Informative references
-
-[CharModel] Unicode Technical Report;17, Character Encoding Model.
-<http://www.unicode.org/unicode/reports/tr17/>.
-
-[Glossary] Unicode Glossary, <http://www.unicode.org/glossary/>.
-
-[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels", March 1997, RFC 2119.
-
-[RFC2434] Thomas Narten and Harald Alvestrand, "Guidelines for IANA
-Considerations", October 1998, RFC 2434.
-
-[Unicode3.1] The Unicode Standard, Version 3.1.0: The Unicode
-Consortium. The Unicode Standard, Version 3.0. Reading, MA,
-Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5, as amended
-by: Unicode Standard Annex #27: Unicode 3.1
-<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>.
-
-[UTR21] Mark Davis. Case Mappings. Unicode Technical Report 21.
-<http://www.unicode.org/unicode/reports/tr21/>.
-
-
-8. Security Considerations
-
-The Unicode and ISO/IEC 10646 repertoires have many characters that look
-similar. In many cases, users of security protocols might do visual
-matching, such as when comparing the names of trusted third parties.
-Because it is impossible to map similar-looking characters without a
-great deal of context such as knowing the fonts used,
-stringprep does nothing to map similar-looking characters together nor
-to prohibit some characters because they look like others.
-
-
-9. IANA Considerations
-
-Stringprep profiles MUST have IETF consensus as described in [RFC 2434].
-Each profile MUST be reviewed by the IESG before it is registered. The
-IESG MAY change a profile before registration.
-
-IANA will start a registry of stringprep profiles. The registry will be
-a single text file that lists the known profiles. Each entry in the
-registry will have three fields:
-
-- Profile name
-
-- RFC in which the profile is defined
-
-- Indicator whether or not this is the most current version of the
-profile
-
-Each version of a profile will remain listed in the registry forever.
-That is, if a new version of a profile supersedes an earlier version,
-both versions will continue to be listed in the registry, but the
-current version indicator will be turned off for the earlier version and
-turned on for the newer version.
-
-
-10. Acknowledgements
-
-Many people from the IETF IDN Working Group and the Unicode Technical
-Committee contributed ideas that went into the first draft of this
-document. Mark Davis and Patrik Faltstrom were particularly helpful in
-some of the ideas, such as the versioning description.
-
-The IDN namprep design team made many useful changes to the first
-draft. That team and its advisors include:
-
-Asmus Freytag
-Cathy Wissink
-Francois Yergeau
-James Seng
-Marc Blanchet
-Mark Davis
-Martin Duerst
-Patrik Faltstrom
-Paul Hoffman
-
-Additional significant improvements were proposed by:
-
-Jonathan Rosenne
-Kent Karlsson
-Scott Hollenbeck
-Dave Crocker
-Erik Nordmark
-
-
-11. Author Contact Information
-
-Paul Hoffman
-Internet Mail Consortium and VPN Consortium
-127 Segre Place
-Santa Cruz, CA  95060 USA
-paul.hoffman@imc.org and paul.hoffman@vpnc.org
-
-Marc Blanchet
-Viagenie inc.
-2875 boul. Laurier, bur. 300
-Ste-Foy, Quebec, Canada, G1V 2M2
-Marc.Blanchet@viagenie.qc.ca
-
-
-A. Unicode repertoires
-
-The following is the only repertoire covered in this document:
-
-Unicode 3.1, as defined in [Unicode3.1].
-
-A.1 Unassigned code points in Unicode 3.1
-
------ Start Table A.1 -----
-0220-0221
-0234-024F
-02AE-02AF
-02EF-02FF
-034F-035F
-0363-0373
-0376-0379
-037B-037D
-037F-0383
-038B
-038D
-03A2
-03CF
-03D8-03D9
-03F6-03FF
-0487
-048A-048B
-04C5-04C6
-04C9-04CA
-04CD-04CF
-04F6-04F7
-04FA-0530
-0557-0558
-0560
-0588
-058B-0590
-05A2
-05BA
-05C5-05CF
-05EB-05EF
-05F5-060B
-060D-061A
-061C-061E
-0620
-063B-063F
-0656-065F
-066E-066F
-06EE-06EF
-06FF
-070E
-072D-072F
-074B-077F
-07B1-0900
-0904
-093A-093B
-094E-094F
-0955-0957
-0971-0980
-0984
-098D-098E
-0991-0992
-09A9
-09B1
-09B3-09B5
-09BA-09BB
-09BD
-09C5-09C6
-09C9-09CA
-09CE-09D6
-09D8-09DB
-09DE
-09E4-09E5
-09FB-0A01
-0A03-0A04
-0A0B-0A0E
-0A11-0A12
-0A29
-0A31
-0A34
-0A37
-0A3A-0A3B
-0A3D
-0A43-0A46
-0A49-0A4A
-0A4E-0A58
-0A5D
-0A5F-0A65
-0A75-0A80
-0A84
-0A8C
-0A8E
-0A92
-0AA9
-0AB1
-0AB4
-0ABA-0ABB
-0AC6
-0ACA
-0ACE-0ACF
-0AD1-0ADF
-0AE1-0AE5
-0AF0-0B00
-0B04
-0B0D-0B0E
-0B11-0B12
-0B29
-0B31
-0B34-0B35
-0B3A-0B3B
-0B44-0B46
-0B49-0B4A
-0B4E-0B55
-0B58-0B5B
-0B5E
-0B62-0B65
-0B71-0B81
-0B84
-0B8B-0B8D
-0B91
-0B96-0B98
-0B9B
-0B9D
-0BA0-0BA2
-0BA5-0BA7
-0BAB-0BAD
-0BB6
-0BBA-0BBD
-0BC3-0BC5
-0BC9
-0BCE-0BD6
-0BD8-0BE6
-0BF3-0C00
-0C04
-0C0D
-0C11
-0C29
-0C34
-0C3A-0C3D
-0C45
-0C49
-0C4E-0C54
-0C57-0C5F
-0C62-0C65
-0C70-0C81
-0C84
-0C8D
-0C91
-0CA9
-0CB4
-0CBA-0CBD
-0CC5
-0CC9
-0CCE-0CD4
-0CD7-0CDD
-0CDF
-0CE2-0CE5
-0CF0-0D01
-0D04
-0D0D
-0D11
-0D29
-0D3A-0D3D
-0D44-0D45
-0D49
-0D4E-0D56
-0D58-0D5F
-0D62-0D65
-0D70-0D81
-0D84
-0D97-0D99
-0DB2
-0DBC
-0DBE-0DBF
-0DC7-0DC9
-0DCB-0DCE
-0DD5
-0DD7
-0DE0-0DF1
-0DF5-0E00
-0E3B-0E3E
-0E5C-0E80
-0E83
-0E85-0E86
-0E89
-0E8B-0E8C
-0E8E-0E93
-0E98
-0EA0
-0EA4
-0EA6
-0EA8-0EA9
-0EAC
-0EBA
-0EBE-0EBF
-0EC5
-0EC7
-0ECE-0ECF
-0EDA-0EDB
-0EDE-0EFF
-0F48
-0F6B-0F70
-0F8C-0F8F
-0F98
-0FBD
-0FCD-0FCE
-0FD0-0FFF
-1022
-1028
-102B
-1033-1035
-103A-103F
-105A-109F
-10C6-10CF
-10F7-10FA
-10FC-10FF
-115A-115E
-11A3-11A7
-11FA-11FF
-1207
-1247
-1249
-124E-124F
-1257
-1259
-125E-125F
-1287
-1289
-128E-128F
-12AF
-12B1
-12B6-12B7
-12BF
-12C1
-12C6-12C7
-12CF
-12D7
-12EF
-130F
-1311
-1316-1317
-131F
-1347
-135B-1360
-137D-139F
-13F5-1400
-1677-167F
-169D-169F
-16F1-177F
-17DD-17DF
-17EA-17FF
-180F
-181A-181F
-1878-187F
-18AA-1DFF
-1E9C-1E9F
-1EFA-1EFF
-1F16-1F17
-1F1E-1F1F
-1F46-1F47
-1F4E-1F4F
-1F58
-1F5A
-1F5C
-1F5E
-1F7E-1F7F
-1FB5
-1FC5
-1FD4-1FD5
-1FDC
-1FF0-1FF1
-1FF5
-1FFF
-2047
-204E-2069
-2071-2073
-208F-209F
-20B0-20CF
-20E4-20FF
-213B-2152
-2184-218F
-21F4-21FF
-22F2-22FF
-237C
-239B-23FF
-2427-243F
-244B-245F
-24EB-24FF
-2596-259F
-25F8-25FF
-2614-2618
-2672-2700
-2705
-270A-270B
-2728
-274C
-274E
-2753-2755
-2757
-275F-2760
-2768-2775
-2795-2797
-27B0
-27BF-27FF
-2900-2E7F
-2E9A
-2EF4-2EFF
-2FD6-2FEF
-2FFC-2FFF
-303B-303D
-3040
-3095-3098
-309F-30A0
-30FF-3104
-312D-3130
-318F
-31B8-31FF
-321D-321F
-3244-325F
-327C-327E
-32B1-32BF
-32CC-32CF
-32FF
-3377-337A
-33DE-33DF
-33FF
-4DB6-4DFF
-9FA6-9FFF
-A48D-A48F
-A4A2-A4A3
-A4B4
-A4C1
-A4C5
-A4C7-ABFF
-D7A4-D7FF
-FA2E-FAFF
-FB07-FB12
-FB18-FB1C
-FB37
-FB3D
-FB3F
-FB42
-FB45
-FBB2-FBD2
-FD40-FD4F
-FD90-FD91
-FDC8-FDCF
-FDFC-FE1F
-FE24-FE2F
-FE45-FE48
-FE53
-FE67
-FE6C-FE6F
-FE73
-FE75
-FEFD-FEFE
-FF00
-FF5F-FF60
-FFBF-FFC1
-FFC8-FFC9
-FFD0-FFD1
-FFD8-FFD9
-FFDD-FFDF
-FFE7
-FFEF-FFF8
-10000-102FF
-1031F
-10324-1032F
-1034B-103FF
-10426-10427
-1044E-1CFFF
-1D0F6-1D0FF
-1D127-1D129
-1D1DE-1D3FF
-1D455
-1D49D
-1D4A0-1D4A1
-1D4A3-1D4A4
-1D4A7-1D4A8
-1D4AD
-1D4BA
-1D4BC
-1D4C1
-1D4C4
-1D506
-1D50B-1D50C
-1D515
-1D51D
-1D53A
-1D53F
-1D545
-1D547-1D549
-1D551
-1D6A4-1D6A7
-1D7CA-1D7CD
-1D800-1FFFD
-2A6D7-2F7FF
-2FA1E-2FFFD
-30000-3FFFD
-40000-4FFFD
-50000-5FFFD
-60000-6FFFD
-70000-7FFFD
-80000-8FFFD
-90000-9FFFD
-A0000-AFFFD
-B0000-BFFFD
-C0000-CFFFD
-D0000-DFFFD
-E0000
-E0002-E001F
-E0080-EFFFD
------ End Table A.1 -----
-
-B. Mapping Tables
-
-The following is the mapping table from Section 3. The table has three
-columns:
-- the code point that is mapped from
-- the zero or more code points that it is mapped to
-- the reason for the mapping
-The columns are separated by semicolons. Note that the second column may
-be empty, or it may have one code point, or it may have more than one
-code point, with each code point separated by a space.
-
-B.1 Commonly mapped to nothing
-
------ Start Table B.1 -----
-00AD; ; Map to nothing
-1806; ; Map to nothing
-180B; ; Map to nothing
-180C; ; Map to nothing
-180D; ; Map to nothing
-200B; ; Map to nothing
-200C; ; Map to nothing
-200D; ; Map to nothing
-FEFF; ; Map to nothing
------ End Table B.1 -----
-
-B.2 Mapping for lowercase used with NFKC
-
------ Start Table B.2 -----
-0041; 0061; Case map
-0042; 0062; Case map
-0043; 0063; Case map
-0044; 0064; Case map
-0045; 0065; Case map
-0046; 0066; Case map
-0047; 0067; Case map
-0048; 0068; Case map
-0049; 0069; Case map
-004A; 006A; Case map
-004B; 006B; Case map
-004C; 006C; Case map
-004D; 006D; Case map
-004E; 006E; Case map
-004F; 006F; Case map
-0050; 0070; Case map
-0051; 0071; Case map
-0052; 0072; Case map
-0053; 0073; Case map
-0054; 0074; Case map
-0055; 0075; Case map
-0056; 0076; Case map
-0057; 0077; Case map
-0058; 0078; Case map
-0059; 0079; Case map
-005A; 007A; Case map
-00B5; 03BC; Case map
-00C0; 00E0; Case map
-00C1; 00E1; Case map
-00C2; 00E2; Case map
-00C3; 00E3; Case map
-00C4; 00E4; Case map
-00C5; 00E5; Case map
-00C6; 00E6; Case map
-00C7; 00E7; Case map
-00C8; 00E8; Case map
-00C9; 00E9; Case map
-00CA; 00EA; Case map
-00CB; 00EB; Case map
-00CC; 00EC; Case map
-00CD; 00ED; Case map
-00CE; 00EE; Case map
-00CF; 00EF; Case map
-00D0; 00F0; Case map
-00D1; 00F1; Case map
-00D2; 00F2; Case map
-00D3; 00F3; Case map
-00D4; 00F4; Case map
-00D5; 00F5; Case map
-00D6; 00F6; Case map
-00D8; 00F8; Case map
-00D9; 00F9; Case map
-00DA; 00FA; Case map
-00DB; 00FB; Case map
-00DC; 00FC; Case map
-00DD; 00FD; Case map
-00DE; 00FE; Case map
-00DF; 0073 0073; Case map
-0100; 0101; Case map
-0102; 0103; Case map
-0104; 0105; Case map
-0106; 0107; Case map
-0108; 0109; Case map
-010A; 010B; Case map
-010C; 010D; Case map
-010E; 010F; Case map
-0110; 0111; Case map
-0112; 0113; Case map
-0114; 0115; Case map
-0116; 0117; Case map
-0118; 0119; Case map
-011A; 011B; Case map
-011C; 011D; Case map
-011E; 011F; Case map
-0120; 0121; Case map
-0122; 0123; Case map
-0124; 0125; Case map
-0126; 0127; Case map
-0128; 0129; Case map
-012A; 012B; Case map
-012C; 012D; Case map
-012E; 012F; Case map
-0130; 0069; Case map
-0131; 0069; Case map
-0132; 0133; Case map
-0134; 0135; Case map
-0136; 0137; Case map
-0139; 013A; Case map
-013B; 013C; Case map
-013D; 013E; Case map
-013F; 0140; Case map
-0141; 0142; Case map
-0143; 0144; Case map
-0145; 0146; Case map
-0147; 0148; Case map
-0149; 02BC 006E; Case map
-014A; 014B; Case map
-014C; 014D; Case map
-014E; 014F; Case map
-0150; 0151; Case map
-0152; 0153; Case map
-0154; 0155; Case map
-0156; 0157; Case map
-0158; 0159; Case map
-015A; 015B; Case map
-015C; 015D; Case map
-015E; 015F; Case map
-0160; 0161; Case map
-0162; 0163; Case map
-0164; 0165; Case map
-0166; 0167; Case map
-0168; 0169; Case map
-016A; 016B; Case map
-016C; 016D; Case map
-016E; 016F; Case map
-0170; 0171; Case map
-0172; 0173; Case map
-0174; 0175; Case map
-0176; 0177; Case map
-0178; 00FF; Case map
-0179; 017A; Case map
-017B; 017C; Case map
-017D; 017E; Case map
-017F; 0073; Case map
-0181; 0253; Case map
-0182; 0183; Case map
-0184; 0185; Case map
-0186; 0254; Case map
-0187; 0188; Case map
-0189; 0256; Case map
-018A; 0257; Case map
-018B; 018C; Case map
-018E; 01DD; Case map
-018F; 0259; Case map
-0190; 025B; Case map
-0191; 0192; Case map
-0193; 0260; Case map
-0194; 0263; Case map
-0196; 0269; Case map
-0197; 0268; Case map
-0198; 0199; Case map
-019C; 026F; Case map
-019D; 0272; Case map
-019F; 0275; Case map
-01A0; 01A1; Case map
-01A2; 01A3; Case map
-01A4; 01A5; Case map
-01A6; 0280; Case map
-01A7; 01A8; Case map
-01A9; 0283; Case map
-01AC; 01AD; Case map
-01AE; 0288; Case map
-01AF; 01B0; Case map
-01B1; 028A; Case map
-01B2; 028B; Case map
-01B3; 01B4; Case map
-01B5; 01B6; Case map
-01B7; 0292; Case map
-01B8; 01B9; Case map
-01BC; 01BD; Case map
-01C4; 01C6; Case map
-01C5; 01C6; Case map
-01C7; 01C9; Case map
-01C8; 01C9; Case map
-01CA; 01CC; Case map
-01CB; 01CC; Case map
-01CD; 01CE; Case map
-01CF; 01D0; Case map
-01D1; 01D2; Case map
-01D3; 01D4; Case map
-01D5; 01D6; Case map
-01D7; 01D8; Case map
-01D9; 01DA; Case map
-01DB; 01DC; Case map
-01DE; 01DF; Case map
-01E0; 01E1; Case map
-01E2; 01E3; Case map
-01E4; 01E5; Case map
-01E6; 01E7; Case map
-01E8; 01E9; Case map
-01EA; 01EB; Case map
-01EC; 01ED; Case map
-01EE; 01EF; Case map
-01F0; 006A 030C; Case map
-01F1; 01F3; Case map
-01F2; 01F3; Case map
-01F4; 01F5; Case map
-01F6; 0195; Case map
-01F7; 01BF; Case map
-01F8; 01F9; Case map
-01FA; 01FB; Case map
-01FC; 01FD; Case map
-01FE; 01FF; Case map
-0200; 0201; Case map
-0202; 0203; Case map
-0204; 0205; Case map
-0206; 0207; Case map
-0208; 0209; Case map
-020A; 020B; Case map
-020C; 020D; Case map
-020E; 020F; Case map
-0210; 0211; Case map
-0212; 0213; Case map
-0214; 0215; Case map
-0216; 0217; Case map
-0218; 0219; Case map
-021A; 021B; Case map
-021C; 021D; Case map
-021E; 021F; Case map
-0222; 0223; Case map
-0224; 0225; Case map
-0226; 0227; Case map
-0228; 0229; Case map
-022A; 022B; Case map
-022C; 022D; Case map
-022E; 022F; Case map
-0230; 0231; Case map
-0232; 0233; Case map
-0345; 03B9; Case map
-037A; 0020 03B9; Additional folding
-0386; 03AC; Case map
-0388; 03AD; Case map
-0389; 03AE; Case map
-038A; 03AF; Case map
-038C; 03CC; Case map
-038E; 03CD; Case map
-038F; 03CE; Case map
-0390; 03B9 0308 0301; Case map
-0391; 03B1; Case map
-0392; 03B2; Case map
-0393; 03B3; Case map
-0394; 03B4; Case map
-0395; 03B5; Case map
-0396; 03B6; Case map
-0397; 03B7; Case map
-0398; 03B8; Case map
-0399; 03B9; Case map
-039A; 03BA; Case map
-039B; 03BB; Case map
-039C; 03BC; Case map
-039D; 03BD; Case map
-039E; 03BE; Case map
-039F; 03BF; Case map
-03A0; 03C0; Case map
-03A1; 03C1; Case map
-03A3; 03C3; Case map
-03A4; 03C4; Case map
-03A5; 03C5; Case map
-03A6; 03C6; Case map
-03A7; 03C7; Case map
-03A8; 03C8; Case map
-03A9; 03C9; Case map
-03AA; 03CA; Case map
-03AB; 03CB; Case map
-03B0; 03C5 0308 0301; Case map
-03C2; 03C3; Case map
-03D0; 03B2; Case map
-03D1; 03B8; Case map
-03D2; 03C5; Additional folding
-03D3; 03CD; Additional folding
-03D4; 03CB; Additional folding
-03D5; 03C6; Case map
-03D6; 03C0; Case map
-03DA; 03DB; Case map
-03DC; 03DD; Case map
-03DE; 03DF; Case map
-03E0; 03E1; Case map
-03E2; 03E3; Case map
-03E4; 03E5; Case map
-03E6; 03E7; Case map
-03E8; 03E9; Case map
-03EA; 03EB; Case map
-03EC; 03ED; Case map
-03EE; 03EF; Case map
-03F0; 03BA; Case map
-03F1; 03C1; Case map
-03F2; 03C3; Case map
-03F4; 03B8; Case map
-03F5; 03B5; Case map
-0400; 0450; Case map
-0401; 0451; Case map
-0402; 0452; Case map
-0403; 0453; Case map
-0404; 0454; Case map
-0405; 0455; Case map
-0406; 0456; Case map
-0407; 0457; Case map
-0408; 0458; Case map
-0409; 0459; Case map
-040A; 045A; Case map
-040B; 045B; Case map
-040C; 045C; Case map
-040D; 045D; Case map
-040E; 045E; Case map
-040F; 045F; Case map
-0410; 0430; Case map
-0411; 0431; Case map
-0412; 0432; Case map
-0413; 0433; Case map
-0414; 0434; Case map
-0415; 0435; Case map
-0416; 0436; Case map
-0417; 0437; Case map
-0418; 0438; Case map
-0419; 0439; Case map
-041A; 043A; Case map
-041B; 043B; Case map
-041C; 043C; Case map
-041D; 043D; Case map
-041E; 043E; Case map
-041F; 043F; Case map
-0420; 0440; Case map
-0421; 0441; Case map
-0422; 0442; Case map
-0423; 0443; Case map
-0424; 0444; Case map
-0425; 0445; Case map
-0426; 0446; Case map
-0427; 0447; Case map
-0428; 0448; Case map
-0429; 0449; Case map
-042A; 044A; Case map
-042B; 044B; Case map
-042C; 044C; Case map
-042D; 044D; Case map
-042E; 044E; Case map
-042F; 044F; Case map
-0460; 0461; Case map
-0462; 0463; Case map
-0464; 0465; Case map
-0466; 0467; Case map
-0468; 0469; Case map
-046A; 046B; Case map
-046C; 046D; Case map
-046E; 046F; Case map
-0470; 0471; Case map
-0472; 0473; Case map
-0474; 0475; Case map
-0476; 0477; Case map
-0478; 0479; Case map
-047A; 047B; Case map
-047C; 047D; Case map
-047E; 047F; Case map
-0480; 0481; Case map
-048C; 048D; Case map
-048E; 048F; Case map
-0490; 0491; Case map
-0492; 0493; Case map
-0494; 0495; Case map
-0496; 0497; Case map
-0498; 0499; Case map
-049A; 049B; Case map
-049C; 049D; Case map
-049E; 049F; Case map
-04A0; 04A1; Case map
-04A2; 04A3; Case map
-04A4; 04A5; Case map
-04A6; 04A7; Case map
-04A8; 04A9; Case map
-04AA; 04AB; Case map
-04AC; 04AD; Case map
-04AE; 04AF; Case map
-04B0; 04B1; Case map
-04B2; 04B3; Case map
-04B4; 04B5; Case map
-04B6; 04B7; Case map
-04B8; 04B9; Case map
-04BA; 04BB; Case map
-04BC; 04BD; Case map
-04BE; 04BF; Case map
-04C1; 04C2; Case map
-04C3; 04C4; Case map
-04C7; 04C8; Case map
-04CB; 04CC; Case map
-04D0; 04D1; Case map
-04D2; 04D3; Case map
-04D4; 04D5; Case map
-04D6; 04D7; Case map
-04D8; 04D9; Case map
-04DA; 04DB; Case map
-04DC; 04DD; Case map
-04DE; 04DF; Case map
-04E0; 04E1; Case map
-04E2; 04E3; Case map
-04E4; 04E5; Case map
-04E6; 04E7; Case map
-04E8; 04E9; Case map
-04EA; 04EB; Case map
-04EC; 04ED; Case map
-04EE; 04EF; Case map
-04F0; 04F1; Case map
-04F2; 04F3; Case map
-04F4; 04F5; Case map
-04F8; 04F9; Case map
-0531; 0561; Case map
-0532; 0562; Case map
-0533; 0563; Case map
-0534; 0564; Case map
-0535; 0565; Case map
-0536; 0566; Case map
-0537; 0567; Case map
-0538; 0568; Case map
-0539; 0569; Case map
-053A; 056A; Case map
-053B; 056B; Case map
-053C; 056C; Case map
-053D; 056D; Case map
-053E; 056E; Case map
-053F; 056F; Case map
-0540; 0570; Case map
-0541; 0571; Case map
-0542; 0572; Case map
-0543; 0573; Case map
-0544; 0574; Case map
-0545; 0575; Case map
-0546; 0576; Case map
-0547; 0577; Case map
-0548; 0578; Case map
-0549; 0579; Case map
-054A; 057A; Case map
-054B; 057B; Case map
-054C; 057C; Case map
-054D; 057D; Case map
-054E; 057E; Case map
-054F; 057F; Case map
-0550; 0580; Case map
-0551; 0581; Case map
-0552; 0582; Case map
-0553; 0583; Case map
-0554; 0584; Case map
-0555; 0585; Case map
-0556; 0586; Case map
-0587; 0565 0582; Case map
-1E00; 1E01; Case map
-1E02; 1E03; Case map
-1E04; 1E05; Case map
-1E06; 1E07; Case map
-1E08; 1E09; Case map
-1E0A; 1E0B; Case map
-1E0C; 1E0D; Case map
-1E0E; 1E0F; Case map
-1E10; 1E11; Case map
-1E12; 1E13; Case map
-1E14; 1E15; Case map
-1E16; 1E17; Case map
-1E18; 1E19; Case map
-1E1A; 1E1B; Case map
-1E1C; 1E1D; Case map
-1E1E; 1E1F; Case map
-1E20; 1E21; Case map
-1E22; 1E23; Case map
-1E24; 1E25; Case map
-1E26; 1E27; Case map
-1E28; 1E29; Case map
-1E2A; 1E2B; Case map
-1E2C; 1E2D; Case map
-1E2E; 1E2F; Case map
-1E30; 1E31; Case map
-1E32; 1E33; Case map
-1E34; 1E35; Case map
-1E36; 1E37; Case map
-1E38; 1E39; Case map
-1E3A; 1E3B; Case map
-1E3C; 1E3D; Case map
-1E3E; 1E3F; Case map
-1E40; 1E41; Case map
-1E42; 1E43; Case map
-1E44; 1E45; Case map
-1E46; 1E47; Case map
-1E48; 1E49; Case map
-1E4A; 1E4B; Case map
-1E4C; 1E4D; Case map
-1E4E; 1E4F; Case map
-1E50; 1E51; Case map
-1E52; 1E53; Case map
-1E54; 1E55; Case map
-1E56; 1E57; Case map
-1E58; 1E59; Case map
-1E5A; 1E5B; Case map
-1E5C; 1E5D; Case map
-1E5E; 1E5F; Case map
-1E60; 1E61; Case map
-1E62; 1E63; Case map
-1E64; 1E65; Case map
-1E66; 1E67; Case map
-1E68; 1E69; Case map
-1E6A; 1E6B; Case map
-1E6C; 1E6D; Case map
-1E6E; 1E6F; Case map
-1E70; 1E71; Case map
-1E72; 1E73; Case map
-1E74; 1E75; Case map
-1E76; 1E77; Case map
-1E78; 1E79; Case map
-1E7A; 1E7B; Case map
-1E7C; 1E7D; Case map
-1E7E; 1E7F; Case map
-1E80; 1E81; Case map
-1E82; 1E83; Case map
-1E84; 1E85; Case map
-1E86; 1E87; Case map
-1E88; 1E89; Case map
-1E8A; 1E8B; Case map
-1E8C; 1E8D; Case map
-1E8E; 1E8F; Case map
-1E90; 1E91; Case map
-1E92; 1E93; Case map
-1E94; 1E95; Case map
-1E96; 0068 0331; Case map
-1E97; 0074 0308; Case map
-1E98; 0077 030A; Case map
-1E99; 0079 030A; Case map
-1E9A; 0061 02BE; Case map
-1E9B; 1E61; Case map
-1EA0; 1EA1; Case map
-1EA2; 1EA3; Case map
-1EA4; 1EA5; Case map
-1EA6; 1EA7; Case map
-1EA8; 1EA9; Case map
-1EAA; 1EAB; Case map
-1EAC; 1EAD; Case map
-1EAE; 1EAF; Case map
-1EB0; 1EB1; Case map
-1EB2; 1EB3; Case map
-1EB4; 1EB5; Case map
-1EB6; 1EB7; Case map
-1EB8; 1EB9; Case map
-1EBA; 1EBB; Case map
-1EBC; 1EBD; Case map
-1EBE; 1EBF; Case map
-1EC0; 1EC1; Case map
-1EC2; 1EC3; Case map
-1EC4; 1EC5; Case map
-1EC6; 1EC7; Case map
-1EC8; 1EC9; Case map
-1ECA; 1ECB; Case map
-1ECC; 1ECD; Case map
-1ECE; 1ECF; Case map
-1ED0; 1ED1; Case map
-1ED2; 1ED3; Case map
-1ED4; 1ED5; Case map
-1ED6; 1ED7; Case map
-1ED8; 1ED9; Case map
-1EDA; 1EDB; Case map
-1EDC; 1EDD; Case map
-1EDE; 1EDF; Case map
-1EE0; 1EE1; Case map
-1EE2; 1EE3; Case map
-1EE4; 1EE5; Case map
-1EE6; 1EE7; Case map
-1EE8; 1EE9; Case map
-1EEA; 1EEB; Case map
-1EEC; 1EED; Case map
-1EEE; 1EEF; Case map
-1EF0; 1EF1; Case map
-1EF2; 1EF3; Case map
-1EF4; 1EF5; Case map
-1EF6; 1EF7; Case map
-1EF8; 1EF9; Case map
-1F08; 1F00; Case map
-1F09; 1F01; Case map
-1F0A; 1F02; Case map
-1F0B; 1F03; Case map
-1F0C; 1F04; Case map
-1F0D; 1F05; Case map
-1F0E; 1F06; Case map
-1F0F; 1F07; Case map
-1F18; 1F10; Case map
-1F19; 1F11; Case map
-1F1A; 1F12; Case map
-1F1B; 1F13; Case map
-1F1C; 1F14; Case map
-1F1D; 1F15; Case map
-1F28; 1F20; Case map
-1F29; 1F21; Case map
-1F2A; 1F22; Case map
-1F2B; 1F23; Case map
-1F2C; 1F24; Case map
-1F2D; 1F25; Case map
-1F2E; 1F26; Case map
-1F2F; 1F27; Case map
-1F38; 1F30; Case map
-1F39; 1F31; Case map
-1F3A; 1F32; Case map
-1F3B; 1F33; Case map
-1F3C; 1F34; Case map
-1F3D; 1F35; Case map
-1F3E; 1F36; Case map
-1F3F; 1F37; Case map
-1F48; 1F40; Case map
-1F49; 1F41; Case map
-1F4A; 1F42; Case map
-1F4B; 1F43; Case map
-1F4C; 1F44; Case map
-1F4D; 1F45; Case map
-1F50; 03C5 0313; Case map
-1F52; 03C5 0313 0300; Case map
-1F54; 03C5 0313 0301; Case map
-1F56; 03C5 0313 0342; Case map
-1F59; 1F51; Case map
-1F5B; 1F53; Case map
-1F5D; 1F55; Case map
-1F5F; 1F57; Case map
-1F68; 1F60; Case map
-1F69; 1F61; Case map
-1F6A; 1F62; Case map
-1F6B; 1F63; Case map
-1F6C; 1F64; Case map
-1F6D; 1F65; Case map
-1F6E; 1F66; Case map
-1F6F; 1F67; Case map
-1F80; 1F00 03B9; Case map
-1F81; 1F01 03B9; Case map
-1F82; 1F02 03B9; Case map
-1F83; 1F03 03B9; Case map
-1F84; 1F04 03B9; Case map
-1F85; 1F05 03B9; Case map
-1F86; 1F06 03B9; Case map
-1F87; 1F07 03B9; Case map
-1F88; 1F00 03B9; Case map
-1F89; 1F01 03B9; Case map
-1F8A; 1F02 03B9; Case map
-1F8B; 1F03 03B9; Case map
-1F8C; 1F04 03B9; Case map
-1F8D; 1F05 03B9; Case map
-1F8E; 1F06 03B9; Case map
-1F8F; 1F07 03B9; Case map
-1F90; 1F20 03B9; Case map
-1F91; 1F21 03B9; Case map
-1F92; 1F22 03B9; Case map
-1F93; 1F23 03B9; Case map
-1F94; 1F24 03B9; Case map
-1F95; 1F25 03B9; Case map
-1F96; 1F26 03B9; Case map
-1F97; 1F27 03B9; Case map
-1F98; 1F20 03B9; Case map
-1F99; 1F21 03B9; Case map
-1F9A; 1F22 03B9; Case map
-1F9B; 1F23 03B9; Case map
-1F9C; 1F24 03B9; Case map
-1F9D; 1F25 03B9; Case map
-1F9E; 1F26 03B9; Case map
-1F9F; 1F27 03B9; Case map
-1FA0; 1F60 03B9; Case map
-1FA1; 1F61 03B9; Case map
-1FA2; 1F62 03B9; Case map
-1FA3; 1F63 03B9; Case map
-1FA4; 1F64 03B9; Case map
-1FA5; 1F65 03B9; Case map
-1FA6; 1F66 03B9; Case map
-1FA7; 1F67 03B9; Case map
-1FA8; 1F60 03B9; Case map
-1FA9; 1F61 03B9; Case map
-1FAA; 1F62 03B9; Case map
-1FAB; 1F63 03B9; Case map
-1FAC; 1F64 03B9; Case map
-1FAD; 1F65 03B9; Case map
-1FAE; 1F66 03B9; Case map
-1FAF; 1F67 03B9; Case map
-1FB2; 1F70 03B9; Case map
-1FB3; 03B1 03B9; Case map
-1FB4; 03AC 03B9; Case map
-1FB6; 03B1 0342; Case map
-1FB7; 03B1 0342 03B9; Case map
-1FB8; 1FB0; Case map
-1FB9; 1FB1; Case map
-1FBA; 1F70; Case map
-1FBB; 1F71; Case map
-1FBC; 03B1 03B9; Case map
-1FBE; 03B9; Case map
-1FC2; 1F74 03B9; Case map
-1FC3; 03B7 03B9; Case map
-1FC4; 03AE 03B9; Case map
-1FC6; 03B7 0342; Case map
-1FC7; 03B7 0342 03B9; Case map
-1FC8; 1F72; Case map
-1FC9; 1F73; Case map
-1FCA; 1F74; Case map
-1FCB; 1F75; Case map
-1FCC; 03B7 03B9; Case map
-1FD2; 03B9 0308 0300; Case map
-1FD3; 03B9 0308 0301; Case map
-1FD6; 03B9 0342; Case map
-1FD7; 03B9 0308 0342; Case map
-1FD8; 1FD0; Case map
-1FD9; 1FD1; Case map
-1FDA; 1F76; Case map
-1FDB; 1F77; Case map
-1FE2; 03C5 0308 0300; Case map
-1FE3; 03C5 0308 0301; Case map
-1FE4; 03C1 0313; Case map
-1FE6; 03C5 0342; Case map
-1FE7; 03C5 0308 0342; Case map
-1FE8; 1FE0; Case map
-1FE9; 1FE1; Case map
-1FEA; 1F7A; Case map
-1FEB; 1F7B; Case map
-1FEC; 1FE5; Case map
-1FF2; 1F7C 03B9; Case map
-1FF3; 03C9 03B9; Case map
-1FF4; 03CE 03B9; Case map
-1FF6; 03C9 0342; Case map
-1FF7; 03C9 0342 03B9; Case map
-1FF8; 1F78; Case map
-1FF9; 1F79; Case map
-1FFA; 1F7C; Case map
-1FFB; 1F7D; Case map
-1FFC; 03C9 03B9; Case map
-20A8; 0072 0073; Additional folding
-2102; 0063; Additional folding
-2103; 00B0 0063; Additional folding
-2107; 025B; Additional folding
-2109; 00B0 0066; Additional folding
-210B; 0068; Additional folding
-210C; 0068; Additional folding
-210D; 0068; Additional folding
-2110; 0069; Additional folding
-2111; 0069; Additional folding
-2112; 006C; Additional folding
-2115; 006E; Additional folding
-2116; 006E 006F; Additional folding
-2119; 0070; Additional folding
-211A; 0071; Additional folding
-211B; 0072; Additional folding
-211C; 0072; Additional folding
-211D; 0072; Additional folding
-2120; 0073 006D; Additional folding
-2121; 0074 0065 006C; Additional folding
-2122; 0074 006D; Additional folding
-2124; 007A; Additional folding
-2126; 03C9; Case map
-2128; 007A; Additional folding
-212A; 006B; Case map
-212B; 00E5; Case map
-212C; 0062; Additional folding
-212D; 0063; Additional folding
-2130; 0065; Additional folding
-2131; 0066; Additional folding
-2133; 006D; Additional folding
-2160; 2170; Case map
-2161; 2171; Case map
-2162; 2172; Case map
-2163; 2173; Case map
-2164; 2174; Case map
-2165; 2175; Case map
-2166; 2176; Case map
-2167; 2177; Case map
-2168; 2178; Case map
-2169; 2179; Case map
-216A; 217A; Case map
-216B; 217B; Case map
-216C; 217C; Case map
-216D; 217D; Case map
-216E; 217E; Case map
-216F; 217F; Case map
-24B6; 24D0; Case map
-24B7; 24D1; Case map
-24B8; 24D2; Case map
-24B9; 24D3; Case map
-24BA; 24D4; Case map
-24BB; 24D5; Case map
-24BC; 24D6; Case map
-24BD; 24D7; Case map
-24BE; 24D8; Case map
-24BF; 24D9; Case map
-24C0; 24DA; Case map
-24C1; 24DB; Case map
-24C2; 24DC; Case map
-24C3; 24DD; Case map
-24C4; 24DE; Case map
-24C5; 24DF; Case map
-24C6; 24E0; Case map
-24C7; 24E1; Case map
-24C8; 24E2; Case map
-24C9; 24E3; Case map
-24CA; 24E4; Case map
-24CB; 24E5; Case map
-24CC; 24E6; Case map
-24CD; 24E7; Case map
-24CE; 24E8; Case map
-24CF; 24E9; Case map
-3371; 0068 0070 0061; Additional folding
-3373; 0061 0075; Additional folding
-3375; 006F 0076; Additional folding
-3380; 0070 0061; Additional folding
-3381; 006E 0061; Additional folding
-3382; 03BC 0061; Additional folding
-3383; 006D 0061; Additional folding
-3384; 006B 0061; Additional folding
-3385; 006B 0062; Additional folding
-3386; 006D 0062; Additional folding
-3387; 0067 0062; Additional folding
-338A; 0070 0066; Additional folding
-338B; 006E 0066; Additional folding
-338C; 03BC 0066; Additional folding
-3390; 0068 007A; Additional folding
-3391; 006B 0068 007A; Additional folding
-3392; 006D 0068 007A; Additional folding
-3393; 0067 0068 007A; Additional folding
-3394; 0074 0068 007A; Additional folding
-33A9; 0070 0061; Additional folding
-33AA; 006B 0070 0061; Additional folding
-33AB; 006D 0070 0061; Additional folding
-33AC; 0067 0070 0061; Additional folding
-33B4; 0070 0076; Additional folding
-33B5; 006E 0076; Additional folding
-33B6; 03BC 0076; Additional folding
-33B7; 006D 0076; Additional folding
-33B8; 006B 0076; Additional folding
-33B9; 006D 0076; Additional folding
-33BA; 0070 0077; Additional folding
-33BB; 006E 0077; Additional folding
-33BC; 03BC 0077; Additional folding
-33BD; 006D 0077; Additional folding
-33BE; 006B 0077; Additional folding
-33BF; 006D 0077; Additional folding
-33C0; 006B 03C9; Additional folding
-33C1; 006D 03C9; Additional folding
-33C3; 0062 0071; Additional folding
-33C6; 0063 2215 006B 0067; Additional folding
-33C7; 0063 006F 002E; Additional folding
-33C8; 0064 0062; Additional folding
-33C9; 0067 0079; Additional folding
-33CB; 0068 0070; Additional folding
-33CD; 006B 006B; Additional folding
-33CE; 006B 006D; Additional folding
-33D7; 0070 0068; Additional folding
-33D9; 0070 0070 006D; Additional folding
-33DA; 0070 0072; Additional folding
-33DC; 0073 0076; Additional folding
-33DD; 0077 0062; Additional folding
-FB00; 0066 0066; Case map
-FB01; 0066 0069; Case map
-FB02; 0066 006C; Case map
-FB03; 0066 0066 0069; Case map
-FB04; 0066 0066 006C; Case map
-FB05; 0073 0074; Case map
-FB06; 0073 0074; Case map
-FB13; 0574 0576; Case map
-FB14; 0574 0565; Case map
-FB15; 0574 056B; Case map
-FB16; 057E 0576; Case map
-FB17; 0574 056D; Case map
-FF21; FF41; Case map
-FF22; FF42; Case map
-FF23; FF43; Case map
-FF24; FF44; Case map
-FF25; FF45; Case map
-FF26; FF46; Case map
-FF27; FF47; Case map
-FF28; FF48; Case map
-FF29; FF49; Case map
-FF2A; FF4A; Case map
-FF2B; FF4B; Case map
-FF2C; FF4C; Case map
-FF2D; FF4D; Case map
-FF2E; FF4E; Case map
-FF2F; FF4F; Case map
-FF30; FF50; Case map
-FF31; FF51; Case map
-FF32; FF52; Case map
-FF33; FF53; Case map
-FF34; FF54; Case map
-FF35; FF55; Case map
-FF36; FF56; Case map
-FF37; FF57; Case map
-FF38; FF58; Case map
-FF39; FF59; Case map
-FF3A; FF5A; Case map
-10400; 10428; Case map
-10401; 10429; Case map
-10402; 1042A; Case map
-10403; 1042B; Case map
-10404; 1042C; Case map
-10405; 1042D; Case map
-10406; 1042E; Case map
-10407; 1042F; Case map
-10408; 10430; Case map
-10409; 10431; Case map
-1040A; 10432; Case map
-1040B; 10433; Case map
-1040C; 10434; Case map
-1040D; 10435; Case map
-1040E; 10436; Case map
-1040F; 10437; Case map
-10410; 10438; Case map
-10411; 10439; Case map
-10412; 1043A; Case map
-10413; 1043B; Case map
-10414; 1043C; Case map
-10415; 1043D; Case map
-10416; 1043E; Case map
-10417; 1043F; Case map
-10418; 10440; Case map
-10419; 10441; Case map
-1041A; 10442; Case map
-1041B; 10443; Case map
-1041C; 10444; Case map
-1041D; 10445; Case map
-1041E; 10446; Case map
-1041F; 10447; Case map
-10420; 10448; Case map
-10421; 10449; Case map
-10422; 1044A; Case map
-10423; 1044B; Case map
-10424; 1044C; Case map
-10425; 1044D; Case map
-1D400; 0061; Additional folding
-1D401; 0062; Additional folding
-1D402; 0063; Additional folding
-1D403; 0064; Additional folding
-1D404; 0065; Additional folding
-1D405; 0066; Additional folding
-1D406; 0067; Additional folding
-1D407; 0068; Additional folding
-1D408; 0069; Additional folding
-1D409; 006A; Additional folding
-1D40A; 006B; Additional folding
-1D40B; 006C; Additional folding
-1D40C; 006D; Additional folding
-1D40D; 006E; Additional folding
-1D40E; 006F; Additional folding
-1D40F; 0070; Additional folding
-1D410; 0071; Additional folding
-1D411; 0072; Additional folding
-1D412; 0073; Additional folding
-1D413; 0074; Additional folding
-1D414; 0075; Additional folding
-1D415; 0076; Additional folding
-1D416; 0077; Additional folding
-1D417; 0078; Additional folding
-1D418; 0079; Additional folding
-1D419; 007A; Additional folding
-1D434; 0061; Additional folding
-1D435; 0062; Additional folding
-1D436; 0063; Additional folding
-1D437; 0064; Additional folding
-1D438; 0065; Additional folding
-1D439; 0066; Additional folding
-1D43A; 0067; Additional folding
-1D43B; 0068; Additional folding
-1D43C; 0069; Additional folding
-1D43D; 006A; Additional folding
-1D43E; 006B; Additional folding
-1D43F; 006C; Additional folding
-1D440; 006D; Additional folding
-1D441; 006E; Additional folding
-1D442; 006F; Additional folding
-1D443; 0070; Additional folding
-1D444; 0071; Additional folding
-1D445; 0072; Additional folding
-1D446; 0073; Additional folding
-1D447; 0074; Additional folding
-1D448; 0075; Additional folding
-1D449; 0076; Additional folding
-1D44A; 0077; Additional folding
-1D44B; 0078; Additional folding
-1D44C; 0079; Additional folding
-1D44D; 007A; Additional folding
-1D468; 0061; Additional folding
-1D469; 0062; Additional folding
-1D46A; 0063; Additional folding
-1D46B; 0064; Additional folding
-1D46C; 0065; Additional folding
-1D46D; 0066; Additional folding
-1D46E; 0067; Additional folding
-1D46F; 0068; Additional folding
-1D470; 0069; Additional folding
-1D471; 006A; Additional folding
-1D472; 006B; Additional folding
-1D473; 006C; Additional folding
-1D474; 006D; Additional folding
-1D475; 006E; Additional folding
-1D476; 006F; Additional folding
-1D477; 0070; Additional folding
-1D478; 0071; Additional folding
-1D479; 0072; Additional folding
-1D47A; 0073; Additional folding
-1D47B; 0074; Additional folding
-1D47C; 0075; Additional folding
-1D47D; 0076; Additional folding
-1D47E; 0077; Additional folding
-1D47F; 0078; Additional folding
-1D480; 0079; Additional folding
-1D481; 007A; Additional folding
-1D49C; 0061; Additional folding
-1D49E; 0063; Additional folding
-1D49F; 0064; Additional folding
-1D4A2; 0067; Additional folding
-1D4A5; 006A; Additional folding
-1D4A6; 006B; Additional folding
-1D4A9; 006E; Additional folding
-1D4AA; 006F; Additional folding
-1D4AB; 0070; Additional folding
-1D4AC; 0071; Additional folding
-1D4AE; 0073; Additional folding
-1D4AF; 0074; Additional folding
-1D4B0; 0075; Additional folding
-1D4B1; 0076; Additional folding
-1D4B2; 0077; Additional folding
-1D4B3; 0078; Additional folding
-1D4B4; 0079; Additional folding
-1D4B5; 007A; Additional folding
-1D4D0; 0061; Additional folding
-1D4D1; 0062; Additional folding
-1D4D2; 0063; Additional folding
-1D4D3; 0064; Additional folding
-1D4D4; 0065; Additional folding
-1D4D5; 0066; Additional folding
-1D4D6; 0067; Additional folding
-1D4D7; 0068; Additional folding
-1D4D8; 0069; Additional folding
-1D4D9; 006A; Additional folding
-1D4DA; 006B; Additional folding
-1D4DB; 006C; Additional folding
-1D4DC; 006D; Additional folding
-1D4DD; 006E; Additional folding
-1D4DE; 006F; Additional folding
-1D4DF; 0070; Additional folding
-1D4E0; 0071; Additional folding
-1D4E1; 0072; Additional folding
-1D4E2; 0073; Additional folding
-1D4E3; 0074; Additional folding
-1D4E4; 0075; Additional folding
-1D4E5; 0076; Additional folding
-1D4E6; 0077; Additional folding
-1D4E7; 0078; Additional folding
-1D4E8; 0079; Additional folding
-1D4E9; 007A; Additional folding
-1D504; 0061; Additional folding
-1D505; 0062; Additional folding
-1D507; 0064; Additional folding
-1D508; 0065; Additional folding
-1D509; 0066; Additional folding
-1D50A; 0067; Additional folding
-1D50D; 006A; Additional folding
-1D50E; 006B; Additional folding
-1D50F; 006C; Additional folding
-1D510; 006D; Additional folding
-1D511; 006E; Additional folding
-1D512; 006F; Additional folding
-1D513; 0070; Additional folding
-1D514; 0071; Additional folding
-1D516; 0073; Additional folding
-1D517; 0074; Additional folding
-1D518; 0075; Additional folding
-1D519; 0076; Additional folding
-1D51A; 0077; Additional folding
-1D51B; 0078; Additional folding
-1D51C; 0079; Additional folding
-1D538; 0061; Additional folding
-1D539; 0062; Additional folding
-1D53B; 0064; Additional folding
-1D53C; 0065; Additional folding
-1D53D; 0066; Additional folding
-1D53E; 0067; Additional folding
-1D540; 0069; Additional folding
-1D541; 006A; Additional folding
-1D542; 006B; Additional folding
-1D543; 006C; Additional folding
-1D544; 006D; Additional folding
-1D546; 006F; Additional folding
-1D54A; 0073; Additional folding
-1D54B; 0074; Additional folding
-1D54C; 0075; Additional folding
-1D54D; 0076; Additional folding
-1D54E; 0077; Additional folding
-1D54F; 0078; Additional folding
-1D550; 0079; Additional folding
-1D56C; 0061; Additional folding
-1D56D; 0062; Additional folding
-1D56E; 0063; Additional folding
-1D56F; 0064; Additional folding
-1D570; 0065; Additional folding
-1D571; 0066; Additional folding
-1D572; 0067; Additional folding
-1D573; 0068; Additional folding
-1D574; 0069; Additional folding
-1D575; 006A; Additional folding
-1D576; 006B; Additional folding
-1D577; 006C; Additional folding
-1D578; 006D; Additional folding
-1D579; 006E; Additional folding
-1D57A; 006F; Additional folding
-1D57B; 0070; Additional folding
-1D57C; 0071; Additional folding
-1D57D; 0072; Additional folding
-1D57E; 0073; Additional folding
-1D57F; 0074; Additional folding
-1D580; 0075; Additional folding
-1D581; 0076; Additional folding
-1D582; 0077; Additional folding
-1D583; 0078; Additional folding
-1D584; 0079; Additional folding
-1D585; 007A; Additional folding
-1D5A0; 0061; Additional folding
-1D5A1; 0062; Additional folding
-1D5A2; 0063; Additional folding
-1D5A3; 0064; Additional folding
-1D5A4; 0065; Additional folding
-1D5A5; 0066; Additional folding
-1D5A6; 0067; Additional folding
-1D5A7; 0068; Additional folding
-1D5A8; 0069; Additional folding
-1D5A9; 006A; Additional folding
-1D5AA; 006B; Additional folding
-1D5AB; 006C; Additional folding
-1D5AC; 006D; Additional folding
-1D5AD; 006E; Additional folding
-1D5AE; 006F; Additional folding
-1D5AF; 0070; Additional folding
-1D5B0; 0071; Additional folding
-1D5B1; 0072; Additional folding
-1D5B2; 0073; Additional folding
-1D5B3; 0074; Additional folding
-1D5B4; 0075; Additional folding
-1D5B5; 0076; Additional folding
-1D5B6; 0077; Additional folding
-1D5B7; 0078; Additional folding
-1D5B8; 0079; Additional folding
-1D5B9; 007A; Additional folding
-1D5D4; 0061; Additional folding
-1D5D5; 0062; Additional folding
-1D5D6; 0063; Additional folding
-1D5D7; 0064; Additional folding
-1D5D8; 0065; Additional folding
-1D5D9; 0066; Additional folding
-1D5DA; 0067; Additional folding
-1D5DB; 0068; Additional folding
-1D5DC; 0069; Additional folding
-1D5DD; 006A; Additional folding
-1D5DE; 006B; Additional folding
-1D5DF; 006C; Additional folding
-1D5E0; 006D; Additional folding
-1D5E1; 006E; Additional folding
-1D5E2; 006F; Additional folding
-1D5E3; 0070; Additional folding
-1D5E4; 0071; Additional folding
-1D5E5; 0072; Additional folding
-1D5E6; 0073; Additional folding
-1D5E7; 0074; Additional folding
-1D5E8; 0075; Additional folding
-1D5E9; 0076; Additional folding
-1D5EA; 0077; Additional folding
-1D5EB; 0078; Additional folding
-1D5EC; 0079; Additional folding
-1D5ED; 007A; Additional folding
-1D608; 0061; Additional folding
-1D609; 0062; Additional folding
-1D60A; 0063; Additional folding
-1D60B; 0064; Additional folding
-1D60C; 0065; Additional folding
-1D60D; 0066; Additional folding
-1D60E; 0067; Additional folding
-1D60F; 0068; Additional folding
-1D610; 0069; Additional folding
-1D611; 006A; Additional folding
-1D612; 006B; Additional folding
-1D613; 006C; Additional folding
-1D614; 006D; Additional folding
-1D615; 006E; Additional folding
-1D616; 006F; Additional folding
-1D617; 0070; Additional folding
-1D618; 0071; Additional folding
-1D619; 0072; Additional folding
-1D61A; 0073; Additional folding
-1D61B; 0074; Additional folding
-1D61C; 0075; Additional folding
-1D61D; 0076; Additional folding
-1D61E; 0077; Additional folding
-1D61F; 0078; Additional folding
-1D620; 0079; Additional folding
-1D621; 007A; Additional folding
-1D63C; 0061; Additional folding
-1D63D; 0062; Additional folding
-1D63E; 0063; Additional folding
-1D63F; 0064; Additional folding
-1D640; 0065; Additional folding
-1D641; 0066; Additional folding
-1D642; 0067; Additional folding
-1D643; 0068; Additional folding
-1D644; 0069; Additional folding
-1D645; 006A; Additional folding
-1D646; 006B; Additional folding
-1D647; 006C; Additional folding
-1D648; 006D; Additional folding
-1D649; 006E; Additional folding
-1D64A; 006F; Additional folding
-1D64B; 0070; Additional folding
-1D64C; 0071; Additional folding
-1D64D; 0072; Additional folding
-1D64E; 0073; Additional folding
-1D64F; 0074; Additional folding
-1D650; 0075; Additional folding
-1D651; 0076; Additional folding
-1D652; 0077; Additional folding
-1D653; 0078; Additional folding
-1D654; 0079; Additional folding
-1D655; 007A; Additional folding
-1D670; 0061; Additional folding
-1D671; 0062; Additional folding
-1D672; 0063; Additional folding
-1D673; 0064; Additional folding
-1D674; 0065; Additional folding
-1D675; 0066; Additional folding
-1D676; 0067; Additional folding
-1D677; 0068; Additional folding
-1D678; 0069; Additional folding
-1D679; 006A; Additional folding
-1D67A; 006B; Additional folding
-1D67B; 006C; Additional folding
-1D67C; 006D; Additional folding
-1D67D; 006E; Additional folding
-1D67E; 006F; Additional folding
-1D67F; 0070; Additional folding
-1D680; 0071; Additional folding
-1D681; 0072; Additional folding
-1D682; 0073; Additional folding
-1D683; 0074; Additional folding
-1D684; 0075; Additional folding
-1D685; 0076; Additional folding
-1D686; 0077; Additional folding
-1D687; 0078; Additional folding
-1D688; 0079; Additional folding
-1D689; 007A; Additional folding
-1D6A8; 03B1; Additional folding
-1D6A9; 03B2; Additional folding
-1D6AA; 03B3; Additional folding
-1D6AB; 03B4; Additional folding
-1D6AC; 03B5; Additional folding
-1D6AD; 03B6; Additional folding
-1D6AE; 03B7; Additional folding
-1D6AF; 03B8; Additional folding
-1D6B0; 03B9; Additional folding
-1D6B1; 03BA; Additional folding
-1D6B2; 03BB; Additional folding
-1D6B3; 03BC; Additional folding
-1D6B4; 03BD; Additional folding
-1D6B5; 03BE; Additional folding
-1D6B6; 03BF; Additional folding
-1D6B7; 03C0; Additional folding
-1D6B8; 03C1; Additional folding
-1D6B9; 03B8; Additional folding
-1D6BA; 03C3; Additional folding
-1D6BB; 03C4; Additional folding
-1D6BC; 03C5; Additional folding
-1D6BD; 03C6; Additional folding
-1D6BE; 03C7; Additional folding
-1D6BF; 03C8; Additional folding
-1D6C0; 03C9; Additional folding
-1D6D3; 03C3; Additional folding
-1D6E2; 03B1; Additional folding
-1D6E3; 03B2; Additional folding
-1D6E4; 03B3; Additional folding
-1D6E5; 03B4; Additional folding
-1D6E6; 03B5; Additional folding
-1D6E7; 03B6; Additional folding
-1D6E8; 03B7; Additional folding
-1D6E9; 03B8; Additional folding
-1D6EA; 03B9; Additional folding
-1D6EB; 03BA; Additional folding
-1D6EC; 03BB; Additional folding
-1D6ED; 03BC; Additional folding
-1D6EE; 03BD; Additional folding
-1D6EF; 03BE; Additional folding
-1D6F0; 03BF; Additional folding
-1D6F1; 03C0; Additional folding
-1D6F2; 03C1; Additional folding
-1D6F3; 03B8; Additional folding
-1D6F4; 03C3; Additional folding
-1D6F5; 03C4; Additional folding
-1D6F6; 03C5; Additional folding
-1D6F7; 03C6; Additional folding
-1D6F8; 03C7; Additional folding
-1D6F9; 03C8; Additional folding
-1D6FA; 03C9; Additional folding
-1D70D; 03C3; Additional folding
-1D71C; 03B1; Additional folding
-1D71D; 03B2; Additional folding
-1D71E; 03B3; Additional folding
-1D71F; 03B4; Additional folding
-1D720; 03B5; Additional folding
-1D721; 03B6; Additional folding
-1D722; 03B7; Additional folding
-1D723; 03B8; Additional folding
-1D724; 03B9; Additional folding
-1D725; 03BA; Additional folding
-1D726; 03BB; Additional folding
-1D727; 03BC; Additional folding
-1D728; 03BD; Additional folding
-1D729; 03BE; Additional folding
-1D72A; 03BF; Additional folding
-1D72B; 03C0; Additional folding
-1D72C; 03C1; Additional folding
-1D72D; 03B8; Additional folding
-1D72E; 03C3; Additional folding
-1D72F; 03C4; Additional folding
-1D730; 03C5; Additional folding
-1D731; 03C6; Additional folding
-1D732; 03C7; Additional folding
-1D733; 03C8; Additional folding
-1D734; 03C9; Additional folding
-1D747; 03C3; Additional folding
-1D756; 03B1; Additional folding
-1D757; 03B2; Additional folding
-1D758; 03B3; Additional folding
-1D759; 03B4; Additional folding
-1D75A; 03B5; Additional folding
-1D75B; 03B6; Additional folding
-1D75C; 03B7; Additional folding
-1D75D; 03B8; Additional folding
-1D75E; 03B9; Additional folding
-1D75F; 03BA; Additional folding
-1D760; 03BB; Additional folding
-1D761; 03BC; Additional folding
-1D762; 03BD; Additional folding
-1D763; 03BE; Additional folding
-1D764; 03BF; Additional folding
-1D765; 03C0; Additional folding
-1D766; 03C1; Additional folding
-1D767; 03B8; Additional folding
-1D768; 03C3; Additional folding
-1D769; 03C4; Additional folding
-1D76A; 03C5; Additional folding
-1D76B; 03C6; Additional folding
-1D76C; 03C7; Additional folding
-1D76D; 03C8; Additional folding
-1D76E; 03C9; Additional folding
-1D781; 03C3; Additional folding
-1D790; 03B1; Additional folding
-1D791; 03B2; Additional folding
-1D792; 03B3; Additional folding
-1D793; 03B4; Additional folding
-1D794; 03B5; Additional folding
-1D795; 03B6; Additional folding
-1D796; 03B7; Additional folding
-1D797; 03B8; Additional folding
-1D798; 03B9; Additional folding
-1D799; 03BA; Additional folding
-1D79A; 03BB; Additional folding
-1D79B; 03BC; Additional folding
-1D79C; 03BD; Additional folding
-1D79D; 03BE; Additional folding
-1D79E; 03BF; Additional folding
-1D79F; 03C0; Additional folding
-1D7A0; 03C1; Additional folding
-1D7A1; 03B8; Additional folding
-1D7A2; 03C3; Additional folding
-1D7A3; 03C4; Additional folding
-1D7A4; 03C5; Additional folding
-1D7A5; 03C6; Additional folding
-1D7A6; 03C7; Additional folding
-1D7A7; 03C8; Additional folding
-1D7A8; 03C9; Additional folding
-1D7BB; 03C3; Additional folding
------ End Table B.2 -----
-
-B.3 Mapping for lowercase used with no normalization
-
------ Start Table B.3 -----
-0041; 0061; Case map
-0042; 0062; Case map
-0043; 0063; Case map
-0044; 0064; Case map
-0045; 0065; Case map
-0046; 0066; Case map
-0047; 0067; Case map
-0048; 0068; Case map
-0049; 0069; Case map
-004A; 006A; Case map
-004B; 006B; Case map
-004C; 006C; Case map
-004D; 006D; Case map
-004E; 006E; Case map
-004F; 006F; Case map
-0050; 0070; Case map
-0051; 0071; Case map
-0052; 0072; Case map
-0053; 0073; Case map
-0054; 0074; Case map
-0055; 0075; Case map
-0056; 0076; Case map
-0057; 0077; Case map
-0058; 0078; Case map
-0059; 0079; Case map
-005A; 007A; Case map
-00B5; 03BC; Case map
-00C0; 00E0; Case map
-00C1; 00E1; Case map
-00C2; 00E2; Case map
-00C3; 00E3; Case map
-00C4; 00E4; Case map
-00C5; 00E5; Case map
-00C6; 00E6; Case map
-00C7; 00E7; Case map
-00C8; 00E8; Case map
-00C9; 00E9; Case map
-00CA; 00EA; Case map
-00CB; 00EB; Case map
-00CC; 00EC; Case map
-00CD; 00ED; Case map
-00CE; 00EE; Case map
-00CF; 00EF; Case map
-00D0; 00F0; Case map
-00D1; 00F1; Case map
-00D2; 00F2; Case map
-00D3; 00F3; Case map
-00D4; 00F4; Case map
-00D5; 00F5; Case map
-00D6; 00F6; Case map
-00D8; 00F8; Case map
-00D9; 00F9; Case map
-00DA; 00FA; Case map
-00DB; 00FB; Case map
-00DC; 00FC; Case map
-00DD; 00FD; Case map
-00DE; 00FE; Case map
-00DF; 0073 0073; Case map
-0100; 0101; Case map
-0102; 0103; Case map
-0104; 0105; Case map
-0106; 0107; Case map
-0108; 0109; Case map
-010A; 010B; Case map
-010C; 010D; Case map
-010E; 010F; Case map
-0110; 0111; Case map
-0112; 0113; Case map
-0114; 0115; Case map
-0116; 0117; Case map
-0118; 0119; Case map
-011A; 011B; Case map
-011C; 011D; Case map
-011E; 011F; Case map
-0120; 0121; Case map
-0122; 0123; Case map
-0124; 0125; Case map
-0126; 0127; Case map
-0128; 0129; Case map
-012A; 012B; Case map
-012C; 012D; Case map
-012E; 012F; Case map
-0130; 0069; Case map
-0131; 0069; Case map
-0132; 0133; Case map
-0134; 0135; Case map
-0136; 0137; Case map
-0139; 013A; Case map
-013B; 013C; Case map
-013D; 013E; Case map
-013F; 0140; Case map
-0141; 0142; Case map
-0143; 0144; Case map
-0145; 0146; Case map
-0147; 0148; Case map
-0149; 02BC 006E; Case map
-014A; 014B; Case map
-014C; 014D; Case map
-014E; 014F; Case map
-0150; 0151; Case map
-0152; 0153; Case map
-0154; 0155; Case map
-0156; 0157; Case map
-0158; 0159; Case map
-015A; 015B; Case map
-015C; 015D; Case map
-015E; 015F; Case map
-0160; 0161; Case map
-0162; 0163; Case map
-0164; 0165; Case map
-0166; 0167; Case map
-0168; 0169; Case map
-016A; 016B; Case map
-016C; 016D; Case map
-016E; 016F; Case map
-0170; 0171; Case map
-0172; 0173; Case map
-0174; 0175; Case map
-0176; 0177; Case map
-0178; 00FF; Case map
-0179; 017A; Case map
-017B; 017C; Case map
-017D; 017E; Case map
-017F; 0073; Case map
-0181; 0253; Case map
-0182; 0183; Case map
-0184; 0185; Case map
-0186; 0254; Case map
-0187; 0188; Case map
-0189; 0256; Case map
-018A; 0257; Case map
-018B; 018C; Case map
-018E; 01DD; Case map
-018F; 0259; Case map
-0190; 025B; Case map
-0191; 0192; Case map
-0193; 0260; Case map
-0194; 0263; Case map
-0196; 0269; Case map
-0197; 0268; Case map
-0198; 0199; Case map
-019C; 026F; Case map
-019D; 0272; Case map
-019F; 0275; Case map
-01A0; 01A1; Case map
-01A2; 01A3; Case map
-01A4; 01A5; Case map
-01A6; 0280; Case map
-01A7; 01A8; Case map
-01A9; 0283; Case map
-01AC; 01AD; Case map
-01AE; 0288; Case map
-01AF; 01B0; Case map
-01B1; 028A; Case map
-01B2; 028B; Case map
-01B3; 01B4; Case map
-01B5; 01B6; Case map
-01B7; 0292; Case map
-01B8; 01B9; Case map
-01BC; 01BD; Case map
-01C4; 01C6; Case map
-01C5; 01C6; Case map
-01C7; 01C9; Case map
-01C8; 01C9; Case map
-01CA; 01CC; Case map
-01CB; 01CC; Case map
-01CD; 01CE; Case map
-01CF; 01D0; Case map
-01D1; 01D2; Case map
-01D3; 01D4; Case map
-01D5; 01D6; Case map
-01D7; 01D8; Case map
-01D9; 01DA; Case map
-01DB; 01DC; Case map
-01DE; 01DF; Case map
-01E0; 01E1; Case map
-01E2; 01E3; Case map
-01E4; 01E5; Case map
-01E6; 01E7; Case map
-01E8; 01E9; Case map
-01EA; 01EB; Case map
-01EC; 01ED; Case map
-01EE; 01EF; Case map
-01F0; 006A 030C; Case map
-01F1; 01F3; Case map
-01F2; 01F3; Case map
-01F4; 01F5; Case map
-01F6; 0195; Case map
-01F7; 01BF; Case map
-01F8; 01F9; Case map
-01FA; 01FB; Case map
-01FC; 01FD; Case map
-01FE; 01FF; Case map
-0200; 0201; Case map
-0202; 0203; Case map
-0204; 0205; Case map
-0206; 0207; Case map
-0208; 0209; Case map
-020A; 020B; Case map
-020C; 020D; Case map
-020E; 020F; Case map
-0210; 0211; Case map
-0212; 0213; Case map
-0214; 0215; Case map
-0216; 0217; Case map
-0218; 0219; Case map
-021A; 021B; Case map
-021C; 021D; Case map
-021E; 021F; Case map
-0222; 0223; Case map
-0224; 0225; Case map
-0226; 0227; Case map
-0228; 0229; Case map
-022A; 022B; Case map
-022C; 022D; Case map
-022E; 022F; Case map
-0230; 0231; Case map
-0232; 0233; Case map
-0345; 03B9; Case map
-0386; 03AC; Case map
-0388; 03AD; Case map
-0389; 03AE; Case map
-038A; 03AF; Case map
-038C; 03CC; Case map
-038E; 03CD; Case map
-038F; 03CE; Case map
-0390; 03B9 0308 0301; Case map
-0391; 03B1; Case map
-0392; 03B2; Case map
-0393; 03B3; Case map
-0394; 03B4; Case map
-0395; 03B5; Case map
-0396; 03B6; Case map
-0397; 03B7; Case map
-0398; 03B8; Case map
-0399; 03B9; Case map
-039A; 03BA; Case map
-039B; 03BB; Case map
-039C; 03BC; Case map
-039D; 03BD; Case map
-039E; 03BE; Case map
-039F; 03BF; Case map
-03A0; 03C0; Case map
-03A1; 03C1; Case map
-03A3; 03C3; Case map
-03A4; 03C4; Case map
-03A5; 03C5; Case map
-03A6; 03C6; Case map
-03A7; 03C7; Case map
-03A8; 03C8; Case map
-03A9; 03C9; Case map
-03AA; 03CA; Case map
-03AB; 03CB; Case map
-03B0; 03C5 0308 0301; Case map
-03C2; 03C3; Case map
-03D0; 03B2; Case map
-03D1; 03B8; Case map
-03D5; 03C6; Case map
-03D6; 03C0; Case map
-03DA; 03DB; Case map
-03DC; 03DD; Case map
-03DE; 03DF; Case map
-03E0; 03E1; Case map
-03E2; 03E3; Case map
-03E4; 03E5; Case map
-03E6; 03E7; Case map
-03E8; 03E9; Case map
-03EA; 03EB; Case map
-03EC; 03ED; Case map
-03EE; 03EF; Case map
-03F0; 03BA; Case map
-03F1; 03C1; Case map
-03F2; 03C3; Case map
-03F4; 03B8; Case map
-03F5; 03B5; Case map
-0400; 0450; Case map
-0401; 0451; Case map
-0402; 0452; Case map
-0403; 0453; Case map
-0404; 0454; Case map
-0405; 0455; Case map
-0406; 0456; Case map
-0407; 0457; Case map
-0408; 0458; Case map
-0409; 0459; Case map
-040A; 045A; Case map
-040B; 045B; Case map
-040C; 045C; Case map
-040D; 045D; Case map
-040E; 045E; Case map
-040F; 045F; Case map
-0410; 0430; Case map
-0411; 0431; Case map
-0412; 0432; Case map
-0413; 0433; Case map
-0414; 0434; Case map
-0415; 0435; Case map
-0416; 0436; Case map
-0417; 0437; Case map
-0418; 0438; Case map
-0419; 0439; Case map
-041A; 043A; Case map
-041B; 043B; Case map
-041C; 043C; Case map
-041D; 043D; Case map
-041E; 043E; Case map
-041F; 043F; Case map
-0420; 0440; Case map
-0421; 0441; Case map
-0422; 0442; Case map
-0423; 0443; Case map
-0424; 0444; Case map
-0425; 0445; Case map
-0426; 0446; Case map
-0427; 0447; Case map
-0428; 0448; Case map
-0429; 0449; Case map
-042A; 044A; Case map
-042B; 044B; Case map
-042C; 044C; Case map
-042D; 044D; Case map
-042E; 044E; Case map
-042F; 044F; Case map
-0460; 0461; Case map
-0462; 0463; Case map
-0464; 0465; Case map
-0466; 0467; Case map
-0468; 0469; Case map
-046A; 046B; Case map
-046C; 046D; Case map
-046E; 046F; Case map
-0470; 0471; Case map
-0472; 0473; Case map
-0474; 0475; Case map
-0476; 0477; Case map
-0478; 0479; Case map
-047A; 047B; Case map
-047C; 047D; Case map
-047E; 047F; Case map
-0480; 0481; Case map
-048C; 048D; Case map
-048E; 048F; Case map
-0490; 0491; Case map
-0492; 0493; Case map
-0494; 0495; Case map
-0496; 0497; Case map
-0498; 0499; Case map
-049A; 049B; Case map
-049C; 049D; Case map
-049E; 049F; Case map
-04A0; 04A1; Case map
-04A2; 04A3; Case map
-04A4; 04A5; Case map
-04A6; 04A7; Case map
-04A8; 04A9; Case map
-04AA; 04AB; Case map
-04AC; 04AD; Case map
-04AE; 04AF; Case map
-04B0; 04B1; Case map
-04B2; 04B3; Case map
-04B4; 04B5; Case map
-04B6; 04B7; Case map
-04B8; 04B9; Case map
-04BA; 04BB; Case map
-04BC; 04BD; Case map
-04BE; 04BF; Case map
-04C1; 04C2; Case map
-04C3; 04C4; Case map
-04C7; 04C8; Case map
-04CB; 04CC; Case map
-04D0; 04D1; Case map
-04D2; 04D3; Case map
-04D4; 04D5; Case map
-04D6; 04D7; Case map
-04D8; 04D9; Case map
-04DA; 04DB; Case map
-04DC; 04DD; Case map
-04DE; 04DF; Case map
-04E0; 04E1; Case map
-04E2; 04E3; Case map
-04E4; 04E5; Case map
-04E6; 04E7; Case map
-04E8; 04E9; Case map
-04EA; 04EB; Case map
-04EC; 04ED; Case map
-04EE; 04EF; Case map
-04F0; 04F1; Case map
-04F2; 04F3; Case map
-04F4; 04F5; Case map
-04F8; 04F9; Case map
-0531; 0561; Case map
-0532; 0562; Case map
-0533; 0563; Case map
-0534; 0564; Case map
-0535; 0565; Case map
-0536; 0566; Case map
-0537; 0567; Case map
-0538; 0568; Case map
-0539; 0569; Case map
-053A; 056A; Case map
-053B; 056B; Case map
-053C; 056C; Case map
-053D; 056D; Case map
-053E; 056E; Case map
-053F; 056F; Case map
-0540; 0570; Case map
-0541; 0571; Case map
-0542; 0572; Case map
-0543; 0573; Case map
-0544; 0574; Case map
-0545; 0575; Case map
-0546; 0576; Case map
-0547; 0577; Case map
-0548; 0578; Case map
-0549; 0579; Case map
-054A; 057A; Case map
-054B; 057B; Case map
-054C; 057C; Case map
-054D; 057D; Case map
-054E; 057E; Case map
-054F; 057F; Case map
-0550; 0580; Case map
-0551; 0581; Case map
-0552; 0582; Case map
-0553; 0583; Case map
-0554; 0584; Case map
-0555; 0585; Case map
-0556; 0586; Case map
-0587; 0565 0582; Case map
-1E00; 1E01; Case map
-1E02; 1E03; Case map
-1E04; 1E05; Case map
-1E06; 1E07; Case map
-1E08; 1E09; Case map
-1E0A; 1E0B; Case map
-1E0C; 1E0D; Case map
-1E0E; 1E0F; Case map
-1E10; 1E11; Case map
-1E12; 1E13; Case map
-1E14; 1E15; Case map
-1E16; 1E17; Case map
-1E18; 1E19; Case map
-1E1A; 1E1B; Case map
-1E1C; 1E1D; Case map
-1E1E; 1E1F; Case map
-1E20; 1E21; Case map
-1E22; 1E23; Case map
-1E24; 1E25; Case map
-1E26; 1E27; Case map
-1E28; 1E29; Case map
-1E2A; 1E2B; Case map
-1E2C; 1E2D; Case map
-1E2E; 1E2F; Case map
-1E30; 1E31; Case map
-1E32; 1E33; Case map
-1E34; 1E35; Case map
-1E36; 1E37; Case map
-1E38; 1E39; Case map
-1E3A; 1E3B; Case map
-1E3C; 1E3D; Case map
-1E3E; 1E3F; Case map
-1E40; 1E41; Case map
-1E42; 1E43; Case map
-1E44; 1E45; Case map
-1E46; 1E47; Case map
-1E48; 1E49; Case map
-1E4A; 1E4B; Case map
-1E4C; 1E4D; Case map
-1E4E; 1E4F; Case map
-1E50; 1E51; Case map
-1E52; 1E53; Case map
-1E54; 1E55; Case map
-1E56; 1E57; Case map
-1E58; 1E59; Case map
-1E5A; 1E5B; Case map
-1E5C; 1E5D; Case map
-1E5E; 1E5F; Case map
-1E60; 1E61; Case map
-1E62; 1E63; Case map
-1E64; 1E65; Case map
-1E66; 1E67; Case map
-1E68; 1E69; Case map
-1E6A; 1E6B; Case map
-1E6C; 1E6D; Case map
-1E6E; 1E6F; Case map
-1E70; 1E71; Case map
-1E72; 1E73; Case map
-1E74; 1E75; Case map
-1E76; 1E77; Case map
-1E78; 1E79; Case map
-1E7A; 1E7B; Case map
-1E7C; 1E7D; Case map
-1E7E; 1E7F; Case map
-1E80; 1E81; Case map
-1E82; 1E83; Case map
-1E84; 1E85; Case map
-1E86; 1E87; Case map
-1E88; 1E89; Case map
-1E8A; 1E8B; Case map
-1E8C; 1E8D; Case map
-1E8E; 1E8F; Case map
-1E90; 1E91; Case map
-1E92; 1E93; Case map
-1E94; 1E95; Case map
-1E96; 0068 0331; Case map
-1E97; 0074 0308; Case map
-1E98; 0077 030A; Case map
-1E99; 0079 030A; Case map
-1E9A; 0061 02BE; Case map
-1E9B; 1E61; Case map
-1EA0; 1EA1; Case map
-1EA2; 1EA3; Case map
-1EA4; 1EA5; Case map
-1EA6; 1EA7; Case map
-1EA8; 1EA9; Case map
-1EAA; 1EAB; Case map
-1EAC; 1EAD; Case map
-1EAE; 1EAF; Case map
-1EB0; 1EB1; Case map
-1EB2; 1EB3; Case map
-1EB4; 1EB5; Case map
-1EB6; 1EB7; Case map
-1EB8; 1EB9; Case map
-1EBA; 1EBB; Case map
-1EBC; 1EBD; Case map
-1EBE; 1EBF; Case map
-1EC0; 1EC1; Case map
-1EC2; 1EC3; Case map
-1EC4; 1EC5; Case map
-1EC6; 1EC7; Case map
-1EC8; 1EC9; Case map
-1ECA; 1ECB; Case map
-1ECC; 1ECD; Case map
-1ECE; 1ECF; Case map
-1ED0; 1ED1; Case map
-1ED2; 1ED3; Case map
-1ED4; 1ED5; Case map
-1ED6; 1ED7; Case map
-1ED8; 1ED9; Case map
-1EDA; 1EDB; Case map
-1EDC; 1EDD; Case map
-1EDE; 1EDF; Case map
-1EE0; 1EE1; Case map
-1EE2; 1EE3; Case map
-1EE4; 1EE5; Case map
-1EE6; 1EE7; Case map
-1EE8; 1EE9; Case map
-1EEA; 1EEB; Case map
-1EEC; 1EED; Case map
-1EEE; 1EEF; Case map
-1EF0; 1EF1; Case map
-1EF2; 1EF3; Case map
-1EF4; 1EF5; Case map
-1EF6; 1EF7; Case map
-1EF8; 1EF9; Case map
-1F08; 1F00; Case map
-1F09; 1F01; Case map
-1F0A; 1F02; Case map
-1F0B; 1F03; Case map
-1F0C; 1F04; Case map
-1F0D; 1F05; Case map
-1F0E; 1F06; Case map
-1F0F; 1F07; Case map
-1F18; 1F10; Case map
-1F19; 1F11; Case map
-1F1A; 1F12; Case map
-1F1B; 1F13; Case map
-1F1C; 1F14; Case map
-1F1D; 1F15; Case map
-1F28; 1F20; Case map
-1F29; 1F21; Case map
-1F2A; 1F22; Case map
-1F2B; 1F23; Case map
-1F2C; 1F24; Case map
-1F2D; 1F25; Case map
-1F2E; 1F26; Case map
-1F2F; 1F27; Case map
-1F38; 1F30; Case map
-1F39; 1F31; Case map
-1F3A; 1F32; Case map
-1F3B; 1F33; Case map
-1F3C; 1F34; Case map
-1F3D; 1F35; Case map
-1F3E; 1F36; Case map
-1F3F; 1F37; Case map
-1F48; 1F40; Case map
-1F49; 1F41; Case map
-1F4A; 1F42; Case map
-1F4B; 1F43; Case map
-1F4C; 1F44; Case map
-1F4D; 1F45; Case map
-1F50; 03C5 0313; Case map
-1F52; 03C5 0313 0300; Case map
-1F54; 03C5 0313 0301; Case map
-1F56; 03C5 0313 0342; Case map
-1F59; 1F51; Case map
-1F5B; 1F53; Case map
-1F5D; 1F55; Case map
-1F5F; 1F57; Case map
-1F68; 1F60; Case map
-1F69; 1F61; Case map
-1F6A; 1F62; Case map
-1F6B; 1F63; Case map
-1F6C; 1F64; Case map
-1F6D; 1F65; Case map
-1F6E; 1F66; Case map
-1F6F; 1F67; Case map
-1F80; 1F00 03B9; Case map
-1F81; 1F01 03B9; Case map
-1F82; 1F02 03B9; Case map
-1F83; 1F03 03B9; Case map
-1F84; 1F04 03B9; Case map
-1F85; 1F05 03B9; Case map
-1F86; 1F06 03B9; Case map
-1F87; 1F07 03B9; Case map
-1F88; 1F00 03B9; Case map
-1F89; 1F01 03B9; Case map
-1F8A; 1F02 03B9; Case map
-1F8B; 1F03 03B9; Case map
-1F8C; 1F04 03B9; Case map
-1F8D; 1F05 03B9; Case map
-1F8E; 1F06 03B9; Case map
-1F8F; 1F07 03B9; Case map
-1F90; 1F20 03B9; Case map
-1F91; 1F21 03B9; Case map
-1F92; 1F22 03B9; Case map
-1F93; 1F23 03B9; Case map
-1F94; 1F24 03B9; Case map
-1F95; 1F25 03B9; Case map
-1F96; 1F26 03B9; Case map
-1F97; 1F27 03B9; Case map
-1F98; 1F20 03B9; Case map
-1F99; 1F21 03B9; Case map
-1F9A; 1F22 03B9; Case map
-1F9B; 1F23 03B9; Case map
-1F9C; 1F24 03B9; Case map
-1F9D; 1F25 03B9; Case map
-1F9E; 1F26 03B9; Case map
-1F9F; 1F27 03B9; Case map
-1FA0; 1F60 03B9; Case map
-1FA1; 1F61 03B9; Case map
-1FA2; 1F62 03B9; Case map
-1FA3; 1F63 03B9; Case map
-1FA4; 1F64 03B9; Case map
-1FA5; 1F65 03B9; Case map
-1FA6; 1F66 03B9; Case map
-1FA7; 1F67 03B9; Case map
-1FA8; 1F60 03B9; Case map
-1FA9; 1F61 03B9; Case map
-1FAA; 1F62 03B9; Case map
-1FAB; 1F63 03B9; Case map
-1FAC; 1F64 03B9; Case map
-1FAD; 1F65 03B9; Case map
-1FAE; 1F66 03B9; Case map
-1FAF; 1F67 03B9; Case map
-1FB2; 1F70 03B9; Case map
-1FB3; 03B1 03B9; Case map
-1FB4; 03AC 03B9; Case map
-1FB6; 03B1 0342; Case map
-1FB7; 03B1 0342 03B9; Case map
-1FB8; 1FB0; Case map
-1FB9; 1FB1; Case map
-1FBA; 1F70; Case map
-1FBB; 1F71; Case map
-1FBC; 03B1 03B9; Case map
-1FBE; 03B9; Case map
-1FC2; 1F74 03B9; Case map
-1FC3; 03B7 03B9; Case map
-1FC4; 03AE 03B9; Case map
-1FC6; 03B7 0342; Case map
-1FC7; 03B7 0342 03B9; Case map
-1FC8; 1F72; Case map
-1FC9; 1F73; Case map
-1FCA; 1F74; Case map
-1FCB; 1F75; Case map
-1FCC; 03B7 03B9; Case map
-1FD2; 03B9 0308 0300; Case map
-1FD3; 03B9 0308 0301; Case map
-1FD6; 03B9 0342; Case map
-1FD7; 03B9 0308 0342; Case map
-1FD8; 1FD0; Case map
-1FD9; 1FD1; Case map
-1FDA; 1F76; Case map
-1FDB; 1F77; Case map
-1FE2; 03C5 0308 0300; Case map
-1FE3; 03C5 0308 0301; Case map
-1FE4; 03C1 0313; Case map
-1FE6; 03C5 0342; Case map
-1FE7; 03C5 0308 0342; Case map
-1FE8; 1FE0; Case map
-1FE9; 1FE1; Case map
-1FEA; 1F7A; Case map
-1FEB; 1F7B; Case map
-1FEC; 1FE5; Case map
-1FF2; 1F7C 03B9; Case map
-1FF3; 03C9 03B9; Case map
-1FF4; 03CE 03B9; Case map
-1FF6; 03C9 0342; Case map
-1FF7; 03C9 0342 03B9; Case map
-1FF8; 1F78; Case map
-1FF9; 1F79; Case map
-1FFA; 1F7C; Case map
-1FFB; 1F7D; Case map
-1FFC; 03C9 03B9; Case map
-2126; 03C9; Case map
-212A; 006B; Case map
-212B; 00E5; Case map
-2160; 2170; Case map
-2161; 2171; Case map
-2162; 2172; Case map
-2163; 2173; Case map
-2164; 2174; Case map
-2165; 2175; Case map
-2166; 2176; Case map
-2167; 2177; Case map
-2168; 2178; Case map
-2169; 2179; Case map
-216A; 217A; Case map
-216B; 217B; Case map
-216C; 217C; Case map
-216D; 217D; Case map
-216E; 217E; Case map
-216F; 217F; Case map
-24B6; 24D0; Case map
-24B7; 24D1; Case map
-24B8; 24D2; Case map
-24B9; 24D3; Case map
-24BA; 24D4; Case map
-24BB; 24D5; Case map
-24BC; 24D6; Case map
-24BD; 24D7; Case map
-24BE; 24D8; Case map
-24BF; 24D9; Case map
-24C0; 24DA; Case map
-24C1; 24DB; Case map
-24C2; 24DC; Case map
-24C3; 24DD; Case map
-24C4; 24DE; Case map
-24C5; 24DF; Case map
-24C6; 24E0; Case map
-24C7; 24E1; Case map
-24C8; 24E2; Case map
-24C9; 24E3; Case map
-24CA; 24E4; Case map
-24CB; 24E5; Case map
-24CC; 24E6; Case map
-24CD; 24E7; Case map
-24CE; 24E8; Case map
-24CF; 24E9; Case map
-FB00; 0066 0066; Case map
-FB01; 0066 0069; Case map
-FB02; 0066 006C; Case map
-FB03; 0066 0066 0069; Case map
-FB04; 0066 0066 006C; Case map
-FB05; 0073 0074; Case map
-FB06; 0073 0074; Case map
-FB13; 0574 0576; Case map
-FB14; 0574 0565; Case map
-FB15; 0574 056B; Case map
-FB16; 057E 0576; Case map
-FB17; 0574 056D; Case map
-FF21; FF41; Case map
-FF22; FF42; Case map
-FF23; FF43; Case map
-FF24; FF44; Case map
-FF25; FF45; Case map
-FF26; FF46; Case map
-FF27; FF47; Case map
-FF28; FF48; Case map
-FF29; FF49; Case map
-FF2A; FF4A; Case map
-FF2B; FF4B; Case map
-FF2C; FF4C; Case map
-FF2D; FF4D; Case map
-FF2E; FF4E; Case map
-FF2F; FF4F; Case map
-FF30; FF50; Case map
-FF31; FF51; Case map
-FF32; FF52; Case map
-FF33; FF53; Case map
-FF34; FF54; Case map
-FF35; FF55; Case map
-FF36; FF56; Case map
-FF37; FF57; Case map
-FF38; FF58; Case map
-FF39; FF59; Case map
-FF3A; FF5A; Case map
-10400; 10428; Case map
-10401; 10429; Case map
-10402; 1042A; Case map
-10403; 1042B; Case map
-10404; 1042C; Case map
-10405; 1042D; Case map
-10406; 1042E; Case map
-10407; 1042F; Case map
-10408; 10430; Case map
-10409; 10431; Case map
-1040A; 10432; Case map
-1040B; 10433; Case map
-1040C; 10434; Case map
-1040D; 10435; Case map
-1040E; 10436; Case map
-1040F; 10437; Case map
-10410; 10438; Case map
-10411; 10439; Case map
-10412; 1043A; Case map
-10413; 1043B; Case map
-10414; 1043C; Case map
-10415; 1043D; Case map
-10416; 1043E; Case map
-10417; 1043F; Case map
-10418; 10440; Case map
-10419; 10441; Case map
-1041A; 10442; Case map
-1041B; 10443; Case map
-1041C; 10444; Case map
-1041D; 10445; Case map
-1041E; 10446; Case map
-1041F; 10447; Case map
-10420; 10448; Case map
-10421; 10449; Case map
-10422; 1044A; Case map
-10423; 1044B; Case map
-10424; 1044C; Case map
-10425; 1044D; Case map
------ End Table B.3 -----
-
-C. Prohibition tables
-
-The tables in this appendix consist of lines with one prohibited code
-point per line. The format of the lines are the value of the code point,
-a semicolon, and a comment which is the name of the code point.
-
-C.1 Space characters
-
------ Start Table C.1 -----
-00A0; NO-BREAK SPACE
-1680; OGHAM SPACE MARK
-2000; EN QUAD
-2001; EM QUAD
-2002; EN SPACE
-2003; EM SPACE
-2004; THREE-PER-EM SPACE
-2005; FOUR-PER-EM SPACE
-2006; SIX-PER-EM SPACE
-2007; FIGURE SPACE
-2008; PUNCTUATION SPACE
-2009; THIN SPACE
-200A; HAIR SPACE
-202F; NARROW NO-BREAK SPACE
-3000; IDEOGRAPHIC SPACE
------ End Table C.1 -----
-
-C.2 Control characters
-
------ Start Table C.2 -----
-0080-009F; [CONTROL CHARACTERS]
-070F; SYRIAC ABBREVIATION MARK
-180E; MONGOLIAN VOWEL SEPARATOR
-2028; LINE SEPARATOR
-2029; PARAGRAPH SEPARATOR
-206A-206F; [CONTROL CHARACTERS]
-FFF9-FFFC; [CONTROL CHARACTERS]
-1D173-1D17A; [MUSICAL CONTROL CHARACTERS]
------ End Table C.2 -----
-
-C.3 Private use and replacement characters
-
------ Start Table C.3 -----
-E000-F8FF; [PRIVATE USE, PLANE 0]
-F0000-FFFFD; [PRIVATE USE, PLANE 15]
-100000-10FFFD; [PRIVATE USE, PLANE 16]
-FFFD; REPLACEMENT CHARACTER
------ End Table C.3 -----
-
-C.4 Non-character code points
-
------ Start Table C.4 -----
-FDD0-FDEF; [NONCHARACTER CODE POINTS]
-FFFE-FFFF; [NONCHARACTER CODE POINTS]
-1FFFE-1FFFF; [NONCHARACTER CODE POINTS]
-2FFFE-2FFFF; [NONCHARACTER CODE POINTS]
-3FFFE-3FFFF; [NONCHARACTER CODE POINTS]
-4FFFE-4FFFF; [NONCHARACTER CODE POINTS]
-5FFFE-5FFFF; [NONCHARACTER CODE POINTS]
-6FFFE-6FFFF; [NONCHARACTER CODE POINTS]
-7FFFE-7FFFF; [NONCHARACTER CODE POINTS]
-8FFFE-8FFFF; [NONCHARACTER CODE POINTS]
-9FFFE-9FFFF; [NONCHARACTER CODE POINTS]
-AFFFE-AFFFF; [NONCHARACTER CODE POINTS]
-BFFFE-BFFFF; [NONCHARACTER CODE POINTS]
-CFFFE-CFFFF; [NONCHARACTER CODE POINTS]
-DFFFE-DFFFF; [NONCHARACTER CODE POINTS]
-EFFFE-EFFFF; [NONCHARACTER CODE POINTS]
-FFFFE-FFFFF; [NONCHARACTER CODE POINTS]
-10FFFE-10FFFF; [NONCHARACTER CODE POINTS]
------ End Table C.4 -----
-
-C.5 Surrogate codes
-
------ Start Table C.5 -----
-D800-DFFF; [SURROGATE CODES]
------ End Table C.5 -----
-
-C.6 Inappropriate for plain text
-
------ Start Table C.6 -----
-FFF9; INTERLINEAR ANNOTATION ANCHOR
-FFFA; INTERLINEAR ANNOTATION SEPARATOR
-FFFB; INTERLINEAR ANNOTATION TERMINATOR
-FFFC; OBJECT REPLACEMENT CHARACTER
------ End Table C.6 -----
-
-C.7 Inappropriate for canonical representation
-
------ Start Table C.7 -----
-2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS]
------ End Table C.7 -----
-
-C.8 Change display properties
-
------ Start Table C.8 -----
-200E; LEFT-TO-RIGHT MARK
-200F; RIGHT-TO-LEFT MARK
-202A; LEFT-TO-RIGHT EMBEDDING
-202B; RIGHT-TO-LEFT EMBEDDING
-202C; POP DIRECTIONAL FORMATTING
-202D; LEFT-TO-RIGHT OVERRIDE
-202E; RIGHT-TO-LEFT OVERRIDE
-206A; INHIBIT SYMMETRIC SWAPPING
-206B; ACTIVATE SYMMETRIC SWAPPING
-206C; INHIBIT ARABIC FORM SHAPING
-206D; ACTIVATE ARABIC FORM SHAPING
-206E; NATIONAL DIGIT SHAPES
-206F; NOMINAL DIGIT SHAPES
------ End Table C.8 -----
-
-C.9 Tagging characters
-
------ Start Table C.9 -----
-E0001; LANGUAGE TAG
-E0020-E007F; [TAGGING CHARACTERS]
------ End Table C.9 -----
-
diff --git a/Documentation/en/I-D/draft-huitema-shipworm-01.txt b/Documentation/en/I-D/draft-huitema-shipworm-01.txt
deleted file mode 100644
index 5ea9c2dd..00000000
--- a/Documentation/en/I-D/draft-huitema-shipworm-01.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-
-This  document has been replaced by draft-ietf-ngtrans-shipworm-00.txt.
-For more information or a copy of the document, contact the author directly.
-
-Draft Author(s):
-
-C. Huitema: huitema@bellcore.com                                                    
-
-
diff --git a/Documentation/en/I-D/draft-ietf-drums-mail-followup-to-01.txt b/Documentation/en/I-D/draft-ietf-drums-mail-followup-to-01.txt
deleted file mode 100644
index 2cc38fc0..00000000
--- a/Documentation/en/I-D/draft-ietf-drums-mail-followup-to-01.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-J. Palme: jpalme@dsv.su.se                                                        

-

-

diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt
deleted file mode 100644
index 8f7aa50b..00000000
--- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt
+++ /dev/null
@@ -1,3734 +0,0 @@
-INTERNET-DRAFT                                John C. Klensin, Editor
-Expires June 1999                         
-December 29, 1998
-                                                        
-
-                  Simple Mail Transfer Protocol 
-
-                 draft-ietf-drums-smtpupd-09.txt
-
-Status of this Memo
-
-This document is an Internet-Draft.  Internet-Drafts are working documents
-of the Internet Engineering Task Force (IETF), its areas, and its working
-groups.  Note that other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months and
-may be updated, replaced, or obsoleted by other documents at any time.  It
-is inappropriate to use Internet- Drafts as reference material or to cite
-them other than as "work in progress."
-
-To view the entire list of current Internet-Drafts, please check the
-"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
-ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
-ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
-
-[[Sections marked with doubled brackets (e.g., "<<") are explicit
-placeholders or known major loose ends. Please review these ASAP. The
-sections with these placeholders are 4.1.2, 4.4, and X.2.]]
-
-[[Appendix X will be removed before the document is submitted to the
-IESG.]]
-
-[[If consensus is reached on this document, it will be forwarded to the
-IESG with the recommendation that it be processed onto the Standards
-track.]]
-
-Copyright Notice
-
-Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-                           Table of Contents
-
-0. Abstract
-
-1. Introduction
-
-2. The SMTP Model
-2.1 Basic Structure
-2.2 The Extension Model
-2.2.1 Background
-2.2.2 Definition and Registration of Extensions
-2.3 Terminology
-2.3.1 Mail Objects
-2.3.2 Senders and Receivers
-2.3.3 Mail Agents
-2.3.4 Host
-2.3.5 Domain
-2.3.6 Buffer and State Table
-2.3.7 Lines
-2.3.8 Originator, Delivery, Relay, and Gateway Systems
-2.3.9 Message Content and Mail Data
-2.3.10 Mailbox and Address
-2.3.11 Reply
-2.4 Syntax Principles
-2.4.1 General Syntax and Transaction Model
-2.4.2 Command and Reply Syntax
-
-3. The SMTP Procedures: An Overview
-3.1 Session Initiation
-3.2 Client Initiation
-3.3 Mail Transactions
-3.4 Forwarding for Address Correction or Updating
-3.5 Commands for Debugging Addresses
-3.5.1 Overview
-3.5.2 VRFY Normal Response
-3.5.3 Meaning of VRFY or EXPN Success Response
-3.5.4 Semantics and Applications of EXPN
-3.6 Domains
-3.7 Relaying
-3.8 Mail Gatewaying
-3.8.1 Header Fields in Gatewaying
-3.8.2 Received Lines in Gatewaying
-3.8.3 Addresses in Gatewaying
-3.8.4 Other Header Fields in Gatewaying
-3.8.5 Envelopes in Gatewaying
-3.9 Terminating Sessions and Connections
-3.10 Mailing Lists and Aliases
-3.10.1 Alias
-3.10.2 List
-
-4. The SMTP Specifications
-4.1 SMTP Commands
-4.1.1 Command Semantics and Syntax
-4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
-4.1.1.2 MAIL (MAIL)
-4.1.1.3 RECIPIENT (RCPT)
-4.1.1.4 DATA (DATA)
-4.1.1.5 RESET (RSET)
-4.1.1.6 VERIFY (VRFY)
-4.1.1.7 EXPAND (EXPN)
-4.1.1.8 HELP (HELP)
-4.1.1.9 NOOP (NOOP)
-4.1.1.10 QUIT (QUIT)
-4.1.2 Lower-level Syntax
-4.1.3 Address Literals
-4.1.4 Order of Commands
-4.1.5 Private-use Commands
-4.2  SMTP Replies
-4.2.1 Reply Code Severities and Theory
-4.2.2 Reply Codes by Function Groups
-4.2.3  Reply Codes in Numeric Order
-4.2.4 Reply Code 502
-4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
-4.3 Sequencing of Commands and Replies
-4.3.1 Sequencing Overview
-4.3.2 Command-Reply Sequences
-4.4 Trace Information
-4.5 Additional Implementation Issues
-4.5.1 Minimum Implementation
-4.5.2 Transparency
-4.5.3 Sizes and Timeouts
-4.5.4 Queuing Strategies
-4.5.4.1 Sending Strategy
-4.5.4.2 Receiving Strategy
-4.5.5 Messages with a null reverse-path
-
-5. Address Resolution and Mail Handling
-
-6. Problem Detection and Handling
-6.1 Reliable Delivery and Replies by Email
-6.2 Loop Detection
-6.3 Compensating for Irregularities
-
-7. Security Considerations
-7.1 Mail Security and Spoofing
-7.2 "Blind" Copies
-7.3 VRFY, EXPN, and Security
-7.4 Information Disclosure in Announcements
-7.5 Information Disclosure in Trace Fields
-7.6 Scope of Operation of SMTP Servers
-
-8. IANA Considerations
-
-9. References
-
-10. Editors' Addresses
-
-11. Acknowledgments
-
-A. TCP Transport Service
-B. Generating SMTP Commands from RFC 822 Headers 
-C. Source Routes
-D. Scenarios
-E. Other Gateway Issues
-F. Deprecated Features of RFC 821
-X. Change Summary and Loose Ends (Temporary)
-
-
-0. Abstract
-
-This document is a self-contained specification of the basic protocol for
-the Internet electronic mail transport, consolidating and updating:
-
- - the original SMTP specification of RFC 821 [RFC-821],
-
- - domain name system requirements and implications for mail transport from
-   RFC 1035 [RFC-DNS] and RFC 974 [RFC-974],
-
- - the clarifications and applicability statements in RFC 1123 [RFC-1123],
-   and
-
- - material drawn from the SMTP Extension mechanisms [SMTPEXT].
-
-It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123.
-However, RFC 821 specifies some features that are not in significant use in
-the Internet of the mid-1990s and (in appendices) some additional transport
-models.  Those sections are omitted here in the interest of clarity and
-brevity; readers needing them should refer to RFC 821.
-
-It also includes some additional material from RFC 1123 that required
-amplification.  This material has been identified in multiple ways, mostly
-by tracking flaming on various lists and newsgroups and problems of unusual
-readings or interpretations that have turned up as the SMTP extensions have
-been deployed.  Where this specification moves beyond consolidation and
-actually differs from earlier documents, it supersedes them technically as
-well as textually.
-
-Although SMTP was designed as a mail transport and delivery protocol, this
-specification also contains information that is important to its use as a
-'mail posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and
-IMAP [RFC-IMAP4].
-
-Section 2.3 provides definitions of terms specific to this document. Except
-when the historical terminology is necessary for clarity, this document
-uses the current 'client' and 'server' terminology to identify the sending
-and receiving SMTP processes, respectively.
-
-A companion document discusses message headers, message bodies and formats
-and structures for them, and their relationship - [MSGFMT].
-
-
-1. Introduction
-
-The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer
-mail reliably and efficiently.
-
-SMTP is independent of the particular transmission subsystem and requires
-only a reliable ordered data stream channel.  While this document
-specifically discusses transport over TCP, other transports are possible.
-Appendices to RFC 821 describe some of them.
-
-An important feature of SMTP is its capability to transport mail across
-transport service environments, usually referred to as "SMTP mail relaying"
-(see section 3.8).  A transport service  environment might consist of the
-mutually-TCP-accessible hosts on  the public Internet, the
-mutually-TCP-accessible hosts on a firewall-isolated private TCP/IP
-Intranet, or hosts in some other LAN or WAN environment utilizing a
-different transport-level protocol.  It is important to realize that
-"transport service environments" are one-to-one with usual definitions of
-"networks".  A process can communicate directly with another process, and
-transport mail using this protocol, through any mutually known and
-connected transport service. Conversely, mail can be relayed or gatewayed
-between processes in two different transport service environments by a
-process known and connected to each of the two transport service
-environments. The Mail eXchanger mechanisms of the domain name system
-[RFC-DNS, and section 5 of this document] allows the identity of hosts
-supporting SMTP relay and gateway processes to be specified.
-
-
-2. The SMTP Model
-
-2.1 Basic Structure
-
-The SMTP design can be pictured as:
-
-               +----------+                +----------+
-   +------+    |          |                |          |
-   | User |<-->|          |      SMTP      |          |
-   +------+    |  Sender- |Commands/Replies| Receiver-|
-   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
-   | File |<-->|          |    and Mail    |          |<-->| File |
-   |System|    |          |                |          |    |System|
-   +------+    +----------+                +----------+    +------+
-                SMTP client                SMTP server
-
-When an SMTP client has a message to transmit, it establishes a two-way
-transmission channel to an SMTP server. The role of an SMTP client is to
-transfer mail messages to one or more SMTP servers, or report its failure
-to do so.
-
-The means by which a mail message is transferred to an SMTP client, and how
-that client determines the domain name(s) to which mail messages are to be
-transferred is a local matter, and is not addressed by this document. In
-some cases, the domain name(s) transferred to, or determined by, an SMTP
-client will identify the final destination(s) of the mail message. In other
-cases, common with SMTP clients associated with implementations of the POP
-[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client
-is inside an isolated transport service environment, the domain name
-determined will identify an intermediate destination through which all mail
-messages are to be relayed.  SMTP clients that transfer all traffic,
-regardless of the target domain names associated with the individual
-messages, or that do not maintain queues for retrying message transmissions
-that initially cannot be completed, may otherwise conform to this
-specification but are not considered fully-capable. Fully-capable SMTP
-implementations, including the relays used by these less capable ones, and
-their destinations, are expected to support all of the queuing, retrying,
-and alternate address functions discussed in this specification.
-
-The means by which an SMTP client, once it has determined a target domain
-name, determines the identity of an SMTP server to which a copy of a
-message is to be transferred, and then performs that transfer, is covered
-by this document. To effect a mail transfer to an SMTP server, an SMTP
-client establishes a two-way transmission channel to that SMTP server. An
-SMTP client determines the address of an appropriate host running an SMTP
-server by resolving a destination domain name to either an intermediate
-Mail eXchanger host or a final target host.
-
-An SMTP server may be either the ultimate destination or an intermediate
-"relay" (that is, it may assume the role of an SMTP client after receiving
-the message) or "gateway" (that is, it may transport the message further
-using some protocol other than SMTP).  SMTP commands are generated by the
-SMTP client and sent to the SMTP server.  SMTP replies are sent from the
-SMTP server to the SMTP client in response to the commands.
-
-Once the transmission channel is established and initial handshaking
-completed, the SMTP client normally initiates a mail transaction. Such a
-transaction consists of a series of commands to specify the originator and
-destination of the mail and transmission of the message content (including
-any headers or other structure) itself. When the same message is sent to
-multiple recipients, this protocol encourages the transmission of only one
-copy of the data for all recipients at the same destination (or
-intermediate relay) host.
-
-The server responds to each command with a reply; replies may indicate that
-the command was accepted, that additional commands are expected, or that a
-temporary or permanent error condition exists. Commands specifying the
-sender or recipients may include server-permitted SMTP service extension
-requests as discussed in section 2.2.  The dialog is purposely lock-step,
-one-at-a-time, although this can be modified by mutually-agreed extension
-requests such as in [RFC-Pipeline].
-
-Once a given mail message has been transmitted, the client may either
-request that the connection be shut down or may initiate other mail
-transactions. In addition, an SMTP client may use a connection to an SMTP
-server for ancillary services such as verification of email addresses or
-retrieval of mailing list subscriber addresses.
-
-As suggested above, this protocol provides mechanisms for the transmission
-of mail.  This transmission normally occurs directly from the sending
-user's host to the receiving user's host when the two hosts are connected
-to the same transport service.  When they are not connected to the same
-transport service, transmission occurs via one or more relay SMTP servers.
-An intermediate host that acts as either an SMTP relay or as a gateway into
-some other transmission environment is usually selected through the use of
-the domain name service (DNS) Mail eXchanger mechanism.
-
-To provide relay capability, the SMTP server is supplied with the name of
-the ultimate destination host as well as the destination mailbox name.
-Usually, intermediate hosts are determined via the DNS MX record, not by
-explicit "source" routing (see appendices C and F.2).
-
-2.2 The Extension Model
-
-2.2.1 Background
-
-In an effort that started in 1990, approximately a decade after RFC 821 was
-completed, the protocol was modified with a "service extensions" model that
-permits the client and server to agree to utilize shared functionality
-beyond the original SMTP requirements. The SMTP extension mechanism defines
-a means whereby an extended SMTP client and server may recognize each
-other, and the server can inform the client as to the service extensions
-that it supports.
-
-Contemporary SMTP implementations MUST support the basic extension
-mechanisms. For instance, servers MUST support the EHLO command even if
-they do not implement any specific extensions and clients SHOULD
-preferentially utilize EHLO rather than HELO. (However, for compatibility
-with older conforming implementations, SMTP clients and servers MUST
-support the original HELO mechanisms as a fallback.)  Unless the different
-characteristics of HELO must be identified for interoperability purposes,
-this document discusses only EHLO.
-
-SMTP is widely deployed and high-quality implementations have proven to be
-very robust. However, the Internet community now considers some services to
-be important that were not anticipated when the protocol was first
-designed.  If support for those services is to be added, it must be done in
-a way that permits older implementations to continue working acceptably.
-The extension framework consists of:
-
- - The SMTP command EHLO, superseding the earlier HELO,
-
- - a registry of SMTP service extensions,
-
- - additional parameters to the SMTP MAIL FROM and RCPT TO commands, and
-
- - optional replacements for verbs defined in this protocol, such as for
-   DATA (see [RFC-BDAT]).
-
-SMTP's strength comes primarily from its simplicity.  Experience with many
-protocols has shown that protocols with few options tend towards ubiquity,
-whereas protocols with many options tend towards obscurity.
-
-Each and every extension, regardless of its benefits, must be carefully
-scrutinized with respect to its implementation, deployment, and
-interoperability costs. In many cases, the cost of extending the SMTP
-service will likely outweigh the benefit.
-
-2.2.2 Definition and Registration of Extensions
-
-The IANA maintains a registry of SMTP service extensions.  A corresponding
-EHLO keyword value is associated with each extension. Each service
-extension registered with the IANA must be defined in a formal
-standards-track or IESG-approved experimental protocol document.  The
-definition must include:
-
- - the textual name of the SMTP service extension;
-
- - the EHLO keyword value associated with the extension;
-
- - the syntax and possible values of parameters associated with the
-   EHLO keyword value;
-
- - any additional SMTP verbs associated with the extension (additional
-   verbs will usually be, but are not required to be, the same as the
-   EHLO keyword value);
-
- - any new parameters the extension associates with the MAIL FROM or
-   RCPT TO verbs;
-
- - a description of how support for the extension affects the behavior
-   of a server and client SMTP; and,
-
- - the increment by which the extension is increasing the maximum
-   length of the commands MAIL FROM and/or RCPT TO, over that specified
-   in this standard.
-
-In addition, any EHLO keyword value starting with an upper or lower case
-"X" refers to a local SMTP service extension used exclusively through
-bilateral agreement.  Keywords beginning with "X" MUST NOT be used in a
-registered service extension.  Conversely, keyword values presented in the
-EHLO response that do not begin with "X" MUST correspond to a standard,
-standards-track, or IESG-approved experimental SMTP service extension
-registered with IANA.  A conforming server MUST NOT offer non-"X"-prefixed
-keyword values that are not described in a registered extension.
-
-Additional verbs and parameter names are bound by the same rules as EHLO
-keywords; specifically, verbs beginning with "X" are local extensions that
-may not be registered or standardized.  Conversely, verbs not beginning
-with "X" must always be registered.
-
-2.3 Terminology
-
-Most of the terminology in this document is common in the Internet at the
-time of its writing.  However, the following terms and concepts are used
-in special ways here, or represent differences in terminology between RFC
-821 and this document, and should be understood before reading further.
-These definitions are normative, that is, they contain specifications to
-which SMTP implementations are required to conform.
-
-The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are used
-in the same general sense here as in the Host Requirements Standards
-[RFC-1123].  Specifically, "MUST" or "MUST NOT" identify absolute
-requirements for conformance to this specification.  Implementations that
-do not conform to them lie outside the scope of this specification and
-often will not interoperate properly with SMTP implementations that do
-conform.  Implementations that are fully conforming also adhere to all
-"SHOULD" and "SHOULD NOT" requirements.  Implementations that adhere to
-all "MUST" ("MUST NOT") but not to all of these are considered to be
-partially conforming.  Such implementations may interoperate properly with
-fully conforming ones and with each other, but this will typically be the
-case only if great care is taken.  Consequently, an implementation should
-violation "SHOULD" ("SHOULD NOT") requirements only under exceptional and
-well-understood circumstances. "SHOULD" (and sometimes "MUST")
-requirements are often imposed by this specification when experience has
-shown that following such requirements or restrictions leads, in practice,
-to better interoperation, or smoother operation of the Internet email
-infrastructure. As a consequence, some of these statements constitute
-recommended practices, rather than the statistically most common practice
-at the time of this writing.  Statements using "MAY" describe features or
-styles of doing things that may be followed, or not, at the discretion of
-the implementation, normally without causing significant interoperability
-problems.  
-
-2.3.1 Mail Objects
-
-SMTP transports a mail object. A mail object contains an envelope and
-content.
-
-The SMTP envelope is sent as a series of SMTP protocol units (described in
-section 3). It consists of an originator address (to which error reports
-should be directed); a delivery mode (e.g., deliver to recipient
-mailboxes); one or more recipient addresses; and optional protocol
-extension material.
-
-The SMTP content is sent in the SMTP DATA protocol unit and has two parts:
-the headers and the body. If the content conforms to existing standards,
-the headers form a collection of field/value pairs structured as described
-in [MSGFMT]; the body, if structured, is defined according to MIME
-[RFC-MIME]. The content is textual in nature, expressed using the US-ASCII
-repertoire [US-ASCII]. Although SMTP extensions (such as [8BitMIME]) may
-relax this restriction for the content body, the content headers are always
-encoded using the US-ASCII repertoire. The algorithm defined in
-[RFC-INTLHDR] is used to represent header values outside the US-ASCII
-repertoire, while still encoding them using the US-ASCII repertoire.
-
-2.3.2 Senders and Receivers
-
-In RFC 821, the two hosts participating in an SMTP transaction were
-described as the "SMTP-sender" and "SMTP-receiver".  This document has been
-changed to reflect current industry terminology and hence refers to them as
-the "SMTP client" (or sometimes just "the client") and "SMTP server" (or
-just "the server"), respectively.  Since a given host may act both as
-server and client in a relay situation, "receiver" and "sender" terminology
-is still used where needed for clarity.
-
-2.3.3 Mail Agents
-
-Additional mail system terminology became common after RFC 821 was
-published and, where convenient, is used in this specification.  In
-particular, SMTP servers and clients provide a mail transport service and
-therefore act as Mail Transfer Agents (MTAs).  Mail User Agents (MUAs or
-UAs) are normally thought of as the sources and targets of mail.  At the
-source, an MUA might collect mail to be transmitted from a user and hand it
-off to an MTA; the final ("delivery") MTA would be thought of as handing
-the mail off to an MUA (or at least transferring responsibility to it).
-However, while these terms are used with at least the appearance of great
-precision in other environments, the implied boundaries between MUAs and
-MTAs often do not accurately match common, and conforming, practices with
-Internet mail.  Hence, the reader should be cautious about inferring the
-strong relationships and responsibilities that might be implied if these
-terms were used elsewhere.
-
-2.3.4 Host
-
-For the purposes of this specification, a host is a computer system
-attached to the Internet (or, in some cases, to a private TCP/IP network)
-and supporting the SMTP protocol.  Hosts are known by names (see "domain");
-identifying them by numerical address is discouraged.
-
-2.3.5 Domain
-
-A domain (or domain name) consists of one or more dot-separated components,
-each consisting of a sequence of letters, digits, and hyphens.  Domain
-names are used as names of hosts and of other entities in the domain name
-hierarchy. For example, a  domain may refer to an alias (label of a CNAME
-RR) or the label of Mail eXchanger records to be used to deliver mail
-instead of representing a host name. See [RFC-DNS] and section 5.
-
-The domain name, as described in this document and in [RFC-DNS], is the
-entire, fully-qualified name (often referred to as an "FQDN").  A domain
-name that is not in FQDN form is no more than a local alias.  Local aliases
-MUST NOT appear in any SMTP transaction.
-
-2.3.6 Buffer and State Table
-
-SMTP sessions are stateful, with both parties carefully maintaining a
-common view of the current state.  In this document we model this state by
-a virtual "buffer" and a "state table" on the server which may be used by
-the client to, for example, "clear the buffer" or "reset the state table,"
-causing the information in the buffer to be discarded and the state to be
-returned to some previous state
-
-2.3.7 Lines
-
-SMTP commands and, unless altered by a service extension, message data, are
-transmitted in "lines".  Lines consist of zero or more data characters
-terminated by the sequence ASCII character "CR" (hex value 0D) followed
-immediately by ASCII character "LF" (hex value 0A). This termination
-sequence is denoted as <CRLF> in this document. Conforming implementations
-MUST NOT recognize or generate any other character or character sequence as
-a line terminator.
-
-2.3.8 Originator, Delivery, Relay, and Gateway Systems
-
-This specification makes a distinction among four types of SMTP systems,
-based on the role those systems play in transmitting electronic mail.  An
-"originating" system (sometimes called an SMTP originator) introduces mail
-into the Internet or, more generally, into a transport service environment.
-A "delivery" SMTP system is one that receives mail from a transport service
-environment and hands it to a mail user agent or deposits it in a message
-store which a mail user agent is expected to subsequently access.  A
-"relay" SMTP system (usually referred to just as a "relay") receives mail
-from an SMTP client and transmits it, without modification to the message
-data other than adding trace information, to another SMTP server for
-further relaying or for delivery.
-
-A "gateway" SMTP system (usually referred to just as a "gateway") receives
-mail from a client system in one transport environment and transmits it to
-a server system in another transport environment. Differences in protocols
-or message semantics between the transport environments on either side of a
-gateway may require that the gateway system perform transformations to the
-message that are not permitted to SMTP relay systems.
-
-2.3.9 Message Content and Mail Data
-
-The terms "message content" and "mail data" are used interchangeably in
-this document to describe the material transmitted after the DATA command
-is accepted and before the end of data indication is transmitted.  Message
-content includes message headers and the possibly-structured message body.
-The MIME specification [RFC-MIME] provides the Standard mechanisms for
-structured message bodies.
-
-2.3.10 Mailbox and Address
-
-As used in this specification, an "address" is a character string that
-identifies a user to whom mail will be sent or a location into which mail
-will be deposited.  The term "mailbox" refers to that depository.  The two
-terms are typically used interchangeably unless the distinction between the
-location in which mail is placed (the mailbox) and a reference to it (the
-address) is important.  An address normally consists of user and domain
-specifications.  The standard mailbox naming convention is defined to be
-"local-part@domain": contemporary usage permits a much broader set of
-applications than simple "user names" and, consequently, the local-part is
-interpreted and assigned semantics only by the host specified in the domain
-part of the address.
-
-2.3.11 Reply
-
-An SMTP reply is an acknowledgment (positive or negative) sent from
-receiver to sender via the transmission channel in response to a command.
-The general form of a reply is a numeric completion code (indicating
-failure or success) usually followed by a text string.  The codes are for
-use by programs and the text is usually intended for human users.
-
-2.4 Syntax Principles
-
-2.4.1 General Syntax and Transaction Model
-
-SMTP commands and replies have a rigid syntax. All commands begin with a
-four letter command verb. All Replies begin with a three digit numeric
-code. In some commands and replies, arguments MUST follow the verb or reply
-code. Some commands do not accept arguments (after the verb), and some
-reply codes are followed, sometimes optionally, by free form text. In both
-cases, where text appears, it is separated from the verb or reply code by a
-<SP>. Complete definitions of commands and replies appear in section 4.
-
-Verbs and argument values are not case sensitive, with the sole
-exception in this specification of a mailbox local-part (SMTP
-Extensions may explicitly specify case-sensitive elements). That is, a
-command verb, an argument value other than a mailbox local-part, and
-free form text MAY be encoded in upper case, lower case, or any mixture
-of upper and lower case with no impact on its meaning.  This is NOT
-true of a mailbox local-part. The local-part of a mailbox MUST BE
-treated as case sensitive. Therefore, SMTP implementations MUST take
-care to preserve the case of mailbox local-parts.  Mailbox domains are
-not case sensitive.  However, exploiting the case sensitivity of
-mailbox local-parts impedes interoperability and is discouraged.
-
-Commands and replies are composed of characters from the ASCII character
-set [US-ASCII]. When the transport service provides an 8-bit byte (octet)
-transmission channel, each 7-bit character is transmitted right justified
-in an octet with the high order bit cleared to zero. More specifically, the
-unextended SMTP service provides seven bit transport only.  An originating
-SMTP client which has not successfully negotiated an appropriate extension
-with a particular server MUST NOT transmit messages with information in the
-high-order bit of octets.  If such messages are transmitted in violation of
-this rule, receiving SMTP servers MAY clear the high-order bit or reject
-the message as invalid.  In general, a relay SMTP SHOULD assume that the
-message content it has received is valid and, assuming that the envelope
-permits doing so, relay it without inspecting that content.  Of course, if
-the content is mislabeled and the data path cannot accept the actual
-content, this may result in ultimate delivery of a severely garbled message
-to the recipient.  Delivery SMTP systems MAY reject ("bounce") such
-messages rather than deliver them.  No sending SMTP system is permitted to
-send envelope commands in any character set other than US-ASCII; receiving
-systems SHOULD reject such commands, normally using "500 syntax error -
-invalid character" replies.
-
-Eight-bit message content transmission MAY be requested of the server by a
-client using extended SMTP facilities, notably the "8BITMIME" extension
-[8BITMIME].  8BITMIME SHOULD be supported by SMTP servers. However, it MUST
-not be construed as authorization to transmit unrestricted eight bit
-material.  8BITMIME MUST NOT be requested by senders for material with the
-high bit on that is not in MIME format with an appropriate content-transfer
-encoding; servers MAY reject such messages.
-
-The metalinguistic notation used in this document corresponds to the
-"Augmented BNF" used in other Internet mail system documents. The reader
-who is not familiar with that syntax should consult [ABNF]. Metalanguage
-terms used in running text are surrounded by pointed brackets (e.g.,
-<CRLF>) for clarity.
-
-2.4.2 Command and Reply Syntax
-
-The commands consist of a command verb followed by an argument field.
-Command verbs are four alphabetic characters and are case insensitive.
-
-This also applies to any symbols representing parameter values, such as
-"TO" or "to" for the forward-path.  Command verbs and the argument fields
-are separated by one or more spaces.  However, case is important in the
-local-part within the reverse-path and forward-path arguments.  In
-particular, for some hosts the user "smith" is different from the user
-"Smith".
-
-A few SMTP servers, in violation of this specification (and RFC 821)
-require that command verbs and certain argument text (such as the
-forward-path and reverse-path in RCPT and MAIL commands) be encoded by
-clients in upper case. Implementations MAY wish to employ this encoding to
-accommodate those servers.
-
-The argument field consists of a variable length character string ending
-with the character sequence <CRLF>.  The receiver will take no action until
-this sequence is received.
-
-The syntax for each command is shown with the discussion of that command.
-Common elements and parameters are shown in section 4.1.2.
-
-
-3. The SMTP Procedures: An Overview
-
-This section contains descriptions of the procedures used in SMTP: session
-initiation, the mail transaction, forwarding mail, verifying mailbox names
-and expanding mailing lists, and the opening and closing exchanges.
-Comments on relaying, a note on mail domains, and a discussion of changing
-roles are included at the end of this section.  Several complete scenarios
-are presented in appendix D.
-
-3.1 Session Initiation
-
-An SMTP session is initiated when a client opens a connection to a server
-and the server responds with an opening message.
-
-SMTP server implementations MAY include identification of their software
-and version information in the connection greeting reply after the 220
-code, a practice that permits more efficient isolation and repair of any
-problems. Implementations MAY make provision for SMTP servers to disable
-the software and version announcement where it causes security concerns.
-While some systems also identify their contact point for mail problems,
-this is not a substitute for maintaining the required "postmaster" address
-(see section 4.5.1).
-
-The SMTP protocol allows a server to formally reject a transaction while
-still allowing the initial connection as follows: a 554 response MAY be
-given in the initial connection opening message instead of the 220.  A
-server taking this approach MUST still wait for the client to send a QUIT
-(see section 4.1.1.10) before closing the connection and SHOULD respond to
-any intervening commands with "503 bad sequence of commands".  Since an
-attempt to make an SMTP connection to such a system is probably in error, a
-server returning a 554 response on connection opening SHOULD provide enough
-information in the reply text to facilitate debugging of the sending
-system.
-
-3.2 Client Initiation
-
-Once the server has sent the welcoming message and the client has received
-it, the client normally sends the EHLO command to the server, indicating
-the client's identity.  In addition to opening the session, use of EHLO
-indicates that the client is able to process service extensions and
-requests that the server provide a list of the extensions it supports.
-Older SMTP systems which are unable to support service extensions and
-contemporary clients which do not require service extensions in the mail
-session being initiated, MAY use HELO instead of EHLO.  Servers MUST NOT
-return the extended EHLO-style response to a HELO command.
-
-In the EHLO command the host sending the command identifies itself; the
-command may be interpreted as saying "Hello, I am <domain>" (and, in the
-case of EHLO, "and I support service extension requests").
-
-3.3 Mail Transactions
-
-There are three steps to SMTP mail transactions.  The transaction starts
-with a MAIL command which gives the sender identification.  A series of one
-or more RCPT commands follows giving the receiver information.  Then a DATA
-command initiates transfer of the mail data and is terminated by the "end
-of mail" data indicator, which also confirms the transaction.
-
-The first step in the procedure is the MAIL command.
-
-   MAIL FROM:<reverse-path> [ <mail-parameters> ] <CRLF>
-
-This command tells the SMTP-receiver that a new mail transaction is
-starting and to reset all its state tables and buffers, including any
-recipients or mail data. The <reverse-path> contains the source mailbox
-(between "<" and ">" brackets, which can be used to report errors (see
-section 4.2 for a discussion of error reporting).  If accepted, the
-SMTP server returns a 250 OK reply.  If the mailbox specification is
-not acceptable for some reason, the server MUST return a reply
-indicating whether the failure is permanent (i.e., will occur again if
-the client tries to send the same address again) or temporary (i.e.,
-the address might be accepted if the client tries again later). Despite
-the apparent scope of this requirement, there are circumstances in
-which the acceptability of the reverse-path may not be determined until
-one or more forward-paths (in RCPT commands) can be examined.  In those
-cases, the server MAY reasonably accept the reverse-path (with a 250
-reply) and then report problems after the forward-paths are received
-and examined.  Normally, failures produce 550 or 553 replies.
-
-Historically, the <reverse-path> can contain more than just a mailbox,
-however, contemporary systems SHOULD NOT use source routing (see appendix
-C).
-
-The optional <mail-parameters> are associated with negotiated SMTP service
-extensions (see section 2.2).
-
-The second step in the procedure is the RCPT command.
-
-   RCPT TO:<forward-path> [ <SP> <rcpt-parameters> ] <CRLF>
-
-This command gives a forward-path (normally a mailbox and domain,
-always surrounded by "<" and ">" brackets) identifying one recipient.
-If accepted, the SMTP server returns a 250 OK reply and stores the
-forward-path.  If the recipient is known not to be a deliverable
-address, the SMTP server returns a 550 reply, typically with a string
-such as "no such user - " and the mailbox name (other circumstances and
-reply codes are possible).  This step of the procedure can be repeated
-any number of times.
-
-The <forward-path> can contain more than just a mailbox.  Historically, the
-<forward-path> can be a source routing list of hosts and the destination
-mailbox, however, contemporary SMTP clients SHOULD NOT utilize source
-routes (see appendix C). Servers MUST be prepared to encounter a list of
-source routes in the forward path, but SHOULD ignore the routes or MAY
-decline to support the relaying they imply.  Similarly, servers MAY decline
-to accept mail that is destined for other hosts or systems.  These
-restrictions make a server useless as a relay for clients that do not
-support full SMTP functionality.  Consequently, restricted-capability
-clients MUST NOT assume that any SMTP server on the Internet can be used as
-their mail processing  (relaying) site. If RCPT TO appears without a
-previous MAIL FROM, the server MUST return a 503 "Bad sequence of commands"
-response. The optional <rcpt-parameters> are associated with negotiated
-SMTP service extensions (see section 2.2).
-
-The third step in the procedure is the DATA command (or some alternative
-specified in a service extension).
-
-   DATA <CRLF>
-
-If accepted, the SMTP server returns a 354 Intermediate reply and considers
-all succeeding lines up to but not including the end of mail data indicator
-to be the message text.  When the end of text is successfully received and
-stored the SMTP-receiver sends a 250 OK reply.
-
-Since the mail data is sent on the transmission channel, the end of mail
-data must be indicated so that the command and reply dialog can be resumed.
-SMTP indicates the end of the mail data by sending a line containing only a
-"." (period or full stop).  A transparency procedure is used to prevent
-this from interfering with the user's text (see section 4.5.2).
-
-The end of mail data indicator also confirms the mail transaction and tells
-the SMTP server to now process the stored recipients and mail data.  If
-accepted, the SMTP server returns a 250 OK reply. The DATA command can fail
-in only two ways:
-
- - If there was no MAIL FROM, or no RCPT TO, command, or all such commands
-   were rejected, the server MAY return a "command out of sequence" (503)
-   reply.  If that reply is received, the client MUST NOT send the message
-   data; more generally, message data MUST NOT be sent unless a 354 reply
-   is received.
-
- - If the verb is initially accepted and the 354 reply issued, the DATA
-   command should fail only if the mail transaction was incomplete (for
-   example, no recipients), or if resources were unavailable, or if the
-   server determines that the message should be rejected for policy or
-   other reasons.
-
-However, in practice, some servers do not perform recipient verification
-until after the message text is received.  These servers SHOULD treat a
-failure for one or more recipients as a "subsequent failure" and return a
-mail message as discussed in section 6.  Using a "550 mailbox not found"
-(or equivalent) reply code after the data are accepted makes it difficult
-or impossible for the client to determine which recipients failed.
-
-When RFC 822 format is being used, the mail data include the memo header
-items such as Date, Subject, To, Cc, From [MSGFMT].  Server SMTP systems
-SHOULD NOT reject messages based on perceived defects in the RFC 822 or
-MIME [RFC-MIME] message header or message body.  In particular, they MUST
-NOT reject messages in which the numbers of Resent- fields do not match or
-Resent-to appears without Resent-from and/or Resent-date.
-
-Mail transaction commands MUST be used in the order discussed above.
-
-
-3.4 Forwarding for Address Correction or Updating
-
-Forwarding support is most often required to consolidate and simplify
-addresses within, or relative to, some enterprise and less frequently to
-establish addresses to link a person's prior address with current one.
-Silent forwarding of messages (without server notification to the sender),
-for security or non-disclosure purposes, is common in the contemporary
-Internet.
-
-In both the enterprise and the "new address" cases, information hiding
-(and sometimes security) considerations argue against exposure of the
-"final" address through the SMTP protocol as a side-effect of the
-forwarding activity.  This may be especially important when the final
-address may not even be reachable by the sender.  Consequently, the
-"forwarding" mechanisms described in section 3.2 of RFC 821, and
-especially the 251 (corrected destination) reply code from RCPT TO are
-deprecated: Servers SHOULD NOT provide that service or return that code.
-
-
-3.5 Commands for Debugging Addresses
-
-3.5.1 Overview
-
-SMTP provides commands to verify a user name or obtain the content of a
-mailing list.  This is done with the VRFY and EXPN commands, which have
-character string arguments.  Implementations SHOULD support VRFY and EXPN
-(however, see section 3.5.2 and 7.3).
-
-For the VRFY command, the string is a user name or a user name and domain
-(see below). If a normal (i.e., 250) response is returned, the response MAY
-include the full name of the user and MUST include the mailbox of the user.
-It MUST be in either of the following forms:
-
-   User Name <local-part@domain>
-   local-part@domain
-
-When a name that is the argument to VRFY could identify more than one
-mailbox, the server MAY either note the ambiguity or identify the
-alternatives.  In other words, any of the following are legitimate
-response to VRFY:
-
-   553 User ambiguous
-
-or
-
-   553- Ambiguous;  Possibilities are
-   553-Joe Smith <jsmith@foo.com>
-   553-Harry Smith <hsmith@foo.com>
-   553 Melvin Smith <dweep@foo.com>
-
-or
-
-   553-Ambiguous;  Possibilities 
-   553- <jsmith@foo.com>
-   553- <hsmith@foo.com>
-   553 <dweep@foo.com>
-
-Under normal circumstances, a client receiving a 553 reply would be
-expected to expose the result to the user.  Use of exactly the forms
-given, and the "user ambiguous" or "ambiguous" keywords, possibly
-supplemented by extended reply codes such as those described in
-[RFC-REPLY], will facilitate automated translation into other languages as
-needed. Of course, a client that was highly automated or that was
-operating in another language than English, might choose to try to
-translate the response, to return some other indication to the user than
-the literal text of the reply, or to take some automated action such as
-consulting a directory service for additional information before reporting
-to the user.
-
-For the EXPN command, the string identifies a mailing list, and the
-successful (i.e., 250) multiline response MAY include the full name of the
-users and MUST give the mailboxes on the mailing list.
-
-In some hosts the distinction between a mailing list and an alias for a
-single mailbox is a bit fuzzy, since a common data structure may hold both
-types of entries, and it is possible to have mailing lists of one mailbox.
-If a request is made to verify a mailing list, a positive response MAY be
-given if a message so addressed would be delivered to everyone on the list,
-otherwise an error SHOULD be reported (e.g., "550 That is a mailing list,
-not a user" or "252 Unable to verify members of mailing list").  If a
-request is made to expand a user name, the server MAY return a positive
-response consisting of a list containing one name, or an error MAY be
-reported (e.g., "550 That is a user name, not a mailing list").
-
-In the case of a successful multiline reply (normal for EXPN) exactly one
-mailbox is to be specified on each line of the reply.  The case of an
-ambiguous request is discussed above.
-
-"User name" is a fuzzy term and has been used deliberately.  An
-implementation of the VRFY or EXPN commands MUST include at least
-recognition of local mailboxes as "user names".  However, since current
-Internet practice often results in a single host handling mail for
-multiple domains, hosts, especially hosts that provide this functionality,
-SHOULD accept the "local-part@domain" form as a "user name"; hosts MAY
-also choose to recognize other strings as "user names".
-
-The case of expanding a mailbox list requires a multiline reply, such as:
-
-   C: EXPN Example-People
-   S: 250-Jon Postel <Postel@isi.edu>
-   S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
-   S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
-
-or
-
-   C EXPN Executive-Washroom-List
-   S: 550 Access Denied to You.
-
-The character string arguments of the VRFY and EXPN commands cannot be
-further restricted due to the variety of implementations of the user name
-and mailbox list concepts.  On some systems it may be appropriate for the
-argument of the EXPN command to be a file name for a file containing a
-mailing list, but again there are a variety of file naming conventions in
-the Internet.  Similarly, historical variations in what is returned by
-these commands are such that the response SHOULD be interpreted very
-carefully, if at all, and SHOULD generally only be used for diagnostic
-purposes.
-
-3.5.2 VRFY Normal Response
-
-When normal (2yz or 551) responses are returned from a VRFY or EXPN
-request, the reply MUST normally include the mailbox name.
-"<local-part@domain>", where "domain" is a fully qualified domain name,
-MUST appear in the syntax.  In exceptional circumstances, free-form text
-MAY be returned.  In order to facilitate parsing by both computers and
-people, addresses SHOULD appear in pointed brackets.  When addresses,
-rather than free-form debugging information, are returned, EXPN and VRFY
-MUST return only valid domain addresses that are usable in SMTP RCPT
-commands.  Consequently, if an address implies delivery to a program or
-other system, the mailbox name used to reach that target MUST be given.
-Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN.
-
-Server implementations SHOULD support both VRFY and EXPN. For security
-reasons, implementations MAY provide local installations a way to disable
-either or both of these commands through configuration options or the
-equivalent.  When these commands are supported, they are not required to
-work across relays when relaying is supported.  Since they were both
-optional in RFC 821, they MUST be listed as service extensions in an EHLO
-response, if they are supported.
-
-3.5.3 Meaning of VRFY or EXPN Success Response
-
-A server MUST NOT return a 220 code in response to a VRFY or EXPN command
-unless it has actually verified the address.  In particular, a server MUST
-NOT return 220 if all it has done is to verify that the syntax given is
-valid.  In that case, 502 (Command not implemented) or 500 (Syntax error,
-command unrecognized) SHOULD be returned.  As stated elsewhere,
-implementation of VRFY and EXPN are strongly recommended.
-Hence, implementations that return 500 or 502 for VRFY are not in full
-compliance with this specification.
-
-There may be circumstances where an address appears to be valid but cannot
-reasonably be verified in real time, particularly when a server is acting
-as a mail exchanger for another server or domain. "Apparent validity" in
-this case would normally involve at least syntax checking and might
-involve verification that any domains specified were ones to which the
-host expected to be able to relay mail.  In these situations, reply code
-252 SHOULD be returned.  These cases parallel the discussion of RCPT
-verification discussed in section 2.1.  Implementations generally SHOULD
-be more aggressive about address verification in the case of VRFY than in
-the case of RCPT, even if it takes a little longer to do so.
-
-3.5.4 Semantics and Applications of EXPN
-
-EXPN is often very useful in debugging and understanding problems with
-mailing lists and multiple-target-address aliases. Some systems have
-attempted to use source expansion of mailing lists as a means of
-eliminating duplicates.  The propagation of aliasing systems with mail on
-the Internet, for hosts (typically with MX and CNAME DNS records), for
-mailboxes (various types of local host aliases), and in various proxying
-arrangements, has made it nearly impossible for these strategies to work,
-and mail systems SHOULD NOT attempt them.
-
-3.6 Domains
-
-Only resolvable, fully-qualified, domain names (FQDNs) are permitted when
-domain names are used in SMTP.  In other words, names that can be resolved
-to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME
-RRs whose targets can be resolved, in turn, to MX or A RRs.  Local
-nicknames or unqualified names MUST NOT be used.  There are two exceptions
-to the rule requiring FQDNs:
-
- - The domain name given in the EHLO command MUST BE either a primary host
-   name (a domain name that resolves to an A RR) or, if the host has no
-   name, an address literal as described in section 4.1.1.1.
-
- - The reserved mailbox name "postmaster" may be used in a RCPT TO command
-   without domain qualification (see section 4.1.1.3) and MUST be accepted
-   if so used.
-
-3.7 Relaying
-
-In general, the availability of Mail eXchanger records in the domain name
-system [RFC-DNS] makes the use of explicit source routes in the Internet
-mail system unnecessary.  Many historical problems with their
-interpretation have made their use undesirable.  SMTP clients SHOULD NOT
-generate explicit source routes except under unusual circumstances.  SMTP
-servers MAY decline to act as mail relays or to accept addresses that
-specify source routes.  When route information is encountered, they are
-also permitted to ignore the route information and simply send to the final
-destination specified as the last element in the route and SHOULD do so.
-There has been an invalid practice of using names that do not appear in the
-DNS as destination names, with the senders counting on the intermediate
-hosts specified in source routing to resolve any problems.  If source
-routes are stripped, this practice will cause failures. This is one of
-several reasons why SMTP clients MUST NOT generate invalid source routes or
-depend on serial resolution of names.
-
-When source routes are not used, the process described in RFC 821 for
-constructing a reverse-path from the forward-path is not applicable and the
-reverse-path at the time of delivery will simply be the address that
-appeared in the MAIL command.
-
-A relay SMTP server is usually the target of a DNS MX record that
-designates it, rather than the final delivery system. The relay server may
-accept or reject the task of relaying the mail in the same way it accepts
-or rejects mail for a local user.  If it accepts the task, it then becomes
-an SMTP client, establishes a transmission channel to the next SMTP server
-specified in the DNS (according to the rules in section 5), and sends it
-the mail.  If it declines to relay mail to a particular address for policy
-reasons, a 550 response SHOULD be returned.
-
-If an SMTP server has accepted the task of relaying the mail and later
-finds that the destination is incorrect or that the mail cannot be
-delivered for some other reason, then it MUST construct an "undeliverable
-mail" notification message and send it to the originator of the
-undeliverable mail (as indicated by the reverse-path).  Formats specified
-for non-delivery reports by other standards (see, for example,
-[RFC-NOTARY1]) SHOULD be used if possible.
-
-This notification message must be from the SMTP server at the relay host
-or the host that first determines that delivery cannot be accomplished.
-Of course, SMTP servers MUST NOT send notification messages about problems
-transporting notification messages.  One way to prevent loops in error
-reporting is to specify a null reverse-path in the MAIL command of a
-notification message.  When such a message is transmitted the reverse-path
-MUST be set to null (see section 4.5.5 for additional discussion).  A MAIL
-command with a null reverse-path appears as follows:
-
-   MAIL FROM:<>
-
-As discussed in section 2.4.1, a relay SMTP has no need to inspect or act
-upon the headers or body of the message data and MUST NOT do so except
-to add its own "Received:" header (section 4.4) and to perform simple
-counting of the number of "Received:" headers in a message (section 6.2).
-
-3.8 Mail Gatewaying
-
-While the relay function discussed above operates within the Internet SMTP
-transport service environment, MX records or various forms of explicit
-routing may require that an intermediate SMTP server perform a translation
-function between one transport service and another.  As discussed in
-section 2.3.8, when such a system is at the boundary between two transport
-service environments, we refer to it as a "gateway" or "gateway SMTP".
-
-Gatewaying mail between different mail environments, such as different mail
-formats and protocols, is complex and does not easily yield to
-standardization.  However, some general requirements may be given for a
-gateway between the Internet and another mail environment.
-
-3.8.1 Header Fields in Gatewaying
-
-Header fields MAY be rewritten when necessary as messages are gatewayed
-across mail environment boundaries. This may involve inspecting the message
-body or interpreting the local-part of the destination address in spite of
-the prohibitions in section 2.4.1
-
-Other mail systems gatewayed to the Internet often use a subset of RFC-822
-headers or provide similar functionality with a different syntax, but some
-of these mail systems do not have an equivalent to the SMTP envelope.
-Therefore, when a message leaves the Internet environment, it may be
-necessary to fold the SMTP envelope information into the message header.  A
-possible solution would be to create new header fields to carry the
-envelope information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however,
-this would require changes in mail programs in foreign environments and
-might risk disclosure of private information (see section 7.2).
-
-3.8.2 Received Lines in Gatewaying
-
-When forwarding a message into or out of the Internet environment, a
-gateway MUST prepend a Received: line, but it MUST NOT alter in any way a
-Received: line that is already in the header.
-
-Received: fields of messages originating from other environments may not
-conform exactly to this specification.  However, the most important use of
-Received: lines is for debugging mail faults, and this debugging can be
-severely hampered by well-meaning gateways that try to "fix" a Received:
-line.  As another consequence of trace fields arising in non-SMTP
-environments, receiving systems MUST NOT reject mail based on the format of
-a trace field and SHOULD be extremely robust in the light of unexpected
-information or formats in those fields.
-
-The gateway SHOULD indicate the environment and protocol in the "via"
-clauses of Received field(s) that it supplies.
-
-3.8.3 Addresses in Gatewaying
-
->From the Internet side, the gateway SHOULD accept all valid address formats
-in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages.
-Gateways are, of course, subject to the same rules for handling source
-routes as those described for other SMTP systems in section 3.3.
-
-3.8.4 Other Header Fields in Gatewaying
-
-The gateway MUST ensure that all header fields of a message that it
-forwards into the Internet meet the requirements for Internet mail.  In
-particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be
-transformed (if necessary) to satisfy RFC-822 syntax, MUST reference only
-fully-qualified domain names, and MUST be effective and useful for sending
-replies.  3.8.5 The translation algorithm used to convert mail from the
-Internet protocols to another environment's protocol SHOULD ensure that
-error messages from the foreign mail environment are delivered to the
-return path from the SMTP envelope, not to the sender listed in the "From:"
-field (or other fields) of the RFC-822 message.
-
-3.8.5 Envelopes in Gatewaying
-
-Similarly, when forwarding a message from another environment into the
-Internet, the gateway SHOULD set the envelope return path in accordance
-with an error message return address, if supplied by the foreign
-environment.  If the foreign environment has no equivalent concept, the
-gateway must select and use a best approximation, with the message
-originator's address as the default of last resort.
-
-3.9 Terminating Sessions and Connections
-
-An SMTP connection is terminated when the client sends a QUIT command.  The
-server responds with a positive reply code, after which it closes the
-connection.
-
-An SMTP server MUST NOT intentionally close the connection except:
-
- - After receiving a QUIT command and responding with a 221 reply.
-
- - After detecting the need to shutdown the SMTP service and returning a
-   421 response code.  This response code can be issued after the server
-   receives any command or, if necessary, asynchronously from command
-   receipt (on the assumption that the client will receive it after the
-   next command is issued).
-
-In particular, a server that closes connections in response to commands
-that are not understood is in violation of this specification. Servers are
-expected to be tolerant of unknown commands, issuing a 500 reply and
-awaiting further instructions from the client.
-
-An SMTP server which is forcibly shut down via external means SHOULD
-attempt to send a line containing a 421 response code to the SMTP client
-before exiting.  The SMTP client will normally read the 421 response code
-after sending its next command.
-
-SMTP clients that experience a connection close, reset, or other
-communications failure due to circumstances not under their control (in
-violation of the intent of this specification but sometimes unavoidable)
-SHOULD, to maintain the robustness of the mail system, treat the mail
-transaction as if a 451 response had been received and act accordingly.
-
-3.10 Mailing Lists and Aliases
-
-An SMTP-capable host SHOULD support both the alias and the list models of
-address expansion for multiple delivery.  When a message is delivered or
-forwarded to each address of an expanded list form, the return address in
-the envelope ("MAIL FROM:") MUST be changed to be the address of a person
-or other entity who administers the list.  However, in this case, the
-message header (see [MSGFMT]) MUST be left unchanged; in particular, the
-"From" field of the message header is unaffected.
-
-An important mail facility is a mechanism for multi-destination delivery
-of a single message, by transforming (or "expanding" or "exploding") a
-pseudo-mailbox address into a list of destination mailbox addresses. When
-a message is sent to such a pseudo-mailbox (sometimes called an
-"exploder"), copies are forwarded or redistributed to each mailbox in the
-expanded list.  Servers SHOULD simply utilize the addresses on the list;
-application of heuristics or other matching rules to eliminate some
-addresses, such as that of the originator, is strongly discouraged.  We
-classify such a pseudo-mailbox as an "alias" or a "list", depending upon
-the expansion rules.
-
-3.10.1 Alias
-
-To expand an alias, the recipient mailer simply replaces the pseudo-mailbox
-address in the envelope with each of the expanded addresses in turn; the
-rest of the envelope and the message body are left unchanged.  The message
-is then delivered or forwarded to each expanded address.
-
-3.10.2 List
-
-A mailing list may be said to operate by "redistribution" rather than
-by "forwarding".  To expand a list, the recipient mailer replaces the
-pseudo-mailbox address in the envelope with all of the expanded
-addresses.  The return address in the envelope is changed so that all
-error messages generated by the final deliveries will be returned to a
-list administrator, not to the message originator, who generally has no
-control over the contents of the list and will typically find error
-messages annoying.
-
-
-4. The SMTP Specifications
-
-4.1 SMTP Commands
-
-4.1.1 Command Semantics and Syntax
-
-The SMTP commands define the mail transfer or the mail system function
-requested by the user.  SMTP commands are character strings terminated by
-<CRLF>.  The commands themselves are alphabetic characters terminated by
-<SP> if parameters follow and <CRLF> otherwise.  (In the interest of
-improved interoperability, SMTP receivers are encouraged to tolerate
-trailing white space before the terminating <CRLF>.)  The syntax of the
-local part of a mailbox must conform to receiver site conventions and the
-syntax specified in section 4.1.2.  The SMTP commands are discussed below.
-The SMTP replies are discussed in section 4.2.
-
-A mail transaction involves several data objects which are communicated as
-arguments to different commands.  The reverse-path is the argument of the
-MAIL command, the forward-path is the argument of the RCPT command, and the
-mail data is the argument of the DATA command.  These arguments or data
-objects must be transmitted and held pending the confirmation communicated
-by the end of mail data indication which finalizes the transaction.  The
-model for this is that distinct buffers are provided to hold the types of
-data objects, that is, there is a reverse-path buffer, a forward-path
-buffer, and a mail data buffer.  Specific commands cause information to be
-appended to a specific buffer, or cause one or more buffers to be cleared.
-
-Several commands (RSET, DATA, QUIT) are specified as not permitting
-parameters.   In the absence of specific extensions offered by the server
-and accepted by the client, clients MUST NOT send such parameters and
-servers SHOULD reject commands containing them as having invalid syntax.  
-
-4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
-
-These commands are used to identify the SMTP client to the SMTP server.
-The argument field contains the fully-qualified domain name of the SMTP
-client if one is available.  In situations in which the SMTP client system
-does not have a meaningful domain name (e.g., when its address is
-dynamically allocated and no reverse mapping record is available), the
-client SHOULD send an address literal (see section 4.1.3), optionally
-followed by information that will help to identify the client system.
-
-The SMTP server identifies itself to the SMTP client in the connection
-greeting reply and in the response to this command.
-
-A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If
-the SMTP server supports the SMTP service extensions it will give a
-successful response, a failure response, or an error response. If the SMTP
-server, in violation of this specification, does not support any SMTP
-service extensions it will generate an error response.  Older client SMTP
-systems MAY, as discussed above, use HELO (as specified in RFC 821) instead
-of EHLO, and servers MUST support the HELO command and reply properly to
-it.  In any event, a client MUST issue HELO or EHLO before starting a mail
-transaction.
-
-These commands, and a "250 OK" reply to one of them, confirm that both the
-SMTP client and the SMTP server are in the initial state, that is, there is
-no transaction in progress and all state tables and buffers are cleared.
-
-Normally, the response to EHLO will be a multiline reply.  Each line of the
-response contains a keyword and, optionally, one or more parameters.  The
-syntax for a positive response, using the ABNF notation and low-level
-terminals of [ABNF], is:
-
-   ehlo-ok-rsp  ::=      "250"    domain [ <SP> greeting ] <CRLF>
-                  / (    "250-"   domain [ <SP> greeting ] <CRLF>
-                      *( "250-"   ehlo-line                <CRLF> )
-                         "250"    <SP> ehlo-line           <CRLF>    )
-   
-   greeting     ::= 1*<any character other than CR or LF>
-   
-   ehlo-line    ::= ehlo-keyword *( <SP> ehlo-param )
-   
-   ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
-                ; syntax and values depend on ehlo-keyword
-
-   ehlo-param   ::= 1*<any CHAR excluding <SP> and all
-                       control characters (US-ASCII 0-31
-                       inclusive)>
-   
-   ALPHA        ::= any one of the 52 alphabetic characters, i.e.,
-                    (A through Z in upper case, and, a through z in lower
-					case) 
-
-Although EHLO keywords may be specified in upper, lower, or mixed case,
-they MUST always be recognized and processed in a case-insensitive manner.
-This is simply an extension of practices specified in RFC 821 and section
-2.4.1.
-
-4.1.1.2 MAIL (MAIL)
-
-This command is used to initiate a mail transaction in which the mail data
-is delivered to one or more mailboxes.  The argument field contains a
-reverse-path.  In general, the MAIL command may be sent only when no mail
-transaction is in progress, see section 4.1.4.
-
-The reverse-path consists of the sender mailbox or a list of hosts.  In
-some types of reporting messages for which a reply is likely to cause a
-mail loop (for example, mail delivery and nondelivery notifications), the
-reverse-path may be null (see section 3.7).
-
-This command clears the reverse-path buffer, the forward-path buffer, and
-the mail data buffer; and inserts the reverse-path information from this
-command into the reverse-path buffer.
-
-If service extensions were negotiated, the MAIL command may also carry
-parameters associated with a particular service extension.
-
-Syntax:
-
-   "MAIL FROM:" Reverse-path  [ <SP> Mail-parameters ]
-
-or
-   "MAIL FROM:<>" [ <SP> Mail-parameters ] 
-
-4.1.1.3 RECIPIENT (RCPT)
-
-This command is used to identify an individual recipient of the mail data;
-multiple recipients are specified by multiple use of this command.
-
-The forward-path normally consists of the required destination mailbox or
-mailboxes.  Sending systems SHOULD not generate the optional list of hosts
-known as a source route.  Receiving systems MUST recognize source route
-syntax but SHOULD strip off the source route specification and utilize the
-domain name associated with the mailbox as if the source route had not been
-provided.
-
-Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST
-NOT be copied into the reverse-path. When mail reaches its ultimate
-destination (the forward-path contains only a destination mailbox), the
-SMTP server inserts it into the destination mailbox in accordance with its
-host mail conventions.
-
-For example, mail received at relay host xyz.com with envelope commands
-
-   MAIL FROM:<userx@y.foo.org>
-   RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
-
-will normally be sent directly on to host d.bar.org with envelope commands
-
-   MAIL FROM:<userx@y.foo.org>
-   RCPT TO:<USERC@D.bar.org>
-
-As provided in appendix C, xyz.com MAY also choose to relay the message to
-jkl.org, using the envelope commands
-
-   MAIL FROM:<userx@y.foo.org>
-   RCPT TO:<@jkl.org:userc@d.bar.org>
-
-Of course, since hosts are not required to relay mail at all, xyz.com may
-also reject the message entirely when the RCPT TO command is received,
-using a 550 code (since this is a "policy reason").
-
-If service extensions were negotiated, the RCPT TO command may also carry
-parameters associated with a particular service extension offered by the
-server.  The client MUST NOT transmit parameters other than those
-associated with a service extension offered by the server in its EHLO
-response.
-
-Syntax:
-   "RCPT TO:" Forward-path  [ <SP> Rcpt-parameters ]
-or
-   "RCPT TO:<Postmaster>" [ <SP> Rcpt-parameters ]
-
-4.1.1.4 DATA (DATA)
-
-The receiver treats the lines (strings ending in <CRLF> sequences, as
-described in section 2.3.7) following the command as mail data from the
-sender. This command causes the mail data to be appended to the mail data
-buffer.  The mail data may contain any of the 128 ASCII character codes,
-although experience has indicated that use of control characters other than
-SP, HT, CR, and LF (especially the ASCII "Null" character) may cause
-problems and SHOULD be avoided when possible.
-
-The mail data is terminated by a line containing only a period, that is,
-the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This is the
-end of mail data indication.  Note that the first <CRLF> of this
-terminating sequence is also the <CRLF> that ends the final line of the
-data (message text) or, if there was no data, ends the DATA command itself.
-An extra <CRLF> MUST NOT be added, as that would cause an empty line to be
-added to the message. The only exception to this rule would arise if the
-message body were passed to the originating SMTP-sender with a final "line"
-that did not end in <CRLF>; in that case, the originating SMTP system MUST
-either reject the message as invalid or add <CRLF> in order to have the
-receiving SMTP server recognize the "end of data" condition.
-
-The custom of accepting lines ending only in <LF>, as a concession to
-non-conforming behavior on the part of some UNIX systems, has proven to
-cause more interoperability problems than it solves, and SMTP server
-systems MUST NOT do this, even in the name of improved robustness.  In
-particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage
-returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of
-mail data indication.
-
-Receipt of the end of mail data indication requires the server to process
-the stored mail transaction information.  This processing consumes the
-information in the reverse-path buffer, the forward-path buffer, and the
-mail data buffer, and on the completion of this command these buffers are
-cleared.  If the processing is successful, the receiver MUST send an OK
-reply.  If the processing fails the receiver MUST send a failure reply. The
-SMTP model does not allow for partial failures at this point: either the
-message is accepted by the server for delivery and a positive response is
-returned or it is not accepted and a failure reply is returned.  Errors
-that are diagnosed subsequently MUST be reported in a mail message, as
-discussed in section 4.4 In sending a positive completion reply to the end
-of data indication, the receiver takes full responsibility for the message
-(see section 6.1).
-
-When the SMTP server accepts a message either for relaying or for final
-delivery, it inserts a trace record (also referred to interchangeably as a
-"time stamp line" or "Received" line) at the top of the mail data.  This
-trace record indicates the identity of the host that sent the message, the
-identity of the host that received the message (and is inserting this time
-stamp), and the date and time the message was received.  Relayed messages
-will have multiple time stamp lines.  Details for formation of these lines,
-including their syntax, is specified in section 4.4.
-
-4.1.1.5 RESET (RSET)
-
-This command specifies that the current mail transaction will be aborted.
-Any stored sender, recipients, and mail data MUST be discarded, and all
-buffers and state tables cleared.  The receiver MUST send a "250 OK" reply
-to a RSET command with no arguments.  A reset command may be issued by the
-client at any time.  It is effectively equivalent to a NOOP if issued
-immediately after EHLO, before EHLO is issued in the session, after an
-end-of-data indicator has been sent and acknowledged, or immediately before
-a QUIT. In other situations, it restores the state to that immediately
-after the most recent EHLO.  An SMTP server MUST NOT close the connection
-as the result of receiving a RSET; that action is reserved for QUIT (see
-section 4.1.1.10).
-
-Since EHLO implies some additional processing and response by the server,
-RSET will normally be more efficient than reissuing that command, even
-though the formal semantics are the same.
-
-There are circumstances, contrary to the intent of this specification, in
-which an SMTP server may receive an indication that the underlying TCP
-connection has been closed or reset.  To preserve the robustness of the
-mail system, SMTP servers SHOULD be prepared for this condition and SHOULD
-treat it as if a QUIT had been received before the connection disappeared.
-
-Syntax:
-   "RSET"
-
-4.1.1.6 VERIFY (VRFY)
-
-This command asks the receiver to confirm that the argument identifies a
-user or mailbox.  If it is a user name, information is returned as
-specified in section 3.5.
-
-This command has no effect on the reverse-path buffer, the forward-path
-buffer, or the mail data buffer.
-
-Syntax: 
-   "VRFY" <SP> String
-
-4.1.1.7 EXPAND (EXPN)
-
-This command asks the receiver to confirm that the argument identifies a
-mailing list, and if so, to return the membership of that list.  If the
-command is successful, a reply is returned containing information as
-described in section 3.5.  This reply will have multiple lines except in
-the trivial case of a one-member list.
-
-This command has no effect on the reverse-path buffer, the forward-path
-buffer, or the mail data buffer.
-
-Syntax:
-   "EXPN" <SP> String
-
-4.1.1.8 HELP (HELP)
-
-This command causes the server to send helpful information to the client.
-The command MAY take an argument (e.g., any command name) and return more
-specific information as a response.
-
-This command has no effect on the reverse-path buffer, the forward-path
-buffer, or the mail data buffer.
-
-SMTP servers SHOULD support HELP without arguments and MAY support it with
-arguments.
-
-Syntax:
-   "HELP" [ <SP> String ]
-
-4.1.1.9 NOOP (NOOP)
-
-This command does not affect any parameters or previously entered commands.
-It specifies no action other than that the receiver send an OK reply.
-
-This command has no effect on the reverse-path buffer, the forward-path
-buffer, or the mail data buffer.  If a parameter string is specified,
-servers SHOULD ignore it.
-
-Syntax:
-   "NOOP" [ <SP> String ]
-
-
-4.1.1.10 QUIT (QUIT)
-
-This command specifies that the receiver MUST send an OK reply, and then
-close the transmission channel.
-
-The receiver MUST NOT intentionally close the transmission channel until it
-receives and replies to a QUIT command (even if there was an error).  The
-sender MUST NOT intentionally close the transmission channel until it sends
-a QUIT command and receives the reply (even if there was an error response
-to a previous command).  If the connection is closed prematurely due to
-violations of the above or system or network failure, the server MUST
-cancel any pending transaction, but not undo any previously completed
-transaction, and generally MUST act as if the command or transaction in
-progress had received a temporary error (i.e., a 4yz response).
-
-Syntax: 
-   "QUIT"
-
-4.1.2 Lower-level Syntax
-
-The syntax of the argument fields of the above commands (using the syntax
-specified in [ABNF] where applicable) is given below.  Some of the
-productions given below are used only in conjunction with source routes as
-described in appendix C.  Terminals not defined in this document, such as
-ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax
-(section 6) of [ABNF] or in the syntax of [MSGFMT].
-
-   Reverse-path = Path
-
-   Forward-path = Path
-
-   Path = "<" [ A-d-l ":" ] Mailbox ">"
-
-   A-d-l = At-domain *( "," A-d-l )    ; Note that this form, the
-                                 so-called "source route", MUST BE
-                                 accepted, SHOULD NOT be generated,
-                                 and SHOULD be ignored.
-
-   At-domain = "@" Domain
-
-   Mail-parameters = *( <SP> Keyword "=" Argument )
-
-   Rcpt-parameters =  *( <SP> Keyword "=" Argument )
-
-   Keyword  = Ldh-str
-   Argument = Atom
-
-   Domain = sub-domain 1*("." sub-domain) / address-literal
-
-   sub-domain = let-dig *(Ldh-str)
-   address-literal = "[" IPv4-address-literal / 
-                  IPv6-address-literal / General-address-literal "]"
-   IPv4-address-literal = snum 3*3("." snum)
-   IPv6-address-literal = "IPv6 " IPv6-addr-string
-   IPv6-addr-string = String         ; IPv6 address in standard form
-                                       [IPv6AddrSpec].  Since this
-                                       form uses colon characters,
-                                       the String will actually need
-                                       to be quoted in all cases.
-   General-address-literal = Standardized-tag <SP> String
-   Standardized-tag = Ldh-str        ; Specified in a
-                                       standards-track RFC 
-                                       and registered with IANA
-   snum = 1*3Digit                   ; representing a decimal integer
-                                       value in the range 0 through 255 
-   let-dig = Alpha / Digit
-   ldh-str = *( Alpha / Digit / "-" ) let-dig
-
-   Mailbox = Local-part "@" Domain
-
-   Local-part = Dot-string / Quoted-string
-
-   Dot-string = Atom [ "." Atom ]
-
-While the above definition for Local-part is relatively permissive, for
-maximum interoperability, a host that expects to receive mail SHOULD avoid
-defining mailboxes where the Local-part requires (or uses) the
-Quoted-string form or where the Local-part is case-sensitive.  For any
-purposes that require generating or comparing Local-parts (e.g., to
-specific mailbox names), all quoted forms MUST be treated as equivalent and
-the sending system SHOULD transmit the form that uses the minimum quoting
-possible.
-
-Systems MUST NOT define mailboxes in such a way as to require the use of
-non-ASCII characters (octets with the high order bit set to one) or ASCII
-"control characters" (decimal value 0-31 and 127).  These characters MUST
-NOT be used in MAIL FROM or RCPT TO commands or other commands that require
-mailbox names.
-
-   String = Atom / Quoted-string
-
-   special = <<Msg-fmt-special>> /     [[placeholder, see above]]
-             the control characters (ASCII codes 0 through 31
-             inclusive and 127)
-
-Note that the backslash, "\", is a quote character, which is used to
-indicate that the next character is to be used literally (instead of its
-normal interpretation).  For example, "Joe\,Smith" indicates a single nine
-character user field with the comma being the fourth character of the
-field.
-
-To promote interoperability and consistent with long-standing guidance
-about conservative use of the DNS in naming and applications (e.g., see
-section 2.3.1 of the base DNS document [RFC-1015]), characters outside the
-set of alphas, digits, and hyphen MUST NOT appear in domain name labels
-for SMTP clients or servers.  In particular, the underscore character is
-not permitted.  SMTP servers that receive a command in which illegal
-character codes have been employed, and for which there are no other
-reasons for rejection, MUST reject that command with a 501 response.
-
-4.1.3 Address Literals
-
-Sometimes a host is not known to the domain name system and communication
-(and, in particular, communication to report and repair the error) is
-blocked.  To bypass this barrier a special literal form of the address is
-allowed as an alternative to a domain name.  For IPv4 addresses, this form
-uses four small decimal integers separated by dots and enclosed by brackets
-such as [123.255.37.2], which indicates an (IPv4) Internet Address in
-sequence-of-octets form.  For IPv6 and other forms of addressing that might
-eventually be standardized, the form consists of a standardized "tag" that
-identifies the address syntax, a space, and the address itself, in a format
-specified as part of the IPv6 standards [IPv6AddrString].
-
-4.1.4 Order of Commands
-
-There are restrictions on the order in which these commands may be used.
-
-A session that will contain mail transactions MUST first be initialized by
-the use of the EHLO command.  An SMTP server SHOULD accept commands for
-non-mail transactions (e.g., VRFY or EXPN) without this initialization.
-
-An EHLO command MAY be issued by a client later in the session.  If it is
-issued after the session begins, the SMTP server MUST clear all buffers and
-reset the state exactly as if a RSET command had been issued.  In other
-words, the sequence of RSET followed immediately by EHLO is redundant, but
-not harmful other than in the performance cost of executing unnecessary
-commands.
-
-If the EHLO command is not acceptable to the SMTP server, 501, 500, or 502
-failure replies MUST be returned as appropriate.  The SMTP server MUST stay
-in the same state after transmitting these replies that it was in before
-the EHLO was received.
-
-The SMTP client MUST ensure that the domain parameter to the EHLO command
-is a valid principal host name (not a CNAME or MX name) for its host.  If
-this is not possible (e.g., when the client's address is dynamically
-assigned and the client does not have an obvious name), an address literal
-SHOULD be substituted for the domain name and supplemental information
-provided that will assist in identifying the client.
-
-An SMTP server MAY verify that the domain name parameter in the EHLO
-command actually corresponds to the IP address of the client. However, the
-server MUST NOT refuse to accept a message if the verification fails: the
-information about verification failure is for logging and tracing only.
-
-The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
-during a session, or without previously initializing a session.  SMTP
-servers SHOULD process these normally (that is, not return a 503 code) even
-if no EHLO command has yet been received; clients SHOULD open a session
-with EHLO before sending these commands.
-
-If these rules are followed, the example in RFC 821 that shows "550 access
-denied to you" in response to an EXPN command is incorrect unless an EHLO
-command precedes the EXPN or the denial of access is based on the client's
-IP address or other authentication or authorization-determining mechanisms.
-
-The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a
-mail transaction.  Once started, a mail transaction consists of a
-transaction beginning command, one or more RCPT commands, and a DATA
-command, in that order.  A mail transaction may be aborted by the RSET (or
-a new EHLO) command.  There may be zero or more transactions in a session.
-MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is
-already open, i.e., it should be sent only if no mail transaction had been
-started in the session, or it the previous one successfully concluded with
-a successful DATA command, or if the previous one was aborted with a RSET.
-
-If the transaction beginning command argument is not acceptable, a 501
-failure reply MUST be returned and the SMTP server MUST stay in the same
-state.  If the commands in a transaction are out of order to the degree
-that they cannot be processed by the server, a 503 failure reply MUST be
-returned and the SMTP server MUST stay in the same state.
-
-The last command in a session MUST be the QUIT command.  The QUIT command
-cannot be used at any other time in a session, but SHOULD be used by the
-client SMTP to request connection closure, even when no session opening
-command was sent and accepted.
-
-4.1.5 Private-use Commands
-
-As specified in section 2.2.2, commands starting in "X" may be used by
-bilateral agreement between the client (sending) and server (receiving)
-SMTP agents.  An SMTP server that does not recognize such a command is
-expected to reply with "500 Command not recognized".  An extended SMTP
-server MAY list the feature names associated with these private commands in
-the response to the EHLO command.
-
-Commands sent or accepted by SMTP systems that do not start with "X" MUST
-conform to the requirements of section 2.2.2.
-
-4.2 SMTP Replies
-
-Replies to SMTP commands serve to ensure the synchronization of requests
-and actions in the process of mail transfer and to guarantee that the SMTP
-client always knows the state of the SMTP server. Every command MUST
-generate exactly one reply.
-
-The details of the command-reply sequence are described in section 4.3.
-
-An SMTP reply consists of a three digit number (transmitted as three
-alphanumeric characters) followed by some text unless specified otherwise
-in this document.  The number is for use by automata to determine what
-state to enter next; the text is for the human user.  The three digits
-contain enough encoded information that the SMTP client need not examine
-the text and may either discard it or pass it on to the user, as
-appropriate. Exceptions are as noted elsewhere in this document.  In
-particular, the 220, 221, 251, 421, and 551 reply codes are associated
-with message text that must be parsed and interpreted by machines.  In the
-general case, the text may be receiver dependent and context dependent, so
-there are likely to be varying texts for each reply code.  A discussion of
-the theory of reply codes is given in section 4.2.1.  Formally, a reply is
-defined to be the sequence: a three-digit code, <SP>, one line of text,
-and <CRLF>, or a multiline reply (as defined in section 4.2.1).  Since, in
-violation of this specification, the text is sometimes not sent, clients
-which do not receive it SHOULD be prepared to process the code alone (with
-or without a trailing space character).  Only the EHLO, EXPN, and HELP
-commands are expected to result in multiline replies in normal
-circumstances, however, multiline replies are allowed for any command.
-
-In ABNF, server responses are:
-
-  Greeting = "220 " Domain [ SP text ] CRLF
-  Reply-line = Reply-code [ SP text ] CRLF 
-
-where "Greeting" appears only in the 220 response that announces that the
-server is opening its part of the connection.
-
-An SMTP server SHOULD send only the reply codes listed in this document.
-An SMTP server SHOULD use the text shown in the examples whenever
-appropriate.
-
-An SMTP client MUST determine its actions only by the reply code, not by
-the text (except for 251 and 551 and, if necessary, 220, 221, and 421
-replies); in the general case, any text, including no text at all (although
-senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank)
-following the reply code is considered part of the text.  Whenever
-possible, a receiver-SMTP SHOULD test the first digit (severity indication)
-of the reply code.
-
-The list of codes that appears below must not be construed as permanent.
-While the addition of new codes should be a rare and significant activity,
-with supplemental information in the textual part of the response being
-preferred, new codes may be added as the result of new Standards or
-Standards-track specifications. Consequently, a sender-SMTP MUST be
-prepared to handle codes not specified in this document and MUST do so by
-interpreting the first digit only.
-
-4.2.1 Reply Code Severities and Theory
-
-The three digits of the reply each have a special significance.  The first
-digit denotes whether the response is good, bad or incomplete. An
-unsophisticated SMTP client, or one that receives an unexpected code, will
-be able to determine its next action (proceed as planned, redo, retrench,
-etc.) by examining this first digit.  An SMTP client that wants to know
-approximately what kind of error occurred (e.g., mail system error, command
-syntax error) may examine the second digit.  The third digit and any
-supplemental information that may be present is reserved for the finest
-gradation of information.
-
-There are five values for the first digit of the reply code:
-
-1yz   Positive Preliminary reply
-   The command has been accepted, but the requested action is being held in
-   abeyance, pending confirmation of the information in this reply.  The
-   SMTP client should send another command specifying whether to continue
-   or abort the action. Note: unextended SMTP does not have any commands
-   that allow this type of reply, and so does not have continue or abort
-   commands.
-
-2yz   Positive Completion reply
-   The requested action has been successfully completed.  A new request may
-   be initiated.
-
-3yz   Positive Intermediate reply
-   The command has been accepted, but the requested action is being held in
-   abeyance, pending receipt of further information.  The SMTP client
-   should send another command specifying this information.  This reply is
-   used in command sequence groups (i.e., in DATA).
-
-4yz   Transient Negative Completion reply
-   The command was not accepted, and the requested action did not occur.
-   However, the error condition is temporary and the action may be
-   requested again.  The sender should return to the beginning of the
-   command sequence (if any). It is difficult to assign a meaning to
-   "transient" when two different sites (receiver- and sender- SMTP agents)
-   must agree on the interpretation. Each reply in this category might have
-   a different time value, but the SMTP client is encouraged to try again.
-   A rule of thumb to determine whether a reply fits into the 4yz or the
-   5yz category (see below) is that replies are 4yz if they can be
-   successful if repeated without any change in command form or in
-   properties of the sender or receiver.  (that is, the command is repeated
-   identically and the receiver does not put up a new implementation.)
-
-5yz   Permanent Negative Completion reply
-   The command was not accepted and the requested action did not occur.
-   The SMTP client is discouraged from repeating the exact request (in the
-   same sequence).  Even some "permanent" error conditions can be
-   corrected, so the human user may want to direct the SMTP client to
-   reinitiate the command sequence by direct action at some point in the
-   future (e.g., after the spelling has been changed, or the user has
-   altered the account status).
-
-The second digit encodes responses in specific categories:
-
-x0z   Syntax: These replies refer to syntax errors, syntactically correct
-   commands that don't fit any functional category, and unimplemented or
-   superfluous commands.
-
-x1z   Information:  These are replies to requests for information, such as
-   status or help.
-
-x2z   Connections: These are replies referring to the transmission channel.
-
-x3z   Unspecified.
-
-x4z   Unspecified.
-
-x5z   Mail system: These replies indicate the status of the receiver mail
-   system vis-a-vis the requested transfer or other mail system action.
-
-The third digit gives a finer gradation of meaning in each category
-specified by the second digit.  The list of replies illustrates this. Each
-reply text is recommended rather than mandatory, and may even change
-according to the command with which it is associated.  On the other hand,
-the reply codes must strictly follow the specifications in this section.
-Receiver implementations should not invent new codes for slightly different
-situations from the ones described here, but rather adapt codes already
-defined.
-
-For example, a command such as NOOP, whose successful execution does not
-offer the SMTP client any new information, will return a 250 reply.  The
-reply is 502 when the command requests an unimplemented non-site-specific
-action.  A refinement of that is the 504 reply for a command that is
-implemented, but that requests an unimplemented parameter.
-
-The reply text may be longer than a single line; in these cases the
-complete text must be marked so the SMTP client knows when it can stop
-reading the reply.  This requires a special format to indicate a multiple
-line reply.
-
-The format for multiline replies requires that every line, except the last,
-begin with the reply code, followed immediately by a hyphen, "-" (also
-known as minus), followed by text.  The last line will begin with the reply
-code, followed immediately by <SP>, optionally some text, and <CRLF>.  As
-noted above, servers SHOULD send the <SP> if subsequent text is not sent,
-but clients MUST be prepared for it to be omitted.
-
-For example:
-   123-First line
-   123-Second line
-   123-234 text beginning with numbers
-   123 The last line
-
-In many cases the SMTP client then simply needs to search for the reply
-code followed by <SP> at the beginning of a line, and ignore all preceding
-lines.  In a few cases, there is important data for the client in the
-reply "text".  The client will be able to identify these cases from the
-current context.
-
-4.2.2 Reply Codes by Function Groups
-
-   500 Syntax error, command unrecognized
-      (This may include errors such as command line too long)
-   501 Syntax error in parameters or arguments
-   502 Command not implemented  (see section 4.2.4)
-   503 Bad sequence of commands
-   504 Command parameter not implemented
-
-   211 System status, or system help reply
-   214 Help message
-      (Information on how to use the receiver or the meaning of a
-      particular non-standard command; this reply is useful only
-      to the human user)
-
-   220 <domain> Service ready
-   221 <domain> Service closing transmission channel
-   421 <domain> Service not available, closing transmission channel
-      (This may be a reply to any command if the service knows it
-      must shut down)
-
-   250 Requested mail action okay, completed
-   251 User not local; will forward to <forward-path>
-      (See section 3.4)
-   252 Cannot VRFY user, but will accept message and attempt 
-       delivery
-      (See section 3.5.3)
-   450 Requested mail action not taken: mailbox unavailable
-      (e.g., mailbox busy)
-   550 Requested action not taken: mailbox unavailable
-      (e.g., mailbox not found, no access, or command rejected
-      for policy reasons)
-   451 Requested action aborted: error in processing
-   551 User not local; please try <forward-path>
-      (See section 3.4)
-   452 Requested action not taken: insufficient system storage
-   552 Requested mail action aborted: exceeded storage allocation
-   553 Requested action not taken: mailbox name not allowed
-      (e.g., mailbox syntax incorrect)  
-   354 Start mail input; end with <CRLF>.<CRLF>
-   554 Transaction failed (Or, in the case of a connection-opening
-       response, "No SMTP service here")
-
-4.2.3  Reply Codes in Numeric Order
-
-   211 System status, or system help reply
-   214 Help message
-      (Information on how to use the receiver or the meaning of a
-      particular non-standard command; this reply is useful only
-      to the human user)
-   220 <domain> Service ready
-   221 <domain> Service closing transmission channel
-   250 Requested mail action okay, completed
-   251 User not local; will forward to <forward-path>
-      (See section 3.4)
-   252 Cannot VRFY user, but will accept message and attempt 
-      delivery
-      (See section 3.5.3)
-
-   354 Start mail input; end with <CRLF>.<CRLF>
-
-   421 <domain> Service not available, closing transmission channel
-      (This may be a reply to any command if the service knows it
-      must shut down)
-   450 Requested mail action not taken: mailbox unavailable
-      (e.g., mailbox busy)
-   451 Requested action aborted: local error in processing
-   452 Requested action not taken: insufficient system storage
-
-   500 Syntax error, command unrecognized
-      (This may include errors such as command line too long)
-   501 Syntax error in parameters or arguments
-   502 Command not implemented (see section 4.2.4)
-   503 Bad sequence of commands
-   504 Command parameter not implemented
-   550 Requested action not taken: mailbox unavailable
-      (e.g., mailbox not found, no access, or command rejected
-      for policy reasons)
-   551 User not local; please try <forward-path>
-      (See section 3.4)
-   552 Requested mail action aborted: exceeded storage allocation
-   553 Requested action not taken: mailbox name not allowed
-      (e.g., mailbox syntax incorrect)
-   554 Transaction failed  (Or, in the case of a connection-opening
-       response, "No SMTP service here")
-
-4.2.4 Reply Code 502
-
-Questions have been raised as to when reply code 502 (Command not
-implemented) SHOULD be returned in preference to other codes.  502 SHOULD
-be used when the command is actually recognized by the SMTP server, but not
-implemented.  If the command is not recognized, code 500 SHOULD be
-returned.  Extended SMTP systems MUST NOT list capabilities in response to
-EHLO for which they will return 502 (or 500) replies.
-
-4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
-
-When an SMTP server returns a positive completion status (2yz code) after
-the DATA command is completed with <CRLF>.<CRLF>, it accepts responsibility
-for:
-
- - delivering the message (if the recipient mailbox exists), or
-
- - if attempts to deliver the message fail due to transient conditions,
-   retrying delivery some reasonable number of times at intervals as
-   specified in section 4.5.4.
-
- - if attempts to deliver the message fail due to permanent conditions, or
-   if repeated attempts to deliver the message fail due to transient
-   conditions, returning appropriate notification to the sender of the
-   original message (using the address in the SMTP MAIL FROM command).
-
-When an SMTP server returns a transient error completion status (4yz) code
-after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
-any further attempt to deliver that message.  The SMTP client retains
-responsibility for delivery of that message and may either return it to the
-user or requeue it for a subsequent attempt (see section 4.5.4.1).  The
-sending user SHOULD be able to interpret the return of a transient or
-permanent failure status as a non-delivery indication.
-
-4.3 Sequencing of Commands and Replies
-
-4.3.1 Sequencing Overview
-
-The communication between the sender and receiver is an alternating
-dialogue, controlled by the sender.  As such, the sender issues a command
-and the receiver responds with a reply.  Unless other arrangements are
-negotiated through service extensions, the sender MUST wait for this
-response before sending further commands.
-
-One important reply is the connection greeting.  Normally, a receiver will
-send a 220 "Service ready" reply when the connection is completed.  The
-sender SHOULD wait for this greeting message before sending any commands.
-
-Note: all the greeting-type replies have the official name (the
-fully-qualified primary domain name) of the server host as the first word
-following the reply code.  Sometimes the host will have no meaningful name.
-See 4.1.3 for a discussion of alternatives in these situations.
-
-For example,
-   220 ISIF.USC.EDU Service ready
-or
-   220 mail.foo.com SuperSMTP v 6.1.2 Service ready
-or
-   220 [10.0.0.1] Clueless host service ready
-
-The table below lists alternative success and failure replies for each
-command.  These SHOULD be strictly adhered to: a receiver may substitute
-text in the replies, but the meaning and action implied by the code numbers
-and by the specific command reply sequence cannot be altered.
-
-4.3.2 Command-Reply Sequences
-
-Each command is listed with its usual possible replies.  The prefixes used
-before the possible replies are "I" for intermediate, "S" for success, and
-"E" for error.  Since some servers may generate other replies under special
-circumstances, and to allow for future extension, SMTP clients SHOULD, when
-possible, interpret only the first digit of the reply and MUST be prepared
-to deal with unrecognized reply codes by interpreting the first digit only.
-Unless extended using the mechanisms described in section 2.2, SMTP servers
-MUST NOT transmit reply codes to an SMTP client that are other than three
-digits or that do not start in a digit between 2 and 5 inclusive.
-
-These sequencing rules and, in principle, the codes themselves, can be
-extended or modified by SMTP extensions offered by the server and accepted
-(requested) by the client.
-
-In addition to the codes listed below, any SMTP command can return any of
-the following codes if the corresponding unusual circumstances are
-encountered:
-
-500  For the "command line too long" case or if the command name was not
-   recognized.  Note that producing a "command not recognized" error in
-   response to the required subset of these commands is a violation of this
-   specification.
-
-501  Syntax error in command or arguments.  In order to provide for future
-   extensions, commands that are specified in this document as not
-   accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 message if
-   arguments are supplied in the absence of EHLO-advertised extensions.
-
-421  Service shutting down and closing transmission channel
-
-Specific sequences are:
-
-CONNECTION ESTABLISHMENT
-   S: 220
-   E: 554
-EHLO or HELO
-   S: 250
-   E: 504, 550
-MAIL
-   S: 250
-   E: 552, 451, 452, 550, 553, 503
-RCPT
-   S: 250, 251 (but see section 3.4 for discussion of 251)
-   E: 550, 551, 552, 553, 450, 451, 452, 503, 550
-DATA
-   I: 354 -> data -> S: 250
-                     E: 552, 554, 451, 452
-   E: 451, 554, 503
-RSET
-   S: 250
-VRFY
-   S: 250, 251, 252
-   E: 550, 551, 553, 502, 504
-EXPN
-   S: 250, 252
-   E: 550, 500, 502, 504
-HELP
-   S: 211, 214
-   E: 502, 504
-NOOP
-   S: 250
-QUIT
-   S: 221
-
-4.4 Trace Information
-
-When an SMTP server receives a message for delivery or further processing,
-it MUST insert trace ("time stamp" or "Received") information at the
-beginning of the message content, as discussed in section 4.1.1.4.
-
-This line MUST be structured as follows:
-
- - The FROM field, which MUST be supplied in an SMTP environment, SHOULD
-   contain both (1) the name of the source host as presented in the EHLO
-   command and (2) an address literal containing the IP address of the
-   source, determined from the TCP connection.
-
- - The ID field MAY contain an "@" as suggested in RFC-822, but this is not
-   required.
-
- - The FOR field MAY contain a list of <path> entries when multiple RCPT
-   commands have been given.  This may raise some security issues and is
-   usually not desirable; see section 7.2.
-
-An Internet mail program MUST NOT change a Received: line that was
-previously added to the message header.  SMTP servers MUST prepend Received
-lines to messages; they MUST NOT change the order of existing lines or
-insert Received lines in any other location.
-
-As the Internet grows, comparability of Received fields is important for
-detecting problems, especially slow relays.  SMTP servers that create
-Received fields SHOULD use explicit offsets in the dates (e.g., -0800),
-rather than time zone names of any type.  Local time (with an offset) is
-preferred to UT when feasible.  This formulation allows slightly more
-information about local circumstances to be specified.  If UT is needed,
-the receiver need merely do some simple arithmetic to convert the values.
-Use of UT loses information about the time zone-location of the server.  If
-a time zone name is used, it SHOULD be included in a comment.
-
-When the delivery SMTP server makes the "final delivery" of a message, it
-inserts a return-path line at the beginning of the mail data.  This use of
-return-path is required; mail systems MUST support it.  The return-path
-line preserves the information in the <reverse-path> from the MAIL
-command.  Here, final delivery means the message has left the SMTP
-enviroment.  Normally, this would mean it had been delivered to the
-destination user or an associated mail drop, but in some cases it may be
-further processed and transmitted by another mail system.
-
-It is possible for the mailbox in the return path to be different from the
-actual sender's mailbox, for example, if error responses are to be
-delivered to a special error handling mailbox rather than to the message
-sender.  When mailing lists are involved, this arrangement is common and
-useful as a means of directing errors to the list maintainer rather than
-the message originator.
-
-The text above implies that the final mail data will begin with a return
-path line, followed by one or more time stamp lines.  These lines will be
-followed by the mail data headers and body [MSGFMT].
-
-It is sometimes difficult for an SMTP server to determine whether or not it
-is making final delivery since forwarding or other operations may occur
-after the message is accepted for delivery.  Consequently, any further
-(forwarding, gateway, or relay) systems MAY remove the return path and
-rebuild the MAIL FROM command as needed to ensure that exactly one such
-line appears in a delivered message.
-
-A message-originating SMTP system SHOULD NOT send a message that already
-contains a Return-path header.  SMTP servers performing a relay function
-MUST NOT inspect the message data, and especially not to the extent needed
-to determine if Return-path headers are present. SMTP servers making final
-delivery MAY remove Return-path headers before adding their own.
-
-The primary purpose of the Return-path is to designate the address to which
-messages indicating non-delivery or other mail system failures are to be
-sent.  For this to be unambiguous, exactly one return path SHOULD be
-present when the message is delivered.  Systems using RFC 822 syntax with
-non-SMTP transports SHOULD designate an unambiguous address, associated
-with the transport envelope, to which error reports (e.g., non-delivery
-messages) should be sent.
-
-Historical note: Text in RFC 822 that appears to contradict the use of the
-Return-path header (or the envelope MAIL FROM address) as the destination
-for error messages is not applicable on the Internet. The MAIL FROM address
-(as copied into the Return-path) MUST be used as the target of any mail
-containing delivery error messages.
-
-In particular:
-
- - a gateway from SMTP->elsewhere SHOULD insert a return-path header,
-   unless it is known that the "elsewhere" transport also uses Internet
-   domain addresses and maintains the envelope sender address separately.
-
- - a gateway from elsewhere->SMTP SHOULD delete any return-path header
-   present in the message, and either copy that information to the SMTP
-   envelope or combine it with information present in the envelope of the
-   other transport system to construct the MAIL FROM part of the SMTP
-   envelope.
-
-The server must give special treatment to cases in which the processing
-following the end of mail data indication is only partially successful.
-This could happen if, after accepting several recipients and the mail data,
-the SMTP server finds that the mail data could be successfully delivered to
-some, but not all, of the recipients.  In such cases, the response to the
-DATA command MUST be an OK reply.  However, the SMTP server MUST compose
-and send an "undeliverable mail" notification message to the originator of
-the message.
-
-A single notification listing all of the failed recipients or separate
-notification messages MUST be sent for each failed recipient.  For economy
-of processing by the sender, the former is preferred when possible.  All
-undeliverable mail notification messages are sent using the MAIL command
-(even if they result from processing the obsolete SEND, SOML, or SAML
-commands) and use a null return path as discussed in section 3.7.
-
-The time stamp line and the return path line are formally defined as
-follows:
- 
-   Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
-   
-   Time-stamp-line = "Received:" FWS Stamp <CRLF>
-   
-   Stamp = From-domain By-domain Opt-info ";"  FWS Daytime
-   
-   From-domain = "FROM" FWS Extended-Domain CFWS 
-   
-   By-domain = "BY" FWS Extended-Domain CFWS
-   
-   Extended-Domain = Domain / 
-              ( Domain FWS "(" TCP-info ")" ) /
-              ( Address-literal FWS "(" TCP-info ")"
-    TCP-info = Address-literal / ( Domain FWS Address-literal )
-                   ; Information derived by server from TCP connection,
- 				     not client EHLO. 
-
-   Opt-info = [Via] [With] [ID] [For]
-   
-   Via = "VIA" FWS Link CFWS 
-   
-   With = "WITH" FWS Protocol CFWS 
-   
-   ID = "ID" FWS String / msg-id CFWS 
-   
-   For = "FOR" FWS 1*( Path / Mailbox ) CFWS 
-   
-   Link = "TCP" / Addtl-Link
-   Addtl-Link = Atom       ; Additional standard names for links are
-                             registered with the Internet Assigned
-                             Numbers Authority (IANA).  "Via" is
-							 primarily of value with non-Internet
-							 transports.
-                             SMTP servers SHOULD NOT use unregistered
-                             names. 
-   Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
-   Attdl-Protocol = Atom    ; Additional standard names for protocols
-                              are registered with the Internet Assigned
-                              Numbers Authority (IANA).  SMTP servers
-                              SHOULD NOT use unregistered names.
-   
-   Daytime =  FWS [ day-of-week "," FWS ] Date FWS Time
-   
-   Date = DD FWS Mon FWS YYYY
-          ; Note that the earlier form, which permits two-digit years, has
-            been deprecated.  SMTP systems MUST use four-digit years.
-   
-   Time = HH ":" MM ":" SS  FWS  Zone
-   
-   DD = 1*2Digit           ; the one or two digit integer day of the
-                             month in the range 1 to 31.
-   
-   Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
-                "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
-   
-   YYYY = 4*4Digit         ; the four decimal integer year in the range
-                             0000 to 9999. 
-   
-   HH = 2*2Digit           ; the two decimal digit hour of the day in
-                             the range 00 to 24.
-   
-   MM = 2*2Digit            ; the two decimal digit integer minute of the hour
-                              in the range 00 to 59.
-   
-   SS = 2*2Digit [ "." 1*Digit ]
-                            ; the two decimal digit integer second of the
-                              minute in the range 00 to 59, with
-                              optional fractional seconds.
-   
-   Zone = ( "+" / "-" ) 4*4Digit [ <SP> "(" String ")" ]
-                            ; A four digit, signed time zone offset,
-                              such as -0500 for US Eastern Standard
-                              Time.  This may be supplemented by a time
-                              zone name in parentheses, e.g., "-0800
-                              (PDT)". Note that there is no default;
-                              time zone information is required and
-                              MUST be supplied.
-                               
-4.5 Additional Implementation Issues
-
-4.5.1 Minimum Implementation
-
-In order to make SMTP workable, the following minimum implementation is
-required for all receivers. The following commands MUST be supported to
-conform to this specification:
-   EHLO
-   HELO
-   MAIL
-   RCPT
-   DATA
-   RSET
-   NOOP
-   QUIT
-
-VRFY, required by RFC 1123 [RFC-1123], is no longer required by this
-specification.   However, since it was required earlier, servers are
-strongly encouraged to at least recognize the syntax and provide pro-forma
-support.
-
-Any system that includes an SMTP server supporting mail relaying or
-delivery MUST support the reserved mailbox "postmaster" as a
-case-insensitive local name. This postmaster address is not strictly
-necessary if the server always returns 554 on connection opening (as
-described in section 3.1).  The requirement to accept mail for postmaster
-implies that RCPT TO commands which specify a mailbox for postmaster at any
-of the domains for which the SMTP server provides mail service, as well as
-the special case of "RCPT TO:<Postmaster>" (with no domain specification),
-MUST be supported.  This requirement does not imply that SMTP systems must
-deliver Postmaster mail in particular cases (e.g., problematic origin
-addresses) in which they have substantive reasons for not doing so.
-
-4.5.2 Transparency
-
-Without some provision for data transparency, the character sequence
-"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.  In
-general, users are not aware of such "forbidden" sequences.  To allow all
-user composed text to be transmitted transparently, the following
-procedures are used:
-
- - Before sending a line of mail text, the SMTP client checks the first
-   character of the line.  If it is a period, one additional period is
-   inserted at the beginning of the line.
-
- - When a line of mail text is received by the SMTP server, it checks the
-   line.  If the line is composed of a single period, it is treated as the
-   end of mail indicator.  If the first character is a period and there are
-   other characters on the line, the first character is deleted.
-
-The mail data may contain any of the 128 ASCII characters.  All characters
-are to be delivered to the recipient's mailbox, including spaces, vertical
-and horizontal tabs, and other control characters.  If the transmission
-channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes
-are transmitted right justified in the octets, with the high order bits
-cleared to zero.  See 3.7 for special treatment of these conditions in SMTP
-systems serving a relay function.
-
-In some systems it may be necessary to transform the data as it is received
-and stored.  This may be necessary for hosts that use a different character
-set than ASCII as their local character set or store data in records rather
-than strings.  If such transformations are necessary, they MUST be
-reversible, especially if such transformations are applied to mail being
-relayed.
-
-4.5.3 Sizes and Timeouts
-
-There are several objects that have required minimum/maximum sizes. Every
-implementation MUST be able to receive objects of at least these sizes.
-Objects larger than these sizes SHOULD be avoided when possible.  However,
-some Internet mail constructs such as encoded X.400 addresses [RFC-X400]
-will often require larger objects: clients MAY attempt to transmit these,
-but MUST be prepared for a server to reject them if they cannot be handled
-by it.  To the maximum extent possible, implementation techniques which
-impose no limits on the length of these objects should be used.
-
-local-part
-   The maximum total length of a user name or other local-part is 64
-   characters.
-
-domain
-   The maximum total length of a domain name or number is 255 characters.
-
-path
-   The maximum total length of a reverse-path or forward-path is 256
-   characters (including the punctuation and element separators).
-
-command line
-   The maximum total length of a command line including the command word
-   and the <CRLF> is 512 characters.  SMTP extensions may be used to
-   increase this limit.
-
-reply line
-   The maximum total length of a reply line including the reply code and
-   the <CRLF> is 512 characters.  More information may be conveyed through
-   multiple-line replies.
-
-text line
-   The maximum total length of a text line including the <CRLF> is 1000
-   characters (not counting the leading dot duplicated for transparency).
-   This number may be increased by the use of SMTP Service Extensions.
-
-message content
-   The maximum total length of a message content (including any message
-   headers as well as the message body) MUST BE at least 64K octets. Since
-   the introduction of multimedia mail [RFC-MIME], message lengths on the
-   Internet have grown dramatically, and message size restrictions should
-   be avoided if at all possible. SMTP server systems that must impose
-   restrictions SHOULD implement the "SIZE" service extension ([RFC-SIZE]),
-   and SMTP client systems that will send large messages SHOULD utilize it
-   when possible.
-
-recipients buffer
-   The minimum total number of recipients that must be buffered is 100
-   recipients. Rejection of messages (for excessive recipients) with fewer
-   than 100 RCPT TO commands is a violation of this specification.  The
-   general principle that relaying SMTP servers MUST NOT, and delivery SMTP
-   servers SHOULD NOT, perform validation tests on message headers suggests
-   that rejecting a message based on the total number of recipients shown
-   in header fields is to be discouraged.  A server which imposes a limit
-   on the number of recipients MUST behave in an orderly fashion,  such as
-   to reject additional addresses over its limit rather than silently
-   discarding addresses previously accepted.  A client that needs to
-   deliver a message containing over 100 RCPT TO commands SHOULD be
-   prepared to transmit in 100-recipient "chunks" if the server declines to
-   accept more than 100 recipients in a single message.
-
-Errors due to exceeding these limits may be reported by using the reply
-codes. Some examples of reply codes are:
-
-   500 Line too long.
-or
-   501 Path too long
-or
-   452 Too many recipients  (see below)
-or
-   552 Too much mail data.
-
-[RFC-821] incorrectly listed the error where an SMTP server exhausts its
-implementation limit on the number of RCPT TO commands ("too many
-recipients") as having reply code 552.  The correct reply code for this
-condition is 452. Clients SHOULD treat a 552 code in this case as a
-temporary, rather than permanent failure so the logic below works.
-
-When a conforming SMTP server encounters this condition, it has at least
-100 successful RCPT commands in its recipients buffer.  If the server is
-able to accept the message, then at least these 100 addresses will be
-removed from the SMTP client's queue.  When the client attempts
-retransmission of those addresses which received 452 responses, at least
-100 of these will be able to fit in the SMTP server's recipients buffer.
-Each retransmission attempt which is able to deliver anything will be able
-to dispose of at least 100 of these recipients.
-
-If an SMTP server has an implementation limit on the number of RCPT TO
-commands and this limit is exhausted, it MUST use a response code of 452.
-If the server has a configured site-policy limitation on the number of RCPT
-TO commands, it MAY instead use a 5XX response code.
-
-In order to interoperate with SMTP servers implementing an older version of
-the protocol, SMTP clients MAY treat a 552 code obtained in response to an
-RCPT command as if it were a 452 response code, especially after some RCPT
-commands have already been accepted in the same mail transaction.
-
-An SMTP client MUST provide a timeout mechanism.  It MUST use per-command
-timeouts rather than somehow trying to time the entire mail transaction.
-Timeouts SHOULD be easily reconfigurable, preferably without recompiling
-the SMTP code.  To implement this, a timer is set for each SMTP command and
-for each buffer of the data transfer.  The latter means that the overall
-timeout is inherently proportional to the size of the message.
-
-Based on extensive experience with busy mail-relay hosts, the minimum
-per-command timeout values SHOULD be as follows:
-
-Initial 220 Message: 5 minutes
-   An SMTP client process needs to distinguish between a failed TCP
-   connection and a delay in receiving the initial 220 greeting message.
-   Many SMTP servers accept a TCP connection but delay delivery of the 220
-   message until their system load permits more mail to be processed.
-
-MAIL Command: 5 minutes
-
-RCPT Command: 5 minutes
-   A longer timeout is required if processing of mailing lists and aliases
-   is not deferred until after the message was accepted.
-
-DATA Initiation: 2 minutes
-   This is while awaiting the "354 Start Input" reply to a DATA command.
-
-Data Block: 3 minutes
-   This is while awaiting the completion of each TCP SEND call transmitting
-   a chunk of data.
-
-DATA Termination: 10 minutes.
-   This is while awaiting the "250 OK" reply. When the receiver gets the
-   final period terminating the message data, it typically performs
-   processing to deliver the message to a user mailbox.  A spurious timeout
-   at this point would be very wasteful and would typically result in
-   delivery of multiple copies of the message, since it has been
-   successfully sent and the server has accepted responsibility for
-   delivery.  See section 6.1 for additional discussion.
-
-An SMTP server SHOULD have a timeout of at least 5 minutes while it is
-awaiting the next command from the sender.
-
-4.5.4 Queuing Strategies
-
-The common structure of a host SMTP implementation includes user mailboxes,
-one or more areas for queuing messages in transit, and one or more daemon
-processes for sending and receiving mail.  The exact structure will vary
-depending on the needs of the users on the host and the number and size of
-mailing lists supported by the host. We describe several optimizations that
-have proved helpful, particularly for mailers supporting high traffic
-levels.
-
-Any queuing strategy MUST include timeouts on all activities on a
-per-command basis. A queuing strategy MUST NOT send error messages in
-response to error messages under any circumstances.
-
-4.5.4.1 Sending Strategy
-
-The general model for an SMTP client is one or more processes that
-periodically attempt to transmit outgoing mail.  In a typical system, the
-program that composes a message has some method for requesting immediate
-attention for a new piece of outgoing mail, while mail that cannot be
-transmitted immediately MUST be queued and periodically retried by the
-sender.  A mail queue entry will include not only the message itself but
-also the envelope information.
-
-The sender MUST delay retrying a particular destination after one attempt
-has failed.  In general, the retry interval SHOULD be at least 30 minutes;
-however, more sophisticated and variable strategies will be beneficial when
-the SMTP client can determine the reason for non-delivery.
-
-Retries continue until the message is transmitted or the sender gives up;
-the give-up time generally needs to be at least 4-5 days.  The parameters
-to the retry algorithm MUST be configurable.
-
-A client SHOULD keep a list of hosts it cannot reach and corresponding
-connection timeouts, rather than just retrying queued mail items.
-
-Experience suggests that failures are typically transient (the target
-system or its connection has crashed), favoring a policy of two connection
-attempts in the first hour the message is in the queue, and then backing
-off to one every two or three hours.
-
-The SMTP client can shorten the queuing delay in cooperation with the SMTP
-server.  For example, if mail is received from a particular address, it is
-likely that mail queued for that host can now be sent. Application of this
-principle may, in many cases, eliminate the requirement for an explicit
-"send queues now" function such as that discussed in [RFC-ETRN].
-
-The strategy may be further modified as a result of multiple addresses per
-host (see below) to optimize delivery time vs. resource usage.
-
-An SMTP client may have a large queue of messages for each unavailable
-destination host.  If all of these messages were retried in every retry
-cycle, there would be excessive Internet overhead and the sending system
-would be blocked for a long period.  Note that an SMTP client can generally
-determine that a delivery attempt has failed only after a timeout of
-several minutes and even a one-minute timeout per connection will result in
-a very large delay if retries are repeated for dozens, or even hundreds, of
-queued messages to the same host.
-
-At the same time, SMTP clients SHOULD use great care in caching negative
-responses from servers.  In an extreme case, if EHLO is issued multiple
-times during the same SMTP connection, different answers may be returned by
-the server. More significantly, 5yz responses to MAIL FROM MUST NOT be
-cached.
-
-When a mail message is to be delivered to multiple recipients, and the SMTP
-server to which a copy of the message is to be sent is the same for
-multiple recipients, then only one copy of the message SHOULD be
-transmitted.  That is, the SMTP client SHOULD use the command sequence:
-MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, DATA,
-..., MAIL, RCPT, DATA.  However, if there are very many addresses, a limit
-on the number of RCPT commands per MAIL command MAY be imposed.
-Implementation of this efficiency feature is strongly encouraged.
-
-Similarly, to achieve timely delivery, the SMTP client MAY support multiple
-concurrent outgoing mail transactions.  However, some limit may be
-appropriate to protect the host from devoting all its resources to mail.
-
-4.5.4.2 Receiving Strategy
-
-The SMTP server SHOULD attempt to keep a pending listen on the SMTP port at
-all times.  This requires the support of multiple incoming TCP connections
-for SMTP.  Some limit MAY be imposed.
-
-As discussed above, when the SMTP server receives mail from a particular
-host address, it could notify the SMTP client to retry any mail pending for
-that host address.
-
-4.5.5   Messages with a null reverse-path
-
-There are several types of notification messages which are required by
-existing and proposed standards to be sent with a null reverse path,
-namely non-delivery notifications as discussed in section 3.7, other kinds
-of Delivery Status Notifications (DSNs, see [RFC 1894]) and also Message
-Disposition Notifications (MDNs, see [RFC 2298]). All of these kinds of
-messages are notifications about a previous message, and they are sent to
-the reverse-path of the previous mail message. (If the delivery of such a
-notification message fails, that usually indicates a problem with the mail
-system of the host to which the notification message is addressed. For
-this reason, at some hosts the MTA is set up to forward such failed
-notification messages to someone who is able to fix problems with the mail
-system, e.g. via the postmaster alias.)
-
-All other types of messages (i.e. any message which is not required by a
-standards-track RFC to have a null reverse-path) SHOULD be sent with with
-a valid, non-null reverse-path.
-
-Implementors of automated email processors should be careful to make sure
-that the various kinds of messages with null reverse-path are handled
-correctly, in particular such systems SHOULD NOT reply to messages with
-null reverse-path. 
-
-
-
-
-5. Address Resolution and Mail Handling
-
-Once an SMTP client lexically identifies a domain to which mail will be
-delivered for processing (as described in sections 3.6 and 3.7), a DNS
-lookup is performed to resolve the domain name (see [RFC-DNS]).  The names
-are expected to be fully-qualified domain names (FQDNs): mechanisms for
-inferring FQDNs from partial names or local aliases are outside of this
-specification and, due to a history of problems, are generally discouraged.
-The lookup first attempts to locate an MX record associated with the name.
-If a CNAME record is found instead, the resulting name is processed as if
-it were the initial name.  If no MX records are found, but an A RR is
-found, the A RR is treated as if it was associated with an implicit MX RR,
-with a preference of 0, pointing to that host.  If one or more MX RRs are
-found for a given name, SMTP systems MUST NOT utilize any A RRs associated
-with that name unless they are located using the MX RRs; the "implicit MX"
-rule above applies only if there are no MX records present.  If MX records
-are present, but none of them are usable, this situation MUST be reported
-as an error.
-
-When the lookup succeeds, the mapping can result in a list of alternative
-delivery addresses rather than a single address, because of multiple MX
-records, multihoming, or both.  To provide reliable mail transmission, the
-SMTP client MUST be able to try (and retry) each of the relevant addresses
-in this list in order, until a delivery attempt succeeds. However, there
-MAY also be a configurable limit on the number of alternate addresses that
-can be tried.  In any case, a host SHOULD try at least two addresses.
-
-Two types of information is used to rank the host addresses: multiple MX
-records, and multihomed hosts.
-
-Multiple MX records contain a preference indication that MUST be used in
-sorting (see below).  Lower numbers are more preferred than higher ones.
-If there are multiple destinations with the same preference and there is no
-clear reason to favor one (e.g., by recognition of an easily-reached
-address), then the sender-SMTP MUST randomize them to spread the load
-across multiple mail exchangers for a specific organization.
-
-The destination host (perhaps taken from the preferred MX record) may be
-multihomed, in which case the domain name resolver will return a list of
-alternative IP addresses.  It is the responsibility of the domain name
-resolver interface to have ordered this list by decreasing preference if
-necessary, and SMTP MUST try them in the order presented.
-
-Although the capability to try multiple alternative addresses is required,
-specific installations may want to limit or disable the use of alternative
-addresses.  The question of whether a sender should attempt retries using
-the different addresses of a multihomed host has been controversial.  The
-main argument for using the multiple addresses is that it maximizes the
-probability of timely delivery, and indeed sometimes the probability of any
-delivery; the counter-argument is that it may result in unnecessary
-resource use. Note that resource use is also strongly determined by the
-sending strategy discussed in section 4.5.4.1.
-
-If a host receives a message with a destination for which it is a
-designated Mail eXchanger, it MAY relay the message (potentially after
-having rewritten the addresses), make final delivery of the message, or
-hand it off using some mechanism outside the SMTP-provided transport
-environment.
-
-If it determines that it should relay the message without rewriting the
-address, it MUST sort the MX records to determine candidates for delivery.
-The records are first ordered by preference, with the lowest-numbered
-records being most preferred.  The relay host MUST then inspect the list
-for any of the names or addresses by which it might be known in mail
-transactions.  If a matching record is found, all records at that
-preference level and higher-numbered ones MUST be discarded from
-consideration.  If there are no records left at that point, it is an error
-condition, and the message MUST be returned as undeliverable.  If records
-do remain, they SHOULD be tried, best preference first, as described above.
-
-
-6. Problem Detection and Handling
-
-6.1 Reliable Delivery and Replies by Email
-
-When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
-message in response to DATA), it is accepting responsibility for delivering
-or relaying the message.  It must take this responsibility seriously. It
-MUST NOT lose the message for frivolous reasons, such as because the host
-later crashes or because of a predictable resource shortage.
-
-If there is a delivery failure after acceptance of a message, the
-receiver-SMTP MUST formulate and mail a notification message.  This
-notification MUST be sent using a null ("<>") reverse path in the envelope.
-The recipient of this notification SHOULD be the address from the envelope
-return path (or the Return-Path: line).  However, if this address is null
-("<>"), the receiver-SMTP MUST NOT send a notification.  Obviously, nothing
-in this section can or should prohibit local decisions (i.e., as part of
-the same system environment as the receiver-SMTP) to log or otherwise
-transmit information about null address events locally if that is desired.
-If the address is an explicit source route, it MUST be stripped down to its
-final hop.
-
-For example, suppose that an error notification must be sent for a message
-that arrived with:
-   MAIL FROM:<@a,@b:user@d>
-
-The notification message SHOULD be sent using: 
-   RCPT TO:<user@d>
-
-Some delivery failures after the message is accepted by SMTP will be
-unavoidable.  For example, it may be impossible for the receiving SMTP
-server to validate all the delivery addresses in RCPT command(s) due to a
-"soft" domain system error, because the target is a mailing list (see
-earlier discussion of RCPT), or because the server is acting as a relay and
-has no immediate access to the delivering system.
-
-To avoid receiving duplicate messages as the result of timeouts, a
-receiver-SMTP MUST seek to minimize the time required to respond to the
-final <CRLF>.<CRLF> end of data indicator.  See RFC-1047 [RFC-1047] for a
-discussion of this problem.
-
-6.2 Loop Detection
-
-Simple counting of the number of "Received:" headers in a message has
-proven to be an effective, although rarely optimal, method of detecting
-loops in mail systems.  SMTP servers using this technique SHOULD use a
-large rejection threshold, normally at least 100 Received entries.
-Whatever mechanisms are used, servers MUST contain provisions for detecting
-and stopping trivial loops.
-
-6.3 Compensating for Irregularities
-
-Unfortunately, variations, creative interpretations, and outright
-violations of Internet mail protocols do occur; some would suggest that
-they occur quite frequently.  The debate as to whether a well-behaved SMTP
-receiver or relay should reject a malformed message, attempt to pass it on
-unchanged, or attempt to repair it to increase the odds of successful
-delivery (or subsequent reply) began almost with the dawn of structured
-network mail and shows no signs of abating.  Advocates of rejection claim
-that attempted repairs are rarely completely adequate and that rejection of
-bad messages is the only way to get the offending software repaired.
-Advocates of "repair" or "deliver no matter what" argue that users prefer
-that mail go through it if at all possible and that there are significant
-market pressures in that direction.  In practice, these market pressures
-may be more important to particular vendors than strict conformance to the
-standards, regardless of the preference of the actual developers.
-
-The problems associated with ill-formed messages were exacerbated by the
-introduction of the split-UA mail reading protocols [RFC-POP2, RFC-POP3,
-RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the use of SMTP as
-a posting protocol, and SMTP servers as relay systems for these client
-hosts (which are often only intermittently connected to the Internet).
-Historically, many of those client machines lacked some of the mechanisms
-and information assumed by SMTP (and indeed, by the mail format protocol
-[RFC-822]).  Some could not keep adequate track of time; others had no
-concept of time zones; still others could not identify their own names or
-addresses; and, of course, none could satisfy the assumptions that underlay
-RFC-822's conception of authenticated addresses.
-
-In response to these weak SMTP clients, many SMTP systems now complete
-messages that are delivered to them in incomplete or incorrect form.  This
-strategy is generally considered appropriate when the server can identify
-or authenticate the client, and there are prior agreements between them.
-By contrast, there is at best great concern about fixes applied by a relay
-or delivery SMTP server that has little or no knowledge of the user or
-client machine.
-
-The following changes to a message being processed MAY be applied when
-necessary by an originating SMTP server, or one used as the target of SMTP
-as an initial posting protocol:
-
- - Addition of a message-id field when none appears
-
- - Addition of a date, time or time zone when none appears
-
- - Correction of addresses to proper FQDN format
-
-The less information the server has about the client, the less likely these
-changes are to be correct and the more caution and conservatism should be
-applied when considering whether or not to perform fixes and how.  These
-changes MUST NOT be applied by an SMTP server that provides an intermediate
-relay function.
-
-In all cases, properly-operating clients supplying correct information are
-preferred to corrections by the SMTP server. In all cases, documentation of
-actions performed by the servers (in trace fields and/or header comments)
-is strongly encouraged.
-
-
-7. Security Considerations
-
-7.1 Mail Security and Spoofing
-
-SMTP mail is inherently insecure in that it is feasible for even fairly
-casual users to negotiate directly with receiving and relaying SMTP servers
-
-
-and create messages that will trick a naive recipient into believing that
-they came from somewhere else.  Constructing such a message so that the
-"spoofed" behavior cannot be detected by an expert is somewhat more
-difficult, but not sufficiently so as to be a deterrent to someone who is
-determined and knowledgeable. Consequently, as knowledge of Internet mail
-increases, so does the knowledge that SMTP mail inherently cannot be
-authenticated, or integrity checks provided, at the transport level. Real
-mail security lies only in end-to-end methods involving the message bodies,
-such as those that can be provided in the MOSS framework [RFC-MOSS].
-
-Various protocol extensions and configuration options that provide
-authentication at the transport level (e.g., from an SMTP client to an SMTP
-server) improve somewhat on the traditional situation described above.
-However, unless they are accompanied by careful handoffs of responsibility
-in a carefully-designed trust environment, they remain inherently weaker
-than end-to-end mechanisms which use digitally signed messages rather than
-depending on the integrity of the transport system.
-
-Efforts to make it more difficult for users to set envelope MAIL FROM and
-header "From" fields to point to valid addresses other than their own are
-largely misguided: they frustrate legitimate applications in which mail is
-sent by one user on behalf of another or in which error (or normal) replies
-should be directed to a special address. (Systems that provide convenient
-ways for users to alter these fields on a per-message basis should attempt
-to establish a primary and permanent mailbox address for the user so that
-Sender fields within the message data can be generated sensibly.)
-
-This specification does not further address the authentication issues
-associated with SMTP other than to advocate that useful functionality not
-be disabled in the hope of providing some small margin of protection
-against an ignorant user who is trying to fake mail.
-
-7.2 "Blind" Copies
-
-Addresses that do not appear in the message headers may appear in the RCPT
-TO commands to an SMTP server for a number of reasons.  The two most common
-involve the use of a mailing address as a "list exploder" (a single address
-that resolves into multiple addresses) and the appearance of "blind
-copies".  Especially when more than one RCPT command is present, and in
-order to avoid defeating some of the purpose of these mechanisms, SMTP
-clients and servers SHOULD NOT copy the full set of RCPT TO command
-arguments into the headers, either as part of trace headers or as
-informational or private-extension headers.  Since this rule is often
-violated in practice, and cannot be enforced, sending SMTP systems that are
-aware of "bcc" use MAY find it helpful to send each blind copy as a
-separate message transaction containing only a single RCPT TO command.
-
-There is no inherent relationship between either "reverse" (MAIL FROM, SAML
-FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP transaction
-("envelope") and the addresses in the headers.  Receiving systems SHOULD
-NOT attempt to deduce such relationships and use them to alter the headers
-of the message for delivery.  The popular "Apparently-to" header is a
-violation of this principle and SHOULD NOT be used.
-
-7.3 VRFY, EXPN, and Security
-
-As discussed in section 3.5, individual sites may want to disable one or
-both VRFY or EXPN for security reasons.  As a corollary to the above,
-implementations that permit this MUST NOT appear to have verified addresses
-that are not, in fact, verified.  If a site disables these commands for
-security reasons, the SMTP server MUST return a 252 response, rather than a
-code that could be confused with successful or unsuccessful verification.
-
-Returning a 250 reply code with the address listed in the VRFY command
-after having checked it only for syntax violates this rule. Of course, an
-implementation that "supports" VRFY by always returning 550 whether or not
-the address is valid is equally not in conformance.
-
-Within the last few years, the contents of mailing lists have become
-popular as an address information source for so-called "spammers." The use
-of EXPN to "harvest" addresses has increased as list administrators have
-installed protections against inappropriate uses of the lists themselves.
-Implementations SHOULD still provide support for EXPN, but sites SHOULD
-carefully evaluate the tradeoffs. As authentication mechanisms are
-introduced into SMTP, some sites may choose to make EXPN available only to
-authenticated requestors.
-
-7.4 Information Disclosure in Announcements
-
-There has been an ongoing debate about the tradeoffs between the debugging
-advantages of announcing server type and version (and, sometimes, even
-server domain name) in the greeting response or in response to the HELP
-command and the disadvantages of exposing useful information to potential
-hostile attack.  The utility of the debugging information is beyond doubt.
-Those who argue for making it available point out that it is far better to
-actually secure an SMTP server rather than hope that trying to conceal
-known vulnerabilities by hiding the server's precise identity will provide
-more protection. Sites are encouraged to evaluate the tradeoff with that
-issue in mind; implementations are strongly encouraged to minimally provide
-for making type and version information available in some way to other
-network hosts.
-
-7.5 Information Disclosure in Trace Fields
-
-In some circumstances, such as when mail originates from within a LAN whose
-hosts are not directly from the public Internet, trace ("Received") fields
-produced in conformance with this specification may disclose host names and
-similar information that would not normally be available.  This ordinarily
-does not pose a problem, but sites with special concerns about name
-disclosure should be aware of it.  Also, the optional FOR clause should be
-supplied with caution or not at all when multiple recipients are involved
-lest it inadvertently disclose the identities of "blind copy" recipients to
-others.
-
-7.6 Scope of Operation of SMTP Servers
-
-It is a well-established principle that an SMTP server may refuse to accept
-mail for any operational or technical reason that makes sense to the site
-providing the server. However, cooperation among sites and installations
-makes the Internet possible.  If sites take excessive advantage of the
-right to reject traffic, the ubiquity of email availability (one of the
-strengths of the Internet) will be threatened; considerable care should be
-taken and balance maintained if a site decides to be selective about the
-traffic it will accept and process.
-
-In recent years, use of the relay function through arbitrary sites has been
-used as part of hostile efforts to hide the actual origins of mail.  Some
-sites have decided to limit the use of the relay function to known or
-identifiable sources, and implementations SHOULD provide the capability to
-perform this type of filtering.  When mail is rejected for these or other
-policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL FROM,
-or RCPT TO as appropriate.
-
-
-8. IANA Considerations
-
-IANA will maintain three registries in support of this specification.  The
-first consists of SMTP service extensions with the associated keywords,
-and, as needed, parameters and verbs.  As specified in section 2.2.2, no
-entry may be made in this registry that starts in an "X".  Entries may be
-made only for service extensions (and associated keywords, parameters, or
-verbs) that are defined in standards-track or experimental RFCs
-specifically approved by the IESG for this purpose.
-
-The second registry consists of "tags" that identify forms of domain
-literals other than those for IPv4 addresses (specified in RFC 821 and in
-this document) and IPv6 addresses (specified in this document).  Additional
-literal types require standardization before being used; none are
-anticipated at this time.
-
-The third, established by RFC 821 and renewed by this specification, is a
-registry of link and protocol identifiers to be used with the "via" and
-"with" subclauses of the time stamp ("Received: header") described in
-section 4.4.  Link and protocol identifiers in addition to those specified
-in this document may be registered only by standardization or by way of an
-RFC-documented, IESG-approved, Experimental protocol extension.
-
-
-9. References
-
-[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
-Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994.
-
-[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax
-Specifications: ABNF", RFC 2234, November 1997.
-
-[IPv6AddrString] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
-Architecture", RFC 1884, December 1995.
-
-[MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt,
-August, 1998
-
-[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
-Messages", RFC 822, Department of Electrical Engineering, University of
-Delaware, August 1982.
-
-[RFC-974] C. Partridge, "Mail routing and the domain system", RFC 974,
-01/01/1986
-
-[RFC-1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047,
-02/01/1988.
-
-[RFC-1123] R. Braden, "Requirements for Internet hosts - application and
-support", 10/01/1989
-
-[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large
-and Binary MIME Messages", RFC 1830, 08/16/1995.
-
-[RFC-DNS] P. Mockapetris, "Domain names - implementation and
-specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and
-facilities", RFC 1034. (STD 13)
-
-[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue
-Starting", RFC 1985, 08/14/1996.
-
-[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version 2", RFC
-1176, 08/20/1990.
-
-[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - Version 4", RFC
-2060, 12/04/1996.
-
-[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part
-Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996.
-
-[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
-(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996.
-
-[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object
-Security Services", RFC 1848, 10/03/1995.
-
-[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status
-Notifications", RFC 1891, 01/15/1996.
-
-[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for
-Delivery Status Notifications", RFC 1894, 01/15/1996.
-
-[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal
-computers", RFC 1056, 06/01/1988.
-
-[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command
-Pipelining", RFC 1854, 10/04/1995.
-
-[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds,
-"Post Office Protocol - version 2", RFC 937, 02/01/1985
-
-[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930,
-5/14/96 (Std 53).
-
-[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893,
-01/15/1996.
-
-[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for
-Message Size Declaration", RFC 1870, 11/06/1995. (STD 10)
-
-[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021
-and RFC 822", RFC 1327, 05/18/1992.
-
-[SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
-Service Extensions", RFC-1869, 11/06/1995. (STD 10)
-
-[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
-Program Protocol Specification", RFC 793, USC/Information Sciences
-Institute, NTIS AD Number A111091, September 1981.
-
-[US-ASCII] United States of America Standards Institute (now American
-National Standards Institute), X3.4, 1968, "USA Code for Information
-Interchange". ANSI X3.4-1968 has been replaced by newer versions with
-slight modifications, but the 1968 version remains definitive for the
-Internet.
-
-
-10. Editor's Address
-
-John C. Klensin
-MCI Communications
-800 Boylston St., 7th floor
-Boston, MA 02199
-USA
-Email: Klensin@mci.net
-Phone: +1 617 960 1011
-Fax:   +1 617 960 1009
-
-
-11. Acknowledgments
-
-Many people worked long and hard on the many iterations of this document.
-There was wide-ranging debate on the mailing list about many technical
-issues, and many contributors helped form the wording in this
-specification. The hundreds of participants in the many discussions since
-RFC 821 was produced are too numerous to mention, but they all helped this
-document become what it is.
-
-
-A. TCP Transport Service
-
-The TCP connection supports the transmission of 8-bit bytes. The SMTP data
-is 7-bit ASCII characters.  Each character is transmitted as an 8-bit byte
-with the high-order bit cleared to zero.  Service extensions may modify
-this rule to permit transmission of full 8-bit data bytes as part of the
-message body, but not in SMTP commands or responses.
-
-
-B. Generating SMTP Commands from RFC 822 Headers
- 
-Some systems use RFC 822 headers (only) in a mail submission protocol, or
-otherwise generate SMTP commands from RFC 822 headers when such a message
-is handed to an MTA from a UA.  While the MTA-UA protocol is a private
-matter, not covered by any Internet Standard, there are problems with this
-approach.  For example, there have been repeated problems with proper
-handling of "bcc" copies and redistribution lists when information that
-conceptually belongs to a mail envelopes is not separated early in
-processing from header information (and kept separate).
-
-It is recommended that the UA provide its initial MTA with an envelope
-separate from the message itself.  However, if the envelope is not
-supplied, SMTP commands SHOULD be generated as follows:
-
-1. Each recipient address from a TO, CC, or BCC header field SHOULD be
-   copied to a RCPT command (generating multiple message copies if that is
-   required for queuing or delivery).  This includes any addresses listed
-   in a RFC 822 "group".  Any BCC fields SHOULD then be removed from the
-   headers.  Once this process is completed, the remaining headers SHOULD
-   be checked to verify that at least one To:, Cc:, or Bcc: header remains.
-   If none do, then a bcc: header with no additional information SHOULD be
-   inserted as specified in [MSGFMT].
-
-2. The return address in the MAIL command SHOULD, if possible, be derived
-   from the system's identity for the submitting (local) user, and the From
-   header field otherwise.  If there is a system identity available, it
-   SHOULD also be copied to the Sender header field if it is different from
-   the address in the From header field.  (Any Sender field that was
-   already there SHOULD be removed.)  Systems may provide a way for
-   submitters to override the envelope return address, but may want to
-   restrict its use to privileged users.  This will not prevent mail
-   forgery, but may lessen its incidence; see section 7.1.
-
-When an MTA is being used in this way, it bears responsibility for ensuring
-that the message being transmitted is valid.  The mechanisms for checking
-that validity, and for handling (or returning) messages that are not valid
-at the time of arrival, are part of the MUA-MTA interface and not covered
-by this specification.
-
-A submission protocol based on Standard RFC 822 information alone MUST NOT
-be used to gateway a message from a foreign (non-SMTP) mail system into an
-SMTP environment.  Additional information to construct an envelope must
-come from some source in the other environment, whether supplemental
-headers or the foreign system's envelope.
-
-Attempts to gateway messages using only their header "to" and "cc" fields,
-have repeatedly caused mail loops and other behavior adverse to the proper
-functioning of the Internet mail environment.  These problems have been
-especially common when the message originates from an Internet mailing list
-and is distributed into the foreign environment using envelope information.
-When these messages are then processed by a header-only remailer, loops
-back to the Internet environment (and the mailing list) are almost
-inevitable.
-
-
-C. Source Routes
-
-The <reverse-path> is a reverse source routing list of hosts and a source
-mailbox.  The first host in the <reverse-path> SHOULD be the host sending
-the MAIL FROM command.  Similarly, the <forward-path> may be a source
-routing lists of hosts and a destination mailbox. However, in general, the
-<forward-path> SHOULD contain only a mailbox and domain name, relying on
-the domain name system to supply routing information if required.  The use
-of source routes is deprecated; while servers MUST be prepared to receive
-and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
-transmit them.
-
-For relay purposes, the forward-path may be a source route of the form
-"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified
-domain names.  This form is used to emphasize the distinction between an
-address and a route.  The mailbox is an absolute address, and the route is
-information about how to get there.  The two concepts should not be
-confused.
-
-If source routes are used, RFC 821 and the text below should be consulted
-for the mechanisms for constructing and updating the forward- and
-reverse-paths.
-
-The SMTP server transforms the command arguments by moving its own
-identifier (its domain name or that of any domain for which it is acting as
-a mail exchanger), if it appears, from the forward-path to the beginning of
-the reverse-path.
-
-Notice that the forward-path and reverse-path appear in the SMTP commands
-and replies, but not necessarily in the message.  That is, there is no need
-for these paths and especially this syntax to appear in the "To:" ,
-"From:", "CC:", etc. fields of the message header. Conversely, SMTP servers
-MUST NOT derive final message delivery information from message header
-fields.
-
-When the list of hosts is present, it is a "reverse" source route and
-indicates that the mail was relayed through each host on the list (the
-first host in the list was the most recent relay).  This list is used as a
-source route to return non-delivery notices to the sender. As each relay
-host adds itself to the beginning of the list, it MUST use its name as
-known in the transport environment to which it is relaying the mail rather
-than that of the transport environment from which the mail came (if they
-are different).
-
-
-D. Scenarios
-
-This section presents complete scenarios of several types of SMTP sessions.
-In the examples, "C:" indicates what is said by the SMTP client, and "S:"
-indicates what is said by the SMTP server.
-
-D.1 A Typical SMTP Transaction Scenario
-
-This SMTP example shows mail sent by Smith at host bar.com, to Jones,
-Green, and Brown at host foo.com.  Here we assume that host bar.com
-contacts host foo.com directly.  The mail is accepted for Jones and Brown.
-Green does not have a mailbox at host foo.com.
-
-   S: 220 foo.com Simple Mail Transfer Service Ready
-   C: EHLO bar.com
-   S: 250-foo.com greets bar.com
-   S: 250-8BITMIME
-   S: 250-SIZE
-   S: 250-DSN
-   S: 250 HELP
-   C: MAIL FROM:<Smith@bar.com>
-   S: 250 OK
-   C: RCPT TO:<Jones@foo.com>
-   S: 250 OK
-   C: RCPT TO:<Green@foo.com>
-   S: 550 No such user here
-   C: RCPT TO:<Brown@foo.com>
-   S: 250 OK
-   C: DATA
-   S: 354 Start mail input; end with <CRLF>.<CRLF>
-   C: Blah blah blah...
-   C: ...etc. etc. etc.
-   C: .
-   S: 250 OK
-   C: QUIT
-   S: 221 foo.com Service closing transmission channel
-
-D.2 Aborted SMTP Transaction Scenario
-
-   S: 220 foo.com Simple Mail Transfer Service Ready
-   C: EHLO bar.com
-   S: 250-foo.com greets bar.com
-   S: 250-8BITMIME
-   S: 250-SIZE
-   S: 250-DSN
-   S: 250 HELP
-   C: MAIL FROM:<Smith@bar.com>
-   S: 250 OK
-   C: RCPT TO:<Jones@foo.com>
-   S: 250 OK
-   C: RCPT TO:<Green@foo.com>
-   S: 550 No such user here
-   C: RSET
-   S: 250 OK
-   C: QUIT
-   S: 221 foo.com Service closing transmission channel
-
-D.3 Relayed Mail Scenario
-
-Step 1  --  Source Host to Relay Host
-
-   S: 220 foo.com Simple Mail Transfer Service Ready
-   C: EHLO bar.com
-   S: 250-foo.com greets bar.com
-   S: 250-8BITMIME
-   S: 250-SIZE
-   S: 250-DSN
-   S: 250 HELP
-   C: MAIL FROM:<JQP@bar.com>
-   S: 250 OK
-   C: RCPT TO:<@foo.com:Jones@XYZ.COM>
-   S: 250 OK
-   C: DATA
-   S: 354 Start mail input; end with <CRLF>.<CRLF>
-   C: Date: Thu, 21 May 1998 05:33:29 -0700
-   C: From: John Q. Public <JQP@bar.com>
-   C: Subject:  The Next Meeting of the Board
-   C: To: Jones@xyz.com
-   C:
-   C: Bill:
-   C: The next meeting of the board of directors will be
-   C: on Tuesday.
-   C:                         John.
-   C: .
-   S: 250 OK
-   C: QUIT
-   S: 221 foo.com Service closing transmission channel
-
-Step 2  --  Relay Host to Destination Host
-
-   S: 220 xyz.com Simple Mail Transfer Service Ready
-   C: EHLO foo.com
-   S: 250 xyz.com is on the air
-   C: MAIL FROM:<@foo.com:JQP@bar.com>
-   S: 250 OK
-   C: RCPT TO:<Jones@XYZ.COM>
-   S: 250 OK
-   C: DATA
-   S: 354 Start mail input; end with <CRLF>.<CRLF>
-   C: Received: from bar.com by foo.com ; Thu, 21 May 1998 05:33:29 -0700
-   C: Date: Thu, 21 May 1998 05:33:22 -0700
-   C: From: John Q. Public <JQP@bar.com>
-   C: Subject:  The Next Meeting of the Board
-   C: To: Jones@xyz.com
-   C:
-   C: Bill:
-   C: The next meeting of the board of directors will be
-   C: on Tuesday.
-   C:                         John.
-   C: .
-   S: 250 OK
-
-   C: QUIT
-   S: 221 foo.com Service closing transmission channel
-
-D.4 Verifying and Sending Scenario
-
-   S: 220 foo.com Simple Mail Transfer Service Ready
-   C: EHLO bar.com
-   S: 250-foo.com greets bar.com
-   S: 250-8BITMIME
-   S: 250-SIZE
-   S: 250-DSN
-   S: 250 HELP
-   C: VRFY Crispin
-   S: 250 Mark Crispin <Admin.MRC@foo.com>
-   C: SEND FROM:<EAK@bar.com>
-   S: 250 OK
-   C: RCPT TO:<Admin.MRC@foo.com>
-   S: 250 OK
-   C: DATA
-   S: 354 Start mail input; end with <CRLF>.<CRLF>
-   C: Blah blah blah...
-   C: ...etc. etc. etc.
-   C: .
-   S: 250 OK
-   C: QUIT
-   S: 221 foo.com Service closing transmission channel
-
-
-E. Other Gateway Issues
-
-In general, gateways between the Internet and other mail systems SHOULD
-attempt to preserve any layering semantics across the boundaries between
-the two mail systems involved.  Gateway- translation approaches that
-attempt to take shortcuts by mapping, (such as envelope information from
-one system to the message headers or body of another) have generally proven
-to be inadequate in important ways.  Systems translating between
-environments that do not support both envelopes and headers and Internet
-mail must be written with the understanding that some information loss is
-almost inevitable.
-
-
-F. Deprecated Features of RFC 821
-
-A few features of RFC 821 have proven to be problematic and SHOULD NOT be
-used in Internet mail.
-
-F.1 TURN
-
-This command, described in RFC 821, raises important security issues since,
-in the absence of strong authentication of the host requesting that the
-client and server switch roles, it can easily be used to divert mail from
-its correct destination.  Its use is deprecated; SMTP systems SHOULD NOT
-use it unless the server can authenticate the client.
-
-F.2 Source Routing
-
-RFC 821 utilized the concept of explicit source routing to get mail from
-one host to another via a series of relays.  The requirement to utilize
-source routes in regular mail traffic was eliminated by the introduction of
-the domain name system "MX" record and the last significant justification
-for them was eliminated by the introduction, in RFC 1123, of a clear
-requirement that addresses following an "@" must all be fully-qualified
-domain names. Consequently, the only remaining justifications for the use
-of source routes are support for very old SMTP clients or MUAs and in mail
-system debugging.  They can, however, still be useful in the latter
-circumstance and for routing mail around serious, but temporary, problems
-such as problems with the relevant DNS records.
-
-SMTP servers MUST continue to accept source route syntax as specified in
-the main body of this document and in RFC 1123.  They MAY, if necessary,
-ignore the routes and utilize only the target domain in the address.  If
-they do utilize the source route, the message MUST be sent to the first
-domain shown in the address.  In particular, a server MUST NOT guess at
-shortcuts within the source route.
-
-Clients SHOULD NOT utilize explicit source routing except under unusual
-circumstances, such as debugging or potentially relaying around firewall or
-mail system configuration errors.
-
-F.3 HELO
-
-As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO
-when the server will accept the former.  Servers must continue to accept
-and process HELO in order to support older clients.
-
-F.4 #-literals
-
-RFC 821 provided for specifying an Internet address as a decimal integer
-host number prefixed by a pound sign, "#".  In practice, that form has been
-obsolete since the introduction of TCP/IP.  It is deprecated and MUST NOT
-be used.
-
-F.5 Dates and Years
-
-When dates are inserted into messages by SMTP clients or servers (e.g., in
-trace fields), four-digit years MUST BE used.  Two-digit years are
-deprecated; three-digit years were never permitted in the Internet mail
-system.
-
-F.6 Sending versus Mailing
-
-In addition to specifying a mechanism for delivering messages to user's
-mailboxes, RFC 821 provided additional, optional, commands to deliver
-messages directly to the user's terminal screen.  These commands (SEND,
-SAML, SOML) were rarely implemented, and changes in workstation technology
-and the introduction of other protocols may have rendered them obsolete
-even where they are implemented.
-
-Clients SHOULD NOT provide SEND, SAML, or SOML as services.  Servers MAY
-implement them.  If they are implemented by servers, the implementation
-model specified in RFC 821 MUST be used and the command names MUST be
-published in the response to the EHLO command.
-
-
-X. Change Summary and Loose Ends (Temporary)
-
-X.1 Change summary
-
-X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and
-draft-ietf-drums-smtpupd-01.txt
-
-(i) Slightly clarified the discussions of rejection and failure of VRFY
-requests and the associated response codes.
-
-(ii) Slightly clarified the discussion of deferred address validation.
-
-(iii) Removed the IPCE terminology and modified the text in section 4.1.1.2
-to explicitly introduce the "mail gateway" terminology and to begin to
-distinguish a mail gateway from a conventional relay.
-
-(iv) Explicitly noted that SMTP clients for things like POP and IMAP may
-send everything to a single relay for further processing, rather than
-resolving final domain names.
-
-(v) Tightened the RSET discussion.
-
-(vi) Deprecation of 251 only for RCPT (still ok for VRFY)
-
-X.1.2.  Substantive changes between draft-ietf-drums-smtpupd-01.txt and
-draft-ietf-drums-smtpupd-02.txt.
-
-Incorporated additional RFC 1123 material; reorganized several sections for
-clarity.  Added definitions and other previous "loose end" material.
-
-X.1.3.  Substantive changes between draft-ietf-drums-smtpupd-02.txt and
-draft-ietf-drums-smtpupd-03.txt.
-
-(i) Eliminated a number of placeholders and tightened some of the
-definitions in section 2.  Added a few new placeholders for consistency
-checking against other documents.
-
-(ii) Removed the state diagrams, per direction at IETF Montreal.
-
-(iii) Added new section 6.3, an attempt to summarize WG discussions on the
-"posting" versus "delivery" versus "relay" functions of SMTP and on whether
-"fixups" are appropriate in different cases.
-
-(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123.
-
-(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship.
-
-(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat.
-
-(v) The remaining miscellaneous changes agreed to in Montreal have been
-incorporated except as noted below.
-
-X.1.4.  Substantive changes between draft-ietf-drums-smtpupd-03.txt and
-draft-ietf-drums-smtpupd-04.txt.
-
-Many small changes have been made between these two versions; the list that
-follows is not exhaustive.
-
-(i) To clarify some of the text, definitions have been introduced to
-distinguish among originating, delivery, relay, and gateway SMTP systems.
-
-(ii) The role of LF-terminated lines has been clarified.
-
-(iii) Several changes have been made to clarify the principle that, no
-matter what originating and final delivery systems might do, relay systems
-are not permitted to tamper with message content, even to "fix" headers
-that are determined to be invalid.  If they deem message content to be
-seriously unacceptable, they are encouraged to reject the messages in
-preference to trying to fix them up, but, in general, the theme is "don't
-look/ don't tell".
-
-(iv) A few more definitions have been added to the terminology section, and
-the separate glossary has been eliminated.
-
-(v) I have taken a shot at text to address some of the controversies that
-have raged on the WG mailing list (e.g., sections 7.4 and 7.5). Since there
-was no consensus on most of those topics, I expect that the inserted text
-will satisfy no one except, perhaps, for agreement that saying nothing
-would have been worse.  As a mechanism for moving forward, the text in
-these controversial areas that now appears will be considered "base";
-alterations will be made only if clear consensus emerges.
-
-(vi) Per discussion in Los Angeles, source routes have been further
-deprecated.
-
-(vii) Some of the VRFY/EXPN materials have been moved to "security
-considerations", where they appear to belong, some text has been added, and
-the conformance statements adjusted to reflect what I perceive to be WG
-consensus.
-
-(viii) New MX resolution material has been added to section 5.  While most
-of this material is from RFC974, the rules have been further tightened to
-reflect current practice and experience (974 is written in a somewhat
-speculative fashion for a standard).  In particular, the behavior of trying
-the target host's A RR when MXs existed but all of them were eliminated is
-now prohibited, which seems necessary if another of other ideas being
-recommended or considered are to be feasible.
-
-X.1.5.  Substantive changes between draft-ietf-drums-smtpupd-04.txt and
-draft-ietf-drums-smtpupd-05.txt.
-
-(i) All normative references to RFC 1123 have been removed from the main
-body of the text (some still appear in the appendices where they will
-remain).
-
-(ii) Section 3.5 has been renamed slightly to distinguish between
-"debugging of SMTP implementations" and "debugging of addresses". Better
-terminology would be welcome.
-
-(iii) Error conditions resulting from the DATA command have been clarified.
-
-(iv) Section 4.2 (SMTP replies) has been revised and tightened to reflect
-reality and recent discussion on the list.
-
-(v) Appendix E has been revised a bit and moved into section 4.2.1. Given
-the importance of the "check only first digit" rule, it has to be there.
-
-(vi) Added new text for "no SMTP service supported" to sections 3.1, 4.2.2,
-4.2.3, and 4.3.2.  As noted in 3.1, I'd rather add 521 (which would work
-perfectly with the model) rather than overloading 554.
-
-(vii) The Return-path language in section 4.4 has been cleaned up a bit.
-
-(viii) Tightened the "postmaster" language in 4.5.1, requiring a small
-change to 4.1.1.3.
-
-(ix) I have unilaterally (with a little help from my friends), increased
-some of the size limits.  64 was much too short for a domain name, and the
-DNS limit of 255 (?) has now been inserted. That leaves the return path
-much too short, but I haven't fixed it (maybe that will cause us to get rid
-of them).  We still have a 64 character limit on the local-part, which is
-also *much* too short. Votes for 128 or longer limits accepted.  See
-X.1.6(I)
-
-(x) The text on the "recipients buffer" has been rewritten so that (I hope)
-it makes sense and gives some explicit guidance for how clients and servers
-should proceed if limits are imposed.
-
-X.1.6.  Substantive changes between draft-ietf-drums-smtpupd-05.txt and
-draft-ietf-drums-smtpupd-06.txt.
-
-Most of the changes in this revision have been editorial rather than
-substantive.  Major substantive changes include:
-
-(i)  The language about maximum sizes of SMTP command lines has been
-reworked, per WG mailing list discussion.
-
-(ii)  Several instances of  "Should" have been promoted to "Must" when the
-reasons for the weaker rule seemed to have disappeared.  In particular, the
-requirement that an SMTP implementation support timeouts has become a MUST.
-Also, conformance to this specification requires support of EHLO.  Older
-systems should claim conformance to the [to-be-historical] 821, not this
-specification.
-
-X.1.7.  Substantive changes between draft-ietf-drums-smtpupd-06.txt and
-draft-ietf-drums-smtpupd-07.txt.
-
-(i) Removed "implied RSET" text associated with QUIT, as specified at the
-December 1997 IETF
-
-(ii) Required that servers support EHLO, as specified at the December 1997
-IETF
-
-X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and
-draft-ietf-drums-smtpupd-08.txt.
-
-This version involves mostly editorial work and cleanup of loose ends.
-
-(i) New 7.5 added (old one renumbered) to discuss info disclosure through
-Received fields.
-
-(ii) Some character set and minor syntax issues clarified.
-
-(iii) Material on code 571 added (thought this had been done long ago;
-slipped through the cracks)
-
-(iv) Many clarifications added as the result of list discussions and
-suggestions.
-
-(v) Error code presentation has been restructured.
-
-(vi) ABNF conversion done
-
-(vii) IPv6 address format inserted per RFC 1884, since we could not get
-clear agreement on an alternative.
-
-(viii) Trivial, silly, examples removed.  Others not yet renumbered.
-
-(ix) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes.  Eric may
-not like the way I've done either of these change very much: the first now
-makes the distinction between returning an address and returning other
-stuff (which was permitted by -06, but the text wasn't as clear as it
-should have been): if it looks like an address, it needs to be an address.
-Similarly, with 4.1.1, Eric wanted to explicitly permit/legitimize "DATA
-<SP> <CRLF>".  I see several disadvantages to doing that, so have inserted
-language that encourages receivers to tolerate trailing white space, which
-may have the same practical effect.
-
-
-X.1.9. Substantive changes between draft-ietf-drums-smtpupd-08.txt and
-draft-ietf-drums-smtpupd-09.txt.
-
-The first ten of these reflect, in order, minuted items from the Chicago
-IETF (IETF 42).
-
-(i) Clarification of "MUST", etc., in the context of this document
-(section 2.3).
-
-(ii) Altered VRFY text to make implementation a SHOULD (section 3.5.1) and
-removed VRFY from the mandatory to implement list (section 4.5.1), per
-42nd IETF (Chicago).
-
-(iii) Clarified that exploders are expected to not purge sender addresses
-from lists (section 3.10).  Note that the Chicago conclusion was that this
-should be a "MUST".  I could not figure out how to do that without
-absolutely prohibiting removing addresses to prevent loops, to guard
-against spammers, or for similar legitimate purposes.  So I have written
-this as a "SHOULD", with additional "strongly discouraged" words.   If
-someone still wants a MUST, suggest text.
-
-(iv) Altered text to permit clients that sometimes, or even always,
-initiate sessions with HELO, rather than EHLO, to be fully-conforming
-(section 3.2).  [[ Editor's note: I continue to believe that a client that
-does not have any service extension support, even to the extent of being
-able to send EHLO and parse the response without doing anything about it,
-should not be considered fully-conforming to this spec (as distinct from
-821).   Consequently, the new text in 3.2 stops well short of encouraging
-clients that don't need service extensions from preferentially using HELO,
-and the text in 2.2.1 (which specifies that the extension mechanisms must
-be supported) has not been changed.
-
-(v) Per Chicago discussions, the text requiring that QUIT be sent has not
-been changed.  The text in 4.1.1.10 requiring that the server wait for
-QUIT has been changed to a SHOULD.  However, the text in 4.1.1.5,
-prohibiting close on receipt of RSET and that elsewhere prohibiting close
-as a normal response, has not been changed.
-
-(vi) Text has been inserted in 4.1.1 and the text in 4.3.2 altered
-slightly to clarify the handling of parameters to RSET, DATA, and QUIT and
-to 4.1.1.9 specify semantics for parameters to NOOP.  I have followed the
-minutes on this although I personally agree with kre's mailing list
-comments that the "servers SHOULD reject" decision leads to silly states.
-I recommend that the WG review this.
-
-(vii) Per discussion in Chicago, no substantive change has been made to
-the specification about underscore characters in domain names (section
-4.1.2).  However, the text has been altered to more accurately reflect
-discussion on the mailing list and the source of the requirement.
-
-(viii) Per discussion in Chicago, no change has been made to the
-preference for local time in Received headers.
-
-(ix) Per discussion in Chicago, code 571 has been removed and policy
-rejection is now reflected i a 550 code (section 3.7 and the response code
-lists).
-
-(x)  Per discussion in Chicago, no change has been made to the
-specification of use of raw CR or LF.
-
-(xi) In section 4.3, the text has been changed, per comments from Dan
-Bernstein and others, to require that clients be able to handle replies
-that do not contain text strings. A few other places patched to match.
-
-(xii) In sections 4.1.1.1 and 8, the placeholders have been removed.
-
-(xiii) Per discussion on the mailing list (and specifically James
-Berriman's concerns), the text has been clarified (sections 4.1.1.2 and
-4.1.4) to prohibit MAIL unless no mail transaction is open.  This is a
-MUST NOT prohibition -- SHOULD NOT makes no sense if this is the direction
-we are going to go.  503 has also been added to the list of valid
-responses for "MAIL" in 4.3.1 - it can't be issued before EHLO/HELO in any
-event.  While it is clear that something should be said, this may not be
-the desired outcome (I selected it because it was conservative and easy
-given the text that was there already); the WG should check that the text
-is as intended.
-
-(xiv) Per discussion on the mailing list, a new section 4.5.5 has been
-added to describe null return paths and their handling (forward pointer
-from 3.7).  The text in 4.5.5 is substantially that suggested by Norbert
-Bollow.   As with (xiii), there is now clear text, but it may not be what
-the WG desires.  Please check.
-
-[9b] Text lost in upload process restored.
-
-(xv) "all addresses" substituted for "each...in turn" in 3.10.2.
-
-(xvi) Requirement for "<" and ">" around paths clarified in section 3.3
-(syntax productions were clear and correct, but not this overview
-material).
-
-[9c]
-
-(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy
-matters. 
-
-
-
-Z.  Full Copyright Statement
-
-Copyright (C) The Internet Society (1998).  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.
-
-Expires June 1999
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt
deleted file mode 100644
index 8584790a..00000000
--- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-
-A new Request for Comments is now available in online RFC libraries.
-
-
-        RFC 2821
-
-        Title:      Simple Mail Transfer Protocol
-        Author(s):  J. Klensin, Editor
-        Status:     Standards Track
-        Date:       April 2001
-        Mailbox:    klensin@research.att.com
-        Pages:      79
-        Characters: 192504
-        Updates:    1123
-        Obsoletes:  821, 974
-
-        I-D Tag:    draft-ietf-drums-smtpupd-13.txt
-
-        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt
-
-
-This document is a self-contained specification of the basic protocol
-for the Internet electronic mail transport.  It consolidates, updates
-and clarifies, but doesn't add new or change existing functionality of
-the following:
- 
--  the original SMTP (Simple Mail Transfer Protocol) specification of
-   RFC 821,
- 
--  domain name system requirements and implications for mail
-   transport from RFC 1035 and RFC 974,
- 
--  the clarifications and applicability statements in RFC 1123,
-   and
- 
--  material drawn from the SMTP Extension mechanisms.
- 
-It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the
-mail transport materials of RFC 1123).  However, RFC 821 specifies
-some features that were not in significant use in the Internet by the
-mid-1990s and (in appendices) some additional transport models.  Those
-sections are omitted here in the interest of clarity and brevity;
-readers needing them should refer to RFC 821.
-
-It also includes some additional material from RFC 1123 that required
-amplification.  This material has been identified in multiple ways,
-mostly by tracking flaming on various lists and newsgroups and
-problems of unusual readings or interpretations that have
-appeared as the SMTP extensions have been deployed.  Where this
-specification moves beyond consolidation and actually differs from
-earlier documents, it supersedes them technically as well as
-textually.
- 
-Although SMTP was designed as a mail transport and delivery protocol,
-this specification also contains information that is important to its
-use as a 'mail submission' protocol, as recommended for POP and IMAP. 
-
-Additional submission issues are discussed in RFC 2476.
- 
-Section 2.3 provides definitions of terms specific to this document.
-Except when the historical terminology is necessary for clarity, this
-document uses the current 'client' and 'server' terminology to
-identify the sending and receiving SMTP processes, respectively.
- 
-A companion document discusses message headers, message bodies
-and formats and structures for them, and their relationship.
-
-This document is a product of the Detailed Revision/Update of Message
-Standards Working Group of the IETF.
-
-This is now a Proposed Standard Protocol.
-
-This document specifies an Internet standards track protocol for
-the Internet community, and requests discussion and suggestions
-for improvements.  Please refer to the current edition of the
-"Internet Official Protocol Standards" (STD 1) for the
-standardization state and status of this protocol.  Distribution
-of this memo is unlimited.
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
-help: ways_to_get_rfcs.  For example:
-
-        To: rfc-info@RFC-EDITOR.ORG
-        Subject: getting rfcs
-
-        help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.echo 
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
-Authors, for further information.
diff --git a/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-01.txt b/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-01.txt
deleted file mode 100644
index f8a652ac..00000000
--- a/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-01.txt
+++ /dev/null
@@ -1,354 +0,0 @@
-
-
-Network Working Group                        K. Toyoda, MGCS
-Internet Draft                       D. Crocker, Brandenburg
-  draft-ietf-fax-esmtp-conneg-01.txt           November 2001
-Expires: May 2002
-
-
-
-                   SMTP Service Extension
-           for Content Negotiation of Internet Fax
-     
-     
-     
-     STATUS OF THIS MEMO
-     
-     This document is an Internet-Draft and is in full
-     conformance with all provisions of Section 10 of
-     RFC2026. Internet-Drafts are working documents of the
-     Internet Engineering Task Force (IETF), its areas, and
-     its working groups.  Note that other groups may also
-     distribute working documents as Internet-Drafts.
-     
-     Internet-Drafts are draft documents valid for a maximum
-     of six months and may be updated, replaced, or
-     obsoleted by other documents at any time.  It is
-     inappropriate to use Internet-Drafts as reference
-     material or to cite them other than as "work in
-     progress."
-     
-     The list of current Internet-Drafts can be accessed at
-          http://www.ietf.org/ietf/1id-abstracts.txt
-     
-     The list of Internet-Draft Shadow Directories can be
-     accessed at
-          http://www.ietf.org/shadow.html.
-     
-     COPYRIGHT NOTICE
-     
-     Copyright (C) The Internet Society (2001).  All Rights
-     Reserved.
-     
-     SUMMARY
-     
-     This document defines a content negotiation SMTP
-     service extension [ESMTP1, ESMTP2] whereby an SMTP
-     client may request information about content
-     capabilities of the target device or system that is
-     serviced by an SMTP server.  The SMTP server may report
-     the target's content capabilities back to the client.
-     This process emulates a classic facsimile start-of-
-     session capabilities negotiation.  This service
-     extension is primarily intended for "direct" SMTP
-     transfers, although relayed scenarios are permitted.
-
-
-
-1.   CONVENTIONS
-     
-     In examples, "C:" and "S:" indicate lines sent by the
-     client and server respectively.
-     
-     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD
-     NOT", and "MAY" in this document are to be interpreted
-     as defined in "Key words for use in RFCs to Indicate
-     Requirement Levels" [KEYWORDS].
-
-
-
-2.   CONTENT NEGOTIATION SERVICE EXTENSION
-     
-     (1)  The name of the SMTP service extension is
-          "Content_Negotiation"
-
-     (2)  The EHLO keyword value associated with this extension
-          is "CONNEG"
-
-     (3)  A parameter using the keyword "CONNEG" is added to the
-          RCPT-TO command
-
-     (4)  The server responds with a report of the content
-          capabilities of the device or system that embodies the
-          target RCPT-TO address.
-
-
-
-3.   CONNEG PARAMETER TO RCPT-TO
-     
-     Parameter:
-          
-          CONNEG
-     
-     Arguments:
-          
-          There are no arguments.
-     
-     Client Action:
-          
-          If the server issued a 250-CONNEG, as part of its
-     EHLO response for the current session, the client MAY
-     issue the CONNEG parameter with RCPT-TO.
-          
-          If the client issues the CONNEG parameter with
-     RCPT-TO, then it MUST honor the capabilities specified
-     in the CONNEG RCPT-TO reply, and transform data that is
-     sent, so that the target can accept the data. The
-     client SHOULD transform the data to the "highest" level
-     of capability of the target.
-     
-     Server Action:
-          
-          If the client specifies CONNEG in the RCPT-TO, but
-     the target does not support the CONNEG parameter, the
-     target MUST reject the RCPT-TO command with a 504
-     reply.
-          
-          If the target does support the CONNEG parameter,
-     then it MUST issue a 250 reply, followed by its
-     capabilities of the target that is specified by the
-     RCPT-TO address.
-          
-           Successful responses to CONNEG RCPT-TO 
-     requests will always be multiple SMTP lines.  The
-     first line is the normal RCPT-TO response, and 
-     subsequent lines beginning with the exact string
-     "250-CONNEG " and "250 CONNEG " are the CONNEG responses.
-     The last line begins with "250 CONNEG ".  if the SMTP 
-     server supports ENHANCEDSTATUSCODES, the exact strings 
-     are "250-2.1.5 CONNEG " and "250 2.1.5 CONNEG ".
-
-         All CONNEG-capable clients and CONNEG-capable servers MUST
-     be able to successfully process CONNEG lines that are up to 512
-     characters long, as required by RFC2821.
-          
-          The contents of the capability listing MUST
-     conform to the specifications in "Content Feature
-     Schema for Internet Fax". [RFC2879]
-
-
-
-4.   SYNTAX
-     
-     Command with "CONNEG":
-      "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>"
-                   / Forward-Path) (SP "CONNEG") CRLF
-
-     Reply:
-      ( ("250-" CRLF) *("250-CONNEG" capability CRLF)
-        ("250 CONNEG" capability CRLF) )/
-      ( ("250-2.1.5" CRLF) 
-          *("250-2.1.5 CONNEG" capability CRLF)
-           ("250 2.1.5 CONNEG" capability CRLF) )
-
-      capability  =  <<as per [RFC2879]>>
-
-
-
-5.   EXAMPLE
-     
-
-     S: 220 ifax1.jp IFAX
-     
-     C: EHLO ifax1.jp
-     
-     S: 250-ifax1.jp
-     S: 250-DSN
-     S: 250 CONNEG
-     
-     C: MAIL FROM:<May@ifax2.jp>
-     
-     S: 250 <May@ifax2.jp> sender ok
-     
-     C: RCPT TO:<June@ifax1.jp> CONNEG
-     
-     S: 250-<June@ifax1.jp> recipient ok
-     S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
-     S: 250-CONNEG   (MRC-mode=0)
-     S: 250-CONNEG   (color=Binary)
-     S: 250-CONNEG   (|(&(dpi=204)
-     S: 250-CONNEG       (dpi-xyratio=[204/98,204/196]) )
-     S: 250-CONNEG     (&(dpi=200)
-     S: 250-CONNEG       (dpi-xyratio=[200/100,1]) )
-     S: 250-CONNEG     (&(dpi=400)
-     S: 250-CONNEG       (dpi-xyratio=1) ) )
-     S: 250-CONNEG   (|(image-coding=[MH,MR,MMR])
-     S: 250-CONNEG      (&(image-coding=JBIG)
-     S: 250-CONNEG        (image-coding-constraint=JBIG-T85)
-     S: 250-CONNEG        (JBIG-stripe-size=128) ) )
-     S: 250-CONNEG   (paper-size=[letter,A4,B4])
-     S: 250 CONNEG   (ua-media=stationery) )
-     
-     C: DATA
-     
-     S: 354 okay, send data
-     
-     C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
-          Per:
-          (  image-file-structure=TIFF-minimal
-             dpi=400
-             image-coding=JBIG
-             size-x=2150
-           )
-        >>
-     
-     S: 250 message accepted
-     
-     C: QUIT
-     
-     S: 221 goodbye
-
-
-     An example when CONNEG-capable server supports 
-     ENHANCEDSTATUSCODES.
-     
-
-     S: 220 ifax1.jp IFAX
-     
-     C: EHLO ifax1.jp
-     
-     S: 250-ifax1.jp
-     S: 250-DSN
-     S: 250-ENHANCEDSTATUSCODES
-     S: 250 CONNEG
-          
-     C: MAIL FROM:<May@ifax2.jp>
-     
-     S: 250 2.1.5<May@ifax2.jp> sender ok
-     
-     C: RCPT TO:<June@ifax1.jp> CONNEG
-     
-     S: 250-2.1.5<June@ifax1.jp> recipient ok
-     S: 250-2.1.5 CONNEG (&(image-file-structure=TIFF-minimal)
-     S: 250-2.1.5 CONNEG   (MRC-mode=0)
-     S: 250-2.1.5 CONNEG   (color=Binary)
-     S: 250-2.1.5 CONNEG   (|(&(dpi=204)
-     S: 250-2.1.5 CONNEG       (dpi-xyratio=[204/98,204/196]) )
-     S: 250-2.1.5 CONNEG     (&(dpi=200)
-     S: 250-2.1.5 CONNEG       (dpi-xyratio=[200/100,1]) )
-     S: 250-2.1.5 CONNEG     (&(dpi=400)
-     S: 250-2.1.5 CONNEG       (dpi-xyratio=1) ) )
-     S: 250-2.1.5 CONNEG   (|(image-coding=[MH,MR,MMR])
-     S: 250-2.1.5 CONNEG      (&(image-coding=JBIG)
-     S: 250-2.1.5 CONNEG        (image-coding-constraint=JBIG-T85)
-     S: 250-2.1.5 CONNEG        (JBIG-stripe-size=128) ) )
-     S: 250-2.1.5 CONNEG   (paper-size=[letter,A4,B4])
-     S: 250 2.1.5 CONNEG   (ua-media=stationery) )
-     
-
-
-6.   IANA CONSIDERATIONS
-     
-     This memo is not intended to create any new issues for
-     IANA.
-
-
-
-7.   SECURITY CONSIDERATIONS
-     
-     This ESMTP option calls for a respondent to disclose
-     its capabilities.  Mechanisms for determining the
-     requestor's authenticated identity are outside the
-     scope of this specification.  It is intended that this
-     mechanism permit disclosure of public information;
-     hence there is no particular need for security
-     measures.
-     
-     However there is nothing to prevent disclosure of
-     sensitive information that should receive restricted
-     distribution.  It is, therefore, the responsibility of
-     the disclosing ESMTP server to determine whether
-     additional security measures should be applied to the
-     use of this ESMTP option.
-
-
-
-8.   ACKNOWLEDGEMENTS
-     
-     Graham Klyne provided useful suggestions to an earlier
-     draft.
-
-
-
-9.   REFERENCES
-     
-     [ESMTP1]  Klensin, J., Freed, N., Rose, M., Stefferud,
-               E. and D. Crocker, "SMTP Service Extensions",
-               RFC 1869, November 1995
-     
-     [ESMTP2]  Klensin, J., "Simple Mail Transfer Protocol",
-               RFC 2821, April 2001.
-     
-     [RFC2879] McIntyre, L. and G. Klyne, "Content Feature
-               Schema for Internet Fax", RFC 2531, August
-               2000
-
-
-
-10.       AUTHORS' ADDRESSES
-     
-     Kiyoshi Toyoda
-     Matsushita Graphic Communication Systems,Inc
-     2-3-8 Shimomeguro, Meguro-Ku
-     Tokyo 153  JAPAN
-     
-     +81.3.5434.7161
-     ktoyoda@rdmg.mgcs.mei.co.jp
-     
-     
-     Dave Crocker
-     Brandenburg InternetWorking
-     675 Spruce Drive
-     Sunnyvale, CA  94086  USA
-     
-     +1.408.246.8253
-     dcrocker@brandenburg.com
-
-
-
-11.       FULL COPYRIGHT STATEMENT
-     
-     Copyright (C) The Internet Society (2001).  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.
-
-
diff --git a/Documentation/en/I-D/draft-ietf-fax-smtp-capabilities-01.txt b/Documentation/en/I-D/draft-ietf-fax-smtp-capabilities-01.txt
deleted file mode 100644
index 27e197a9..00000000
--- a/Documentation/en/I-D/draft-ietf-fax-smtp-capabilities-01.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-N. Joffe: njoffe@cisco.com                                                        

-D. Wing: dwing@cisco.com                                                         

-

-

diff --git a/Documentation/en/I-D/draft-ietf-fax-smtp-session-04.txt b/Documentation/en/I-D/draft-ietf-fax-smtp-session-04.txt
deleted file mode 100644
index d55e5a1e..00000000
--- a/Documentation/en/I-D/draft-ietf-fax-smtp-session-04.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Applications Area                                             Neil Joffe
-Internet Draft                                                  Dan Wing
-August 7, 1998                                             Cisco Systems
-Expires January 1999                                      Larry Masinter
-                                                       Xerox Corporation
-
-                       SMTP Service Extension for
-                           Immediate Delivery
-
-                   draft-ietf-fax-smtp-session-04.txt
-
-Status of this memo
-
-   This document is an Internet-Draft. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups.  Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   To view the entire list of current Internet-Drafts, please check
-   the "1id-abstracts.txt" listing contained in the Internet-Drafts
-   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
-   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
-   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
-   (US West Coast).
-
-
-      NOTE: although this work has been discussed in the IETF-FAX
-      working group, it does not purport to represent the
-      consensus of the group.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1997, 1998).  All Rights
-   Reserved.
-
-Abstract
-
-   This memo defines an extension to SMTP which provides a mechanism for
-   requesting immediate message delivery over SMTP instead of normal
-   store-and-forward delivery.  It also provides a mechanism for
-   querying the SMTP server if immediate delivery was successful, is
-   still in progress, or was simply queued as a normal store-and-forward
-   message.
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                 [Page 1]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-0.  Administrivia
-
-0.1.  Changes Since Previous Versions
-
-   Changes from -03 to -04:
-      * Added "failed" code.
-      * Added status=x.y.z, where x.y.z is from RFC1893 and
-        FAX Report Extensions [REPORT-EXTEND].
-
-   Changes from draft-ietf-fax-smtp-session-02.txt to -03:
-      * Corrected grammer and typos.  Added clarifications to
-        some areas.
-
-   Changes from draft-ietf-fax-smtp-session-01.txt to -02:
-
-      * Added sequence of events and state diagram sections
-        to clarify timing and responsibility issues.
-
-      * Server's reply to STAT is now a sequence of simple codes instead
-        of a multipart/report.
-
-      * STAT command polls for all recipients that had SESSION
-        on the RCPT command.
-
-   Changes from draft-ietf-fax-smtp-session-00.txt to -01:
-
-      * Added copyright notice
-
-      * Reference to [FAX-DSN].
-
-   Changes from draft-wing-smtp-session-00 to
-   draft-ietf-fax-smtp-session-00.txt:
-
-      * Server's reply to STAT is now a complete multipart/report
-
-      * Language clarifications
-
-      * Require immediate SMTP server reply after client sends "."
-
-      * Specify SMTP server must respond to STAT within 30 seconds
-
-1.  Introduction
-
-   Historically, SMTP [RFC821] has been used for store and forward
-   delivery of messages.  This memo describes a new SMTP extension
-   called SESSION.  This new extension allows an SMTP client to request
-   immediate delivery by the SMTP server.
-
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                 [Page 2]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-   This Session extension was motivated by an analysis of the
-   requirements for using the Internet to deliver fax messages, and,
-   coupled with a mechanism for exchanging capabilities and preferences
-   of sender and recipient, can be used by email<->fax gateway
-   applications.  In addition, the SESSION extension may be useful for
-   other messaging applications where immediate delivery and
-   confirmation of immediate delivery are requested.
-
-   The LMTP protocol [RFC2033] provides immediate delivery, but as
-   discussed in [RFC2033] can aggravate the duplicate message delivery
-   problem [RFC1047], especially over a WAN.  The Session extension
-   described in this memo is intended to provide immediate delivery of
-   SMTP messages without aggravating the duplicate message delivery
-   problem.
-
-   This extension presumes either a direct connection between sender and
-   recipient or a chain of session-enabled servers in which each
-   supports this Session extension.
-
-   If an MTA in the SMTP "path" does not support Session, delivery
-   automatically falls back to normal store and forward, and such
-   fallback is communicated to the SMTP client, as described in section
-   3.2.
-
-   Unlike the deprecated SAML, SOML and SEND commands (documented in
-   [RFC821] and deprecated in [DRUMS]) the SESSION extension allows for a
-   mix of immediate and store & forward delivery recipients.
-
-   This memo uses the mechanism described in [RFC1869] to define an
-   extension to the SMTP protocol for immediate delivery.
-
-1.2.  Discussion of This Draft
-
-   This draft is being discussed on the "ietf-fax" mailing list.  To
-   subscribe, send a message to <ietf-fax-request@imc.org> with the line
-   "subscribe" in the body of the message.  Archives are available from
-   http://www.imc.org/ietf-fax.
-
-1.3.  Requirements Notation
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Framework for Immediate Delivery Support
-
-   The immediate message delivery is defined as follows:
-
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                 [Page 3]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-       (1)  The name of the immediate extension is Session;
-
-       (2)  the EHLO keyword value associated with the immediate
-            extension is SESSION;
-
-       (3)  no parameter is used with the SESSION EHLO keyword;
-
-       (4)  one new SMTP verb, STAT (used to determine if immediate
-            delivery was successful) is defined with this extension, and
-            is described in section 3;
-
-       (5)  one optional parameter is added to the RCPT command, using
-            the esmtp-keyword SESSION, and is described in section 4,
-
-            no parameters are added to the MAIL FROM command;
-
-       (6)  the maximum length of a RCPT TO is increased by 8
-            characters.
-
-3.  Esmtp-keyword SESSION
-
-   Upon receiving a RCPT command with the esmtp-keyword SESSION, a
-   session-enabled server will normally send either a positive (2xx) or
-   negative (5xx) reply to the SMTP client.
-
-   A 250 reply code indicates that the session-enabled server believes
-   the message will be sent immediately -- that is, that the request for
-   SESSION delivery will be honored.
-
-   If a session-enabled server is aware that it will be unable to
-   send the message immediately (that is, the request for SESSION will
-   not be honored), but the session-enabled server is willing to send
-   the message via its normal SMTP queue, it SHOULD respond with a 252
-   reply code.  The SMTP client can use this information to inform the
-   user that immediate delivery isn't available, and the SMTP client (or
-   the user) may decide on a different transmission mechanism.
-
-3.1.  Delivery Responsibility
-
-   As per normal SMTP, once a sender has received a positive response to
-   its end of mail data indicator, the receiver has accepted all
-   responsibility for message delivery.
-
-   If an MTA is relaying a message using this Session extension,
-   and it fails to receive a positive response to its end of mail data
-   indicator from the next-hop mailer, the Session-enabled MTA MUST
-   queue the message as a normal SMTP store-and-forward message for
-   later delivery.  This is because the MTA performing the relaying
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                 [Page 4]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-   accepted responsibility for message delivery at this point.  See
-   the section "Sequence of Events" for details.
-
-3.2.  Fallback to Store and Forward
-
-   This section describes scenarios which would cause immediate delivery
-   to fallback to normal store-and-forward delivery.
-
-3.2.1.  Mailers that do not implemention this Session extension
-
-   If an MTA is encountered which does not support the Session
-   extension, the MTA which detected this SHOULD respond to
-   its incoming SMTP connection with a 252 response code.  As
-   Session delivery is not possible to the next-hop mailer,
-   normal store-and-forward mail delivery will occur.
-
-3.2.1.  Excessive Delays with Multiple MTAs
-
-   The cumulative delays of going through many MTAs will cause Session
-   delivery to fail (by falling back to normal store-and-forward).
-   Proper configuration and deployment of SMTP servers will prevent this
-   problem.
-
-   Implementors must carefully design session-enabled MTAs to respond
-   quickly when Session recipients are present to minimize timing
-   problems.  Each MTA is maintaining its own SMTP timeouts
-   which can't be exceeded by the entire end-to-end delay [RFC1123].
-
-   Additionally, Session is not expected to work reliably across
-   lossy links or with overloaded mailers.
-
-3.3.  Sequence of Events and State Diagrams
-
-   This section describes the sequence of events for a RCPT command
-   that contains the esmtp-keyword SESSION, and also includes
-   State Diagrams for various components.
-
-3.3.1.  Events - Single Remote MTA
-
-   If the RCPT command contains the esmtp-keyword SESSION, the
-   SMTP server SHOULD connect to the next-hop mailer prior to
-   responding to the SMTP client's RCPT command.
-
-      +-----+    +--------+     +-------+    +-----------+
-      | user| => |Original| ==> | MTA-1 | => | receiving |  user@host-x
-      |agent|    |  MTA   |     |       |    |   MTA-1   |
-      +-----+    +--------+     +-------+    +-----------+
-        (A)         (B)           (C)           (D)
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                 [Page 5]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-
-   Using the above diagram:
-
-      1.  the SMTP client (A) would initiate an SMTP transaction with
-          (B), and send a RCPT command with the esmtp-keyword SESSION to
-          (B), then
-
-      2.  (B) would initiate an SMTP transaction with (C) and send the
-          same RCPT command with the esmtp-keyword SESSION to (C), then
-
-      3.  (C) would initiate an SMTP transaction with (D) and send the
-          same RCPT command with the esmtp-keyword to (D), then
-
-      4.  (D) would send its response to (C), which would send the
-          response to (B), which would send the response to (A), then
-
-      5.  (A) would send its next RCPT command (if sending to
-          multiple recipients), then
-
-      6.  (A) would indicate it wants to send the message body by
-          sending the DATA (or BDAT if using [RFC1830]) command, then
-
-      7.  (B) would send the DATA (or BDAT) command to (C),
-          which would send it to (D), which would send its response
-          code to (C), which is sent to (B), which is sent to
-          (A), then
-
-      8.  (A) sends its message body to (B), which SHOULD spool
-          it to a local disk while sending it to (C), which SHOULD
-          spool it to a local disk while sending it to (D), which
-          writes it to the local user's mailstore.
-
-      9.  (A) sends its end of mail data indicator ("." unless using
-          [RFC1830]), then
-
-     10.  (B) responds to the end of mail data indicator immediately
-          (and is now responsible for message delivery should it
-          fail after this point), then (B) sends the end of mail data
-          indicator to (C), then
-
-     11.  (C) responds to the end of mail data indicator
-          immediately (and is now responsible for message delivery
-          should it fail after this point), then (C) sends the end of
-          mail data indicator to (D)
-
-     12.  (D) responds to the end of mail data indicator when it has
-          finished writing to the user's mailbox.
-
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                 [Page 6]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-          If there are multiple local recipients and one or more
-          recipients succeeded, but at least one failed, (D) must issue
-          a postive response code to prevent duplicate message delivery
-          [RFC1047].  It MUST generate a bounce message for the failed
-          local recipient(s), and the bounce SHOULD be in the format
-          of a DSN [DSN].
-
-3.3.2.  Events - Multiple Remote MTAs
-
-   The case where there are multiple remote MTAs is a more complex
-   case than described above, but the same rules apply.
-
-                                 +-----------+
-                             -=> | receiving |  user@host-x
-                            /    |   MTA-1   |
-   +-----+    +--------+   /     +-----------+
-   | user| => |Original| =<          (C)
-   |agent|    |  MTA   |   \
-   +-----+    +--------+    \    +-----------+
-     (A)         (B)         -=> | receiving |  user@host-y
-                                 |   MTA-2   |
-                                 +-----------+
-                                     (D)
-
-   (B) would have to send the appropriate RCPT command with the
-   esmtp-keyword SESSION, the appropriate next-hop MTA (C or D) for each
-   recipient (user@host-x, user@host-y) and echo the responses back to
-   (A).
-
-   When (A) sends its DATA command, (B) would have to send the DATA
-   command to both MTAs, and reply to (A) if both MTAs have responded
-   positively.
-
-   When (A) sends its end of mail data indicator, (B) must respond
-   immediately, and then (B) can send the end of mail data indicator
-   to (C) and (D).
-
-   If (B) does not receive a positive (2xx) response from (C) or (D),
-   (B) must queue the message as a normal store and forward message.
-
-3.3.3.  State diagram - MTA relay
-
-   The following state diagram describes the behavior of an MTA relaying
-   Session connection.
-
-        |
-        V (1)
-      +---------+  (2)  +---------+
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                 [Page 7]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-      | Setup   |------>| Connect |
-      | message |<------| forward |
-      +---------+  (3)  +---------+
-        |
-        V (4)
-      +---------+ (5) +---------+ (6) +---------+ (7) +--------+
-      | Sending |---->| Waiting |---->| Gather  |---->| Query  |
-      |  data   |     |         |<----| status  |<----| status |
-      +---------+     +---------+ (9) +---------+ (8) +--------+
-                          |
-                          V (10)
-                        +----------+
-                        | Complete |
-                        +----------+
-
-
-   (1)  Event:  Incoming MAIL FROM.
-        Test:   -
-        Action: Prepare to forward message.
-
-   (2)  Event:  incoming RCPT TO
-        Test:
-        Action: IF connection to next-hop server for this message does
-                not already exist then create connection and issue MAIL
-                FROM command.  Issue RCPT TO command to next-hop
-                server.
-
-   (3)  Event:  Response to RCPT TO command.
-        Test:   -
-        Action: Respond to incoming RCPT TO.
-
-   (4)  Event:  Incoming DATA/BDAT.
-        Test:   -
-        Action: Issue DATA/BDAT on forward connections, and
-                forward data as it is received.
-
-   (5)  Event:  End of data, with confirmation from all downstream MTAs
-        Test:   -
-        Action: Wait
-
-   (6)  Event:  Incoming STAT command.
-        Test:   -
-        Action: Start gathering status - straight to (7)
-
-   (7)  Event:  -
-        Test:   There are more downstream MTAs to query.
-        Action: Issue STAT command on next downstream MTA.
-
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                 [Page 8]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-   (8)  Event:  Response to STAT command.
-        Test:   -
-        Action: Pass back as response to incoming STAT.  If status
-                indicates completion then close the downstream
-                connection.
-
-   (9)  Event:  -
-        Test:   There are no more downstream MTAs to query.
-        Action: Wait.
-
-   (10) Event:  Incoming RSET, MAIL FROM or SMTP connection broken.
-        Test:   -
-        Action: Close any remaining downstream connections.
-
-4.  New SMTP Verb STAT
-
-   One new SMTP verb is introduced with this extension.  The STAT verb
-   causes the SMTP server to respond with the Session delivery status of
-   all Session recipients.
-
-   An SMTP client MAY send the STAT command if it used the esmtp-keyword
-   SESSION on one of its RCPT commands, but the SMTP client is not
-   required to use the STAT verb.  SMTP servers which implement the
-   SESSION extension MUST implement the STAT verb.
-
-   The SMTP client MUST NOT send the STAT command unless all of the
-   following are true:  (1) the SMTP client sent a RCPT command with the
-   esmtp-keyword SESSION; (2) the SMTP server sent a positive response
-   to that RCPT command; (3) the SMTP client has finished sending the
-   message body and sent the end of mail data indicator ("." or BDAT
-   LAST).  If the SMTP client sends the STAT command when not all of the
-   above conditions are met, the SMTP server MUST send a response code
-   of 503.
-
-   The syntax of the STAT verb, using the notation described in
-   [RFC2234], is:
-
-      stat-cmd = "STAT" CR LF
-
-4.1.  Format of STAT Response
-
-   The SMTP server's positive response to the STAT command is a
-   multiline SMTP response.  Each line contains information on each
-   Session recipient, in the order specified by the SMTP client.
-
-   If the SMTP server is making a negative response to the STAT command
-   the response should be a 5xx response code and follow the normal SMTP
-   rules for multiple line responses.  There is no specific format of
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                 [Page 9]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-   5xx responses.
-
-   The syntax of the positive response must be parsable by an SMTP
-   client.  Using the notation described in [RFC2234], the syntax is:
-
-      stat-response  = *( "250-" [cmd-status SP] resp-line CR LF )
-                          "250 " [cmd-status SP] resp-line CR LF
-
-      resp-line      = forward-path SP session-status
-                       [SP "by=" mta-hostname]
-
-      session-status = "delivered" terminal /
-                       "in-progress" SP prog-value /
-                       "queued" terminal /
-                       "failed" terminal
-
-      terminal       = SP trans-status [SP trans-id]
-
-      trans-status   = "status=" status-code
-
-      trans-id       = "trans=" transaction
-
-      status-code    = <"status-code" from [RFC1893], with
-                        extensions defined in [REPORT-EXTENSIONS]>
-
-      prog-value     = sent-count "/" total-count
-
-      sent-count     = 1*DIGIT
-
-      total-count    = 1*DIGIT
-
-      mta-hostname   = *( ALPHA / DIGIT / "." / "-" / "_" )
-
-      transaction    = *( ALPHA / DIGIT / "." / "-" / "_" )
-
-      cmd-status     = "2.5.0" <only present if SMTP server supports
-                                [RFC2034]>
-
-      forward-path   = <forward-path as specified in the RCPT command,
-                        including "<" and ">" characters>
-
-   The <session-status> can be spelled in any combination of uppercase
-   and lowercase letters.  The meaning of the various values are
-   as follows:
-
-   "delivered"    Session delivery was successful.  Message was
-                  delivered to the recipient immediately.  This is a
-                  terminal value.  This can optionally be followed
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                [Page 10]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-                  with <trans-id>.
-
-   "in-progress"  Session delivery has not yet completed.  A STAT
-                  command issued later will show final status of this
-                  message.  This is the only non-terminal value.  This
-                  must be followed by <prog-value>.
-
-   "queued"       Session delivery failed for some reason, but the MTA
-                  was able to successfully queue the message using
-                  normal SMTP store-and-forward.  One cause of this
-                  status is when the session-enabled server forwards the
-                  message to a non-session-enabled server.  This is a
-                  terminal value.  This can optionally be followed
-                  with <trans-id>.
-
-   "failed"       Delivery failed.  The message will be bounced if
-                  no DSN was requested, or if a DSN including
-                  "NOTIFY=FAILED" was requested [RFC1891].
-
-
-   <mta-hostname> indicates the host generating the information,
-   and can be used to help trace a message passing along a path
-   of session-aware mailers.
-
-   <trans-id> is used to provide the client with a unique transaction
-   number to associate with each delivery.  This can be useful for
-   accounting or tracing messages.  This number need only be unique
-   for that MTA, it doesn't need to be world-unique.
-
-   The two values of the <prog-value> element can be page numbers, byte
-   counts, disk blocks, or any other useful count of the progress of
-   this transaction, as determined by the SMTP server.  The values
-   can be displayed by the MUA to the user as-is, or the MUA can use the
-   values to calculate the percentage of completion for presentation
-   to the user.  The value of <total-count> is the number of units
-   the SMTP server has received, the value of <sent-count> is the
-   number of units the SMTP server has sent to the next-hop
-   mailer.  See example 6.1.
-
-   If an SMTP client sends a STAT command and the SMTP server has
-   already informed the SMTP client (in the response to a previous
-   STAT command) that all recipients had terminal values, the SMTP
-   server MAY return a 503 reply.
-
-4.2.  Sequence of Events
-
-   The STAT command has a similar sequence of events as described
-   in section 3.3, above.
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                [Page 11]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-
-   Note that the STAT command can only be issued in the same
-   SMTP transaction.  There is no provision for an SMTP client to
-   start a new SMTP transaction and query the status of Session
-   delivery for a previous SMTP transaction.
-
-4.3.  Timing Considerations
-
-   The SMTP server SHOULD respond to a STAT command no later than 60
-   seconds after a STAT command is received.  After 120 seconds an SMTP
-   client MAY assume the connection to the SMTP server is broken.
-
-   To prevent excessive network activity by an SMTP client querying
-   delivery status "too often", the SMTP server may delay responding to
-   a client's STAT command.  Such a delay MUST NOT exceed 10 seconds.
-
-   Due to the delays inherent in establishing connections with each MTA
-   in the SMTP "path", SMTP servers that implement the Session extension
-   SHOULD also implement [RFC2197], and SMTP clients SHOULD use
-   pipelining if available.
-
-5.  Security Considerations
-
-   This section describes new security vulnerabilities that are
-   introduced with this SMTP extension.  Security vulnerabilities
-   that are inherient to SMTP itself are not described.
-
-5.1.  Denial of Service
-
-   As Session consumes more resources on MTAs, denial of service attacks
-   against MTAs may be more effective.
-
-   XXX - more verbage
-
-5.2.  Abuse of Immediate Delivery
-
-   This is some concern that users will always choose the 'deliver
-   immediately' button or mailer option in their MUA.  As immediate
-   delivery requires more resources on MTAs, this is indeed a
-   concern.
-
-   To alleviate such concerns, ISPs could charge extra for immediate
-   delivery involving their mailers, offering immediate delivery
-   as a value-add service, not accept Session messages during periods of
-   high usage, or limit the total number of Session connections or
-   the number of Session connections to/from certain hosts or
-   domains.
-
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                [Page 12]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-6.  Examples
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server respectively.  If such lines are wrapped without a new "C:" or
-   "S:" label, then the wrapping is for editorial clarity and is not
-   part of the command.
-
-6.1.  Successful Session Delivery to Two Recipients
-
-   This example shows a successful Session delivery with two recipients.
-   The first recipient, bill@fuggles.com, was still being queued when
-   the first STAT command was sent by the client, but a subsequent STAT
-   command shows the final status.
-
-      S: 220 mailer.cisco.com ESMTP service ready
-      C: EHLO pc.cisco.com
-      S: 250-mailer.cisco.com says hello
-      S: 250 SESSION
-      C: MAIL FROM:<dwing@cisco.com>
-      S: 250 <dwing@cisco.com> Sender ok
-      C: RCPT TO:<bill@fuggles.com> SESSION
-      S: 250 <bill@fuggles.com> and options ok
-      C: RCPT TO:<njoffe@cisco.com> SESSION
-      S: 250 <njoffe@cisco.com> and options ok
-      C: DATA
-      S: 354 Enter your data
-      C: From: Dan Wing <dwing@cisco.com>
-      C: To: njoffe@cisco.com, bill@fuggles.com
-      C: Date: Mon, 6 Oct 1997 12:42:32 -0700
-      C: Subject: Palo Alto Coffee shops
-      C:
-      C: What is a good coffee shop in Palo Alto?
-      C: .
-      S: 250 message accepted
-      C: STAT
-      S: 250-<bill@fuggles.com> in-progress 5/184 by=fwall.cisco.com
-      S: 250 <njoffe@cisco.com> delivered by=popstore.cisco.com
-      trans=E23132
-      C: STAT
-      S: 250-<bill@fuggles.com> in-progress 43/50 by=example.com
-      S: 250 <njoffe@cisco.com> delivered by=popstore.cisco.com
-      trans=E23132
-      C: STAT
-      S: 250-<bill@fuggles.com> delivered by=mailer.fuggles.com
-      S: 250 <njoffe@cisco.com> delivered by=popstore.cisco.com
-      trans=E23132
-      C: QUIT
-      S: 221 Goodbye
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                [Page 13]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-   (The string "trans=E23132" is shown on a separate line in
-   this example for clarity.  The string would appear on one line.
-
-6.2.  Unsuccessful Session Delivery
-
-   This example shows the client wanted to send the message
-   immediately, and the server responded with a "250" (indicating
-   it believed the message could be sent immediately), but a problem
-   occurred forcing the mailer at pea.com to deliver the message
-   using store-and-forward.
-
-      S: 220 mailer.cisco.com ESMTP service ready
-      C: EHLO pc.cisco.com
-      S: 250-mailer.cisco.com says hello
-      S: 250 SESSION
-      C: MAIL FROM:<dwing@cisco.com>
-      S: 250 <dwing@cisco.com> Sender ok
-      C: RCPT TO:<greengiant@peas.com> SESSION
-      S: 250 <greengiant@peas.com> and options ok
-      C: DATA
-      S: 354 Enter your data
-      C: From: Dan Wing <dwing@cisco.com>
-      C: To: "Jolly" <greengiant@peas.com>
-      C: Date: Mon, 6 Oct 1997 12:42:32 -0700
-      C: Subject: Veggies
-      C:
-      C: Veggies are good for you, but from a can?
-      C: .
-      S: 250 message accepted
-      C: STAT
-      S: 250 <greengiant@peas.com> queued by=peas.com
-      C: QUIT
-      S: 221 Goodbye
-
-6.3.  SMTP Client Disconnects Before Sending STAT
-
-   The SMTP client is not required to query the success/failure
-   of immediate message delivery.  The following transaction
-   is legal.
-
-      S: 220 mailer.cisco.com ESMTP service ready
-      C: EHLO pc.cisco.com
-      S: 250-mailer.cisco.com says hello
-      S: 250 SESSION
-      C: MAIL FROM:<dwing@cisco.com>
-      S: 250 <dwing@cisco.com> Sender ok
-      C: RCPT TO:<masinter@parc.xerox.com> SESSION
-      S: 250 <masinter@parc.xerox.com> and options ok
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                [Page 14]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-      C: DATA
-      S: 354 Enter your data
-      C: From: Dan Wing <dwing@cisco.com>
-      C: To: masinter@parc.xerox.com
-      C: Date: Mon, 6 Oct 1997 12:42:32 -0700
-      C: Subject: Palo Alto Coffee shops
-      C:
-      C: How does this look?
-      C: .
-      S: 250 message accepted
-      C: QUIT
-      S: 221 Goodbye
-
-7.  Acknowledgments
-
-   Much of this document was produced by work begun in the Internet FAX
-   Working Group of the IETF.
-
-   The authors would like to thank Ned Freed (Innosoft), Graham Klyne
-   (Integralis), Keith Moore (University of Tennessee), Jeff
-   VanDyke (NetCentric), and Greg Vaudreuil (Lucent) for their
-   contributions to this work.
-
-   ((others?))
-
-8.  References
-
-   [DRUMS] J. Klensin, D. Mann, "Simple Mail Transfer Protocol",
-   Internet Draft, Work in Progress, draft-ietf-drums-smtpupd-??.txt.
-
-   [REPORT-EXTENSIONS] D. Wing, "Fax Extensions to DSN and MDN",
-   Internet Draft, Work in Progress,
-   draft-ietf-fax-report-extensions.txt.
-
-   [RFC821] J. Postel, "Simple Mail Transfer Protocol", STD-10, RFC 821,
-   August 1982.
-
-   [RFC1047] C. Partridge, "DUPLICATE MESSAGES AND SMTP", RFC 1047,
-   February 1988.
-
-   [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
-   and Support", RFC 1123, October 1989.
-
-   [RFC1830] G. Vaudreuil, "SMTP Service Extensions for Transmission of
-   Large and Binary MIME Messages", RFC 1830 (Experimental), August
-   1995.
-
-   [RFC1891] K. Moore, "SMTP Service Extension for Delivery Status
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                [Page 15]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-   Notifications", RFC 1891, January 1996.
-
-   [RFC1893] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC
-   1893, January 1996.
-
-   [RFC1869] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker,
-   "SMTP Service Extensions", STD-10, RFC 1869, November 1995.
-
-   [RFC2033] J. Myers, "Local Mail Transfer Protocol", RFC 2033, October
-   1996.
-
-   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
-   Requirement Levels", BCP-14, RFC 2119, March 1997.
-
-   [RFC2197] N. Freed, "SMTP Service Extension for Command Pipelining",
-   RFC 2197, September 1997.  .in -5
-
-   [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
-   Specifications: ABNF", RFC 2234, November 1997.
-
-9.  Copyright
-
-   Copyright (C) The Internet Society (1997, 1998).  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 implmentation 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.
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                [Page 16]
-
-Internet Draft          SMTP Immediate Delivery              August 1998
-
-
-10.  Authors' Addresses
-
-   Neil Joffe
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706  USA
-
-   Phone: +1 408 526 4000
-   Email: njoffe@cisco.com
-
-
-   Dan Wing
-   Cisco Systems, Inc.
-   101 Cooper Street
-   Santa Cruz, CA 95060  USA
-
-   Phone: +1 408 457 5200
-   Fax:   +1 408 457 5208
-   Email: dwing@cisco.com
-
-
-   Larry Masinter
-   Xerox Palo Alto Research Center
-   3333 Coyote Hill Road
-   Palo Alto, CA 94304  USA
-
-   Phone:  +1 415 812 4365
-   Fax:    +1 415 812 4333
-   Email:  masinter@parc.xerox.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Joffe, Wing, Masinter     Expires January 1999                [Page 17]
-
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ietf-impp-datetime-05.txt b/Documentation/en/I-D/draft-ietf-impp-datetime-05.txt
deleted file mode 100644
index 28e49597..00000000
--- a/Documentation/en/I-D/draft-ietf-impp-datetime-05.txt
+++ /dev/null
@@ -1,1140 +0,0 @@
-
-
-
-
-
-
-Network Working Group                        G. Klyne, MIMEsweeper Group
-Internet Draft                               C. Newman, Sun Microsystems
-                                                         2 November 2001
-                                                       Expires: May 2002
-
-
-               Date and Time on the Internet: Timestamps
-                   <draft-ietf-impp-datetime-05.txt>
-
-
-Status of this memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC 2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress".
-
-     The list of current Internet-Drafts can be accessed at
-     http://www.ietf.org/1id-abstracts.html
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-     http://www.ietf.org/shadow.html
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2001.  All Rights Reserved.
-
-
-Abstract
-
-   This document defines a date and time format for use in Internet
-   protocols that is a profile of the ISO 8601 [ISO8601] standard for
-   representation of dates and times using the Gregorian calendar.
-
-
-
-
-
-
-
-
-
-Newman & Klyne                                                  [Page 1]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-Table of Contents
-
-   1. Introduction
-   2. Definitions
-   3. Two Digit Years
-   4. Local Time
-   4.1. Coordinated Universal Time (UTC)
-   4.2. Local Offsets
-   4.3. Unknown Local Offset Convention
-   4.4. Unqualified Local Time
-   5. Date and Time format
-   5.1. Ordering
-   5.2. Human Readability
-   5.3. Rarely Used Options
-   5.4. Redundant Information
-   5.5. Simplicity
-   5.6. Internet Date/Time Format
-   5.7. Restrictions
-   5.8. Examples
-   6. Acknowledgements
-   7. References
-   8. Security Considerations
-   9. Authors' Addresses
-   Appendix A. ISO 8601 Collected ABNF
-   Appendix B. Day of the Week
-   Appendix C. Leap Years
-   Appendix D. Leap Seconds
-   Appendix E. Amendment history
-   Full copyright statement
-
-1. Introduction
-
-   Date and time formats cause a lot of confusion and interoperability
-   problems on the Internet.  This document addresses many of the
-   problems encountered and makes recommendations to improve consistency
-   and interoperability when representing and using date and time in
-   Internet protocols.
-
-   This document includes an Internet profile of the ISO 8601 [ISO8601]
-   standard for representation of dates and times using the Gregorian
-   calendar.
-
-
-
-
-
-
-
-
-
-
-Newman & Klyne                                                  [Page 2]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-   There are many ways in which date and time values might appear in
-   Internet protocols:  this document focuses on just one common usage,
-   viz. timestamps for Internet protocol events.  This limited
-   consideration has the following consequences:
-
-   o  All dates and times are assumed to be in the "current era",
-      somewhere between 0000AD and 9999AD.
-
-   o  All times expressed have a stated relationship (offset) to
-      Coordinated Universal Time (UTC).  (This is distinct from some
-      usage in scheduling applications where a local time and location
-      may be known, but the actual relationship to UTC may be dependent
-      on the unknown or unknowable actions of politicians or
-      administrators.  The UTC time corresponding to 17:00 on 23rd March
-      2005 in New York may depend on administrative decisions about
-      daylight savings time.  This specification steers well clear of
-      such considerations.)
-
-   o  Timestamps can express times that occurred before the introduction
-      of UTC.  Such timestamps are expressed relative to universal time,
-      using the best available practice at the stated time.
-
-   o  Date and time expressions indicate an instant in time.
-      Description of time periods, or intervals, is not covered here.
-
-
-2. Definitions
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [RFC2119].
-
-   UTC         Coordinated Universal Time as maintained by the Bureau
-               International des Poids et Mesures (BIPM).
-
-   second      A basic unit of measurement of time in the International
-               System of Units.  It is defined as the duration of
-               9,192,631,770 cycles of microwave light absorbed or
-               emitted by the hyperfine transition of cesium-133 atoms
-               in their ground state undisturbed by external fields.
-
-   minute      A period of time of 60 seconds.  However, see also the
-               restrictions in section 5.7 and Appendix D for how leap
-               seconds are denoted within minutes.
-
-   hour        A period of time of 60 minutes.
-
-
-
-
-
-Newman & Klyne                                                  [Page 3]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-   day         A period of time of 24 hours.
-
-   leap year   In the Gregorian calendar, a year which has 366 days.  A
-               leap year is a year whose number is divisible by four an
-               integral number of times, except that if it is a
-               centennial year (i.e. divisible by one hundred) it shall
-               also be divisible by four hundred an integral number of
-               times.
-
-   ABNF        Augmented Backus-Naur Form, a format used to represent
-               permissible strings in a protocol or language, as defined
-               in [ABNF].
-
-   Email Date/Time Format
-               The date/time format used by Internet Mail as defined by
-               RFC 2822 [IMAIL-UPDATE].
-
-   Internet Date/Time Format
-               The date format defined in section 5 of this document.
-
-   Timestamp   This term is used in this document to refer to an
-               unambiguous representation of some instant in time.
-
-   For more information about time scales, see Appendix E of [NTP],
-   Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF].
-
-
-3. Two Digit Years
-
-   The following requirements are to address the problems of ambiguity
-   of 2-digit years:
-
-   o  Internet Protocols MUST generate four digit years in dates.
-
-   o  The use of 2-digit years is deprecated.  If a 2-digit year is
-      received, it should be accepted ONLY if an incorrect
-      interpretation will not cause a protocol or processing failure
-      (e.g. if used only for logging or tracing purposes).
-
-   o  It is possible that a program using two digit years will represent
-      years after 1999 as three digits.  This occurs if the program
-      simply subtracts 1900 from the year and doesn't check the number
-      of digits.  Programs wishing to robustly deal with dates generated
-      by such broken software may add 1900 to three digit years.
-
-
-
-
-
-
-
-Newman & Klyne                                                  [Page 4]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-   o  It is possible that a program using two digit years will represent
-      years after 1999 as ":0", ":1", ... ":9", ";0", ...  This occurs
-      if the program simply subtracts 1900 from the year and adds the
-      decade to the US-ASCII character zero. Programs wishing to
-      robustly deal with dates generated by such broken software should
-      detect non-numeric decades and interpret appropriately.
-
-   The problems with two digit years amply demonstrate why all dates and
-   times used in Internet protocols MUST be fully qualified.
-
-
-4. Local Time
-
-4.1. Coordinated Universal Time (UTC)
-
-   Because the daylight saving rules for local time zones are so
-   convoluted and can change based on local law at unpredictable times,
-   true interoperability is best achieved by using Coordinated Universal
-   Time (UTC).  This specification does not cater to local time zone
-   rules.
-
-4.2. Local Offsets
-
-   The offset between local time and UTC is often useful information.
-   For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local
-   offset provides a useful heuristic to determine the probability of a
-   prompt response.  Attempts to label local offsets with alphabetic
-   strings have resulted in poor interoperability in the past [IMAIL],
-   [HOST-REQ].  As a result, RFC2822 [IMAIL-UPDATE] has made numeric
-   offsets mandatory.
-
-   Numeric offsets are calculated as "local time minus UTC".  So the
-   equivalent time in UTC can be determined by subtracting the offset
-   from the local time.  For example, 18:50:00-04:00 is the same time as
-   22:50:00Z.
-
-
-      NOTE: Following ISO 8601, numeric offsets represent only time
-      zones that differ from UTC by an integral number of minutes.
-      However, many historical time zones differ from UTC by a non-
-      integral number of minutes.  To represent such historical time
-      stamps exactly, applications must convert them to a representable
-      time zone.
-
-
-
-
-
-
-
-
-Newman & Klyne                                                  [Page 5]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-4.3. Unknown Local Offset Convention
-
-   If the time in UTC is known, but the offset to local time is unknown,
-   this can be represented with an offset of "-00:00".  This differs
-   semantically from an offset of "Z" or "+00:00", which imply that UTC
-   is the preferred reference point for the specified time.  RFC2822
-   [IMAIL-UPDATE] describes a similar convention for email.
-
-4.4. Unqualified Local Time
-
-   A number of devices currently connected to the Internet run their
-   internal clocks in local time and are unaware of UTC.  While the
-   Internet does have a tradition of accepting reality when creating
-   specifications, this should not be done at the expense of
-   interoperability.  Since interpretation of an unqualified local time
-   zone will fail in approximately 23/24 of the globe, the
-   interoperability problems of unqualified local time are deemed
-   unacceptable for the Internet.  Systems that are configured with a
-   local time, are unaware of the corresponding UTC offset, and depend
-   on time synchronization with other Internet systems, MUST use a
-   mechanism that ensures correct synchronization with UTC.  Some
-   suitable mechanisms are:
-
-   o  Use Network Time Protocol [NTP] to obtain the time in UTC.
-
-   o  Use another host in the same local time zone as a gateway to the
-      Internet.  This host MUST correct unqualified local times they are
-      transmitted to other hosts.
-
-   o  Prompt the user for the local time zone and daylight saving rule
-      settings.
-
-
-5. Date and Time format
-
-   This section discusses desirable qualities of date and time formats
-   and defines a profile of ISO 8601 for use in Internet protocols.
-
-5.1. Ordering
-
-   If date and time components are ordered from least precise to most
-   precise, then a useful property is achieved.  Assuming that the time
-   zones of the dates and times are the same (e.g. all in UTC),
-   expressed using the same string (e.g. all "Z" or all "+00:00"), and
-   all times have the same number of fractional second digits, then the
-   date and time strings may be sorted as strings (e.g. using the
-   strcmp() function in C) and a time-ordered sequence will result.  The
-   presence of optional punctuation would violate this characteristic.
-
-
-
-Newman & Klyne                                                  [Page 6]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-5.2. Human Readability
-
-   Human readability has proved to be a valuable feature of Internet
-   protocols.  Human readable protocols greatly reduce the costs of
-   debugging since telnet often suffices as a test client and network
-   analyzers need not be modified with knowledge of the protocol.  On
-   the other hand, human readability sometimes results in
-   interoperability problems.  For example, the date format "10/11/1996"
-   is completely unsuitable for global interchange because it is
-   interpreted differently in different countries.  In addition, the
-   date format in [IMAIL] has resulted in interoperability problems when
-   people assumed any text string was permitted and translated the three
-   letter abbreviations to other languages or substituted date formats
-   which were easier to generate (e.g. the format used by the C function
-   ctime).  For this reason, a balance must be struck between human
-   readability and interoperability.
-
-   Because no date and time format is readable according to the
-   conventions of all countries, Internet clients SHOULD be prepared to
-   transform dates into a display format suitable for the locality.
-   This may include translating UTC to local time.
-
-5.3. Rarely Used Options
-
-   A format which includes rarely used options is likely to cause
-   interoperability problems.  This is because rarely used options are
-   less likely to be used in alpha or beta testing, so bugs in parsing
-   are less likely to be discovered.  Rarely used options should be made
-   mandatory or omitted for the sake of interoperability whenever
-   possible.
-
-   The format defined below includes only one rarely used option:
-   fractions of a second.  It is expected that this will be used only by
-   applications which require strict ordering of date/time stamps or
-   which have an unusual precision requirement.
-
-5.4. Redundant Information
-
-   If a date/time format includes redundant information, that introduces
-   the possibility that the redundant information will not correlate.
-   For example, including the day of the week in a date/time format
-   introduces the possibility that the day of week is incorrect but the
-   date is correct, or vice versa.  Since it is not difficult to compute
-   the day of week from a date (see Appendix B), the day of week should
-   not be included in a date/time format.
-
-
-
-
-
-
-Newman & Klyne                                                  [Page 7]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-5.5. Simplicity
-
-   The complete set of date and time formats specified in ISO 8601
-   [ISO8601] is quite complex in an attempt to provide multiple
-   representations and partial representations.  Appendix A contains an
-   attempt to translate the complete syntax of ISO 8601 into ABNF.
-   Internet protocols have somewhat different requirements and
-   simplicity has proved to be an important characteristic.  In
-   addition, Internet protocols usually need complete specification of
-   data in order to achieve true interoperability.  Therefore, the
-   complete grammar for ISO 8601 is deemed too complex for most Internet
-   protocols.
-
-   The following section defines a profile of ISO 8601 for use on the
-   Internet.  It is a conformant subset of the ISO 8601 extended format.
-   Simplicity is achieved by making most fields and punctuation
-   mandatory.
-
-5.6. Internet Date/Time Format
-
-   The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
-   new protocols on the Internet.  This is specified using the syntax
-   description notation defined in [ABNF].
-
-      date-fullyear   = 4DIGIT
-      date-month      = 2DIGIT  ; 01-12
-      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
-      time-hour       = 2DIGIT  ; 00-23
-      time-minute     = 2DIGIT  ; 00-59
-      time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second rules
-      time-secfrac    = "." 1*DIGIT
-      time-numoffset  = ("+" / "-") time-hour ":" time-minute
-      time-offset     = "Z" / time-numoffset
-
-      partial-time    = time-hour ":" time-minute ":" time-second
-                        [time-secfrac]
-      full-date       = date-fullyear "-" date-month "-" date-mday
-      full-time       = partial-time time-offset
-
-      date-time       = full-date "T" full-time
-
-
-     NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in
-     this syntax may alternatively be lower case "t" or "z"
-     respectively.
-
-     NOTE: ISO 8601 defines date and time separated by "T".
-     Applications using this syntax may choose, for the sake of
-
-
-
-Newman & Klyne                                                  [Page 8]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-     readability, to specify a full-date and full-time separated by
-     (say) a space character.
-
-
-5.7. Restrictions
-
-   The grammar element date-mday represents the day number within the
-   current month.  The maximum value varies based on the month and year
-   as follows:
-
-      Month Number  Month/Year           Maximum value of date-mday
-      ------------  ----------           --------------------------
-      01            January              31
-      02            February, normal     28
-      02            February, leap year  29
-      03            March                31
-      04            April                30
-      05            May                  31
-      06            June                 30
-      07            July                 31
-      08            August               31
-      09            September            30
-      10            October              31
-      11            November             30
-      12            December             31
-
-   Appendix C contains sample C code to determine if a year is a leap
-   year.
-
-   The grammar element time-second may have the value "60" at the end of
-   months in which a leap second occurs -- to date: June
-   (XXXX-06-30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see
-   Appendix D for a table of leap seconds.  It is also possible for a
-   leap second to be subtracted, at which times the maximum value of
-   time-second is "58".  At all other times the maximum value of
-   time-second is "59".  Further, in time zones other than "Z", the leap
-   second point is shifted by the zone offset (so it happens at the same
-   instant around the globe).
-
-   Leap seconds cannot be predicted far into the future.  The
-   International Earth Rotation Service publishes bulletins [IERS] that
-   announce leap seconds with a few weeks' warning.  Applications should
-   not generate timestamps involving inserted leap seconds until after
-   the leap seconds are announced.
-
-   Although ISO 8601 permits the hour to be "24", this profile of ISO
-   8601 only allows values between "00" and "23" for the hour in order
-   to reduce confusion.
-
-
-
-Newman & Klyne                                                  [Page 9]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-5.8. Examples
-
-   Here are some examples of Internet date/time format.
-
-      1985-04-12T23:20:50.52Z
-
-   This represents 20 minutes and 50.52 seconds after the 23rd hour of
-   April 12th, 1985 in UTC.
-
-      1996-12-19T16:39:57-08:00
-
-   This represents 39 minutes and 57 seconds after the 16th hour of
-   December 19th, 1996 with an offset of -08:00 from UTC (Pacific
-   Standard Time).  Note that this is equivalent to 1996-12-20T00:39:57Z
-   in UTC.
-
-      1990-12-31T23:59:60Z
-
-   This represents the leap second inserted at the end of 1990.
-
-      1990-12-31T15:59:60-08:00
-
-   This represents the same leap second in Pacific Standard Time, 8
-   hours behind UTC.
-
-      1937-01-01T12:00:27.87+00:20
-
-   This represents the same instant of time as noon, January 1, 1937,
-   Netherlands time.  Standard time in the Netherlands was exactly 19
-   minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
-   1937-06-30.  This time zone cannot be represented exactly using the
-   HH:MM format, and this timestamp uses the closest representable UTC
-   offset.
-
-
-
-6. Acknowledgements
-
-   The following people provided helpful advice for an earlier
-   incarnation of this document:  Ned Freed, Neal McBurnett, David
-   Keegel, Markus Kuhn, Paul Eggert and Robert Elz.  Thanks are also due
-   to participants of the IETF Calendaring/Scheduling working group
-   mailing list, and participants of the time zone mailing list.
-
-   The following reviewers contributed helpful suggestions for the
-   present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn.
-   Paul Eggert provided many careful observations regarding the
-   subtleties of leap seconds and time zone offsets.
-
-
-
-Newman & Klyne                                                 [Page 10]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-7. References
-
-   [Zeller]    Chr. Zeller, "Kalender-Formeln", Acta Mathematica, Vol.
-               9, Nov 1886.
-
-   [IMAIL]     Crocker, D., "Standard for the Format of Arpa Internet
-               Text Messages", RFC 822, August 1982.
-
-   [IMAIL-UPDATE]
-               Resnick, P., "Internet Message Format", RFC 2822, April
-               2001.
-
-   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
-               Specifications: ABNF", RFC 2234, November 1997.
-
-   [ISO8601]   "Data elements and interchange formats -- Information
-               interchange -- Representation of dates and times", ISO
-               8601:1988(E), International Organization for
-               Standardization, June, 1988.
-
-   [ISO8601:2000]
-               "Data elements and interchange formats -- Information
-               interchange -- Representation of dates and times", ISO
-               8601:2000, International Organization for
-               Standardization, December, 2000.
-
-   [HOST-REQ]  Braden, R., "Requirements for Internet Hosts --
-               Application and Support", RFC 1123, Internet Engineering
-               Task Force, October 1989.
-
-   [IERS]      International Earth Rotation Service Bulletins,
-               <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.
-
-   [NTP]       Mills, D., "Network Time Protocol (Version 3)
-               Specification, Implementation and Analysis", RFC 1305,
-               University of Delaware, March 1992.
-
-   [ITU-R-TF]  International Telecommunication Union Recommendations for
-               Time Signals and Frequency Standards Emissions.
-               <http://www.itu.ch/publications/itu-r/iturtf.htm>
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", RFC 2119, Internet Engineering Task
-               Force, March 1997.
-
-
-
-
-
-
-
-Newman & Klyne                                                 [Page 11]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-8. Security Considerations
-
-   Since the local time zone of a site may be useful for determining a
-   time when systems are less likely to be monitored and might be more
-   susceptible to a security probe, some sites may wish to emit times in
-   UTC only.  Others might consider this to be loss of useful
-   functionality at the hands of paranoia.
-
-
-9. Authors' Addresses
-
-   Chris Newman
-   Sun Microsystems
-   1050 Lakes Drive, Suite 250
-   West Covina, CA 91790 USA
-
-   Email: cnewman@iplanet.com
-
-   Graham Klyne (editor, this revision)
-   MIMEsweeper Group
-   1310 Waterside
-   Arlington Business Park
-   Theale
-   Reading, RG7 4SA
-   United Kingdom.
-   Telephone: +44 118 903 8000
-   Facsimile: +44 118 903 9000
-   E-mail:    GK@ACM.ORG
-
-
-Appendix A. ISO 8601 Collected ABNF
-
-   This information is based on the 1988 version of ISO 8601.  There may
-   be some changes in the 2000 revision.
-
-   ISO 8601 does not specify a formal grammar for the date and time
-   formats it defines.  The following is an attempt to create a formal
-   grammar from ISO 8601.  This is informational only and may contain
-   errors.  ISO 8601 remains the authoritative reference.
-
-   Note that due to ambiguities in ISO 8601, some interpretations had to
-   be made.  First, ISO 8601 is not clear if mixtures of basic and
-   extended format are permissible.  This grammar permits mixtures.  ISO
-   8601 is not clear on whether an hour of 24 is permissible only if
-   minutes and seconds are 0.  This assumes that an hour of 24 is
-   permissible in any context.  Restrictions on date-mday in section 5.7
-   apply.  ISO 8601 states that the "T" may be omitted under some
-   circumstances.  This grammar requires the "T" to avoid ambiguity.
-
-
-
-Newman & Klyne                                                 [Page 12]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-   ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
-   be proceeded by a "0" if less than unity.  Annex B.2 of ISO 8601
-   gives examples where the decimal fractions are not preceded by a "0".
-   This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is
-   in error.
-
-      date-century    = 2DIGIT  ; 00-99
-      date-decade     =  DIGIT  ; 0-9
-      date-subdecade  =  DIGIT  ; 0-9
-      date-year       = date-decade date-subdecade
-      date-fullyear   = date-century date-year
-      date-month      = 2DIGIT  ; 01-12
-      date-wday       =  DIGIT  ; 1-7  ; 1 is Monday, 7 is Sunday
-      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
-      date-yday       = 3DIGIT  ; 001-365, 001-366 based on year
-      date-week       = 2DIGIT  ; 01-52, 01-53 based on year
-
-      datepart-fullyear = [date-century] date-year ["-"]
-      datepart-ptyear   = "-" [date-subdecade ["-"]]
-      datepart-wkyear   = datepart-ptyear / datepart-fullyear
-
-      dateopt-century   = "-" / date-century
-      dateopt-fullyear  = "-" / datepart-fullyear
-      dateopt-year      = "-" / (date-year ["-"])
-      dateopt-month     = "-" / (date-month ["-"])
-      dateopt-week      = "-" / (date-week ["-"])
-
-      datespec-full     = datepart-fullyear date-month ["-"] date-mday
-      datespec-year     = date-century / dateopt-century date-year
-      datespec-month    = "-" dateopt-year date-month [["-"] date-mday]
-      datespec-mday     = "--" dateopt-month date-mday
-      datespec-week     = datepart-wkyear "W"
-                          (date-week / dateopt-week date-wday)
-      datespec-wday     = "---" date-wday
-      datespec-yday     = dateopt-fullyear date-yday
-
-      date              = datespec-full / datespec-year / datespec-month /
-          datespec-mday / datespec-week / datespec-wday / datespec-yday
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman & Klyne                                                 [Page 13]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-   Time:
-
-      time-hour         = 2DIGIT ; 00-24
-      time-minute       = 2DIGIT ; 00-59
-      time-second       = 2DIGIT ; 00-58, 00-59, 00-60 based on leap-second rules
-      time-fraction     = ("," / ".") 1*DIGIT
-      time-numoffset    = ("+" / "-") time-hour [[":"] time-minute]
-      time-zone         = "Z" / time-numoffset
-
-      timeopt-hour      = "-" / (time-hour [":"])
-      timeopt-minute    = "-" / (time-minute [":"])
-
-      timespec-hour     = time-hour [[":"] time-minute [[":"] time-second]]
-      timespec-minute   = timeopt-hour time-minute [[":"] time-second]
-      timespec-second   = "-" timeopt-minute time-second
-      timespec-base     = timespec-hour / timespec-minute / timespec-second
-
-      time              = timespec-base [time-fraction] [time-zone]
-
-      iso-date-time     = date "T" time
-
-   Durations:
-
-      dur-second        = 1*DIGIT "S"
-      dur-minute        = 1*DIGIT "M" [dur-second]
-      dur-hour          = 1*DIGIT "H" [dur-minute]
-      dur-time          = "T" (dur-hour / dur-minute / dur-second)
-      dur-day           = 1*DIGIT "D"
-      dur-week          = 1*DIGIT "W"
-      dur-month         = 1*DIGIT "M" [dur-day]
-      dur-year          = 1*DIGIT "Y" [dur-month]
-      dur-date          = (dur-day / dur-month / dur-year) [dur-time]
-
-      duration          = "P" (dur-date / dur-time / dur-week)
-
-   Periods:
-
-      period-explicit   = date-time "/" date-time
-      period-start      = date-time "/" duration
-      period-end        = duration "/" date-time
-
-      period            = period-explicit / period-start / period-end
-
-
-
-
-
-
-
-
-
-Newman & Klyne                                                 [Page 14]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-Appendix B. Day of the Week
-
-   The following is a sample C subroutine loosely based on Zeller's
-   Congruence [Zeller] which may be used to obtain the day of the week
-   for dates on or after 0000-02-01:
-
-
-      char *day_of_week(int day, int month, int year)
-      {
-          int cent;
-          char *dayofweek[] = {
-              "Sunday", "Monday", "Tuesday", "Wednesday",
-              "Thursday", "Friday", "Saturday"
-          };
-
-          /* adjust months so February is the last one */
-          month -= 2;
-          if (month < 1) {
-              month += 12;
-              --year;
-          }
-          /* split by century */
-          cent = year / 100;
-          year %= 100;
-          return (dayofweek[((26 * month - 2) / 10 + day + year
-                            + year / 4 + cent / 4 - 2 * cent) % 7]);
-      }
-
-
-
-Appendix C. Leap Years
-
-   Here is a sample C subroutine to calculate if a year is a leap year:
-
-
-      /* This returns non-zero if year is a leap year.  Must use 4 digit year.
-       */
-      int leap_year(int year)
-      {
-          return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
-      }
-
-
-
-
-
-
-
-
-
-
-Newman & Klyne                                                 [Page 15]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-Appendix D. Leap Seconds
-
-   Information about leap seconds can be found at:
-   <http://tycho.usno.navy.mil/leapsec.html>.  In particular, it notes
-   that:
-
-      The decision to introduce a leap second in UTC is the
-      responsibility of the International Earth Rotation Service (IERS).
-      According to the CCIR Recommendation, first preference is given to
-      the opportunities at the end of December and June, and second
-      preference to those at the end of March and September.
-
-   When required, insertion of a leap second occurs as an extra second
-   at the end of a day in UTC, represented by a timestamp of the form
-   YYYY-MM-DDT23:59:60Z.  A leap second occurs simultaneously in all
-   time zones, so that time zone relationships are not affected.  See
-   section 5.8 for some examples of leap second times.
-
-   The following table is an excerpt from the table maintained by the
-   United States Naval Observatory.  The source data is located at:
-
-      <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman & Klyne                                                 [Page 16]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-   This table shows the date of the leap second, and the difference
-   between the time standard TAI (which isn't adjusted by leap seconds)
-   and UTC after that leap second.
-
-
-      UTC Date  TAI - UTC After Leap Second
-      --------  ---------------------------
-      1972-06-30     11
-      1972-12-31     12
-      1973-12-31     13
-      1974-12-31     14
-      1975-12-31     15
-      1976-12-31     16
-      1977-12-31     17
-      1978-12-31     18
-      1979-12-31     19
-      1981-06-30     20
-      1982-06-30     21
-      1983-06-30     22
-      1985-06-30     23
-      1987-12-31     24
-      1989-12-31     25
-      1990-12-31     26
-      1992-06-30     27
-      1993-06-30     28
-      1994-06-30     29
-      1995-12-31     30
-      1997-06-30     31
-      1998-12-31     32
-
-
-Appendix E. Amendment history
-
-[[[RFC editor:  please remove this appendix on publication.]]]
-
-
-00a 30-Mar-2001 This document version created from Chris Newman's
-                original as 'draft-ietf-impp-datetime-00.txt'.  Material
-                relating to future times (schedule events) and time zone
-                names has been removed.  Added introductory text setting
-                the scope for this document.  Various small editorial
-                changes.
-
-00b 03-Apr-2001 Added reference [ABNF], and updated citations.  Added
-                comment about possible use of space-separated date/time
-                fields.  Added comment about possible use of lower case
-                "t" and "z" in syntax.  Corrected leap-second examples
-                and noted that leap second point is offset by time zone.
-
-
-
-Newman & Klyne                                                 [Page 17]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-01a 06-Apr-2001 Updated author affiliation and contact details.  Udated
-                leap-second table.
-
-01b 10-May-2001 Clarified provenance of (non-normative) information in
-                appendix A.
-
-02a 11-May-2001 Reference updated email specification (RFC2822).
-
-02b 14-May-2001 Fix up some detailed information concerning leap
-                seconds.  Include text describing timestamps for times
-                before introduction of UTC.  Caution against the use of
-                future timestamps using leap seconds.  Correction to
-                day-of-week sample code, and note restriction on
-                applicability.  Various editorial corrections.
-
-03a 23-May-2001 Editorial fixes.  Minor clarification of leap seconds.
-
-03b 24-May-2001 More clarification of leap seconds and time zones.
-
-03c 25-May-2001 More minor editorial fixes.
-
-04a 03-Jul-2001 Fix off-by-one error in Netherlands example.
-
-05a 03-Jul-2001 Add note requesting that this appendix be removed on RFC
-                publication.  Revised author affiliation.  Add
-                boilerplate and reference for RFC2119 language usage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman & Klyne                                                 [Page 18]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps          November 2001
-
-
-Full copyright statement
-
-   Copyright (C) The Internet Society 2001.  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Newman & Klyne                                                 [Page 19]
-
-
diff --git a/Documentation/en/I-D/draft-ietf-ipngwg-dns-discovery-analysis-00.txt b/Documentation/en/I-D/draft-ietf-ipngwg-dns-discovery-analysis-00.txt
deleted file mode 100644
index 0b6f76f8..00000000
--- a/Documentation/en/I-D/draft-ietf-ipngwg-dns-discovery-analysis-00.txt
+++ /dev/null
@@ -1,2478 +0,0 @@
-
-
-
-
-
-
-
-IPNG Working Group                       DNS Discovery Design Team
-INTERNET-DRAFT                                 Dave Thaler, Editor
-Expires September 2001                               July 12, 2001
-
-
-
-
-
-       Analysis of DNS Server Discovery Mechanisms for IPv6
-        <draft-ietf-ipngwg-dns-discovery-analysis-00.txt>
-
-
-
-
-
-                       Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that
-other groups may also distribute working documents as Internet-
-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time. It is inappropriate to use Internet- Drafts
-as reference material or to cite them other than as "work in
-progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-
-
-Copyright Notice
-
-Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-
-Abstract
-
-
-
-
-
-Expires January 2002                                      [Page 1]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-There are any number of ways that IPv6 hosts can discover
-information required to enable name resolution, in the absence of
-a DHCP server.  This document discusses the issues and provides a
-taxonomy of possible solutions, and evaluates them against various
-design criteria.  Finally, it provides recommendations as input to
-the standards process.
-
-
-1.  Introduction
-
-The function of name-to-address resolution (or vice versa) in IP
-is performed by the Domain Name Service (DNS) [RFC1034, RFC1035].
-Using DNS requires that at least one DNS Server be known and
-reachable by a device desiring to resolution.
-
-There is also underway, known as Multicast DNS (mDNS) [MDNS], on
-resolving names on the link in the absence of a DNS Server.  In a
-managed environment with DNS Servers, mDNS is typically disabled
-(via the domain search path).  As a result, it is required that a
-device be able to discover whether DNS Servers are available and
-discover its search path.  Thus, the mechanisms analyzed in this
-report do not conflict with, but actually support the mDNS work.
-
-In the absence of a DHCP server, the current IPv6 protocol suite
-does not yet provide a mechanism to discover DNS servers or search
-paths.  To solve this problem, a design team was chartered by the
-IPNG Working Group to investigate possible solutions and provide a
-recommendation as input to the working group.
-
-This document summarizes the approaches investigated, and provides
-an analysis of each, and describes its recommendations.  The
-design team participants are listed in the Authors' Addresses
-section below.
-
-
-2.  Requirements
-
-For a device to effectively resolve names, and potentially allow
-resolution of its name to be performed, the following information
-is required:
-
- o One or more addresses of DNS servers.  If a list is obtained, a
-   client need only rediscover DNS servers if all addresses in the
-   list are unreachable.  However, if a list is obtained from a
-   single point, such as one of the DNS servers, then a
-
-
-
-
-
-Expires January 2002                                      [Page 2]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   requirement exists that the list of servers be up-to-date and
-   easily maintainable.
-
- o Domain name
-
- o Search path.  It is currently common practice, for the search
-   path to be computed by a device based on its domain name
-   obtained.  However, a DHCP option [DOMSEARCH] is being proposed
-   in the DHC WG, and so search path configuration is likely to be
-   a requirement in general.
-
-It is a further requirement that the above information be obtained
-without using a DHCP server.
-
-Automatic configuration of DNS servers, if no DNS servers exist
-within the IPv6 site, is not a requirement.  However, it is
-expected that there may be devices on site boundaries which will
-want to relay messages containing the above types of DNS
-information across site boundaries.  One such likely scenario
-would be a home gateway device, where a home is its own site,
-wanting to allow devices in the home to discover and use an
-external DNS server, provided by an ISP.
-
-
-3.  Criteria for Evaluation
-
-Each mechanism can be evaluated against a number of criteria:
-
-Scalability
-   Is the mechanism scalable to a huge number of devices within a
-   site?
-
-Security
-   Does the mechanism support authentication?  What pre-
-   configuration is assumed?
-
-Time to Deploy
-   Can the mechanism be deployed immediately?  What devices need
-   to have software updated to deploy the mechanism?  What devices
-   need to have additional configuration done with existing
-   software?
-
-Business Motivation
-   Do the parties required to implement any new code have a
-   business motivation to do so, in preference to other options?
-
-
-
-
-
-Expires January 2002                                      [Page 3]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   Do the parties required to deploy any new devices or software
-   have a business motivation to do so, in preference to other
-   options?
-
-Standardization
-   Does the mechanism require anything new to be standardized?  If
-   so, is the standardization within the realm of another Working
-   Group?
-
-Fate Sharing
-   If deployed, does the mechanism introduce dependencies on other
-   devices, protocols, or processes that would not normally be
-   required to perform name resolution?
-
-Convergence Time
-   Upon the failure of a DNS server, router, or link, how long
-   does it take for the mechanism to converge?
-
-Scenarios
-   Does the mechanism work in all scenarios?  Scenarios of note
-   include:
-
-   o  Isolated link with a DNS server but no routers
-
-   o  Site with routers, but no multicast routing enabled
-
-   o  Hosts connected over an NBMA link
-
-
-4.  Taxonomy
-
-Mechanisms can be categorized by their choice of transport
-mechanism (e.g., are the messages multicast or unicast?), and by
-their choice of packet format.
-
-Sections 5 and 6 cover these two axes, and describe the set of
-mechanisms evaluated.
-
-
-5.  Transport Mechanisms
-
-5.1.  Anycast for DNS server discovery only
-
-This method is based on the use of a well-known site-scoped
-anycast address which is used during DNS server discovery only.
-
-
-
-
-
-Expires January 2002                                      [Page 4]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-We assume that IANA defines a well-known site-scoped anycast
-address, which can be assigned one or more servers.  For optimal
-fate-sharing, we assume that these servers are DNS servers.  The
-aim is to provide a mechanism that allows DNS servers assigned the
-well-known anycast address to be reachable within a site.
-
-The proposal is based on a two-step discovery process.  First, a
-device sends, using a connection-less protocol, a server-discovery
-message with the anycast address as a destination address.  The
-message will eventually reach a topologically closest server with
-the anycast address.  The server will send a reply with a unicast
-address as the source address, containing a list of unicast
-addresses of valid DNS servers, plus the domain name and search
-path.  Thereafter, all communication for name resolution is done
-using one of the unicast addresses in the list obtained.  Only if
-all addresses in the list are unreachable does the device need to
-repeat the discovery process.
-
-Obviously, this requires that all IPv6 devices requiring DNS
-server discovery in the absence of a DHCP server must implement
-this mechanism.
-
-
-There are three immediate deployment options:
-
-a) Run the servers on routers, and configure them to inject host
-   routes for the anycast address into the site's routing
-   infrastructure.
-
-b) Run a routing protocol on the servers, and configure them to
-   inject host routes for the anycast address into the site's
-   routing infrastructure.  Note that this requires that a server
-   and its router(s) must run the same routing protocol, at least
-   for communication between the router(s) and the server(s) on
-   the link.  Note that, however, a server does not need to
-   participate fully in the routing protocol, it only needs to be
-   able to inject routes.  For example, RIPng [RIPNG], configured
-   for outbound advertisements only, would be sufficient.
-
-c) Run multiple servers on the same link(s), and configure their
-   local router(s) to inject host routes for the anycast address
-   into the site's routing infrastructure.  Running multiple
-   servers on the same link provides robustness to the failure of
-   a server, while routing provides robustness to the loss of
-   routers and other links.  There may still be some failures,
-
-
-
-
-
-Expires January 2002                                      [Page 5]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   however, such as a unidirectional failure of the router's
-   interface, which are not handled by this option.
-
-If new code can be added to the router, a fourth option is also
-possible:
-
-d)  Using Neighbor Discovery to track whether servers are present.
-    In this case a router will be configured to solicit certain
-    Site-scoped anycast addresses when booting. This can also be
-    done periodically.  Upon receiving a reply, the router will
-    have the true address of the server in its Neighbor Cache and
-    can inject a host route into the system for this Site-scoped
-    anycast address.  A variant of this option, which would not
-    require configuring the routers with the addresses to solicit,
-    would be to combine it with running a routing protocol on the
-    servers.  The router could then solicit whatever addresses
-    were advertised in host routes, and take advantage of neighbor
-    unreachability detection to quickly expire host routes.
-
-    Routers should have this feature and allow configuration to
-    enable or disable it. Also the Site-scoped addresses can be
-    configurable when enabling this feature. This is to ensure
-    that network administrators can add new Site-scoped addresses
-    without the need for new software.  On some links, it may be
-    required to not allow hosts to announce these services.  Hence
-    soliciting anycast addresses should not be enabled on those
-    links.
-
-    It should be noted that this option does not require any
-    protocol changes to ND, as it relies on the allocation of
-    Well-known site-scoped anycast addresses to the hosts.
-
-
-For a longer-term solution, a mechanism for communicating anycast
-group joins to routers is desired.  It is expected that this would
-be done as an extension to the Multicast Listener Discovery [MLD]
-protocol, and the sockets API for joining multicast groups.  There
-is now work in progress [HOST-ANYCAST] in this regard.
-
-More details on generic anycast issues are available in [ITOJUN-
-ANYCAST].
-
-
-
-
-
-
-
-
-
-Expires January 2002                                      [Page 6]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-5.1.1.  Evaluation
-
-Scalability
-   The use of anycast can scale up to an arbitrarily large number
-   of devices within the site, since to perform DNS server
-   discovery, devices will only contact their closest server.  As
-   a result, scalability can be achieved by adding more servers as
-   the number of devices increases.  Since all traffic is unicast
-   traffic, no extra bandwidth is consumed on links other than
-   those between a device and its closest server.
-
-   A large number of servers can also be supported easily, if
-   desired, since only a single server is contacted to obtain a
-   list of DNS servers, and the list obtained need not contain all
-   DNS servers in the site.
-
-
-Security
-   The use of anycast is vulnerable to the same attacks as
-   unicast.  This mechanism can best be authenticated by having
-   the content signed via a content-specific mechanism.
-
-   It may be possible to use IPsec to authenticate the discovery
-   messages, but IKE cannot be used for anycast transmission, as
-   RFC 2373 does not allow an anycast address to be used as the
-   source address of packets.  As a result, barring future
-   research and development of other key distribution protocols,
-   using IPsec instead of a content-specific mechanism would
-   require manual keying.
-
-   In addition to securing discovery messages, it is also
-   necessary to secure the mechanism used to communicate anycast
-   joins from DNS servers to routers.  Without such
-   authentication, the possibility would exist for a rogue server
-   to redirect traffic to itself, and away from valid servers.
-
-   In option (a), this is easy since the server is on the same
-   machine as the router.  Likewise, in option (c), joins are done
-   by manual configuration which is easily securable.  Option (b),
-   however, requires utilizing authentication mechanisms available
-   with current routing protocols (e.g., MD5 with RIPng [RIPMD5]).
-
-   In option (d), only Neighbor Discovery messages need to be
-   secured.  However, authenticating Neighbor Discovery messages
-   is needed regardless of the option chosen, even if only to
-
-
-
-
-
-Expires January 2002                                      [Page 7]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   secure discovery by devices on the same link.
-
-
-Time to Deploy
-   Anycast discovery can be deployed as soon as clients are
-   available, using any of the immediate-term options listed
-   above, alone or in any combination, at the choice of each site
-   administrator, without any need to coordinate with others.
-
-   For immediate option (a), one must update one or more routers
-   to run a server, if none already do.
-
-   For immediate option (b), one must update one or more DNS
-   servers to run an IPv6 routing protocol which can talk to its
-   local router(s).
-
-   For immediate option (c), one must ensure that multiple servers
-   are deployed on the same link(s).  One then configures its
-   local routers with a static host route for the anycast address.
-
-   To deploy option (d), routers on servers' links need to be able
-   to inject routes based on responses received from ND
-   solicitations.  This would require SW upgrades for those
-   existing routers.
-
-   In all four options, one must finally configure the servers
-   with the well-known anycast address.  No configuration is
-   needed on other routers or devices, so configuration is
-   confined to a small number of devices.  It is expected that at
-   least one of the above options will be acceptable to IPv6 site
-   administrators for the immediate future.
-
-
-Business Motivation
-   The primary business motivation is that it can be deployed
-   immediately with a minimum of effort and cost, compared to
-   other options.  As time progresses, the incentive to upgrade to
-   either option (d) or a dynamic joining protocol is that the
-   site would not be limited to the three basic options.
-
-
-Standardization
-   For immediate deployment, including option (d), nothing new is
-   required.  For a longer-term optimal solution, an anycast-
-   joining protocol is required.  It is expected that this would
-
-
-
-
-
-Expires January 2002                                      [Page 8]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   be done within the IPv6 Working Group as an extension to MLD.
-
-
-Fate Sharing
-   This mechanism exhibits good fate sharing properties.  No
-   additional dependencies on any other devices, protocols, or
-   processes exist, beyond those that are already required for
-   performing actual name resolution using DNS (i.e., unicast
-   reachability).
-
-
-Convergence Time
-   When a router or link fails, the convergence time is the
-   convergence time of the unicast routing protocol in the site,
-   if the server is off-link, or the convergence time of Neighbor
-   Discovery if the server is on-link.  When a server fails, this
-   is also the convergence time of DNS server discovery, but not
-   for name resolution.  Since unicast is used for actual name
-   resolution, a host with a list of DNS servers may converge
-   faster to another DNS server it previously discovered, when a
-   DNS server fails.
-
-
-Scenarios
-   This mechanism should work in all scenarios discussed.
-   Specifically, it will work in the absence of routers and in the
-   absence of multicast-capable media and routing protocols.
-
-
-5.2.  Anycast for name resolution
-
-Assign a well-known site-scoped anycast address to DNS servers.
-Use anycast destination address on DNS queries.  Anycast packet
-will eventually reach the topologically a closest DNS server.  DNS
-server will send a reply.
-
-While the other mechanisms evaluated try to obtain unicast IPv6
-addresses of DNS servers, this approach uses anycast as the actual
-name resolution transport.
-
-Acquiring the domain name and search path must still be done as in
-section 5.1 above, however.
-
-
-
-
-
-
-
-
-Expires January 2002                                      [Page 9]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-5.2.1.  Configuration
-
-Define a well-known site-scoped anycast address, and write it down
-on a document.  Let us assume that it is fec0::9999 for now.
-
-Configure clients to send DNS queries to the address.  The
-configuration does not need to be modified even if the machine
-moves from a site to another, as the anycast address is well-
-known.
-
-Configure DNS servers (server-1, server-2 to server-N) with the
-anycast address, and make them reply the query to fec0::9999.
-Make sure that packets with the anycast destination address get
-routed to DNS servers.  (see a section below on this topic)
-
-5.2.2.  Actual use
-
-(1)  When a DNS name resolution is necessary for a client, the
-     client would transmit a DNS query (usually UDP) toward
-     fec0::9999.
-
-     client -> fec0::9999    DNS query
-
-(2)  The DNS query will reach one of the DNS servers (suppose it
-     was "server-X").  The server will resolve the name by making
-     a recursive query.  The server will send a reply to the
-     client.  If we follow the RFC 2373 restriction that an
-     anycast address cannot be used as a source address, we need
-     to use server-X's unicast address as the source.  In this
-     case, DNS clients should not check the source address of DNS
-     replies.  Some existing implementations do this to check if
-     the packet was really from the server queried.  The check is
-     rather weak, however, as it is easy to spoof the source
-     address.  Instead, DNSSEC should be used here.
-
-     server-X -> client  DNS reply
-
-5.2.3.  Evaluation
-
-Note that there are multiple ways to handle anycast routing in a
-site.  Some of them require us to inject a /128 route into the
-routing system, some of them does not.
-
-Scalability
-   The scalability of the proposal is exactly the same as the
-
-
-
-
-
-Expires January 2002                                     [Page 10]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   scalability implication in anycast routing.  Note that, as the
-   proposal uses a site-scoped anycast address, we need to scale
-   up to a single site - we do not need to scale up to the whole
-   Internet.
-
-   Regarding to the site network size, the approach should have no
-   problem, except the possible delay imposed by extra hops
-   between DNS clients and servers.
-
-   Regarding to the impact from the number of possible DNS servers
-   to the site routing system, there should be no problem.  Even
-   if we are to inject a /128 route to the site routing system, we
-   will have a single extra routing entry on site routers.  As we
-   share a single site-scoped anycast address among the DNS
-   servers, we just need to carry a single /128 route in the site
-   routing system.
-
-   Regarding to the load balancing among DNS servers, it depends
-   on (1) the network topology in the site, (2) where the DNS
-   servers are located, (3) where the DNS clients are located, and
-   (4) the anycast routing mechanism we use.  If we need to
-   implement a perfect load balancing among DNS servers (equal
-   load onto each DNS servers), we should just put DNS servers
-   onto a single IPv6 subnet.  Neighbor discovery for anycast
-   address should take care of it.  Refer to [ND], section 7.2.7.
-
-   There is no impact against the worldwide routing system.
-
-
-Security
-   The security issues with this mechanism are the same as those
-   discussed in section 5.1.
-
-Time to Deploy
-   The proposal is based on standardized mechanisms, including
-   anycast, routing protocols (like RIPng) and DNS lookup over
-   IPv6.  This is just a matter of configuration to deploy this
-   proposal.
-
-   There are widely-deployed implementations that support anycast
-   address assignment.  There are many IPv6 routing protocol
-   implementations.
-
-   As for DNS lookup over IPv6, there are servers (including ISC
-   BIND9) and clients (including BIND9, NetBSD, OpenBSD, FreeBSD,
-
-
-
-
-
-Expires January 2002                                     [Page 11]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   and Linux) that support it.
-
-   The use of TCP with anycast needs more study (spec-wise), so
-   DNS query/reply over IPv6 TCP may need some time to deploy.
-
-   Regarding to the sanity checks made by DNS client
-   implementation, BIND-based implementation has a configurable
-   option to turn off the source address validation on the DNS
-   reply packet.
-
-   To deploy this proposal, there is no requirement to run
-   additional servers.
-
-Business Motivation
-   If there are operating system implementations without anycast
-   support, we apparently cannot use the operating system
-   implementation as a DNS server.  If there are commercial
-   operating systems that do not support anycast, they now have a
-   good motivation to support it.
-
-Standardization
-   As the proposal uses DNS as the content format, it is safe to
-   say that the content is standardized well.
-
-   We already have couple of standardized IPv6 routing protocols.
-   So even if we are to use routing protocol to inject a /128
-   route for the DNS server anycast address, there should be no
-   problem.
-
-   For full discussions on anycast routing, refer to [ADDRARCH]
-   and [ITOJUN-ANYCAST].
-
-Fate Sharing
-   As DNS queries use site-scoped anycast address as the
-   destination, DNS query/reply relies upon anycast routing
-   mechanism.  There is no circular dependency between anycast
-   routing and DNS lookups.
-
-Convergence Time
-   There are couple of possible configurations for anycast packet
-   delivery.
-
-   If we run anycast DNS servers on routers, the convergence time
-   will be the same as the router failure recovery time.  When a
-   router with DNS server dies, we need to wait until another
-
-
-
-
-
-Expires January 2002                                     [Page 12]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   router to take it over.
-
-   If we inject /128 routes onto the site routing system for
-   anycast packet delivery, the convergence time will depend on
-   the routing information propagation time of the site routing
-   system.
-
-   As to partial failure (like DNS server daemon died but the
-   operating system is alive), there are many failure modes to
-   mention and there are many implementation dependencies.
-   Implementers may need to diagnose partial failure modes in
-   detail.
-
-Scenarios
-   This mechanism should work in all scenarios discussed.
-
-
-5.3.  Link-scoped multicast with router-only responses
-
-This transport approach is modeled after IPv6 Neighbor Discovery
-[ND] transport mechanisms.  It could be part of [ND] or another
-protocol using a similar transport mechanism.
-
-This approach has two modes.  The first is routers periodically
-advertise DNS information (e.g., DNS server addresses, default
-domain, and search path) to all nodes on a link by sending an
-advertisement to the all nodes link-scope multicast address (i.e.,
-FF02::1 ).
-
-The second mode is that nodes needing DNS information can send a
-solicitation to the all routers link-scope multicast address
-(e.g., FF02::2) requesting DNS information.  Routers with the DNS
-information will respond with an advertisement with the requested
-DNS information.  This advertisement will be sent to the unicast
-address of the node sending the solicitation.
-
-
-5.3.1.  Evaluation
-
-Scalability
-   This transport approach has excellent scalability.  It scales
-   as well as ND and DNS does currently.  All of the multicast
-   traffic is local to the link. The periodic advertisement rates
-   can be tuned to environment including turn it off completely
-   and relying on the solicitation/advertisement mode.
-
-
-
-
-
-Expires January 2002                                     [Page 13]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   ND transport mechanisms work on a variety of link (e.g.,
-   multicast capable, point-to-point, shared media, etc.).  It
-   will well suited for both wired and wireless links.
-
-
-Security
-   Mechanisms that are being developed to authenticate ND can be
-   applied to this approach as well.  The only preconfiguration is
-   done in routers where the DNS information is held.
-
-   No new security issues are raised.  All of the traffic is link-
-   scoped.  Any attacks require link access and if successful only
-   affect nodes on the individual link.
-
-
-Time to Deploy
-   This approach requires implementation in nodes wishing to learn
-   DNS information and in routers to provide the information.  The
-   router will need to be configured with the DNS information
-   needed in the advertisements.
-
-   If done as an extension to ND, it will be a small amount of
-   work to extend the ND implementation to add the additional
-   functionality.  If done in a new protocol it would be more
-   difficult to create the new protocol.
-
-   It should be possible to deploy it quickly once the details are
-   scoped out and the implementations are developed.  There is no
-   new network wide services such as multicast or anycast that
-   need to be deployed.  There are no dependencies with other
-   protocols.
-
-
-Business Motivation
-   This approach is a simple extension to existing protocols in
-   existing products and there should be ample motivation to add
-   it to existing products.  No complex dependencies are created.
-   No new network transport mechanisms (e.g., anycast) are
-   required.  No network operators have to deploy any new
-   transport mechanisms (e.g., multicast and/or anycast).
-
-
-Standardization
-   A single document would have to be written to describe an
-   extension to ND or a new protocol.  This would have to become
-
-
-
-
-
-Expires January 2002                                     [Page 14]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   an IETF standard.  This is within the scope of the IPng working
-   group.  No other IETF working groups would need to be involved.
-
-
-Fate Sharing
-   The only fate sharing issue raised is that it ties the
-   discovery of DNS information with the operation of routers on a
-   link.  This is very similar to the common practice with IPv4 of
-   using Bootp relays in routers to communicate with DHCP servers,
-   so in practical terms the issue is very small.
-
-   No changes are made to DNS servers or way nodes communicate
-   with DNS servers.
-
-
-Convergence Time
-   Convergence time is similar to current IPv4 DNS operation using
-   DHCP for DNS discovery. No new convergence issues are created.
-   If one of a set of DNS servers is unavailable (e.g., down,
-   isolated, etc.), then normal DNS recover mechanisms will select
-   an alternative DNS servers.
-
-   If one of a set of routers is unavailable, other routers on the
-   link will continue providing the DNS information.
-
-   If the last DNS server is unavailable, then it is down.  If the
-   last router is unavailable, then new nodes will not be able to
-   learn DNS information or reach any DNS server through the
-   router.
-
-
-Scenarios
-   This mechanism works over a broad range of scenarios.  It
-   should work as well on links that are high performance (e.g.,
-   LANs) and low performance (e.g., wireless).
-
-   However, this mechanism relies on routers and does not support
-   DNS servers on isolated links.  Other local DNS server
-   discovery mechanisms (e.g., multicast DNS) would be needed.
-   This approach is believed to be compatible with multicast DNS
-   approach being developed in the IETF.
-
-   It can be used in either a periodic multicast advertisement, or
-   a solicitation/advertisement mode.
-
-
-
-
-
-
-Expires January 2002                                     [Page 15]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-5.4.  Link-scoped multicast (with router assist)
-
-In this approach, devices send a request to a (new) well-known
-link-scoped multicast address.  DNS servers and routers both
-listen to this multicast address.  If any DNS servers exist on the
-list, they can respond directly to the host.
-
-In addition, routers are responsible for using some other
-mechanism to obtain the DNS server list (e.g., one of the other
-mechanisms evaluated in this document).  Routers with the DNS
-information will respond with an advertisement with the requested
-DNS information.
-
-
-5.4.1.  Evaluation
-
-Scalability
-   This mechanism scales fine on each individual link.  The
-   scalability across the site depends on the scalability of the
-   inter-router mechanism used.
-
-
-Security
-   The use of multicast is vulnerable to the same attacks as
-   unicast.  This mechanism can best be authenticated by having
-   the content signed via a content-specific mechanism.
-
-   It may be possible to use IPsec to authenticate the discovery
-   messages, but IKE cannot be used for multicast transmission.
-   As a result, barring future research and development of other
-   key distribution protocols, using IPsec instead of a content-
-   specific mechanism would require manual keying.
-
-   In contrast to the anycast approaches, it is not strictly
-   necessary to secure the mechanism used to communicate multicast
-   joins from DNS servers to routers, since a rogue server cannot
-   redirect traffic to itself that would otherwise reach a valid
-   server.
-
-
-Time to Deploy
-   This approach can be deployed by devices immediately, as link-
-   scoped multicast is already ubiquitous.  However, the time to
-   deploy router assist to discover off-link servers depends on
-   the inter-router mechanism chosen.
-
-
-
-
-
-Expires January 2002                                     [Page 16]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-Business Motivation
-   No strong business case for choosing this mechanism over the
-   others evaluated is known.
-
-
-Standardization
-   Nothing new is required, beyond whatever is required for the
-   content mechanism and the inter-router mechanism.
-
-
-Fate Sharing
-   Good fate sharing is preserved in this partial mechanism, as no
-   additional dependencies on other devices or protocols is
-   introduced, beyond whatever is required for the inter-router
-   mechanism.
-
-
-Convergence Time
-   The convergence time depends on the convergence time of the
-   inter-router mechanism used.
-
-
-Scenarios
-   This mechanism works on an isolated link, and can work in the
-   absence of multicast routing (provided a non-multicast inter-
-   router mechanism is used).
-
-   However, it does not support the NBMA link scenario.
-
-
-5.5.  Site-scoped multicast
-
-Site-scoped multicast could be used to discover all DNS servers
-within a site.  This would be analogous to the way multicast is
-currently used by IPv6 hosts to discover their neighboring
-routers, but over the span of a site rather than just a single
-link.
-
-There are several possible ways for site-scoped multicast to be
-used for DNS (or any other) server discovery.  The clients could
-send multicast query packets to a well-known, site-local, "all-
-site-DNS-servers" multicast address, to which all DNS servers
-would listen and respond.  Alternatively, the servers themselves
-could send periodic multicast advertisement packets to a well-
-known, site-local, "all-site-DNS-clients" multicast address, to
-
-
-
-
-
-Expires January 2002                                     [Page 17]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-which all clients would listen in order to discover the presence
-and address(es) of all of the site's DNS servers.  Probably the
-best approach, from the point of view of responsiveness, scaling,
-and traffic volume is to use both of those techniques in
-combination, exactly as they are used for router discovery, as
-follows:
-
-
-o  Two well-known, site-local scoped, multicast addresses are
-   assigned by IANA, one for all-site-DNS-routers and one for all-
-   site-DNS-clients.
-
-
-o  When a DNS server starts up, it multicasts a small number (say,
-   3) of advertisement messages to the all-site-DNS-clients
-   address at short (sub-second) intervals, and then continues to
-   retransmit the advertisement messages but at much larger
-   intervals (30 seconds or more).  It also sends a unicast
-   response to any (unicast or multicast) DNS discovery query
-   message it receives.
-
-
-o  When a client starts up (or when the first attempt to perform a
-   DNS look-up occurs), if the client has not yet heard any
-   advertisements from DNS servers, it multicast up to a small
-   number (say, 3) of query messages to the all-site-DNS-servers
-   address at short (sub-second) intervals, stopping as soon as it
-   receives a response from a DNS server or it reaches the small
-   retransmission limit.  From that point on, the client does not
-   send any multicast queries, but rather relies on passively
-   discovering additional DNS servers (and DNS servers that fail
-   and subsequently recover) by listening on the the all-site-DNS-
-   clients address for advertisements.
-
-The response and advertisement messages would ideally contain only
-the address of the sending DNS (rather than a list of multiple DNS
-servers, which which would impose an undesirable requirement for
-configuration of, or a coordinating protocol among, the servers).
-That one address could be found either in the Source Address field
-of the IPv6 header or in the content of the message.  Clients
-would build their lists of candidate DNS servers by taking the
-union of the responses/advertisements received.
-
-To avoid the need for additional packet exchanges, the response
-and advertisement messages should also carry the other information
-
-
-
-
-
-Expires January 2002                                     [Page 18]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-required by the client, i.e., the domain name and default domain
-search list to be used by clients within the site.  [Open issue:
-what ought a client to when not all DNS serves are advertising the
-same information?]
-
-
-5.5.1.  Evaluation
-
-Scalability
-   The recommended technique, above, imposes a steady-state
-   traffic load on a site of one multicast packet per DNS server,
-   every (30 second or greater) advertisement transmission
-   interval.   Because almost all nodes would be expected to
-   listen to those multicasts, they would effectively be site-wide
-   broadcast messages.  However, note that the retransmission
-   interval can safely be made quite large to minimize the
-   overhead of those message, since the technique does not rely on
-   a small interval for its responsiveness; rather, the periodic
-   multicast advertisements serve the role of ensuring long-term
-   consistency and recovering from rare failures (e.g., loss of
-   three packets in a row, or site partitioning).
-
-   In addition to the overhead of the periodic advertisements,
-   there is also the small (maximum 3 packet) burst load of
-   queries/ responses/advertisements that occur whenever a client
-   or DNS server starts up.  Note that these costs are comparable
-   to those incurred by the anycast techniques described in other
-   sections.  They can also be further reduced by a more
-   sophisticated design, in which queries and/or responses are
-   delayed for small, randomized time intervals in order to do
-   "suppression" of identical queries or responses that occur very
-   close together, e.g., when a site comes up after a site-wide
-   power-failure.
-
-   Using this technique requires that all, or almost all, nodes
-   within a site send multicast packets at some point or another.
-   A multicast routing implementation that instantiated state for
-   every active multicast source node would have a state cost on
-   the order of the number of nodes in the site.  It may be
-   preferable to use a multicast routing protocol that
-   instantiates state only for each active multicast source
-   *subnet* (which is sufficient to support shortest-path
-   multicast delivery), or for each multicast destination address
-   (so-called "shared-tree" multicast, which does not try to
-   achieve shortest-path delivery, which is not important for this
-
-
-
-
-
-Expires January 2002                                     [Page 19]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   particular application).
-
-
-Security
-   The security evaluation for all types of multicast is discussed
-   in section 5.4.1.
-
-
-Time to Deploy
-   It is expected that most sites will not have site-wide
-   multicast deployed in the near-term future.  As a result, it
-   may be some time before a site-scoped multicast solution could
-   be deployed.
-
-
-Business Motivation
-   Given the perceived extra cost of managing a multicast-enabled
-   infrastructure, when other solutions relying only on unicast
-   routing exist, it is expected that no strong business case for
-   choosing site-scoped multicast exists.
-
-
-Standardization
-   Protocols needed for multicast connectivity are already on the
-   standards track, or in progress.
-
-
-Fate Sharing
-   This mechanism places an extra dependency on the correct
-   functioning of the multicast routing system.  There are no
-   dependencies on any extra devices, however, beyond those that
-   are already required for name resolution.
-
-
-Convergence Time
-   When a router or link fails, the convergence time is the
-   convergence time of the multicast routing protocol in the site.
-   When a server fails, this is also the convergence time of DNS
-   server discovery, but not for name resolution.  Since unicast
-   is used for actual name resolution, a host with a list of DNS
-   servers may converge faster to another DNS server it previously
-   discovered, when a DNS server fails.
-
-
-
-
-
-
-
-
-Expires January 2002                                     [Page 20]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-Scenarios
-   This mechanism works on an isolated link with a DNS server but
-   no routers.
-
-   However, it does not work in a site with no multicast routing
-   enabled, or among hosts connected over an NBMA link.
-
-
-5.6.  Hybrid
-
-It is possible to combine the above approaches in some situations.
-For example, the option for link-scoped multicast with router
-assist requires one of the other options to form a complete
-solution.
-
-It is also possible for one of the above mechanisms to be the
-default, but allow use of one of the other mechanisms based on
-local manual configuration, or on configuration obtained
-information obtained from say Router Advertisements.  Of course,
-if routers can distribute the address to use for discovery, then a
-router which does not have multicast routing enabled must not
-distribute a site-scoped multicast address.
-
-The disadvantage with router overrides is that devices must be
-prepared to handle multiple mechanisms, increasing the complexity
-of the implementations.
-
-
-6.  Message Content Mechanisms
-
-6.1.  DHCP
-
-In this mechanism, the messages sent to DNS servers are DHCP-
-format messages, and the DNS servers send DHCP messages in
-response.
-
-The domain name can be obtained by having the DNS server include a
-Domain Name option in the response.  A DHCP option to obtain a
-domain search path [DOMSEARCH] is currently being discussed in the
-DHC WG.  Without this option, the search path behavior would be no
-different from the behavior today, where the search path is simply
-computed based on the domain name obtained.  A list of DNS servers
-would also require a new DHCP option, which is already required if
-DHCP for IPv6 is to be implemented.
-
-
-
-
-
-
-Expires January 2002                                     [Page 21]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-6.1.1.  Evaluation
-
-Scalability
-   Only one round trip of messages is required, and there is no
-   need to run any additional servers.  In other respects, this
-   mechanism has the same scalability properties as the underlying
-   transport mechanism chosen.
-
-
-Security
-   A means of securing DHCP content that does not rely on IPsec
-   has been proposed in the DHC Working Group [DHCPAUTH].
-
-
-Time to Deploy
-   This would require time to implement a DHCP parser in DNS
-   servers.  In addition, DHCP for IPv6 is still being defined by
-   the DHC Working Group.
-
-
-Business Motivation
-   Devices wanting to resolve names probably already have to
-   implement a DHCP parser and be able to obtain DNS-related
-   configuration information using DHCP messages.  As a result, it
-   is expected that little extra work would be required by stack
-   implementers beyond implementing DHCPv6.
-
-
-Standardization
-   The DHCP for IPv6 content format is still being defined by the
-   DHC Working Group.
-
-
-Fate Sharing
-   Good fate sharing would require that DNS servers also implement
-   a DHCP parser.  Otherwise, it is necessary to run a DHCP
-   service on the DNS servers which simply responds to requests
-   for DNS information.  In such a configuration, an additional
-   dependency on the DHCP service would be introduced by this
-   mechanism.
-
-
-Convergence Time
-   This mechanism has the same convergence time as the underlying
-   transport mechanism chosen.
-
-
-
-
-
-Expires January 2002                                     [Page 22]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-Scenarios
-   This mechanism works in the same scenarios as the underlying
-   transport mechanism chosen.
-
-
-6.2.  DNS
-
-DNS itself can be used, as long as the transport mechanism ensures
-that discovery messages reach DNS servers, to obtain the DNS
-server list, default domain name, and domain search path.
-
-DNS has many record types that could be used.  For example, SOA
-and NS records contain relevant information.  However, the name
-resolution configuration information which an administrator
-desires that a host should use may not match the usual
-configuration of the DNS server (e.g., might use a different
-domain name).  Hence, using information encoded in separate
-records is more flexible.  It is also desirable that an
-administrator can give different configuration information to
-hosts in different subnets, since this capability exists when a
-DHCP server is present.
-
-There are many ways to accomplish the above.  On the query side,
-the subnet prefix can be encoded in the hostname part of the
-query.  On the response side, the server list, domain name, and
-search path can be encoded in the response, potentially using SRV
-records [SRV] with a special encoding, or using TXT records [TXT],
-or even defining a new record type.
-
-
-
-6.2.1.  Evaluation
-
-Scalability
-   The mechanism has one round trip to the DNS server and the
-   security overhead.  Using Secret Keys, if possible, will
-   produce no more packets, but some processing on the DNS server
-   to match the clients secret key using [TSIG].  Using Diffie-
-   Hellman with [DNSSEC], if many clients attempt this at the same
-   time will put extreme processing demands on the DNS server.
-   But it is doubtful that one or a few DNS Servers will handle
-   1000's of clients.  See Security Evaluation below.
-
-Security
-   If the client can preconfigure a well known private or public
-
-
-
-
-
-Expires January 2002                                     [Page 23]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   key then TSIG or DNSSEC can be used with the same packets
-   presented for the query.  If this is not the case, then either
-   TSIG keys will have to be negotiated using [TKEY] or a Diffie-
-   Hellman Key [DIFFSEC] exchange will have to take place using
-   DNSSEC.  After the client has the proper key then the query can
-   be performed.
-
-Time to Deploy
-   This mechanism can be deployed now.  If the address provided to
-   the Client is an Anycast address then resolver implementations
-   would have to not use the present mechanisms to verify the
-   source address of a QUERY response is equivalent to the
-   destination address of the QUERY to the DNS Server.  Likewise
-   for Multicast DNS.
-
-Business Motivation
-   All DNS suppliers are now implementing TSIG and DNSSEC.  The
-   biggest business motivation for this mechanism is that it
-   requires the least new code of any of the mechanisms evaluated,
-   and provides the greatest robustness since there are no
-   dependencies on other protocols or services.
-
-Standardization
-   If SRV or TXT records are used, there is no standardization
-   required other than the specific mechanism document in the IPv6
-   Working Group.  If a new record type is required, the DNSEXT
-   Working Group would be involved.
-
-Fate Sharing
-   There are no dependencies on other than the normal DNS
-   processes implemented today, nor are there any new dependencies
-   created from these content messages.
-
-Convergence Time
-   There is no degradation in convergence time with this content
-   set of messages, other than awaiting for a failed network to
-   respond again or a DNS Server(s) to come back up after reboot.
-   Once the resolver has done the DNS queries the knowledge from
-   the server on most implementations becomes stateful and stored
-   to non-volatile storage.  In the case of embedded systems with
-   no non-volatile storage the DNS Server address would have to be
-   relearned.
-
-Scenarios
-   This mechanism should work in all scenarios discussed.
-
-
-
-
-
-Expires January 2002                                     [Page 24]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-6.3.  Node Information Query
-
-ICMPv6 node information query [NODEINFO] provides a way to query
-IPv6 addresses assigned to a machine.  This could be used to query
-IPv6 unicast address for a DNS server, from a DNS server IPv6
-anycast/multicast address.
-
-To get a local domain name and search path, new query types
-(QTypes) would need to be defined for these information types.
-
-6.3.1.  Evaluation
-
-Scalability
-   As ICMPv6 node information query will be handled by the DNS
-   server node itself, there is no need for running an additional
-   server.  This mechanism has the same scalability properties as
-   the underlying transport mechanism chosen.
-
-
-Security
-   IPsec is the only way to prevent malicious packets.  It depends
-   on the actual transport protocol used with ICMPv6 node
-   information query, if IPsec is usable or not.  For example, it
-   is rather hard to use IPsec with anycast/multicast, so IPsec
-   may not work well if we use anycast/multicast.
-
-
-Time to Deploy
-   While there exist some implementations of node information
-   queries, implementation is not ubiquitous.
-
-
-Business Motivation
-   There does not seem to be any strong business motivation for
-   implementing a node information query parser, in preference to
-   other options.
-
-
-Standardization
-   The ICMPv6 node information query has not made it to RFC status
-   yet, but is owned by the IPv6 Working Group.
-
-
-Fate Sharing
-   Depends on how we combine this with other mechanisms, and
-
-
-
-
-
-Expires January 2002                                     [Page 25]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   transport protocols.
-
-
-Convergence Time
-   Depends on how we combine this with other mechanisms, and
-   transport protocols.
-
-
-Scenarios
-   This mechanism should work in all scenarios in which the
-   transport mechanism works.
-
-
-6.4.  RA Extensions
-
-The basic approach is to define a new ND option that would contain
-the DNS information.  Existing ND transport mechanisms (i.e.,
-advertisements and solicitations) mechanisms would be used.  This
-would work in the same way that nodes learn about routers and
-prefixes, etc.
-
-A ND new option would be defined that routers could send in router
-advertisements.
-
-
-This approach has two modes of operation.  The first is routers
-periodically send the DNS Configuration Option in their periodic
-router advertisements.
-
-The second mode is that nodes needing DNS information can send a
-solicitation to the routers on the link requesting the DNS
-Configuration options.
-
-This approach has an issue that the DNS information needs to be
-configured in the routers doing the advertisements.  There are
-several approaches to this:
-
-
-a) Many routers may already have most of this information
-   configured.  Routers also function as hosts and may have DNS
-   server addresses, default domain, and list of domains to search
-   in their configuration file.  For example, Cisco IOS [IOS] has
-   the following commands:
-
-
-
-
-
-
-
-Expires January 2002                                     [Page 26]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   ip domain-name name
-      Define a default domain name that the Cisco IOS software
-      will use to complete unqualified host names.
-
-
-   ip domain-list name
-      Define a list of default domain names to complete
-      unqualified host names.
-
-
-   ip name-server server-addr1 [server-addr2...server-addr6]
-      Specify one or more hosts that supply name information.
-
-   At least in the case of Cisco routers, and probably most
-   others, no additional work is needed to add the DNS information
-   to the routers.
-
-
-b) The next approach, that is consistent with current router
-   management practice, is to configure the router manually with
-   the DNS information that they would advertise w/ IPv6 ND.  This
-   could be done by CLI commands as shown above and/or by other
-   mechanisms normally used to configure routers (e.g., web
-   interfaces, proprietary tools, etc.)
-
-   The work to implement this is minor and part of implementation
-   the feature in the router.  No new management/distribution
-   protocols.
-
-
-c) The next approach, also consistent with current router
-   management practice, is that the router configuration files are
-   created centrally and remotely installed on the router.  This
-   is done today with a mix to special tools, text editors, pearl
-   scripts, vendor management systems, etc.  It is very common
-   practice to create files of CLI commands and push them to the
-   routers.  No new management and/or distribution protocols are
-   required.
-
-
-d) Create or extend an SNMP MIB (do we have an ND MIB?) that
-   contains this information and use existing management tools to
-   set the information in the router.  Also common practice and no
-   new management/distribution protocols.  A MIB is required and
-   extensions to management tools to support the new variables.
-
-
-
-
-
-Expires January 2002                                     [Page 27]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-e) Extend Router Renumbering (RR) to contain this information and
-   use it to advertise it to the routers.  This is mostly
-   consistent with what RR does and allows control reasonable fine
-   grained control of to allow different information per router or
-   even per interface.
-
-Without changing the intended usage of Router Advertisements, the
-natural transport mechanism used would be Link-scoped multicast
-with router-only response.
-
-
-6.4.1.  Evaluation
-
-Scalability
-   This mechanism has excellent scalability properties.  It scales
-   as well as ND and DNS does currently.  All of the multicast
-   traffic is local to the link. The periodic advertisement rates
-   can be tuned to environment including turn it off completely
-   and relying on the solicitation/advertisement mode.
-
-
-Security
-   ND does not currently have authentication mechanisms built in,
-   but there is ongoing work to investigate using AH with ND.
-   This approach would use what ever solution is selected for ND
-   authentication.
-
-
-Time to Deploy
-   This approach requires implementation in nodes wishing to learn
-   DNS information and in routers to provide the information.  The
-   router will need to be configured with the DNS information
-   needed in the advertisements.
-
-   It is a relatively minor amount of work to add a new option to
-   an existing router and/or node implementations of ND.  It
-   should be possible to deploy it quickly once the details are
-   scoped out and the implementations are developed.  There is no
-   new network wide services such as multicast or anycast that
-   need to be deployed.  There are no dependencies with other
-   protocols.
-
-
-Business Motivation
-   The business motivation is very good.  The implementation,
-
-
-
-
-
-Expires January 2002                                     [Page 28]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   documentation, and support cost are minor and very much in line
-   with existing ND features.  There are no new protocols and/or
-   transports to deploy, document, and support.
-
-   Devices wanting to discover DNS servers already have to have an
-   RA parser in them.  It is expected that implementors would find
-   it easier to extend an existing parser than to add a new
-   parser.
-
-
-Standardization
-   This mechanism would require a new RA option format to be
-   standardized.  This would be done by the IPv6 Working Group.
-
-
-Fate Sharing
-   The only fate sharing issue raised is that it ties the
-   discovery of DNS information with the operation of routers on a
-   link.  This is very similar to the common practice with IPv4 of
-   using Bootp relays in routers to communicate with DHCP servers,
-   so in practical terms the issue is very small.
-
-   No changes are made to DNS servers or way nodes communicate
-   with DNS servers.
-
-
-Convergence Time
-   Convergence time is similar to current IPv4 DNS operation using
-   DHCP for DNS discovery. No new convergence issues are created.
-   If one of a set of DNS servers is unavailable (e.g., down,
-   isolated, etc.), then normal DNS recover mechanisms will select
-   an alternative DNS servers.
-
-   If one of a set of routers is unavailable, other routers on the
-   link will continue providing the DNS information.
-
-   If the last DNS server is unavailable, then it is down.  If the
-   last router is unavailable, then new nodes will not be able to
-   learn DNS information or reach any DNS server through the
-   router.
-
-
-Scenarios
-   This mechanism works over a broad range of scenarios.  It
-   should work as well on links that are high performance (e.g.,
-
-
-
-
-
-Expires January 2002                                     [Page 29]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   LANs) and low performance (e.g., wireless).
-
-   However, this mechanism relies on routers and does not support
-   DNS servers on isolated links.  Other local DNS server
-   discovery mechanisms (e.g., multicast DNS) would be needed.
-   This approach is believed to be compatible with multicast DNS
-   approach being developed in the IETF.
-
-   It can be used in either a periodic multicast advertisement, or
-   a solicitation/advertisement mode.
-
-
-6.5.  SLP
-
-The Service Location Protocol [RFC 2608] provides a general
-framework for service discovery.  Services are modeled on the
-basis of their type, location, and a set of attributes.
-
-Clients use SLP to request services on the basis of the attributes
-required and retrieve both the location and attributes of all
-services fulfilling the request.  In the case of DNS server
-discovery, a DNS client could discover the location, domain name
-and search path to use, all in one message round trip
-(SrvRqst/SrvRply) if the Attribute List Extension is used, or two
-round trips (SrvRqst/SrvRply, AttrRqst/AttrRply) if the Attribute
-List extension is not supported.
-
-Without changing the basic SLPv2 protocol, the natural transport
-mechanism used would be Site-scoped multicast.
-
-
-6.5.1.  Evaluation
-
-Scalability
-
-   This mechanism has the same scalability properties as the
-   underlying transport mechanism chosen.
-
-
-Security
-   SLPv2 provides its own security so that those who obtain
-   service location and attribute information can verify the
-   signature over it.  These digital signatures are calculated
-   using keys which are distributed by some external mechanism
-   (SLPv2 does not provide mechanisms for cryptographic key
-
-
-
-
-
-Expires January 2002                                     [Page 30]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   distribution).
-
-
-Time to Deploy
-   SLPv2 for IPv6 is not yet a proposed standard.  It will shortly
-   enter IETF last call.
-
-   There are no IPv6 SLPv2 implementations yet.  SLPv2 over IPv4
-   has been implemented by many vendors and is used for a variety
-   of purposes.
-
-
-Business Motivation
-   Rather than each protocol supplying its own service discovery
-   protocol, SLP can provide a general purpose mechanism which
-   will minimize the software required and allow for common
-   operational considerations and management.
-
-
-Standardization
-   SLPv2 is a Proposed Standard.  SLPv2 over IPv6 and the
-   Attribute List Extension are both about to enter IETF last call
-   before being advanced to Proposed Standard.
-
-
-Fate Sharing
-   SLP would require an additional protocol to be used to
-   configure DNS resolvers - namely, a SLP user agent library.
-   DNS servers would need to be advertised using a SLP service
-   agent - this functionality could be provided by a library
-   invoked by a DNS server, or by an additional service running on
-   the DNS server host (although this is more complicated and less
-   assured of not advertising the DNS server when it is in fact
-   not available).
-
-
-Convergence Time
-   If no directory agents are deployed, convergence time is on the
-   order of milliseconds:  the only way that a DNS resolver could
-   discover a DNS server which was not available would be if the
-   DNS server failed after answering that it was available.
-
-   If directory agents are available, convergence depends on the
-   soft state registration lifetime - which could be of any
-   granularity on the order of seconds - but typically is on the
-
-
-
-
-
-Expires January 2002                                     [Page 31]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   order of minutes.  During this interval it is possible for a
-   client to discover a service which has gone off line since the
-   service location has been cached by a directory agent
-   temporarily.
-
-
-Scenarios
-
-   o  Isolated link with a DNS server but no routers
-
-      SLP requests multicast on the link would enable DNS clients
-      to directly discover DNS servers, domain name and search
-      path.
-
-      The DNS clients and servers would have to make use of a SLP
-      library to accomplish this.  Another alternative is a
-      service advertising process co-resident on the DNS server
-      host which advertises the DNS server on its behalf.  In this
-      case, no modification of the DNS server would be necessary.
-
-
-   o  Site with routers, but no multicast routing enabled
-
-      Routers use SLP to discover DNS servers on attached links.
-      The routers can then use other mechanisms to distribute the
-      location of the DNS servers (add an anycast routing entry
-      for each DNS server, send extensions to routing
-      advertisements, etc.)
-
-      DNS clients could use link-scoped multicast SLP discovery,
-      and routers could answer these requests on behalf of DNS
-      servers.  The problem with this approach is that it does not
-      specify the way in which DNS server locations are propagated
-      between routers.
-
-      Thus, SLP can be used as a mechanism to provide dynamic and
-      decentralized service discovery for the system, but only
-      between the routers and the DNS servers.  The mechanism
-      between the routers to propagate DNS service locations would
-      have to be satisfied by some additional protocol (such as
-      OSPF extensions).
-
-      In summary, a link-scoped multicast with router-assist
-      transport mechanism would be needed in this scenario.
-
-
-
-
-
-
-Expires January 2002                                     [Page 32]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-   o  NBMA Link
-
-      This scenario could not be supported without changing the
-      SLP protocol to work with anycast addresses.  However, it is
-      not expected that this is a very important scenario.
-
-
-6.6.  Something New
-
-Any number of other mechanisms (e.g., HTTP, SNMP, etc.)  could
-also be extended, but it is expected that any other mechanism
-would take at least as long to deploy, and have no significant
-advantage over the other mechanisms evaluated above.
-
-
-7.  Recommendations
-
-Based on team discussion, and WG consensus at IETF 49, the
-recommendation for transport mechanism is to use site-scoped
-anycast.  That is, IANA should allocate a well-known site-local
-anycast address for DNS servers.
-
-No specific recommendation is made regarding using anycast for
-discovery-only or for actual name resolution.  However, we observe
-that choice can be made by individual sites as follows.  Nodes
-will use the anycast address to discover DNS-specific information
-such as the domain name, search path, and DNS server list.  If the
-DNS server list contains just the anycast address itself, the
-anycast address will also be used for name resolution.
-
-Based on subsequent team discussion, the recommendation to the WG
-regarding the content mechanism is to use DNS.  That is, the
-recommendation is that the WG should define the details of how the
-DNS server list, domain name, and search path, can be encoded in
-DNS records.  The team's initial recommendation is that the IPv6
-WG investigate whether SRV records are sufficient, and if not,
-then either TXT records or a new record type should be used.  It
-is believed that the information should and can be encoded in a
-single response message.
-
-Finally, it is recommended that the "Other stateful configuration"
-flag in the Router Advertisement be used to control whether to use
-DHCP or this mechanism.  That is, the analysis and recommendations
-in this document apply only to links where the "Other stateful
-configuration" flag is zero.
-
-
-
-
-
-Expires January 2002                                     [Page 33]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-8.  Appendix A: Summary Grid
-
-Figure 1 summarizes information on transport mechanisms:
-
-                 |Any(Disc)|Any(Res)|LnkM(Rtr)|LnkM(Gen)|SiteM
------------------+---------+--------+---------+---------+---------
-SW upgrades      |-/S/SR   |-/S/SR  |R        |R        |UR
------------------+---------+--------+---------+---------+---------
-Reconfig changes |S        |-       |R        |S        |-
------------------+---------+--------+---------+---------+---------
-New dependencies |-        |-       |router,  |linkmcast|multicast
-                 |         |        |linkmcast|         |routing,
-                 |         |        |         |         |linkmcast
------------------+---------+--------+---------+---------+---------
-Convergence time |fast     |per-rtg |fast     |fast     |fast
------------------+---------+--------+---------+---------+---------
-Can use IKE      |no       |no      |no       |no       |no
------------------+---------+--------+---------+---------+---------
-Standards work   |-/ipngwg |-/ipngwg|ipngwg   |ipngwg   |-
------------------+---------+--------+---------+---------+---------
-Deployable "now" |yes      |yes     |no       |no       |no
------------------+---------+--------+---------+---------+---------
-
-              Figure 1: Transport Mechanism Summary
-
-Key:
- / separates multiple deployment options
- - = No devices
- S = All DNS servers
-SR = All routers with directly-connected DNS servers
-UR = All routers which don't have multicast routing implemented
- R = All routers
-
-SW upgrades = what boxes, other than devices wanting to discover
-DNS servers, require software upgrades?
-
-Reconfig changes = what boxes need to be reconfigured when the set
-of DNS servers changes?
-
-New dependencies = what new dependencies are added?
-
-Convergence Time = how long does it take to contact a new DNS
-server when a server/link/router fails?  "Fast" = a device can
-immediately use an alternate server if reachable.  "Per-rtg" =
-Device must wait until routing converges for the unreachable
-
-
-
-
-
-Expires January 2002                                     [Page 34]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-address.
-
-Can use IKE = can IKE be used for key negotiation?
-
-Standards work = what WGs would be required to standardize new
-items?
-
-Deployable "now" = could a new client using this mechanism be
-deployed immediately, without requiring implementation of new code
-for routers or servers?
-
-Figure 2 summarizes information on content mechanisms:
-
-                  |DHCP      |DNS      |NIQ      |RA       |SLP
-------------------+----------+---------+---------+---------+---------
-Round trips used  |1         |1        |1        |1        |1
-------------------+----------+---------+---------+---------+---------
-Has own signatures|yes       |yes      |-        |no       |yes
-------------------+----------+---------+---------+---------+---------
-Has own key dist  |-         |yes      |-        |-        |-
-------------------+----------+---------+---------+---------+---------
-Standards work    |dhc       |dnsext?  |ipngwg   |ipngwg   |svrloc
-------------------+----------+---------+---------+---------+---------
-Need addl parser  |in servers|-        |yes      |-        |yes
-------------------+----------+---------+---------+---------+---------
-Generalizable     |yes       |yes      |yes      |-        |yes
-------------------+----------+---------+---------+---------+---------
-Deployable "now"  |no        |yes      |no       |no       |no
-------------------+----------+---------+---------+---------+---------
-
-               Figure 2: Content Mechanism Summary
-
-Round trips used = How many round trips are required?
-
-Has own signatures? = Does the content have its own signature
-facility?  (a "no" means it relies on IPsec)
-
-Standards work = what WGs would be required to standardize new
-items?
-
-Need addl parser = besides any parsers that a device must already
-implement to perform basic name resolution, does the mechanism
-introduce a requirement for another parser?
-
-Generalizable = can the mechanism be generalized to allow
-
-
-
-
-
-Expires January 2002                                     [Page 35]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-discovery of other types of information or services?
-
-Deployable "now" = could a new client using this mechanism be
-deployed immediately, without requiring implementation of new code
-for routers or servers?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires January 2002                                     [Page 36]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-9.  Authors' Addresses
-
-     Bernard Aboba
-     Microsoft
-     One Microsoft Way
-     Redmond, WA 98052, USA
-     Email: aboba@internaut.com
-
-     Jim Bound
-     Compaq Computer Corporation
-     110 Spitbrook Road ZK3-3/U14
-     Nashua, NH 03062-2698
-     Email: bound@zk3.dec.com
-
-     Steve Deering
-     Cisco Systems, Inc.
-     170 West Tasman Drive
-     San Jose, CA 95134-1706, USA
-     Email: deering@cisco.com
-
-     Erik Guttman
-     Sun Microsystems
-     Bahnstr. 2
-     74915 Waibstadt, Germany
-     Email: erik.guttman@sun.com
-
-     Jun-ichiro itojun HAGINO
-     Research Laboratory, Internet Initiative Japan Inc.
-     Takebashi Yasuda Bldg.,
-     3-13 Kanda Nishiki-cho,
-     Chiyoda-ku, Tokyo 101-0054, JAPAN
-     Email: itojun@iijlab.net
-
-     Robert M. Hinden
-     Nokia
-     313 Fairchild Drive
-     Mountain View, CA 94043, USA
-     Email: hinden@iprg.nokia.com
-
-     Tatuya JINMEI
-     Research and Development Center, Toshiba Corporation
-     1 Komukai Toshiba-cho, Kawasaki-chi
-     Kanagawa 212-8582
-     Japan
-     Email: jinmei@isl.rdc.toshiba.co.jp
-
-
-
-
-
-Expires January 2002                                     [Page 37]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-     Atsushi Onoe
-     Internet Systems Laboratory, IN Laboratories, Sony Corporation
-     6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001
-     Japan
-     Email: onoe@sm.sony.co.jp
-
-     Hesham Soliman
-     Ericsson Australia
-     61 Rigall St., Broadmeadows
-     Melbourne, Victoria 3047
-     Australia
-     Email: Hesham.Soliman@ericsson.com.au
-
-     David Thaler
-     Microsoft
-     One Microsoft Way
-     Redmond, WA 98052, USA
-     Email: dthaler@microsoft.com
-
-
-10.  References
-
-[ANYCAST]
-     Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
-     Service", RFC 1546, November 1993.
-
-[ADDRARCH]
-     Hinden, R., and S. Deering, "IP Version 6 Addressing
-     Architecture", RFC 2373, July 1998.
-
-[DHCPAUTH]
-     Droms, R., and W. Arbaugh, "Authentication for DHCP
-     Messages", draft-ietf-dhc-authentication-16.txt, January
-     2001.
-
-[DIFFSEC]
-     D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
-     Name System (DNS)", RFC 2539, March 1999.
-
-[DNSSEC]
-     D. Eastlake, "Domain Name System Security Extensions", RFC
-     2535, March 1999.
-
-[DOMSEARCH]
-     B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc-
-
-
-
-
-
-Expires January 2002                                     [Page 38]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-     domsearch-01.txt, December 2000.
-
-[HOST-ANYCAST]
-     Haberman, B., and D. Thaler, "Host-based Anycast using MLD",
-     draft-haberman-ipngwg-host-anycast-00.txt, February 2001.
-
-[IOS]
-     Cisco IOS Release 12.0 Configuration Guides,
-     http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/cbkixol.htm
-
-[ITOJUN-ANYCAST]
-     Jun-ichiro Hagino and K. Ettikan, "An analysis of IPv6
-     anycast", draft-itojun-ipv6-anycast-analysis-02.txt, February
-     2001.
-
-[MDNS]
-     Esibov, L., Aboba, B., and D. Thaler, "Multicast DNS", draft-
-     ietf-dnsext-mdns-00.txt, November 2000.
-
-[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
-     for IP Version 6 (IPv6)", RFC 2461, December 1998.
-
-[NODEINFO]
-     Matt Crawford, "IPv6 Node Information Queries", draft-ietf-
-     ipngwg-icmp-name-lookups-07.txt, August 2000.
-
-[RFC1034]
-     P. Mockapetris, "Domain Names - Concepts and Facilities", STD
-     13, RFC 1034, November 1987.
-
-[RFC1035]
-     P. Mockapetris, "Domain Names - Implementation and
-     Specifications", STD 13, RFC 1035, November 1987.
-
-[RIPMD5]
-     Baker, F., and R. Atkinson, "RIP-2 MD5 Authentication", RFC
-     2082, January 1997.
-
-[RIPNG]
-     Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
-     January 1997.
-
-[SLPv2]
-     Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
-     Location Protocol, Version 2", RFC 2608, June 1999.
-
-
-
-
-
-Expires January 2002                                     [Page 39]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-[SRV]
-     Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-     specifying the location of services (DNS SRV)", RFC 2782,
-     February 2000.
-
-[TSIG]
-     Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-     "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-     2845, May 2000.
-
-[TKEY]
-     D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)" RFC
-     2930, September 2000
-
-[TXT]
-     R. Rosenbaum, "Using the Domain Name System To Store
-     Arbitrary String Attributes", RFC 1464, May 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires January 2002                                     [Page 40]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-11.  Full Copyright Statement
-
-Copyright (C) The Internet Society (2001).  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."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires January 2002                                     [Page 41]
-
-
-
-
-
-Draft                       DDDT Report               January 2002
-
-
-
-Table of Contents
-
-
-1 Introduction ..............................................    2
-2 Requirements ..............................................    2
-3 Criteria for Evaluation ...................................    3
-4 Taxonomy ..................................................    4
-5 Transport Mechanisms ......................................    4
-5.1 Anycast for DNS server discovery only ...................    4
-5.1.1 Evaluation ............................................    7
-5.2 Anycast for name resolution .............................    9
-5.2.1 Configuration .........................................   10
-5.2.2 Actual use ............................................   10
-5.2.3 Evaluation ............................................   10
-5.3 Link-scoped multicast with router-only responses ........   13
-5.3.1 Evaluation ............................................   13
-5.4 Link-scoped multicast (with router assist) ..............   16
-5.4.1 Evaluation ............................................   16
-5.5 Site-scoped multicast ...................................   17
-5.5.1 Evaluation ............................................   19
-5.6 Hybrid ..................................................   21
-6 Message Content Mechanisms ................................   21
-6.1 DHCP ....................................................   21
-6.1.1 Evaluation ............................................   22
-6.2 DNS .....................................................   23
-6.2.1 Evaluation ............................................   23
-6.3 Node Information Query ..................................   25
-6.3.1 Evaluation ............................................   25
-6.4 RA Extensions ...........................................   26
-6.4.1 Evaluation ............................................   28
-6.5 SLP .....................................................   30
-6.5.1 Evaluation ............................................   30
-6.6 Something New ...........................................   33
-7 Recommendations ...........................................   33
-8 Appendix A: Summary Grid ..................................   34
-9 Authors' Addresses ........................................   37
-10 References ...............................................   38
-11 Full Copyright Statement .................................   41
-
-
-
-
-
-
-
-
-
-
-
-Expires January 2002                                     [Page 42]
-
diff --git a/Documentation/en/I-D/draft-ietf-ldapbis-url-01.txt b/Documentation/en/I-D/draft-ietf-ldapbis-url-01.txt
deleted file mode 100644
index 809b9703..00000000
--- a/Documentation/en/I-D/draft-ietf-ldapbis-url-01.txt
+++ /dev/null
@@ -1,637 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                Mark Smith, Editor
-Request for Comments: DRAFT               Netscape Communications Corp.
-Obsoletes: RFC 2255                                           Tim Howes
-                                                        Loudcloud, Inc.
-
-                                                            10 May 2001
-
-
-                          The LDAP URL Format
-                    <draft-ietf-ldapbis-url-01.txt>
-
-
-
-1.  Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups.  Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet- Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Discussion of this document should take place on the LDAP (v3)
-   Revison (ldapbis) Working Group mailing list <ietf-
-   ldapbis@openldap.org>.  After appropriate review and discussion, this
-   document will be submitted as a Standards Track replacement for RFC
-   2255.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-2.  Abstract
-
-   LDAP is the Lightweight Directory Access Protocol, defined in
-   [RFC2251bis], [RFC2252bis], and [RFC2253bis].  This document
-   describes a format for an LDAP Uniform Resource Locator.  The format
-   describes an LDAP search operation used to retrieve information from
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 1]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-   an LDAP directory, or, in the context of an LDAPv3 referral or
-   reference, the format describes a service where an LDAP operation may
-   be progressed.  Note:  not all of the parameters of the LDAP search
-   operation described in [RFC2251bis] can be expressed using the format
-   defined in this document.
-
-   This document specifies the LDAP URL format for version 3 of LDAP and
-   clarifies how LDAP URLs are resolved. This document also defines an
-   extension mechanism for LDAP URLs, so that future documents can
-   extend their functionality, for example, to provide access to new
-   LDAPv3 extensions as they are defined.
-
-   This document replaces RFC 2255. See Appendix A for a list of changes
-   relative to RFC 2255.
-
-   The key words "MUST", "MAY", and "SHOULD" used in this document are
-   to be interpreted as described in [RFC2119].
-
-3.  URL Definition
-
-   An LDAP URL begins with the protocol prefix "ldap" and is defined by
-   the following grammar, following the ABNF notation defined in
-   [RFC2234].
-
-       ldapurl    = scheme "://" [hostport] ["/" dn
-                    ["?" [attributes] ["?" [scope]
-                    ["?" [filter] ["?" extensions]]]]]
-       scheme     = "ldap"
-       hostport   = <hostport from Section 3.2.2 of [RFC2396]>
-       dn         = <distinguishedName from Section 3 of [RFC2253bis]>
-       attributes = attrdesc *("," attrdesc)
-       attrdesc   = <AttributeDescription from Section 4.1.5 of [RFC2251bis]> / "*"
-       scope      = "base" / "one" / "sub"
-       filter     = <filter from Section 4 of [RFC2254bis]>
-       extensions = extension *("," extension)
-       extension  = ["!"] extype ["=" exvalue]
-       extype     = oid / oiddescr
-       exvalue    = <LDAPString from section 4.1.2 of [RFC2251bis]>
-       oid        = <LDAPOID from section 4.1.2 of [RFC2251bis]>
-       oiddescr   = <name from section 3.2 of [LDAP-IANA]>
-
-   The "ldap" prefix indicates an entry or entries residing in the LDAP
-   server running on the given hostname at the given portnumber.
-
-   The dn is an LDAP Distinguished Name using the string format
-   described in [RFC2253bis]. It identifies the base object of the LDAP
-   search or the target of a non-search operation.
-
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 2]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-   The attributes construct is used to indicate which attributes should
-   be returned from the entry or entries.  Individual attrdesc names are
-   as defined for AttributeDescription in [RFC2251bis].
-
-   The scope construct is used to specify the scope of the search to
-   perform in the given LDAP server.  The allowable scopes are "base"
-   for a base object search, "one" for a one-level search, or "sub" for
-   a subtree search.
-
-   The filter is used to specify the search filter to apply to entries
-   within the specified scope during the search.  It has the format
-   specified in [RFC2254bis].
-
-   The extensions construct provides the LDAP URL with an extensibility
-   mechanism, allowing the capabilities of the URL to be extended in the
-   future. Extensions are a simple comma-separated list of type=value
-   pairs, where the =value portion MAY be omitted for options not
-   requiring it. Each type=value pair is a separate extension. These
-   LDAP URL extensions are not necessarily related to any of the LDAPv3
-   extension mechanisms. Extensions may be supported or unsupported by
-   the client resolving the URL. An extension prefixed with a '!'
-   character (ASCII 33) is critical. An extension not prefixed with a
-   '!' character is non-critical.
-
-   If an extension is supported by the client, the client MUST obey the
-   extension if the extension is critical. The client SHOULD obey
-   supported extensions that are non-critical.
-
-   If an extension is unsupported by the client, the client MUST NOT
-   process the URL if the extension is critical.  If an unsupported
-   extension is non-critical, the client MUST ignore the extension.
-
-   If a critical extension cannot be processed successfully by the
-   client, the client MUST NOT process the URL. If a non-critical
-   extension cannot be processed successfully by the client, the client
-   SHOULD ignore the extension.
-
-   The extension type (extype) MAY be specified using the oid form
-   (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension).  Use
-   of the oiddesc form SHOULD be restricted to registered object
-   identifier descriptive names.  See [LDAP-IANA] for registration
-   details and usage guidelines for descriptive names.
-
-   No LDAP URL extensions are defined in this document.  Other documents
-   or a future version of this document MAY define other extensions.
-
-   Note that characters that are not safe (e.g., spaces) (as defined in
-   section 2.1 of [RFC2396]), and the single Reserved character '?'
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 3]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-   occurring inside a dn, filter, or other element of an LDAP URL MUST
-   be escaped using the % method described in section 2.4 of [RFC2396].
-   If a comma character ',' occurs inside an extension value, the
-   character MUST also be escaped using the % method.
-
-
-4.  Defaults for Fields of the LDAP URL
-
-   Some fields of the LDAP URL are optional, as described above.  In the
-   absence of any other specification, the following general defaults
-   SHOULD be used when a field is absent.  Note:  other documents MAY
-   specify different defaulting rules; for example, section 4.1.11 of
-   [RFC2251bis] specifies a different rule for determining the correct
-   DN to use when it is absent in an LDAP URL that is returned as a
-   referral.
-
-   hostport
-      The default LDAP port is TCP port 389. If no hostport is given,
-      the client must have some apriori knowledge of an appropriate LDAP
-      server to contact.
-
-   dn
-      If no dn is given, the default is the zero-length DN, "".
-
-   attributes
-      If the attributes part is omitted, all user attributes of the
-      entry or entries should be requested (e.g., by setting the
-      attributes field AttributeDescriptionList in the LDAP search
-      request to a NULL list, or (in LDAPv3) by requesting the special
-      attribute name "*").
-
-   scope
-      If scope is omitted, a scope of "base" is assumed.
-
-   filter
-      If filter is omitted, a filter of "(objectClass=*)" is assumed.
-
-   extensions
-      If extensions is omitted, no extensions are assumed.
-
-
-5.  Examples
-
-   The following are some example LDAP URLs using the format defined
-   above.  The first example is an LDAP URL referring to the University
-   of Michigan entry, available from an LDAP server of the client's
-   choosing:
-
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 4]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-     ldap:///o=University%20of%20Michigan,c=US
-
-   The next example is an LDAP URL referring to the University of
-   Michigan entry in a particular ldap server:
-
-     ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
-
-   Both of these URLs correspond to a base object search of the
-   "o=University of Michigan,c=US" entry using a filter of
-   "(objectclass=*)", requesting all attributes.
-
-   The next example is an LDAP URL referring to only the postalAddress
-   attribute of the University of Michigan entry:
-
-     ldap://ldap1.example.net/o=University%20of%20Michigan,
-            c=US?postalAddress
-
-   The corresponding LDAP search operation is the same as in the
-   previous example, except that only the postalAddress attribute is
-   requested.
-
-   The next example is an LDAP URL referring to the set of entries found
-   by querying the given LDAP server on port 6666 and doing a subtree
-   search of the University of Michigan for any entry with a common name
-   of "Babs Jensen", retrieving all attributes:
-
-     ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
-            c=US??sub?(cn=Babs%20Jensen)
-
-   The next example is an LDAP URL referring to all children of the c=GB
-   entry:
-
-     ldap://ldap1.example.com/c=GB?objectClass?one
-
-   The objectClass attribute is requested to be returned along with the
-   entries, and the default filter of "(objectclass=*)" is used.
-
-   The next example is an LDAP URL to retrieve the mail attribute for
-   the LDAP entry named "o=Question?,c=US" is given below, illustrating
-   the use of the escaping mechanism on the reserved character '?'.
-
-     ldap://ldap2.example.com/o=Question%3f,c=US?mail
-
-   The next example illustrates the interaction between LDAP and URL
-   quoting mechanisms.
-
-     ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04)
-
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 5]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-   The filter in this example uses the LDAP escaping mechanism of \ to
-   encode three zero or null bytes in the value. In LDAP, the filter
-   would be written as (int=\00\00\00\04). Because the \ character must
-   be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
-
-   The following three URLs that are equivalent, assuming that the
-   defaulting rules specified in section 4 of this document are used:
-
-     ldap://ldap.example.net
-     ldap://ldap.example.net/
-     ldap://ldap.example.net/?
-
-   These three URLs all point to the root DSE on the ldap.example.net
-   server.
-
-The final two examples show use of a hypothetical, experimental bind
-name extension (the value associated with the extension is an LDAP DN).
-
-     ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
-     ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
-
-   The two URLs are the same, except that the second one marks the e-
-   bindname extension as critical. Notice the use of the % encoding
-   method to encode the commas within the distinguished name value in
-   the e-bindname extension.
-
-
-6.  Security Considerations
-
-   General URL security considerations discussed in [RFC2396] are
-   relevant for LDAP URLs.
-
-   The use of security mechanisms when processing LDAP URLs requires
-   particular care, since clients may encounter many different servers
-   via URLs, and since URLs are likely to be processed automatically,
-   without user intervention. A client SHOULD have a user-configurable
-   policy about which servers to connect to using which security
-   mechanisms, and SHOULD NOT make connections that are inconsistent
-   with this policy.  If a client chooses to reuse an existing
-   connection when resolving one or more LDAP URL, it MUST ensure that
-   the connection is compatible with the URL and that no security
-   policies are violated.
-
-   Sending authentication information, no matter the mechanism, may
-   violate a user's privacy requirements.  In the absence of specific
-   policy permitting authentication information to be sent to a server,
-   a client should use an anonymous connection.  (Note that clients
-   conforming to previous LDAP URL specifications, where all connections
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 6]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-   are anonymous and unprotected, are consistent with this
-   specification; they simply have the default security policy.)  Simply
-   opening a connection to another server may violate some users'
-   privacy requirements, so clients should provide the user with a way
-   to control URL processing.
-
-   Some authentication methods, in particular reusable passwords sent to
-   the server, may reveal easily-abused information to the remote server
-   or to eavesdroppers in transit, and should not be used in URL
-   processing unless explicitly permitted by policy.  Confirmation by
-   the human user of the use of authentication information is
-   appropriate in many circumstances.  Use of strong authentication
-   methods that do not reveal sensitive information is much preferred.
-   If the URL represents a referral for an update operation, strong
-   authentication methods SHOULD be used.  Please refer to the Security
-   Considerations section of [RFC2829bis] for more information.
-
-   The LDAP URL format allows the specification of an arbitrary LDAP
-   search operation to be performed when evaluating the LDAP URL.
-   Following an LDAP URL may cause unexpected results, for example, the
-   retrieval of large amounts of data, the initiation of a long-lived
-   search, etc.  The security implications of resolving an LDAP URL are
-   the same as those of resolving an LDAP search query.
-
-7.  Acknowledgements
-
-   The LDAP URL format was originally defined at the University of
-   Michigan. This material is based upon work supported by the National
-   Science Foundation under Grant No. NCR-9416667. The support of both
-   the University of Michigan and the National Science Foundation is
-   gratefully acknowledged.
-
-   This document is an update to RFC 2255 by Tim Howes and Mark Smith.
-   Changes included in this revised specification are based upon
-   discussions among the authors, discussions within the LDAP (v3)
-   Revision Working Group (ldapbis), and discussions within other IETF
-   Working Groups.  The contributions of individuals in these working
-   groups is gratefully acknowledged.  Several people in particular have
-   made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
-   Kurt Zeilenga, and Jim Sermersheim deserve special thanks for their
-   contributions.
-
-8.  References
-
-   [LDAP-IANA] IETF LDAPBis WG, "IANA Considerations for LDAP", a work
-   in progress.
-
-   [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 7]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-   Requirement Levels," RFC 2119, March 1997.
-
-   [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
-   Specifications:  ABNF", RFC 2234, November 1997.
-
-   [RFC2251bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
-   (v3)", a work in progress.
-
-   [RFC2252bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
-   (v3): Attribute Syntax Definitions", a work in progress.
-
-   [RFC2253bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
-   (v3): UTF-8 String Representation of Distinguished Names", a work in
-   progress.
-
-   [RFC2254bis] IETF LDAPBis WG, "A String Representation of LDAP Search
-   Filters", a work in progress.
-
-   [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
-   RFC 2279, January 1998.
-
-   [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
-   Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
-   [RFC2829bis] IETF LDAPBis WG, "Authentication Methods for LDAP", a
-   work in progress.
-
-
-9.  Authors' Address
-
-   Mark Smith, Editor
-   Netscape Communications Corp.
-   Mailstop USCA17-201
-   4170 Network Circle
-   Santa Clara, CA 95054
-   USA
-   +1 650 937-3477
-   mcs@netscape.com
-
-   Tim Howes
-   Loudcloud, Inc.
-   599 N. Mathilda Ave.
-   Sunnyvale, CA 94086
-   USA
-   +1 408 744-7509
-   howes@loudcloud.com
-
-
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 8]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  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.
-
-
-11.  Appendix A: Changes Since RFC 2255
-
-11.1.  Technical Changes
-
-   "URL Definition" section: added missing "*" as an alternative for the
-   attrdesc part of the URL.  It is believed that existing
-   implementations of RFC 2255 already support this.  Added angle
-   brackets around free-form prose in the "dn", "hostport", "attrdesc",
-   "filter", and "exvalue" rules.  Changed the ABNF for ldapurl to group
-   the dn component with the preceding slash.  Changed the extype rule
-   to be an LDAPOID from RFC2251bis or an OID description from LDAP-
-   IANA.  Changed the text about extension types so it references LDAP-
-   IANA.  Reordered rules to more closely follow the order the elements
-   appear in the URL.
-
-   "Bindname Extension": removed due to lack of known implementations.
-
-
-
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 9]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-11.2.  Editorial Changes
-
-   "Abstract" section: changed the text indicate that RFC 2255 is
-   replaced by this document (instead of RFC 1959).  Added text to
-   indicate that LDAP URLs are used for references and referrals.  Fixed
-   typo (replaced the nonsense phrase "to perform to retrieve" with
-   "used to retrieve").  Added a note to let the reader know that not
-   all of the parameters of the LDAP search operation described in
-   [RFC2251bis] can be expressed using this format.
-
-   IESG Note: removed note about lack of satisfactory mandatory
-   authentication mechanisms.
-
-   "URL Definition" section: removed second copy of ldapurl grammar and
-   following two paragraphs (editorial error in RFC 2255).  Fixed line
-   break within '!' sequence.  Reworded last paragraph to clarify which
-   characters must be URL escaped.   Added text to indicate that LDAP
-   URLs are used for references and referrals.  Added text that refers
-   to the ABNF from RFC 2234.
-
-   "Defaults for Fields of the LDAP URL" section: added; formed by
-   moving text about defaults out of the "URL Definition" section.
-
-   "URL Processing" section: clarified that connections MAY be reused
-   only if the open connection is compatible with the URL.  Added text
-   to indicate that use of security services is encouraged and that they
-   SHOULD be used when updates are involved.  Removed "dn" from
-   discussion of authentication methods.  Added note that the client MAY
-   interrogate the server to determine the most appropriate method.
-
-   "Examples" section: Modified examples to use example.com and
-   example.net hostnames.  Added missing '?' to the LDAP URL example
-   whose filter contains three null bytes.  Removed space after one
-   comma within a DN.  Revised the bindname example to use e-bindname.
-   Added some examples to show URL equivalence with respect to the dn
-   portion of the URL.
-
-   "Security Considerations" section: Added a note about connection
-   reuse.  Added a note about using strong authentication methods for
-   updates.  Added a reference to RFC 2829.  Added note that simply
-   opening a connection may violate some users' privacy requirements.
-
-   "Acknowledgements" section: added statement about this being an
-   update to RFC 2255.  Added added Kurt Zeilenga and Jim Sermersheim.
-
-   "References" section: changed from [1] style to [RFC2251bis] style
-   throughout the document.  Added references to RFCs 2234 and 2829.
-   Updated RFC 1738 references to the appropriate sections within RFC
-
-
-
-Smith & Howes      Intended Category: Standards Track          [Page 10]
-
-INTERNET-DRAFT            The LDAP URL Format                10 May 2001
-
-
-   2396.  Updated the references to refer to LDAPBis WG documents.
-   Added a reference to the LDAP IANA document.
-
-   Header and "Authors' Addresses" sections: added "editor" next to Mark
-   Smith's name.  Updated affiliation and contact information.
-
-   Copyright: updated the year.
-
-   "Table of Contents" section: added.
-
-
-12.  Appendix B: Changes Since Previous Document Revision
-
-   This appendix lists all changes relative to the last published
-   revision, draft-ietf-ldapbis-url-00.txt.  Note that these changes are
-   also included in Appendix A, but are included here for those who have
-   already reviewed draft-ietf-ldapbis-url-00.txt.
-
-
-12.1.  Technical Changes
-
-   "URL Definition" section: changed the ABNF for ldapurl to group the
-   dn component with the preceding slash.  Changed the extype rule to be
-   is an LDAPOID from RFC2251bis or an OID description from LDAP-IANA.
-   Changed the text about extension types so it references LDAP-IANA.
-
-   "Bindname Extension": removed due to lack of known implementations.
-
-
-
-12.2.  Editorial Changes
-
-   "Examples" section: revised the bindname example to use e-bindname
-   and added some examples to show URL equivalence with respect to the
-   dn portion of the URL.
-
-   "Appendix C: Loose Ends": removed this section entirely.
-
-   References: updated references to refer to LDAPBis WG documents.
-   Added a reference to the LDAP IANA document.
-
-
-This Internet Draft expires on 10 November 2001.
-
-
-
-
-
-
-
-
-Smith & Howes      Intended Category: Standards Track          [Page 11]
-
-
-
-1.     Status of this Memo............................................1
-2.     Abstract.......................................................1
-3.     URL Definition.................................................2
-4.     Defaults for Fields of the LDAP URL............................4
-5.     Examples.......................................................4
-6.     Security Considerations........................................6
-7.     Acknowledgements...............................................7
-8.     References.....................................................7
-9.     Authors' Address...............................................8
-10.    Full Copyright Statement.......................................9
-11.    Appendix A: Changes Since RFC 2255.............................9
-11.1.     Technical Changes...........................................9
-11.2.     Editorial Changes...........................................10
-12.    Appendix B: Changes Since Previous Document Revision...........11
-12.1.     Technical Changes...........................................11
-12.2.     Editorial Changes...........................................11
diff --git a/Documentation/en/I-D/draft-ietf-mailext-mail-attributes-07.txt b/Documentation/en/I-D/draft-ietf-mailext-mail-attributes-07.txt
deleted file mode 100644
index d04db73c..00000000
--- a/Documentation/en/I-D/draft-ietf-mailext-mail-attributes-07.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-
-
-A new Request for Comments is now available in online RFC libraries.
-
-
-        RFC 2076:
-
-        Title:      Common Internet Message Headers
-        Author:     J. Palme
-        Date:       February 1997
-        Mailbox:    jpalme@dsv.su.se
-        Pages:      27
-        Characters: 47639
-        Updates/Obsoletes: None
-
-        URL:        ftp://ds.internic.net/rfc/rfc2076.txt
-
-
-This memo contains a table of commonly occurring headers in headings
-of e-mail messages. This document is a product of the Mail Extensions
-Working Group of the IETF.
-
-This memo provides information for the Internet community.  This memo
-does not specify an Internet standard of any kind.  Distribution of
-this memo is unlimited.
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@CNRI.RESTON.VA.US.  Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@ISI.EDU.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@ISI.EDU with the message body 
-help: ways_to_get_rfcs.  For example:
-
-        To: rfc-info@ISI.EDU
-        Subject: getting rfcs
-
-        help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to admin@DS.INTERNIC.NET.  Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.
-
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@ISI.EDU.  Please consult RFC 1543, Instructions to RFC
-Authors, for further information.
-
-
-Joyce K. Reynolds and Mary Kennedy
-USC/Information Sciences Institute
-
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt b/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt
deleted file mode 100644
index 2cad09fa..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt
+++ /dev/null
@@ -1,562 +0,0 @@
-
-
-
-
-
-
-Internet Draft                                                 T. Hansen
-draft-ietf-msgtrk-model-04.txt                         AT&T Laboratories
-Valid for six months                                    November 6, 2001
-
-
-
-                Message Tracking Model and Requirements
-
-                    <draft-ietf-msgtrk-model-04.txt>
-
-                         Authors' version: 1.14
-
-     Status of this Memo
-
-     This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC2026.
-
-     Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other documents at
-any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed on the MSGTRK working
-group mailing list, ietf-msgtrk@imc.org.  To subscribe, send a message
-with the word "subscribe" in the body (on a line by itself) to the
-address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
-be found at http://www.ietf.org/archive/msgtrk.
-
-Copyright Notice
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can I track
-the messages?  Message tracking is the ability to find out the path that
-a particular message has taken through a messaging system and the
-current routing status of that message.  This document provides a model
-
-
-
-Hansen,Lin                                                      [Page 1]
-
-Internet Draft  Message Tracking Model and Requirements November 6, 2001
-
-
-of message tracking that can be used for understanding the Internet-wide
-message infrastructure and to further enhance those capabilities to
-include message tracking, as well as requirements for proposed message
-tracking solutions.
-
-1.  Problem Statement
-
-     Consider sending a package through a package delivery company.
-Once you've sent a package, you would like to be able to find out if the
-package has been delivered or not, and if not, where that package
-currently is and what its status is.  Note that the status of a package
-may not include whether it was delivered to its addressee, but just the
-destination.  Many package carriers provide such services today, often
-via a web interface.
-
-     Message tracking extends that capability to the Internet-wide mes-
-sage infrastructure, analogous to the service provided by package car-
-riers:  the ability to quickly locate where a message (package) is, and
-to determine whether or not the message (package) has been delivered to
-its final destination.  An Internet-standard approach will allow the
-development of message tracking applications that can operate in a
-multi-vendor messaging environment, and will encourage the operation of
-the function across administrative boundaries.
-
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS].
-
-2.  Definitions
-The following terms are relevant to message tracking.  The terms Track-
-ing User Agent and Tracking Server are new, while all other terms have
-been collected here from other sources.
-
-     Originating Mail User Agent (MUA)
-               The originating mail user agent is the software used to
-               compose and originate a message.  It is the software sit-
-               ting on a person's desktop.
-
-     Originating Mail Submission Agent (MSA)
-               The Mail Submission Agent accepts a message from a User
-               Agent, adds or modifies it as required for Internet stan-
-               dards and/or site policy, and injects the message into
-               the network.  The MSA may be the initial MTA or may hand
-               off the message to an MTA.
-
-     Message Transfer Agent (MTA)
-               A Message Transfer Agent accepts a message and moves it
-               forward towards its destination.  That destination may be
-
-
-
-Hansen,Lin                                                      [Page 2]
-
-Internet Draft  Message Tracking Model and Requirements November 6, 2001
-
-
-               local or reached via another MTA.  It may use a local
-               queue to store the message before transferring it
-               further.  Any MTA may generate a Non-Delivery Notifica-
-               tion.
-
-     Intermediate Message Transfer Agent (MTA)
-               An Intermediate MTA is an MTA that accepts a message for
-               transfer somewhere else.
-
-     Final Message Transfer Agent (MTA)
-               A Final MTA is an MTA that accepts a message for local
-               delivery.  It is the final place that a message is
-               accepted.  The final MTA is what sends any Delivery
-               Status Notificatons (DSNs).  (Intermediate MTA's may also
-               send a DSN if it relays to a non-DSN aware MTA.)
-
-     Foreign Message Transfer Agent
-               A foreign MTA provides delivery of messages using other
-               protocols than those specified for Internet mail, such as
-               an X.400 mail system.
-
-     Gateway Message Transfer Agent (GW-MTA)
-               A gateway MTA accepts a message for transfer to a foreign
-               MTA outside of the Internet protocol space.
-
-     Local Delivery Agent (LDA)
-               The local Delivery Agent delivers the message to the
-               local message store.  (The MTA and LDA are often combined
-               into the same program.)
-
-     Delivery Status Notification (DSN)
-               A Delivery Status Notification [RFC-DSN] is produced by
-               an MTA when a message is unsuccessfully delivered, either
-               to its next hop or the final message store, or when it is
-               successfully delivered, either to a foreign MTA, to a
-               local delivery agent, or a non-DSN aware MTA.  Positive
-               notifications are only performed [RFC-ESMTP-DSN] when
-               specifically requested.
-
-     Non-Delivery Notification (NDN)
-               A non-delivery notification is a special form of DSN
-               indicating unsuccessful delivery.
-
-     Message Disposition Notification (MDN)
-               A Message Disposition Notification is used to report the
-               disposition of a message after it has been successfully
-               delivered to a recipient.
-
-
-
-
-Hansen,Lin                                                      [Page 3]
-
-Internet Draft  Message Tracking Model and Requirements November 6, 2001
-
-
-     Tracking User Agent (TUA)
-               A tracking user agent wants to find information on a mes-
-               sage on the behalf of a user.  It is the requestor or
-               initiator of such a request.  (The MUA and TUA could be
-               combined into the same program.)
-
-     Tracking Server
-               A tracking server provides tracking information to a
-               tracking client.  It is the repository of the information
-               about a message for the traversal through a particular
-               MTA.  (The tracking server and MTA may run on the same
-               system.)
-
-3.  Entities
-
-     The entities involved in message tracking are:  message user
-agents, message submission agents, message transfer agents, tracking
-user agents and tracking servers.
-
-4.  Requirements
-
-     These are requirements that any message tracking solution must be
-able to satisfy:
-
-     The message tracking solution:
-
-     **   MUST scale to the internet.
-
-     **   MUST be easy to deploy.
-
-     **   SHOULD maximize the reuse of existing, already deployed tech-
-          nology and infrastructure.
-
-     **   If possible, SHOULD extend existing protocols and not invent
-          new ones.
-
-     **   SHOULD have a low implementation cost.  (This makes it easy to
-          incorporate into existing products.)
-
-     **   MUST restrict tracking of a message to the originator of the
-          message (or a delegate).
-
-     **   MUST be able to do authentication.
-
-     **   MAY allow an originator to delegate this responsibility to a
-          third party.
-
-     **   SHOULD have the property that they would allow per-message
-
-
-
-Hansen,Lin                                                      [Page 4]
-
-Internet Draft  Message Tracking Model and Requirements November 6, 2001
-
-
-          delegation of the tracking responsibility.
-
-     **   MUST require a tracking user agent to prove that they are per-
-          mitted to request the tracking information.
-
-     **   MUST be able to uniquely identify messages.
-
-     **   MUST require every message to have unique identification.
-
-5.  Interaction Models
-
-     There are several models by which tracking of messages can be
-enabled, by which messages can be tracked, and by which information can
-be requested and gathered.
-
-5.1.  Tracking Enabling Models
-
-     Either the envelope or message header must contain enough informa-
-tion to track a message and securely retrieve information about the mes-
-sage.  Any message that does not have enough information to track it is
-by definition not trackable.
-
-     If there is not enough information available in current standard
-envelopes or message headers, then the current standards will need to be
-extended.  Either the MUA or MSA must determine the additional informa-
-tion and enable the tracking by adding the additional information to
-either the envelope or header.
-
-     This leads to two tracking enabling models:  passive enabling and
-active enabling.
-
-5.1.1.  Passive Enabling Model
-The "passive enabling" model assumes that there is sufficient informa-
-tion available.  No UA or MSA interaction occurs to turn tracking on; it
-is on by default.
-
-5.1.2.  Active Enabling Model
-
-     The "active  enabling" model requires that the MUA and MSA exchange
-information when the message is submitted.  This exchange indicates that
-logging of the message's traversal should be performed, as well as pro-
-viding enough additional information to allow the message to be tracked.
-This information will need to be passed on to subsequent MTAs as needed.
-
-5.2.  Tracking Request Models
-There are several models by which tracking information may be requested.
-
-
-
-
-
-Hansen,Lin                                                      [Page 5]
-
-Internet Draft  Message Tracking Model and Requirements November 6, 2001
-
-
-5.2.1.  Passive Request Model
-
-     The "passive request" model requires active enabling to indicate
-that some form of tracking is to be performed.  The tracking information
-can be sent back immediately (as a form of telemetry) or sent to a 3rd
-party for later retrieval.
-
-5.2.2.  Passive Request Tracking Information
-
-     Forms of passive tracking information that could potentially be
-requested are  as  follows.  Note that mechanisms already exist for
-requesting the information marked with a (+).  The references for such
-mechanisms are listed at the end of each such entry.
-
-     **   send a DSN of a message arriving at an intermediate MTA
-
-     **   (+) send a DSN of a message being rejected while at an inter-
-          mediate MTA [RFC-DSN]
-
-     **   (+) send a DSN of a message leaving an intermediate MTA and
-          going to another MTA [RFC-DELIVER-BY]
-
-     **   send a DSN of a message arriving at a final MTA
-
-     **   (+) send a DSN of a message being rejected while at a final
-          MTA [RFC-DSN]
-
-     **   (+) send a DSN of a message being delivered to a user's mes-
-          sage store [RFC-DSN]
-
-     **   (+) send a DSN of a message being delivered to a foreign MTA
-          [RFC-DSN]
-
-     **   (+) send an MDN of a message being read by an end user [RFC-
-          MDN]
-
-5.3.  Active Request Model
-
-     The "active request" model requires an active query by a user's
-user agent to the MSA, intermediate MTAs and final MTA, or to a third
-party, to find the message's status as known by that MTA.  Active
-request will work with either passive enabling or active enabling.
-
-5.3.1.  Server Chaining vs. Server Referrals
-When a tracking server has been asked for tracking information, and the
-message has been passed on to another MTA of which this tracking server
-has no tracking knowledge, there are two modelling choices:
-
-
-
-
-Hansen,Lin                                                      [Page 6]
-
-Internet Draft  Message Tracking Model and Requirements November 6, 2001
-
-
-     **   the first tracking server will contact the next tracking
-          server to query for status and pass back the combined status
-          (server chaining), or
-
-     **   the first tracking server will return the address of the next
-          MTA and the tracking client has the responsibility of contact-
-          ing the next tracking server (server referrals).
-
-5.3.2.  Active Request Tracking Information
-Forms of active tracking information that could potentially be requested
-are as follows.  (Note that no mechanisms currently exist for requesting
-such information.)
-
-     **   the message has been queued for later delivery
-
-     **   the message was delivered locally
-
-     **   the message was delivered to another MTA,
-
-     **   the message was delivered to a foreign MTA
-
-     **   ask a different tracking server,
-
-     **   I know but can't tell you,
-
-     **   I don't know.
-
-5.4.  Combining DSN and MDN Information with Message Tracking Informa-
-tion
-
-     The information that would be retrieved by message tracking and the
-information that is returned for DSN and MDN requests all attempt to
-answer the question of "what happened to message XX"?  The information
-provided by each is complementary in nature, but similar.  A tracking
-user agent could use all three possible information  sources  to present
-a total view of the status of a message.
-
-     Both DSN and MDN notifications utilize the formats defined by RFC
-1892 [RFC-REPORT].  This suggests that the information returned by mes-
-sage tracking solutions should also be similar.
-
-6.  Security
-
-     This is a security model for message identification and authentica-
-tion that could be deployed.  (There may be others.)
-
-     A Tracking User Agent must prove that they are permitted to request
-tracking information about a message.  Every [RFC-822]-compliant message
-
-
-
-Hansen,Lin                                                      [Page 7]
-
-Internet Draft  Message Tracking Model and Requirements November 6, 2001
-
-
-is supposed to contain a Message-Id header.  One possible mechanism is
-for the originator to calculate a one-way hash A from the message ID +
-time stamp + a per-user secret.  The user then calculates another one-
-way hash B to be the hash of A.  The user includes B in the submitted
-message, and retains A.  Later, when the user makes a message tracking
-request to the messaging system or tracking entity, it submits A in the
-tracking request.  The entity receiving the tracking request then uses A
-to calculate B, since it was already provided B, verifying that the
-requestor is authentic.  In summary,
-
-     A = H(message ID + time stamp + secret)
-
-     B = H(A)
-
-Another possible mechanism for A is to ignore the message ID and time
-stamp and just use a one-way hash from a large (>128 bits) random
-number.  B would be calculated as before.  In summary,
-
-     A = H(large-random-number)
-
-     B = H(A)
-
-This is similar in technique to the methods used for One-Time Passwords
-[RFC-OTP].  The success of these techniques is dependent on the random-
-ness of the per-user secret or the large random number, which can be
-incredibly difficult in some environments.
-
-     If the originator of a message were to delegate his or her tracking
-request to a third party by sending it A, this would be vulnerable to
-snooping over unencrypted sessions.  The user can decide on a message-
-by-message basis if this risk is acceptable.
-
-7.  References
-
-
-     [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
-               Text Messages", STD 11, RFC 822, UDEL, August 1982.
-
-     [RFC-DELIVER-BY]
-               Newman, D., "Deliver By SMTP Service Extension", draft-
-               newman-deliver-02.txt, Innosoft, January 1999.
-
-     [RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible Message For-
-               mat for Delivery Status Notifications", RFC 1894, Univer-
-               sity of Tennessee, Octel Network Services, January 1996.
-
-     [RFC-ESMTP-DSN]
-               Moore, K., "SMTP Service Extension for Delivery Status
-
-
-
-Hansen,Lin                                                      [Page 8]
-
-Internet Draft  Message Tracking Model and Requirements November 6, 2001
-
-
-               Notifications", RFC 1891, University of Tennessee, Janu-
-               ary 1996.
-
-     [RFC-KEYWORDS]
-               Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", RFC 2119, Harvard University, March
-               1997.
-
-     [RFC-MDN] Fajman, R., "An Extensible Message Format for Message
-               Disposition Notifications", RFC 2298, National Institutes
-               of Health, March 1998.
-
-     [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw, M., "A One-Time
-               Password System", RFC 2289, Bellcore, Kaman Sciences Cor-
-               poration, Nesser & Nesser Consulting, Bellcore, February
-               1998.
-
-     [RFC-REPORT]
-               Vaudreuil, G., "The Multipart/Report Content Type for the
-               Reporting of Mail System Administrative Messages", RFC
-               1892, Octel Network Services, January 1996.
-
-     [RFC-SMTP]Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-               821, USC/Information Sciences Institute, August 1982.
-
-8.  Acknowledgements
-
-     This document is the product of input from many people and many
-sources, including all of the members of the Message Tracking Working
-Group.  It owes much to earlier work by Gordon Jones, Bruce Ernst and
-Greg Vaudreuil.  In particular, I'd like to also thank Ken Lin for his
-considerable contributions to the early drafts.
-
-9.  Authors' Addresses
-     Tony Hansen
-     AT&T Laboratories
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1 732 576-3207
-     E-Mail: tony@att.com
-
-10.  Full Copyright Statement
-
-     Copyright (C) The Internet Society (1999).  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
-
-
-
-Hansen,Lin                                                      [Page 9]
-
-Internet Draft  Message Tracking Model and Requirements November 6, 2001
-
-
-assist in its implmentation may be prepared, copied, published and dis-
-tributed, 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 organisations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet Stan-
-dards 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.
-
-     This document expires May 6, 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hansen,Lin                                                     [Page 10]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-04.txt b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-04.txt
deleted file mode 100644
index 733bb4dc..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-04.txt
+++ /dev/null
@@ -1,1066 +0,0 @@
-
-
-
-
-
-
-Internet Draft                                                 T. Hansen
-draft-ietf-msgtrk-mtqp-04.txt                          AT&T Laboratories
-Valid for six months                                   November 20, 2001
-
-
-
-                    Message Tracking Query Protocol
-
-                    <draft-ietf-msgtrk-mtqp-04.txt>
-
-                         Authors' version: 1.10
-
-     Status of this Memo
-
-     This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC2026.
-
-     Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other documents at
-any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed on the MSGTRK working
-group mailing list, ietf-msgtrk@imc.org.  To subscribe, send a message
-with the word "subscribe" in the body (on a line by itself) to the
-address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
-be found at http://www.ietf.org/archive/msgtrk.
-
-Copyright Notice
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can I track
-the messages?  Message tracking is the ability to find out the path that
-a particular message has taken through a messaging system and the
-current routing status of that message.  This document describes the
-
-
-
-Hansen                                                          [Page 1]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-Message Tracking Query Protocol that is used in conjunction with exten-
-sions to the ESMTP protocol to provide a complete message tracking solu-
-tion for the Internet.
-
-1.  Introduction
-
-     The Message Tracking Models and Requirements document [DRAFT-
-TRACK-MODEL] discusses the models that message tracking solutions could
-follow, along with requirements for a message tracking solution that can
-be used with the Internet-wide message infrastructure.  This memo and
-its companions, [DRAFT-TRACK-ESMTP] and [DRAFT-TRACK-TSN], describe a
-complete message tracking solution that satisfies those requirements.
-The memo [DRAFT-TRACK-ESMTP] defines an extension to the SMTP service
-that provides the information necessary to track messages.  This memo
-defines a protocol that can be used to query the status of messages that
-have been transmitted on the Internet via SMTP.  The memo [DRAFT-TRACK-
-TSN] describes the message/tracking-status [RFC-MIME] media type that is
-used to report tracking status information.  Using the model document's
-terminology, this solution uses active enabling and active requests with
-both request and chaining referrals.
-
-1.1.  Terminology
-
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in [RFC-KEYWORDS].
-
-     All syntax descriptions use the ABNF specified by [RFC-ABNF].  Ter-
-minal nodes not defined elsewhere in this document are defined in [RFC-
-ABNF], [RFC-URI], [DRAFT-TRACK-ESMTP] or [RFC-SMTPEXT].
-
-1.2.  Changes Made for -04
-
-     Reworked the SRV lookup description.
-
-     Other comments from the list.
-
-     Changes to the ABNF.
-
-     Changed "must" to "MUST" in section 4.
-
-     Changed "may" to "MAY" in section 4.
-
-     More examples.
-
-     Eliminated the registry of vnd. options.
-
-     Eliminated lots of unused references.
-
-
-
-Hansen                                                          [Page 2]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-1.3.  Changes Made for -03
-
-     Changed references.
-
-     Worked on error codes.
-
-     Made examples more real with secrets and hashes.
-
-     Fixes to examples.
-
-     Added dot-stuffed example.
-
-     Additional TLS info.
-
-     Better Security Considerations section.
-
-1.4.  Changes Made for -02
-
-     This section will be removed before publication.
-
-     Provided information on lookup for an MTQP server: SRV MTQP, then
-MX, then A.
-
-     Provided a section on firewall considerations
-
-     Provided a section on service DNS considerations
-
-     At IANA's request, left the port number as XXXX and added more
-information on the option registry.
-
-     Added text on various error conditions and fixed ABNF for error
-response codes.
-
-     Fleshed out the tracking examples.
-
-2.  Basic Operation
-
-     The Message Tracking Query Protocol (MTQP) is similar to many other
-line-oriented Internet protocols, such as [POP3] and [NNTP].  Initially,
-the server host starts the MTQP service by listening on TCP port XXXX
-(TBD by IANA).
-
-     When an MTQP client wishes to make use of the message tracking ser-
-vice, it establishes a TCP connection with the server host, as recorded
-from the initial message submission or as returned by a previous track-
-ing request.  To find the server host, the MTQP client first does an SRV
-lookup for the server host using DNS SRV records, with a service name of
-"mtqp" and a protocol name of "tcp", as in _mtqp._tcp.smtp3.example.com.
-
-
-
-Hansen                                                          [Page 3]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-(See the "Usage rules" section in [RFC-SRV] for details.)  If the SRV
-records do not exist, the MTQP client then does an address record lookup
-for the server host.
-
-     When the connection is established, the MTQP server sends a greet-
-ing.  The MTQP client and MTQP server then exchange commands and
-responses (respectively) until the connection is closed or aborted.
-
-2.1.  Tracking Service DNS Considerations
-
-     Because of the ways server host lookups are performed, many dif-
-ferent tracking server host configurations are supported.
-
-     A mail system that uses a single mail server host and has the MTQP
-server host on the same server host will most likely have a single MX
-record pointing at the server host, and if not, will have an A record.
-Both mail and MTQP clients will access that host directly.
-
-     A mail system that uses a single mail server host, but wants track-
-ing queries to be performed on a different machine, MUST have an SRV
-MTQP record pointing at that different machine.
-
-     A mail system that uses multihomed mail servers has two choices for
-providing tracking services: either all mail servers must be running
-tracking servers that are able to retrieve information on all messages,
-or the tracking service must be performed on one (or more) machine(s)
-that are able to retrieve information on all messages.  In the former
-case, no additional DNS records are needed beyond the MX records already
-in place for the mail system.  In the latter case, SRV MTQP records are
-needed that point at the machine(s) that are running the tracking ser-
-vice.  In both cases, note that the tracking service MUST be able to
-handle the queries for all messages accepted by that mail system.
-
-2.2.  Commands
-
-     Commands in MTQP consist of a case-insensitive keyword, possibly
-followed by one or more parameters.  All commands are terminated by a
-CRLF pair.  Keywords and parameters consist of printable ASCII charac-
-ters.  Keywords and parameters are separated by whitespace (one or more
-space or tab characters).  A command line is limited to 998 characters
-before the CRLF.
-
-2.3.  Responses
-
-     Responses in MTQP consist of a status indicator that indicates suc-
-cess or failure.  Successful commands may also be followed by additional
-lines of data.  All response lines are terminated by a CRLF pair and are
-limited to 998 characters before the CRLF.  There are several status
-
-
-
-Hansen                                                          [Page 4]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-indicators:  "+OK" indicates success; "+OK+" indicates a success fol-
-lowed by additional lines of data, a multi-line success response; "-
-TEMP" indicates a temporary failure; "-ERR" indicates a permanent
-failure; and "-BAD" indicates a protocol error (such as for unrecognized
-commands).
-
-     A status indicator MAY be followed by a series of machine-parsable,
-case-insensitive response information giving more data about the errors.
-These are separated from the status indicator and each other by a single
-slash character ("/", decimal code 47).  Following that, there MAY be
-white space and a human-readable text message.  The human-readable text
-message is not intended to be presented to the end user, but should be
-appropriate for putting in a log for use in debugging problems.
-
-     In a multi-line success response, each subsequent line is ter-
-minated by a CRLF pair and limited to 998 characters before the CRLF.
-When all lines of the response have been sent, a final line is sent con-
-sisting of a single period (".", decimal code 046) and a CRLF pair.  If
-any line of the multi-line response begins with a period, the line is
-"dot-stuffed" by prepending the period with a second period.  When exa-
-mining a multi-line response, the client checks to see if the line
-begins with a period.  If so, and octets other than CRLF follow, the
-first octet of the line (the period) is stripped away.  If so, and if
-CRLF immediately follows the period, then the response from the MTQP
-server is ended and the line containing the ".CRLF" is not considered
-part of the multi-line response.
-
-     An MTQP server MUST respond to an unrecognized, unimplemented, or
-syntactically invalid command by responding with a negative -BAD status
-indicator.  A server MUST respond to a command issued when the session
-is in an incorrect state by responding with a negative -ERR status indi-
-cator.
-
-2.4.  Optional Timers
-
-     An MTQP server MAY have an inactivity autologout timer.  Such a
-timer MUST be of at least 10 minutes in duration.  The receipt of any
-command from the client during that interval should suffice to reset the
-autologout timer.  An MTQP server MAY limit the number of commands,
-unrecognized commands, or total connection time, or MAY use other cri-
-teria, to prevent denial of service attacks.
-
-2.5.  Firewall Considerations
-
-     A firewall mail gateway has two choices when receiving a tracking
-query for a host within its domain: it may return a response to the
-query that says the message has been passed on, but no further informa-
-tion is available; or it may perform a chaining operation itself,
-
-
-
-Hansen                                                          [Page 5]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-gathering information on the message from the mail hosts behind the
-firewall, and returning to the MTQP client the information for each
-behind-the-firewall hop, or possibly just the final hop information,
-possibly also disguising the names of any hosts behind the firewall.
-Which option is picked is an adminstrative decision and is not further
-mandated by this document.
-
-3.  Initialization and Option Response
-
-     Once the TCP connection has been opened by an MTQP client, the MTQP
-server issues an initial status response that indicates its readiness.
-If the status response is positive (+OK or +OK+), the client may proceed
-with other commands.
-
-     The initial status response MUST include the response information
-"/MTQP".  Negative responses MUST include a reason code as response
-information.  The following reason codes are defined here; unrecognized
-reason codes added in the future may be treated as equivalent to "una-
-vailable".
-     "/" "unavailable"
-     "/" "admin"
-
-     The reason code "/admin" SHOULD be used when the service is una-
-vailable for administrative reasons.  The reason code "/unavailable"
-SHOULD be used when the service is unavailable for other reasons.
-
-     If the server has any options enabled, they are listed as the
-multi-line response of the initial status response, one per line.  An
-option specification consists of an identifier, optionally followed by
-option-specific parameters.  An option specification may be continued
-onto additional lines by starting the continuation lines with white
-space.  The option identifier is case insensitive.  Option identifiers
-beginning with the characters "vnd." are reserved for vendor use.  (See
-below.)
-
-     One option specification is defined here:
-
-     STARTTLS
-
-This capability MUST be listed if the optional STARTTLS command is sup-
-ported by the MTQP server.  It has no parameters.
-
-     Example #1 (no options):
-     S: +OK/MTQP MTQP server ready
-
-     Example #2 (service temporarily unavailable):
-     S: -TEMP/MTQP/admin Service down for admin, call back later
-
-
-
-
-Hansen                                                          [Page 6]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-     Example #3 (service permanently unavailable):
-     S: -ERR/MTQP/unavailable Service down
-
-     Example #4 (alternative for no options):
-     S: +OK+/MTQP MTQP server ready
-     S: .
-
-     Example #5 (options available):
-     S: +OK+/MTQP MTQP server ready
-     S: starttls
-     S: vnd.com.example.option2 with parameters private to example.com
-     S: vnd.com.example.option3 with a very long
-     S:  list of parameters
-     S: .
-
-4.  TRACK Command
-
-     Syntax:
-          "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF
-
-          mtrk-secret = base64
-
-     Envid is defined in [DRAFT-TRACK-ESMTP].  Mtrk-secret is the secret
-A described in [DRAFT-TRACK-ESMTP], encoded using base64.
-
-     When the client issues the TRACK command, and the user is vali-
-dated, the MTQP server retrieves tracking information about an email
-message.  To validate the user, the value of mtrk-secret is hashed using
-SHA1, as described in [RFC-SHA1].  The hash value is then compared with
-the value passed with the message when it was originally sent.  If the
-hash values match, the user is validated.
-
-     A successful response MUST be multi-line, consisting of a [RFC-
-MIME] body part.  The MIME body part MUST be of type multipart/related,
-with subparts of message/tracking-status, as defined in [DRAFT-TRACK-
-TSN].  The response contains the tracking information about the email
-message that used the given tracking-id.
-
-
-     In each of the examples below, the envid is "<12345-
-20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B
-is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94".  The message
-came from example.com and the MTQP server is example2.com.
-
-     Example #6 Message Delivered:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
-     S: +OK+ Tracking information follows
-     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
-
-
-
-Hansen                                                          [Page 7]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-     S:
-     S: --%%%%
-     S: Content-Type: message/tracking-status
-     S:
-     S: Original-Envelope-Id: 12345-20010101@example.com
-     S: Reporting-MTA: dns; example2.com
-     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
-     S:
-     S: Original-Recipient: rfc822; user1@example1.com
-     S: Final-Recipient: rfc822; user1@example1.com
-     S: Action: delivered
-     S: Status: 2.5.0
-     S:
-     S: --%%%%--
-     S: .
-
-     Example #7 Message Transferred:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
-     S: +OK+ Tracking information follows
-     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
-     S:
-     S: --%%%%
-     S: Content-Type: message/tracking-status
-     S:
-     S: Original-Envelope-Id: 12345-20010101@example.com
-     S: Reporting-MTA: dns; example2.com
-     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
-     S:
-     S: Original-Recipient: rfc822; user1@example1.com
-     S: Final-Recipient: rfc822; user1@example1.com
-     S: Action: transferred
-     S: Remote-MTA: dns; example3.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S: Status: 2.4.0
-     S:
-     S: --%%%%--
-     S: .
-
-     Example #8 Message Delayed and a DotStuffed Header:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
-     S: +OK+ Tracking information follows
-     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
-     S: ..Dot-Stuffed-Header: as an example
-     S:
-     S: --%%%%
-     S: Content-Type: message/tracking-status
-     S:
-     S: Original-Envelope-Id: 12345-20010101@example.com
-
-
-
-Hansen                                                          [Page 8]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-     S: Reporting-MTA: dns; example2.com
-     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
-     S:
-     S: Original-Recipient: rfc822; user1@example1.com
-     S: Final-Recipient: rfc822; user1@example1.com
-     S: Action: delayed
-     S: Status: 4.4.1 (No answer from host)
-     S: Remote-MTA: dns; example3.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S: Will-Retry-Until: Thu,  4 Jan 2001 15:15:15 -0500
-     S:
-     S: --%%%%--
-     S: .
-
-     Example #9 Two Users, One Relayed, One Failed:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
-     S: +OK+ Tracking information follows
-     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
-     S:
-     S: --%%%%
-     S: Content-Type: message/tracking-status
-     S:
-     S: Original-Envelope-Id: 12345-20010101@example.com
-     S: Reporting-MTA: dns; example2.com
-     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
-     S:
-     S: Original-Recipient: rfc822; user1@example1.com
-     S: Final-Recipient: rfc822; user1@example1.com
-     S: Action: relayed
-     S: Status: 2.1.9
-     S: Remote-MTA: dns; example3.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S:
-     S: Original-Recipient: rfc822; user2@example1.com
-     S: Final-Recipient: rfc822; user2@example1.com
-     S: Action: failed
-     S: Status 5.2.2 (Mailbox full)
-     S: Remote-MTA: dns; example3.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S:
-     S: --%%%%--
-     S: .
-
-     Example #10 Firewall:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
-     S: +OK+ Tracking information follows
-     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
-     S:
-
-
-
-Hansen                                                          [Page 9]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-     S: --%%%%
-     S: Content-Type: message/tracking-status
-     S:
-     S: Original-Envelope-Id: 12345-20010101@example.com
-     S: Reporting-MTA: dns; example2.com
-     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
-     S:
-     S: Original-Recipient: rfc822; user1@example1.com
-     S: Final-Recipient: rfc822; user1@example1.com
-     S: Action: relayed
-     S: Status: 2.1.9
-     S: Remote-MTA: dns; example2.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S:
-     S: --%%%%
-     S: Content-Type: message/tracking-status
-     S:
-     S: Original-Envelope-Id: 12345-20010101@example.com
-     S: Reporting-MTA: dns; smtp.example3.com
-     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
-     S:
-     S: Original-Recipient: rfc822; user2@example1.com
-     S: Final-Recipient: rfc822; user4@example3.com
-     S: Action: delivered
-     S: Status: 2.5.0
-     S:
-     S: --%%%%--
-     S: .
-
-     Example #11 Firewall, Combining Per-Recipient Blocks:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
-     S: +OK+ Tracking information follows
-     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
-     S:
-     S: --%%%%
-     S: Content-Type: message/tracking-status
-     S:
-     S: Original-Envelope-Id: 12345-20010101@example.com
-     S: Reporting-MTA: dns; example2.com
-     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
-     S:
-     S: Original-Recipient: rfc822; user1@example1.com
-     S: Final-Recipient: rfc822; user1@example1.com
-     S: Action: relayed
-     S: Status: 2.1.9
-     S: Remote-MTA: dns; example2.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S:
-
-
-
-Hansen                                                         [Page 10]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-     S: Original-Recipient: rfc822; user2@example1.com
-     S: Final-Recipient: rfc822; user4@example3.com
-     S: Action: delivered
-     S: Status: 2.5.0
-     S:
-     S: --%%%%--
-     S: .
-
-     Example #12 Firewall, Hiding System Names Behind the Firewall:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
-     S: +OK+ Tracking information follows
-     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
-     S:
-     S: --%%%%
-     S: Content-Type: message/tracking-status
-     S:
-     S: Original-Envelope-Id: 12345-20010101@example.com
-     S: Reporting-MTA: dns; example2.com
-     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
-     S:
-     S: Original-Recipient: rfc822; user1@example1.com
-     S: Final-Recipient: rfc822; user1@example1.com
-     S: Action: relayed
-     S: Status: 2.1.9
-     S: Remote-MTA: dns; example2.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S:
-     S: --%%%%
-     S: Content-Type: message/tracking-status
-     S:
-     S: Original-Envelope-Id: 12345-20010101@example.com
-     S: Reporting-MTA: dns; example2.com
-     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
-     S:
-     S: Original-Recipient: rfc822; user2@example1.com
-     S: Final-Recipient: rfc822; user4@example1.com
-     S: Action: delivered
-     S: Status: 2.5.0
-     S:
-     S: --%%%%--
-     S: .
-
-5.  COMMENT Command
-
-     Syntax:
-          "COMMENT" opt-text CRLF
-
-          opt-text = [WSP *(VCHAR / WSP)]
-
-
-
-Hansen                                                         [Page 11]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-     When the client issues the COMMENT command, the MTQP server MUST
-respond with a successful response (+OK or +OK+).  All optional text
-provided with the COMMENT command are ignored.
-
-6.  STARTTLS Command
-
-     Syntax:
-          "STARTTLS" CRLF
-
-     TLS [TLS], more commonly known as SSL, is a popular mechanism for
-enhancing TCP communications with privacy and authentication.  An MTQP
-server MAY support TLS.  If an MTQP server supports TLS, it MUST include
-"STARTTLS" in the option specifications list on protocol startup.
-
-     If the server returns a negative response, it MAY use one of the
-following response codes:
-     "/" "unsupported"
-     "/" "unavailable"
-     "/" "tlsinprogress"
-
-     If TLS is not suported, then a response code of "/unsupported"
-SHOULD be used.  If TLS is not available for some other reason, then a
-reponse code of "/unavailable" SHOULD be used.  If a TLS session is
-already in progress, then it is a protocol error and "-BAD" MUST be
-returned with a response code of "/tlsinprogress".
-
-     After receiving a positive response to a STARTTLS command, the
-client MUST start the TLS negotiation before giving any other MTQP com-
-mands.
-
-     If the MTQP client is using pipelining (see below), the STARTTLS
-command must be the last command in a group.
-
-6.1.  Processing After the STARTTLS Command
-
-     If the TLS handshake fails, the server SHOULD abort the connection.
-
-     After the TLS handshake has been completed, both parties MUST
-immediately decide whether or not to continue based on the authentica-
-tion and privacy achieved. The MTQP client and server may decide to move
-ahead even if the TLS negotiation ended with no authentication and/or no
-privacy because most MTQP services are performed with no authentication
-and no privacy, but some MTQP clients or servers may want to continue
-only if a particular level of authentication and/or privacy was
-achieved.
-
-     If the MTQP client decides that the level of authentication or
-privacy is not high enough for it to continue, it SHOULD issue an MTQP
-
-
-
-Hansen                                                         [Page 12]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-QUIT command immediately after the TLS negotiation is complete.  If the
-MTQP server decides that the level of authentication or privacy is not
-high enough for it to continue, it SHOULD reply to every MTQP command
-from the client (other than a QUIT command) with a negative "-ERR"
-response and a response code of "/insecure".
-
-6.2.  Result of the STARTTLS Command
-
-     Upon completion of the TLS handshake, the MTQP protocol is reset to
-the initial state (the state in MTQP after a server starts up).  The
-server MUST discard any knowledge obtained from the client prior to the
-TLS negotiation itself. The client MUST discard any knowledge obtained
-from the server, such as the list of MTQP options, which was not
-obtained from the TLS negotiation itself.
-
-     At the end of the TLS handshake, the server acts as if the connec-
-tion had been initiated and responds with an initial status response
-and, optionally, a list of server options.  The list of MTQP server
-options received after the TLS handshake MUST be different than the list
-returned before the TLS handshake.  In particular, a server MUST NOT
-return the STARTTLS option in the list of server options after a TLS
-handshake has completed.
-
-     Both the client and the server MUST know if there is a TLS session
-active.  A client MUST NOT attempt to start a TLS session if a TLS ses-
-sion is already active.
-
-7.  QUIT Command
-
-     Syntax:
-          "QUIT" CRLF
-
-     When the client issues the QUIT command, the MTQP session ter-
-minates.  The QUIT command has no parameters.  The server MUST respond
-with a successful response.  The client MAY close the session from its
-end immediately after issuing this command (if the client is on an
-operating system where this does not cause problems).
-
-8.  Pipelining
-
-     The MTQP client may elect to transmit groups of MTQP commands in
-batches without waiting for a response to each individual command.  The
-MTQP server MUST process the commands in the order received.
-
-     Specific commands may place further constraints on pipelining.  For
-example, STARTTLS must be the last command in a batch of MTQP commands.
-
-     The following two examples are identical:
-
-
-
-Hansen                                                         [Page 13]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-     Example #13 :
-     C: TRACK <tracking-id> YWJjZGVmZ2gK
-     S: +OK+ Tracking information follows
-     S:
-     S: ... tracking details #1 go here ...
-     S: .
-     C: TRACK <tracking-id-2> QUJDREVGR0gK
-     S: +OK+ Tracking information follows
-     S:
-     S: ... tracking details #2 go here ...
-     S: .
-
-     Example #14 :
-     C: TRACK <tracking-id> YWJjZGVmZ2gK
-     C: TRACK <tracking-id-2> QUJDREVGR0gK
-     S: +OK+ Tracking information follows
-     S:
-     S: ... tracking details #1 go here ...
-     S: .
-     S: +OK+ Tracking information follows
-     S:
-     S: ... tracking details #2 go here ...
-     S: .
-
-9.  URL Format
-
-     The MTQP URL scheme is used to designate MTQP servers on Internet
-hosts accessible using the MTQP protocol.  An MTQP URL takes one of the
-following forms:
-
-     mtqp://<mserver>/track/<envid>/<mtrk-secret>
-     mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret>
-
-     The first form is used to refer to an MTQP server on the standard
-port, while the second form specifies a non-standard port.  Both of
-these forms specify that the TRACK command is to be issued using the
-given tracking id (envid) and authorization secret (mtrk-secret).  The
-path element "/track/" is case insensitive, but the envid and mtrk-
-secret may not be.
-
-9.1.  MTQP URL Syntax
-
-     This is an ABNF description of the MTQP URL.
-
-     mtqp-url = "mtqp://" net_loc "/track/" envid "/" mtrk-secret
-
-
-
-
-
-
-Hansen                                                         [Page 14]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-10.  IANA Considerations
-
-     System port number XXXX - TBD by IANA
-
-     The service name to be registered with the Internet Assigned Number
-Authority (IANA) is "MTQP".
-
-     This document requests that IANA maintain one new registry: MTQP
-options.  The registry's purpose is to register options to this proto-
-col.  Options whose names do not begin with "vnd." MUST be defined in a
-standards track or IESG approved experimental RFC.  New MTQP options
-MUST include the following information as part of their definition:
-
-     option identifier
-     option parameters
-     added commands
-     standard commands affected
-     specification reference
-     discussion
-
-     One MTQP option is defined in this document:
-     option identifier: STARTTLS option parameters: none added commands:
-     STARTTLS standard commands affected: none specification reference:
-     RFC TBD discussion: see RFC TBD
-
-     Additional vendor-specific options for this protocol have names
-that begin with "vnd.".  After the "vnd." would appear the reversed
-domain name of the vendor, another dot ".", and a name for the option
-itself.  For example, "vnd.com.example.extinfo" might represent a
-vendor-specific extension providing extended information by the owner of
-the "example.com" domain.  These names MAY be registered with IANA.
-
-11.  Security Considerations
-
-     If the originator of a message were to delegate his or her tracking
-request to a third party, this would be vulnerable to snooping over
-unencrypted sessions.  The user can decide on a message-by-message basis
-if this risk is acceptable.
-
-     The security of tracking information is dependent on the randomness
-of the secret chosen for each message and the level of exposure of that
-secret.  If different secrets are used for each message, then the max-
-imum exposure from tracking any message will be that single message for
-the time that the tracking information is kept on any MTQP server.  If
-this level of exposure is too much, TLS may be used to reduce the expo-
-sure further.
-
-     It should be noted that message tracking is not an end-to-end
-
-
-
-Hansen                                                         [Page 15]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-mechanism.  Thus, if an MTQP client/server pair decide to use TLS
-privacy, they are not securing tracking queries with any prior or suc-
-cessive MTQP servers.
-
-     Both the MTQP client and server must check the result of the TLS
-negotiation to see whether acceptable authentication or privacy was
-achieved.  Ignoring this step completely invalidates using TLS for secu-
-rity.  The decision about whether acceptable authentication or privacy
-was achieved is made locally, is implementation-dependent, and is beyond
-the scope of this document.
-
-     The MTQP client and server should note carefully the result of the
-TLS negotiation.  If the negotiation results in no privacy, or if it
-results in privacy using algorithms or key lengths that are deemed not
-strong enough, or if the authentication is not good enough for either
-party, the client may choose to end the MTQP session with an immediate
-QUIT command, or the server may choose to not accept any more MTQP com-
-mands.
-
-     A man-in-the-middle attack can be launched by deleting the
-"STARTTLS" option response from the server.  This would cause the client
-not to try to start a TLS session.  An MTQP client can protect against
-this attack by recording the fact that a particular MTQP server offers
-TLS during one session and generating an alarm if it does not appear in
-an option response for a later session.
-
-     If TLS is not used, a tracking request is vulnerable to replay
-attacks, such that a snoop can later replay the same handshake again to
-potentially gain more information about a message's status.
-
-     Before the TLS handshake has begun, any protocol interactions are
-performed in the clear and may be modified by an active attacker.  For
-this reason, clients and servers MUST discard any knowledge obtained
-prior to the start of the TLS handshake upon completion of the TLS
-handshake.
-
-     If a client/server pair successfully performs a TLS handshake and
-the server does chaining referrals, then the server SHOULD attempt to
-negotiate TLS at the same security level at the next hop.  In a hop-by-
-hop scenario, STARTTLS is a request for "best effort" security and
-should be treated as such.
-
-     SASL is not used because authentication is per message rather than
-per user.
-
-12.  Protocol Syntax
-
-     This is a collected ABNF description of the MTQP protocol.
-
-
-
-Hansen                                                         [Page 16]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-     conversation = command-response *( client-command command-response )
-
-     # client side
-     client-command = track-command / starttls-command / quit-command / comment-command
-
-     track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF
-
-     mtrk-secret = base64
-
-     starttls-command = "STARTTLS" CRLF
-
-     quit-command = "QUIT" CRLF
-
-     comment-command = "COMMENT" opt-text CRLF
-
-     # server side
-     command-response = success-response / temp-response / error-response / bad-response
-
-     temp-response = "-TEMP" response-info opt-text CRLF
-
-     opt-text = [WSP *(VCHAR / WSP)]
-
-     error-response = "-ERR" response-info opt-text CRLF
-
-     bad-response = "-BAD" response-info opt-text CRLF
-
-     success-response = single-line-success / multi-line-success
-
-     single-line-success = "+OK" response-info opt-text CRLF
-
-     multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf
-
-     dataline = *998OCTET CRLF
-
-     dotcrlf = "." CRLF
-
-     option-list = *option-line
-
-     option-line = identifier opt-text *(CRLF WSP opt-text) CRLF
-
-     NAMECHAR = ALPHA / DIGIT / "-" / "_"
-
-     identifier = (ALPHA / "_") *NAMECHAR)
-
-     response-info = *( "/" ( "admin" / "unavailable" / "unsupported" /
-             "tlsinprogress" / "insecure" / 1*NAMECHAR ) )
-
-
-
-
-
-Hansen                                                         [Page 17]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-13.  Acknowledgements
-
-     The description of STARTTLS is based on [RFC-SMTP-TLS].
-
-14.  References
-
-     [RFC-SHA1] RFC TBD, D. Eastlake & P. Jones, "US Secure Hash Stan-
-dard 1 (SHA1)", TBD 2001.
-
-     [RFC-MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Inter-
-net Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
-Innosoft, First Virtual, November 1996.
-
-     [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
-BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Demon
-Internet Ltd., November 1997.
-
-     [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to
-Indicate Requirement Levels", Harvard University, March 1997.
-
-     [RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for
-Authentication", Netscape Communications, March 1999.
-
-     [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for
-Secure SMTP over TLS", Internet Mail Consortium, January 1999.
-
-     [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR
-for specifying the location of services (DNS SRV)" Troll Technologies,
-Internet Software Consortium, Microsoft Corp., February 2000
-
-     [DRAFT-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T.
-Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc.,
-AT&T Laboratories, TBD 2001.
-
-     [DRAFT-TRACK-MODEL] draft-ietf-msgtrk-model-*.txt, T. Hansen, "Mes-
-sage Tracking Models and Requirements", AT&T Laboratories, TBD 2001.
-
-     [DRAFT-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
-Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2001.
-
-     [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
-form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine,
-Xerox Corporation, August 1998.
-
-15.  Author's Address
-
-     Tony Hansen
-     AT&T Laboratories
-
-
-
-Hansen                                                         [Page 18]
-
-Internet Draft      Message Tracking Query Protocol    November 20, 2001
-
-
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1.732.576.3207
-     E-Mail: tony@att.com
-
-16.  Full Copyright Statement
-
-     Copyright (C) The Internet Society (1999).  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 dis-
-tributed, 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 Stan-
-dards 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.
-
-     This document expires May 20, 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hansen                                                         [Page 19]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-protocol-00.txt b/Documentation/en/I-D/draft-ietf-msgtrk-protocol-00.txt
deleted file mode 100644
index e223f995..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-protocol-00.txt
+++ /dev/null
@@ -1,500 +0,0 @@
-Internet Draft						       E. Allman
-draft-ietf-msgtrk-protocol-00.txt			  Sendmail, Inc.
-Valid for six months					       T. Hansen
-						       AT&T Laboratories
-							  March	10, 2000
-
-
-
-			 SMTP Service Extension
-			  for Message Tracking
-
-		  <draft-ietf-msgtrk-protocol-00.txt>
-
-			 Authors' version: 1.1
-
-     Status of this Memo
-
-     This document is an Internet-Draft	and is in full conformance with
-all provisions of Section 10 of	RFC2026.
-
-     Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that other
-groups may also	distribute working documents as	Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of	six
-months and may be updated, replaced, or	obsoleted by other documents at
-any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in	progress."
-
-     The list of current Internet-Drafts can be	accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft	Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed	on the MSGTRK working
-group mailing list, ietf-msgtrk[-request]@imc.org.  An archive of the
-mailing	list may be found at http://www.ietf.org/archive/msgtrk.
-
-Copyright Notice
-
-     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can	I track
-the messages?  Message tracking	is the ability to find out the path that
-a particular message has taken through a messaging system and the
-
-
-
-Allman,Hansen						        [Page 1]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-current	routing	status of that message.	 This document provides	exten-
-sions to the ESMTP protocol to enhance its capabilities	to include mes-
-sage tracking.
-
-1.  Introduction
-
-     The Message Tracking Models and Requirements document [RFC-TRACK-
-MODEL] discusses the models that message tracking solutions could fol-
-low, along with	requirements for a message tracking solution that can be
-used with the Internet-wide message infrastructure.  This memo defines
-an extension to	the SMTP service that provides a message tracking solu-
-tion that satisfies those requirements.	 Using the model document's ter-
-minology, it uses active enabling and active requests with request
-referrals.
-
-....
-
-This document is very drafty; its purpose is to	promote	discussion.
-Sections that are obviously in need of filling out have	comments begin-
-ning with "--".
-
-
-1.1.  Terminology
-
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT",	"RECOMMENDED", "MAY", and "OPTIONAL" in	this
-document are to	be interpreted as described in RFC 2119	[RFC-KEYWORDS].
-
-
-
-2.  Framework for the Message Tracking Service Extension
-
-     The Message Trackng extension to SMTP is laid out as follows:
-
-     **	  the name of the SMTP service defined here is "Message	Track-
-	  ing";
-
-     **	  the EHLO keyword value associated with the extension is
-	  "TRACK";
-
-     **	  the TRACK keyword has	no parameters;
-
-     **	  the TRACKID parameter	is added to the	MAIL FROM command;
-
-     **	  a new	SMTP verb, "MTRK", is defined.
-
-     The rest of this memo defines how support for the extension effects
-     the behavior of a message transfer	agent.
-
-
-
-Allman,Hansen						        [Page 2]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-3.  Message Tracking Enabling
-
-     An	SMTP client wishing to request message tracking	support	for a
-message	may issue the EHLO command to start an SMTP session, to	deter-
-mine if	the server supports any	of several service extensions.	If the
-server responds	with code 250 to the EHLO command, and the response
-includes the EHLO keyword TRACK, then the Message Tracking extension (as
-described in this memo)	is supported.  In general, an ESMTP server which
-implements this	service	extension will propagate message tracking infor-
-mation when relaying mail to other SMTP-based MTAs that	also support
-this extension,	and make a "best effort" to record when	messages are
-passed into other environments.
-
-4.  Additional Parameter for the MAIL FROM Command
-
-     The extended MAIL FROM command is issued by a client when it wishes
-to request that	a server maintain tracking information for the message.
-The extended MAIL FROM command is identical to the MAIL	commands defined
-in [RFC-821], except that the additional parameter may appear after the
-recipient address.  The	general	syntax for extended SMTP commands is
-defined	in [RFC-ESMTP].
-
-4.1.  The TRACKID parameter of the ESMTP MAIL FROM Command
-
-     The TRACKID esmtp-keyword on the extended MAIL FROM command speci-
-fies whether or	not the	message	should be tracked by the server.  If the
-TRACKID	esmtp-keyword is used, it MUST have an associated esmtp-value,
-which is constructed as	described next.
-
-4.2.  Creating the TRACKID Parameter
-
-     The TRACKID parameter consists of two parts: a per-message	authen-
-tication string, the Auth String, and a	per-message tracking identifica-
-tion string, the Tracking ID.
-
-4.2.1.	Tracking ID
-
-     A key requirement of message tracking is the ability to uniquely
-identify a message with	a globally and temporally unique signature.  The
-Message-Id: header is required by [RFC-822] to identify	a message, and
-is usually required to be globally and temporally unique.  So it is
-almost sufficient for tracking identification.	However, a Message ID
-will be	reused under certain circumstances, such as when a message is
-resent,	and such messages must be able to be tracked separately	from the
-original message.  The Tracking	ID is REQUIRED to be the same value as
-used for the Message ID, without the angle brackets, and augmented by a
-colon ":" and a	generational counter.  The generational	counter	will be
-an unsigned integer value that SHOULD start at the value of 0.	For
-
-
-
-Allman,Hansen						        [Page 3]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-example, if the	value of the Message-ID: header	is
-"<123456.89012391@domain.example>", then the value of the tracking ID
-will be	"123456.89012391@domain.example:0".  If	a message is ever resent
-or retransmitted for any other reason by an end-user client, then the
-generational counter MUST be incremented by one.  (The generational
-counter	MAY additionally be incremented	by a small (<10) random	number.)
-
-4.2.2.	Secret Value
-
-     For messages to be	tracked, the mail user agent must use a	secret
-value.	This secret value MAY be a per-message secret, such as a 128-bit
-(16-byte) random number.
-
-4.2.3.	Stored Authentication Value
-
-     The value of the Tracking ID, T, is concatentated with the	secret
-value, S, and passed through the [RFC-MD5] one-way hash	function, to
-create the Stored Authentication Value,	A.
-
-     A = H(T + S)
-
-
-4.2.4.	Transmitted Authentication String
-
-     The Transitted Authentication String, B, is created by passing the
-Stored Authentication Value, A,	through	the MD5	one-way	hash function,
-producing a 16-byte value.  This value is then expressed as a series of
-32 hexadecimal digits, either lower- or	upper-case, transmitted	in
-internet byte order (low-endian	???? ) [RFC-????].
-
-     B = hex(H(A))
-
-4.2.5.	The TRACKID Parameter
-
-     The TRACKID parameter, P, is created from the transmitted authenti-
-cation string, B, a colon ":", and the tracking	ID, T.
-
-     P = B + ":" + T
-
-
-5.  Message Tracking Requests
-
-     The MTRK command is issued	by the client host when	it wishes to
-determine the current status of	a message previously sent to that server
-host.  The syntax of this command is as	follows:
-
-     MTRK <stored-authentication-value>:<tracking-id><CR><LF>
-
-
-
-
-Allman,Hansen						        [Page 4]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-<tracking-id> is the tracking ID, T, of	a message previously sent to
-this server.  The <stored-authentication-value>	is the Stored Authenti-
-cation Value A (as calculated above) for that message.	The <stored-
-authentication-value> is expressed as a	series of 32 hexadecimal digits,
-either lower- or upper-case, transmitted in internet byte order	[RFC-
-????].	This command may be issued at any time once a session is esta-
-blished, as long as there is not a transaction occurring.  Thus, this
-command	is illegal between a MAIL FROM:	command	and the	end of the DATA
-commands and responses.
-
-things to add:
--- data	to be returned
--- states to be	returned
--- format to be	returned
--- responses to	the verb, 250, 4xx, 5xx
-
-
-other things to	consider:
--- firewalls? (treat as	gateway	MTAs and let them do chaining?)
--- affect on SUBMIT? can we ask	MSA to return the A and	B hash?
--- use message-id directly and require message-id to be	in first 1k of
-message?
-
-
-6.  Examples
-
-     --	examples go here
-
-6.1.  Message Tracking Enabling
-
-
-     S:	220 smtp.example.com ESMTP server ready
-     C:	EHLO example.example.com
-     S:	250-smtp.example.com
-     S:	250 TRACK
-     C:	MAIL FROM:<user@example.com>
-	 TRACKID=1234567890123456789012:12345.54321@example.com:0
-     S:	250 <user@example.com> sender ok
-     C:	RCPT TO:<user2@example.com>
-     S:	25o <user2@example.com>	recipient ok
-     C:	DATA
-     S:	354 okay, send message
-     C:	Message-Id: <12345.54321@example.com>
-     C:	(rest of message here)
-     C:	.
-     S:	250 message accepted
-     C:	QUIT
-     S:	221 goodbye
-
-
-
-Allman,Hansen						        [Page 5]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-6.2.  Message Tracking Request
-
-     S:	220 smtp.example.com ESMTP server ready
-     C:	EHLO example.example.com
-     S:	250-smtp.example.com
-     S:	250 TRACK
-     C:	MTRK 1234567890123456789012:12345.54321@example.com:0
-     S:	-- response to be determined
-
-7.  Security Considerations
-
-     things to add:
--- text	about no more than a single message can	be lost
--- man in the middle attack
--- see RFC 1894	for security considerations on DSNs and	RFC 2298 on MDNs
-
--- We probably cannot get away with the	following statement:
-
-This RFC does not discuss security issues and is not believed to raise
-any security issues not	already	endemic	in electronic mail and present
-in fully conforming implementations of [RFC821], or otherwise made pos-
-sible by [MIME].
-
-
-8.  References
-
-     [RFC-821] Postel, J., "Simple Mail	Transfer Protocol", STD	10, RFC
-821, University	of Southern California / Information Sciences Institute,
-August 1982.
-
-[RFC-822] Crocker, D., "Standard for the Format	of ARPA	Internet Text
-Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
-[RFC-ESMTP] Klensin, J., Freed,	N., Rose, M., Stefferud, E., and D.
-Crocker, "SMTP Service Extensions", RFC	1651, MCI, Innosoft, Dover Beach
-Consulting, Inc., Network Management Associates, Inc., Silicon Graphics,
-Inc., July 1994.
-
-[RFC-MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-April 1992.
-
-[RFC-MODEL] Hansen, T.,	"Message Tracking Models and Requirements", RFC
-????, AT&T Laboratories, ???? 2000.
-
-[RFC-????]  something on internet byte order
-
-
-
-
-
-
-Allman,Hansen						        [Page 6]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-9.  Authors' Addresses
-
-     Eric Allman
-     Sendmail, Inc.
-     street address
-     city, state zip
-
-     Phone: +1
-     E-Mail: eric@sendmail.com
-
-     Tony Hansen
-     AT&T Laboratories
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1 732 576-3207
-     E-Mail: tony@att.com
-
-10.  Full Copyright Statement
-
-     Copyright (C) The Internet	Society	(1999).	 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 implmentation may	be prepared, copied, published and dis-
-tributed, 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 organisations,
-except as needed for the purpose of developing Internet	standards in
-which case the procedures for copyrights defined in the	Internet Stan-
-dards 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.
-
-     This document expires September 10, 2000.
-
-
-
-
-
-Allman,Hansen						        [Page 7]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-11.  Appendix A	-- Sample Code
-
-     For the sake of illustration, we provide the following sample C
-code for the creation of the saved and transmitted authentication
-strings.  The code is based on MD5 code	as described in	[RFC-MD5].  The
-input is a secret and transaction ID, the output is two	33-byte	strings
-containing the values of the two authentication	strings, encoded as hex
-digits,	and NUL-terminated.
-
--- I have not yet compiled this	code or	verified that it does indeed
-generate network byte order.
-     /*
-     **	Function: trackauth
-     */
-     #include <md5.h>
-
-     void
-     trackauth(
-		     /*	input parameters ... */
-	 unsigned char*	secret;		    /* pointer to secret */
-	 int secret_len;		    /* length of secret	*/
-	 unsigned char*	transaction_id;	    /* pointer to transaction ID */
-	 int transaction_id_len;	    /* length of transaction ID	*/
-		     /*	output parameters ... */
-	 unsigned char saved_auth_str[33];  /* A: saved	authentication string */
-	 unsigned char trans_auth_str[33];  /* B: transmitted auth. string */
-     )
-     {
-	 MD5_CTX context;		    /* MD5 engine */
-	 unsigned char outbuf[16];	    /* where to	store the context */
-	 register int i, j;		    /* counters	*/
-	 static	char hexdigits[] = "0123456789abcdef";
-
-	 MD5Init(&context);
-	 MD5Update(&context, secret, secret_len);
-	 MD5Update(&context, transaction_id, transaction_id_len);
-	 MD5Final(outbuf, &context);
-	 for (i	= 0, j = 0; i <	16; i++)
-	     {
-	     saved_auth_str[j++] = hexdigits[outbuf[i] & 0xF];
-	     saved_auth_str[j++] = hexdigits[(outbuf[i]	>> 4) &	0xF];
-	     }
-	 saved_auth_str[j] = '\0';
-
-	 MD5Init(&context);
-	 MD5Update(&context, saved_auth_str, 16);
-	 MD5Final(outbuf, &context);
-	 for (i	= 0, j = 0; i <	16; i++)
-
-
-
-Allman,Hansen						        [Page 8]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-	     {
-	     trans_auth_str[j++] = hexdigits[outbuf[i] & 0xF];
-	     trans_auth_str[j++] = hexdigits[(outbuf[i]	>> 4) &	0xF];
-	     }
-	 trans_auth_str[j] = '\0';
-     }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allman,Hansen						        [Page 9]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-protocol-05.txt b/Documentation/en/I-D/draft-ietf-msgtrk-protocol-05.txt
deleted file mode 100644
index 3bd82593..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-protocol-05.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-T. Hansen: tony@att.com                                                            

-E. Allman: eric+ietf@sendmail.com                                                  

-

-

diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-03.txt b/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-03.txt
deleted file mode 100644
index 932877c2..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-03.txt
+++ /dev/null
@@ -1,434 +0,0 @@
-
-
-
-
-Internet Draft                                               E. Allman
-draft-ietf-msgtrk-smtpext-03.txt                        Sendmail, Inc.
-Valid for six months                                         T. Hansen
-Updates: RFC 1891                                    AT&T Laboratories
-                                                      November 2, 2001
-
-
-
-
-                        SMTP Service Extension
-                         for Message Tracking
-
-                  <draft-ietf-msgtrk-smtpext-03.txt>
-
-Status of This Memo
-
-     This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.  Internet-Drafts are
-working documents of the Internet Engineering Task Force (IETF), its
-areas, and its working groups.  Note that other groups may also
-distribute working documents as Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other documents
-at any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at:
-
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at:
-
-    http://www.ietf.org/shadow.html
-
-
-     This document is a submission by the MSGTRK Working Group of the
-Internet Engineering Task Force (IETF).  Comments should be submitted
-to the ietf-msgtrk@imc.org mailing list.  An archive of the mailing
-list may be found at
-
-    http://www.imc.org/ietf-msgtrk/index.html
-
-
-     Distribution of this memo is unlimited.
-
-
-1.  Abstract
-
-        This memo defines an extension to the SMTP service whereby a
-   client may mark a message for future tracking.
-
-Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
-
-
-2.  Other Documents and Conformance
-
-        The model used for Message Tracking is described in [DRAFT-
-   MTRK-MODEL].
-
-        Doing a Message Tracking query is intended as a "last resort"
-   mechanism.  Normally, Delivery Status Notifications (DSNs) [RFC-
-   DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]
-   would provide the primary delivery status.  Only if the message is
-   not received, or there is no response from either of these
-   mechanisms should a Message Tracking query be issued.
-
-        The definition of the base64 token is imported from section
-   6.8 of [RFC-MIME].
-
-        Syntax notation in this document conforms to [RFC-ABNF].
-
-        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
-   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
-   in this document are to be interpreted as described in RFC 2119
-   [RFC-KEYWORDS].
-
-
-3.  SMTP Extension Overview
-
-        The Message Tracking SMTP service extension uses the SMTP
-   service extension mechanism described in [RFC-ESMTP].  The
-   following service extension is hereby defined:
-
-    (1)   The name of the SMTP service extension is "Message
-          Tracking".
-
-    (2)   The EHLO keyword value associated with this extension is
-          "MTRK".
-
-    (3)   No parameters are allowed with this EHLO keyword value.
-          Future documents may extend this specification by specifying
-          options.
-
-    (4)   One optional parameter using the keyword "MTRK" is added to
-          the MAIL command.  In addition, the ENVID parameter of the
-          MAIL command (as defined in RFC 1891 sections 5.4) MUST be
-          supported, with extensions as described below.  The ORCPT
-          parameter of the RCPT command (as defined in RFC 1891
-          section 5.2) MUST also be supported.
-
-    (5)   The maximum length of a MAIL command line is increased by 40
-          characters by the possible addition of the MTRK keyword and
-          value.  Note that the 507 character extension of RCPT
-          commands for the ORCPT parameter and the 107 character
-          extension of MAIL commands for the ENVID parameter as
-          mandated by RFC 1891 [RFC-DSN-SMTP] must also be included.
-
-    (6)   No SMTP verbs are defined by this extension.
-
-
-
-
-Allman & Hansen                                               [Page 2]
-
-Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
-
-
-4.  The Extended MAIL Command
-
-        The extended MAIL command is issued by an SMTP client when it
-   wishes to inform an SMTP server that message tracking information
-   should be retained for future querying.  The extended MAIL command
-   is identical to the MAIL command as defined in [RFC-SMTP], except
-   that MTRK, ORCPT, and ENVID parameters appear after the address.
-
-   4.1.  The MTRK parameter to the ESMTP MAIL command
-
-           Any sender wishing to request the retention of data for
-      further tracking of message must first tag that message as
-      trackable by creating two values A and B:
-
-          A = some-large-random-number
-          B = SHA1(A)
-
-      The large random number A is calculated on a host-dependent
-      basis.  See [RFC-RANDOM] for a discussion of choosing good
-      random numbers.  This random number MUST be at least 128 bits
-      but MUST NOT be more than 1024 bits.
-
-           The 128-bit hash B of A is then computed using the SHA-1
-      algorithm as described in [NIST-SHA1].
-
-           The sender then base64 encodes value B and passes that
-      value as the mtrk-certifier on the MAIL command:
-
-          mtrk-parameter  = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
-          mtrk-certifier  = base64        ; authenticator
-          mtrk-timeout    = 1*9digit      ; seconds until timeout
-
-
-           A is stored in the originator's tracking database to
-      validate future tracking requests as described in [DRAFT-MTRK-
-      MTQP].  B is stored in tracking databases of compliant receiver
-      MTAs and used to authenticate future tracking requests.
-
-           The mtrk-timeout field indicates the number of seconds that
-      the client requests that this tracking information be retained
-      on intermediate servers, as measured from the initial receipt of
-      the message at that server.  Servers MAY ignore this value if it
-      violates local policy.  In particular, servers MAY silently
-      enforce an upper limit to how long they will retain tracking
-      data; this limit MUST be at least one day.
-
-           If no mtrk-timeout field is specified then the server
-      should use a local default.  This default SHOULD be 8-10 days
-      and MUST be at least one day.  Notwithstanding this clause, the
-      information MUST NOT be expired while the message remains in the
-      queue for this server: that is, an MTQP server MUST NOT deny
-      knowledge of a message while that same message sits in the MTA
-      queue.
-
-           If the message is relayed to another compliant SMTP server,
-      the MTA acting as the client SHOULD pass an mtrk-timeout field
-
-
-Allman & Hansen                                               [Page 3]
-
-Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
-
-
-      equal to the remaining life of that message tracking
-      information.  Specifically, the tracking timeout is decremented
-      by the number of seconds the message has lingered at this MTA
-      and then passed to the next MTA.  If the decremented tracking
-      timeout is less than or equal to zero, the entire MTRK parameter
-      MUST NOT be passed to the next MTA; essentially, the entire
-      tracking path is considered to be lost at that point.
-
-           See [RFC-DELIVERYBY] section 4 for an explanation of why a
-      timeout is used instead of an absolute time.
-
-   4.2.  Use of ENVID
-
-           To function properly, Message Tracking requires that each
-      message have a unique identifier that is never reused by any
-      other message.  For that purpose, if the MTRK parameter is
-      given, an ENVID parameter MUST be included, and the syntax of
-      ENVID from RFC 1891 section 5.4 is extended as follows:
-
-          envid-parameter = "ENVID=" unique-envid
-          unique-envid    = local-envid "@" fqhn
-          local-envid     = xtext
-          fqhn            = xtext
-
-      The unique-envid MUST be chosen in such a way that the same
-      ENVID will never be used by any other message sent from this
-      system or any other system.  In most cases, this means setting
-      fqhn to be the fully qualified host name of the system
-      generating this ENVID, and local-envid to an identifier that is
-      never re-used by that host.
-
-           In some cases, the total length of (local-envid + fqhn + 1)
-      (for the `@' sign) may exceed the total acceptable length of
-      ENVID (100).  In this case, the fqhn SHOULD be replaced by the
-      SHA1(fqhn) encoded into BASE64.  After encoding, the 160 bit
-      SHA-1 will be a 27 octet string, which limits local-envid to 72
-      octets.  Implementors are encouraged to use an algorithm for the
-      local-envid that is reasonably unique.  For example, sequential
-      integers have a high probability of intersecting with sequential
-      integers generated by a different host, but a SHA-1 of the
-      current time of day concatenated with the host's IP address and
-      a random number are unlikely to intersect with the same
-      algorithm generated by a different host.
-
-           Any resubmissions of this message into the message
-      transmission system MUST assign a new ENVID.  In this context,
-      "resubmission" includes forwarding or resending a message from a
-      user agent, but does not include MTA-level aliasing or
-      forwarding where the message does not leave and re-enter the
-      message transmission system.
-
-   4.3.  Forwarding Tracking Certifiers
-
-           MTAs SHOULD forward unexpired tracking certifiers to
-      compliant mailers as the mail is transferred during regular hop-
-      to-hop transfers.  If the "downstream" MTA is not MTRK-
-
-
-Allman & Hansen                                               [Page 4]
-
-Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
-
-
-      compliant, then the MTRK= parameter MUST be deleted.  If the
-      downstream MTA is DSN-compliant, then the ENVID and ORCPT
-      parameters MUST NOT be deleted.
-
-           If aliasing, forwarding, or other redirection of a
-      recipient occurs, and the result of the redirection is exactly
-      one recipient, then the MTA SHOULD treat this as an ordinary
-      hop-to-hop transfer and forward the MTRK=, ENVID=, and ORCPT=
-      values; these values MUST NOT be modified.
-
-           MTAs MUST NOT copy MTRK certifiers when a recipient is
-      aliased, forwarded, or otherwise redirected and the redirection
-      results in more than one recipient.  However, an MTA MAY
-      designate one of the multiple recipients as the "primary"
-      recipient to which tracking requests shall be forwarded; other
-      addresses MUST NOT receive tracking certifiers.  MTAs MUST NOT
-      forward MTRK certifiers when doing mailing list expansion.
-
-
-5.  Security Issues
-
-   5.1.  Denial of service
-
-           An attacker could attempt to flood the database of a server
-      by submitting large numbers of small, tracked messages.  In this
-      case, a site may elect to lower its maximum retention period
-      retroactively.
-
-   5.2.  Confidentiality
-
-           The mtrk-authenticator value (``A'') must be hard to
-      predict and not reused.
-
-           The originating client must take reasonable precautions to
-      protect the secret.  For example, if the secret is stored in a
-      message store (e.g., a "Sent" folder), the client must make sure
-      the secret isn't accessible by attackers, particularly on a
-      shared store.
-
-           Many site administrators believe that concealing names and
-      topologies of internal systems and networks is an important
-      security feature.  MTAs need to balance such desires with the
-      need to provide adequate tracking information.
-
-           In some cases site administrators may want to treat
-      delivery to an alias as final delivery in order to separate
-      roles from individuals.  For example, sites implementing
-      ``postmaster'' or ``webmaster'' as aliases may not wish to
-      expose the identity of those individuals by permitting tracking
-      through those aliases.  In other cases, providing the tracking
-      information for an alias is important, such as when the alias
-      points to the user's preferred public address.
-
-           Therefore, implementors are encouraged to provide
-      mechanisms by which site administrators can choose between these
-      alternatives.
-
-
-Allman & Hansen                                               [Page 5]
-
-Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
-
-
-6.  Acknowledgements
-
-        Several individuals have commented on and enhanced this draft,
-   including Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris
-   Newman, and Gregory Neil Shapiro.
-
-7.  References
-
-   [DRAFT-MTRK-MODEL]
-        T. Hansen, ``Message Tracking Model and Requirements.''
-        draft-ietf-msgtrk-model-03.txt.  November 2000.
-
-   [DRAFT-MTRK-MTQP]
-        T. Hansen, ``Message Tracking Query Protocol.''  draft-ietf-
-        msgtrk-mtqp-01.txt.  November 2000.
-
-   [RFC-ABNF]
-        Crocker, D., Editor, and P. Overell, ``Augmented BNF for
-        Syntax Specifications: ABNF'', RFC 2234, November 1997.
-
-   [RFC-DELIVERYBY]
-        D. Newman, ``Deliver By SMTP Service Extension.''  RFC 2852.
-        June 2000.
-
-   [RFC-DSN-REPT]
-        G. Vaudreuil, ``The Multipart/Report Content Type for the
-        Reporting of Mail System Administrative Messages.''  RFC 1892.
-        January 1996.
-
-   [RFC-DSN-SMTP]
-        K. Moore, ``SMTP Service Extension for Delivery Status
-        Notifications.''  RFC 1891.  January 1996.
-
-   [RFC-DSN-STAT]
-        K. Moore and G. Vaudreuil, ``An Extensible Message Format for
-        Delivery Status Notifications.''  RFC 1894.  January 1996.
-
-   [RFC-EMSSC]
-        G. Vaudreuil, ``Enhanced Mail System Status Codes.''  RFC
-        1893.  January 1996.
-
-   [RFC-ESMTP]
-        Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N.
-        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.
-        November 1995.
-
-   [RFC-KEYWORDS]
-        S. Bradner, ``Key words for use in RFCs to Indicate
-        Requirement Levels.''  RFC 2119.  March 1997.
-
-   [RFC-MDN]
-        R. Fajman, ``An Extensible Message Format for Message
-        Disposition Notifications.''  RFC 2298.  March 1998.
-
-   [RFC-MIME]
-        N. Freed and N. Borenstein, ``Multipurpose Internet Mail
-
-
-Allman & Hansen                                               [Page 6]
-
-Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
-
-
-        Extensions (MIME) Part One: Format of Internet Message
-        Bodies.''  RFC 2045.  November 1996.
-
-   [RFC-MSGFMT]
-        P. Resnick, editor, ``Internet Message Format.''  RFC 2822.
-        April 2001.
-
-   [RFC-RANDOM]
-        D. Eastlake, S. Crocker, and J. Schiller, ``Randomness
-        Recommendations for Security.''  RFC 1750.  December 1994.
-
-   [RFC-RELATED]
-        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
-        2387.  August 1998.
-
-   [NIST-SHA1]
-        NIST FIPS PUB 180-1, ``Secure Hash Standard.''  National
-        Institute of Standards and Technology, U.S. Department of
-        Commerce.  May 1994.  DRAFT.
-
-   [RFC-SMTP]
-        J. Klensin, editor, ``Simple Mail Transfer Protocol.''  RFC
-        2821.  April 2001.
-
-8.  Authors' Addresses
-
-       Eric Allman
-       Sendmail, Inc.
-       6425 Christie Ave, 4th Floor
-       Emeryville, CA  94608
-       U.S.A.
-
-       E-Mail: eric@Sendmail.COM
-       Phone: +1 510 594 5501
-       Fax: +1 510 594 5429
-
-
-       Tony Hansen
-       AT&T Laboratories
-       Lincroft, NJ 07738
-       U.S.A.
-
-       Phone: +1 732 576 3207
-       E-Mail: tony@att.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allman & Hansen                                               [Page 7]
-
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-03.txt b/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-03.txt
deleted file mode 100644
index 5ef65831..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-03.txt
+++ /dev/null
@@ -1,565 +0,0 @@
-
-
-
-
-Internet Draft                                               E. Allman
-draft-ietf-msgtrk-trkstat-03.txt                        Sendmail, Inc.
-Valid for six months                                  November 2, 2001
-Updates: RFC 1893
-
-
-
-
-              The Message/Tracking-Status MIME Extension
-
-                  <draft-ietf-msgtrk-trkstat-03.txt>
-
-Status of This Memo
-
-     This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.  Internet-Drafts are
-working documents of the Internet Engineering Task Force (IETF), its
-areas, and its working groups.  Note that other groups may also
-distribute working documents as Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other documents
-at any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at:
-
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at:
-
-    http://www.ietf.org/shadow.html
-
-
-     This document is a submission by the MSGTRK Working Group of the
-Internet Engineering Task Force (IETF).  Comments should be submitted
-to the ietf-msgtrk@imc.org mailing list.  An archive of the mailing
-list may be found at
-
-    http://www.imc.org/ietf-msgtrk/index.html
-
-
-     Distribution of this memo is unlimited.
-
-1.  Abstract
-
-        Message Tracking is expected to be used to determine the
-   status of undelivered e-mail upon request.  Tracking is used in
-   conjunction with Delivery Status Notifications [RFC-DSN-SMTP] and
-   Message Disposition Notifications [RFC-MDN]; generally, a message
-   tracking request will be issued only when a DSN or MDN has not been
-   received within a reasonable timeout period.
-
-        This memo defines a MIME [RFC-MIME] content-type for message
-   tracking status in the same spirit as RFC 1894, ``An Extensible
-   Message Format for Delivery Status Notifications'' [RFC-DSN-STAT].
-
-Internet Draft          Message/Tracking-Status       November 2, 2001
-
-
-   It is to be issued upon a request as described in ``Message
-   Tracking Query Protocol'' [DRAFT-MTRK-MTQP].  This memo defines
-   only the format of the status information.  An extension to SMTP
-   [RFC-ESMTP] to label messages for further tracking and request
-   tracking status is defined in a separate memo [DRAFT-MTRK-SMTPEXT].
-
-2.  Other Documents and Conformance
-
-        The model used for Message Tracking is described in [DRAFT-
-   MTRK-MODEL].
-
-        Message tracking is intended for use as a "last resort"
-   mechanism.  Normally, Delivery Status Notifications (DSNs) [RFC-
-   DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]
-   would provide the primary delivery status.  Only if no response is
-   received from either of these mechanisms would Message Tracking be
-   used.
-
-        This document is based on [RFC-DSN-STAT].  Sections 1.3
-   (Terminology), 2.1.1 (General conventions for DSN fields), 2.1.2
-   ("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC
-   822) of [RFC-DSN-STAT] are included into this document by
-   reference.  Other sections are further incorporated as described
-   herein.
-
-        Syntax notation in this document conforms to [RFC-ABNF].
-
-        The following lexical tokens, defined in [RFC-MSGFMT], are
-   used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF,
-   DIGIT, LF, linear-white-space, SPACE, text.  The date-time lexical
-   token is defined in [RFC-HOSTREQ].
-
-        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
-   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
-   in this document are to be interpreted as described in RFC 2119
-   [RFC-KEYWORDS].
-
-
-3.  Format of a Message Tracking Status Notification
-
-        A Message Tracking Status Notification (MTSN) is intended to
-   be returned as the body of a Message Tracking request [DRAFT-MTRK-
-   MTQP].  The actual body MUST be a multipart/related [RFC-RELATED]
-   with type parameter of "message/tracking-status"; each subpart MUST
-   be of type "message/tracking-status" as described herein.  The
-   multipart/related body can include multiple message/tracking-status
-   parts if an MTQP server chains requests to the next server; see
-   [DRAFT-MTRK-MODEL] and [DRAFT-MTRK-MTQP] for more information about
-   chaining.
-
-   3.1.  The message/tracking-status content-type
-
-           The message/tracking-status content-type is defined as
-      follows:
-
-
-
-
-Allman                                                        [Page 2]
-
-Internet Draft          Message/Tracking-Status       November 2, 2001
-
-
-          MIME type name:           message
-          MIME subtype name:        tracking-status
-          Optional parameters:      none
-          Encoding considerations:  "7bit" encoding is sufficient and
-                                    MUST be used to maintain readability
-                                    when viewed by non-MIME mail readers.
-          Security considerations:  discussed in section 4 of this memo.
-
-
-           The body of a message/tracking-status is modeled after
-      [RFC-DSN-STAT].  That body consists of one or more "fields"
-      formatted to according to the ABNF of RFC 2822 header "fields"
-      (see [RFC-MSGFMT]).  The per-message fields appear first,
-      followed by a blank line.  Following the per-message fields are
-      one or more groups of per-recipient fields.  Each group of per-
-      recipient fields is preceded by a blank line.  Note that there
-      will be a blank line between the final per-recipient field and
-      the MIME boundary, since one CRLF is necessary to terminate the
-      field, and a second is necessary to introduce the MIME boundary.
-      Formally, the syntax of the message/tracking-status content is
-      as follows:
-
-          tracking-status-content =
-                    per-message-fields 1*( CRLF per-recipient-fields )
-
-      The per-message fields are described in section 3.2.  The per-
-      recipient fields are described in section 3.3.
-
-      3.1.1.  General conventions for MTSN fields
-
-              Section 2.1.1 (General conventions for DSN fields) of
-         [RFC-DSN-STAT] is included herein by reference.  Notably, the
-         definition of xtext is identical to that of that document.
-
-      3.1.2.  *-type subfields
-
-              Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is
-         included herein by reference.  Notably, the definitions of
-         address-type, diagnostic-type, and MTA-name type are
-         identical to that of RFC 1894.
-
-
-   3.2.  Per-Message MTSN Fields
-
-           Some fields of an MTSN apply to all of the addresses in a
-      single envelope.  These fields may appear at most once in any
-      MTSN.  These fields are used to correlate the MTSN with the
-      original message transaction and to provide additional
-      information which may be useful to gateways.
-
-          per-message-fields =
-                    original-envelope-id-field CRLF
-                    reporting-mta-field CRLF
-                    arrival-date CRLF
-                    *( extension-field CRLF )
-
-
-
-Allman                                                        [Page 3]
-
-Internet Draft          Message/Tracking-Status       November 2, 2001
-
-
-      3.2.1.  The Original-Envelope-Id field
-
-              The Original-Envelope-Id field is defined as in section
-         2.2.1 of [RFC-DSN-STAT].  This field is REQUIRED.
-
-      3.2.2.  The Reporting-MTA field
-
-              The Reporting-MTA field is defined as in section 2.2.2
-         of [RFC-DSN-STAT].  This field is REQUIRED.
-
-      3.2.3.  The Arrival-Date field
-
-              The Arrival-Date field is defined as in section 2.2.5 of
-         [RFC-DSN-STAT].  This field is REQUIRED.
-
-
-   3.3.  Per-Recipient MTSN fields
-
-           An MTSN contains information about attempts to deliver a
-      message to one or more recipients.  The delivery information for
-      any particular recipient is contained in a group of contiguous
-      per-recipient fields.  Each group of per-recipient fields is
-      preceded by a blank line.
-
-           The syntax for the group of per-recipient fields is as
-      follows:
-
-          per-recipient-fields =
-                    original-recipient-field CRLF
-                    final-recipient-field CRLF
-                    action-field CRLF
-                    status-field CRLF
-                    [ remote-mta-field CRLF ]
-                    [ last-attempt-date-field CRLF ]
-                    [ will-retry-until-field CRLF ]
-                    *( extension-field CRLF )
-
-
-      3.3.1.  Original-Recipient field
-
-              The Original-Recipient field is defined as in section
-         2.3.1 of [RFC-DSN-STAT].  This field is REQUIRED.
-
-      3.3.2.  Final-Recipient field
-
-              The required Final-Recipient field is defined as in
-         section 2.3.2 of [RFC-DSN-STAT].  This field is REQUIRED.
-
-      3.3.3.  Action field
-
-              The required Action field indicates the action performed
-         by the Reporting-MTA as a result of its attempt to deliver
-         the message to this recipient address.  This field MUST be
-         present for each recipient named in the MTSN.  The syntax is
-         as defined in section 2.3.3 of RFC 1894.  This field is
-         REQUIRED.
-
-
-Allman                                                        [Page 4]
-
-Internet Draft          Message/Tracking-Status       November 2, 2001
-
-
-              Valid actions are:
-
-         failed       The message could not be delivered.  If DSNs
-                      have been enabled, a "failed" DSN should already
-                      have been returned.
-
-         delayed      The message is currently waiting in the MTA
-                      queue for future delivery.  Essentially, this
-                      action means "the message is located, and it is
-                      here."
-
-         delivered    The message has been successfully delivered to
-                      the final recipient.  This includes "delivery"
-                      to a mailing list exploder.  It does not
-                      indicate that the message has been read.  No
-                      further information is available; in particular,
-                      the tracking agent SHOULD NOT attempt further
-                      "downstream" tracking requests.
-
-         expanded     The message has been successfully delivered to
-                      the recipient address as specified by the
-                      sender, and forwarded by the Reporting-MTA
-                      beyond that destination to multiple additional
-                      recipient addresses.  However, these additional
-                      addresses are not trackable, and the tracking
-                      agent SHOULD NOT attempt further "downstream"
-                      tracking requests.
-
-         relayed      The message has been delivered into an
-                      environment that does not support message
-                      tracking.  No further information is available;
-                      in particular, the tracking agent SHOULD NOT
-                      attempt further "downstream" tracking requests.
-
-         transferred  The message has been transferred to another
-                      MTRK-compliant MTA.  The tracking agent SHOULD
-                      attempt further "downstream" tracking requests
-                      unless that information is already given in a
-                      chaining response.
-
-         opaque       The message may or may not have been seen by
-                      this system.  No further information is
-                      available or forthcoming.
-
-              There may be some confusion between when to use
-         "expanded" versus "delivered".  Whenever possible, "expanded"
-         should be used when the MTA knows that the message will be
-         sent to multiple addresses.  However, in some cases the
-         delivery occurs to a program which, unknown to the MTA,
-         causes mailing list expansion; in the extreme case, the
-         delivery may be to a real mailbox that has the side effect of
-         list expansion.  If the MTA cannot ensure that this delivery
-         will cause list expansion, it should set the action to
-         "delivered".
-
-
-
-
-Allman                                                        [Page 5]
-
-Internet Draft          Message/Tracking-Status       November 2, 2001
-
-
-      3.3.4.  Status field
-
-              The Status field is defined as in RFC 1894 section
-         2.3.4.  A new code is added to RFC 1893 [RFC-EMSSC],
-         "Enhanced Mail System Status Codes",
-
-             X.1.9   Message relayed to non-compliant mailer"
-
-                 The mailbox address specified was valid, but the
-                 message has been relayed to a system that does not
-                 speak this protocol; no further information can be
-                 provided.
-         A 2.1.9 Status field MUST be used exclusively with a
-         "relayed" Action field.  This field is REQUIRED.
-
-      3.3.5.  Remote-MTA field
-
-              The Remote-MTA field is defined as in section Reference
-         2.3.5 of [RFC-DSN-STAT].  This field MUST NOT be included if
-         no delivery attempts have been made or if the Action field
-         has value "opaque".  If delivery to some agent other than an
-         MTA (for example, a Local Delivery Agent) then this field MAY
-         be included, giving the name of the host on which that agent
-         was contacted.
-
-      3.3.6.  Last-Attempt-Date field
-
-              The Last-Attempt-Date field is defined as in section
-         Reference 2.3.7 of [RFC-DSN-STAT].  This field is REQUIRED if
-         any delivery attempt has been made and the Action field does
-         not have value "opaque", in which case it will specify when
-         it last attempted to deliver this message to another MTA or
-         other Delivery Agent.  This field MUST NOT be included if no
-         delivery attempts have been made.
-
-      3.3.7.  Will-Retry-Until field
-
-              The Will-Retry-Until field is defined as in section
-         Reference 2.3.8 of [RFC-DSN-STAT].  If the message is not in
-         the local queue or the Action field has the value ``opaque''
-         the Will-Retry-Until field MUST NOT be included; otherwise,
-         this field SHOULD be included.
-
-   3.4.  Extension fields
-
-           Future extension fields may be defined as defined in
-      section 2.4 of [RFC-DSN-STAT].
-
-   3.5.  Interaction Between MTAs and LDAs
-
-           A message that has been delivered to a Local Delivery Agent
-      (LDA) that understands message tracking (in particular, an LDA
-      speaking LMTP [RFC-LMTP] that supports the MTRK extension)
-      SHOULD pass the tracking request to the LDA.  In this case, the
-      Action field for the MTA->LDA exchange will look the same as a
-      transfer to a compliant MTA; that is, a "transferred" tracking
-
-
-Allman                                                        [Page 6]
-
-Internet Draft          Message/Tracking-Status       November 2, 2001
-
-
-      status will be issued.
-
-
-4.  Security Issues
-
-   4.1.  Forgery
-
-           Malicious servers may attempt to subvert message tracking
-      and return false information.  This could result in misdirection
-      or misinterpretation of results.
-
-   4.2.  Confidentiality
-
-           Another dimension of security is confidentiality.  There
-      may be cases in which a message recipient is autoforwarding
-      messages but does not wish to divulge the address to which the
-      messages are autoforwarded.  The desire for such confidentiality
-      will probably be heightened as "wireless mailboxes", such as
-      pagers, become more widely used as autoforward addresses.
-
-           MTA authors are encouraged to provide a mechanism which
-      enables the end user to preserve the confidentiality of a
-      forwarding address.  Depending on the degree of confidentiality
-      required, and the nature of the environment to which a message
-      were being forwarded, this might be accomplished by one or more
-      of:
-
-      (a)  respond with a "relayed" tracking status when a message is
-           forwarded to a confidential forwarding address, and
-           disabling further message tracking requests.
-
-      (b)  declaring the message to be delivered, issuing a
-           "delivered" tracking status, re-sending the message to the
-           confidential forwarding address, and disabling further
-           message tracking requests.
-
-           The tracking algorithms MUST NOT allow tracking through
-      list expansions.  When a message is delivered to a list, a
-      tracking request MUST respond with an "expanded" tracking status
-      and MUST NOT display the contents of the list.
-
-5.  Acknowledgements
-
-        Several individuals have commented on and enhanced this draft,
-   including Tony Hansen, Philip Hazel, Alexey Melnikov, Lyndon
-   Nerenberg, Chris Newman, Gregory Neil Shapiro, and Dan Wing.
-
-6.  References
-
-   [DRAFT-MTRK-MODEL]
-        T. Hansen, ``Message Tracking Model and Requirements.''
-        draft-ietf-msgtrk-model-03.txt.  November 2000.
-
-   [DRAFT-MTRK-MTQP]
-        T. Hansen, ``Message Tracking Query Protocol.''  draft-ietf-
-        msgtrk-mtqp-01.txt.  November 2000.
-
-
-Allman                                                        [Page 7]
-
-Internet Draft          Message/Tracking-Status       November 2, 2001
-
-
-   [DRAFT-MTRK-SMTPEXT]
-        E. Allman, ``SMTP Service Extension for Message Tracking.''
-        draft-ietf-msgtrk-smtpext-00.txt.  December 2000.
-
-   [RFC-ABNF]
-        Crocker, D., Editor, and P. Overell, ``Augmented BNF for
-        Syntax Specifications: ABNF'', RFC 2234, November 1997.
-
-   [RFC-DSN-REPT]
-        G. Vaudreuil, ``The Multipart/Report Content Type for the
-        Reporting of Mail System Administrative Messages.''  RFC 1892.
-        January 1996.
-
-   [RFC-DSN-SMTP]
-        K. Moore, ``SMTP Service Extension for Delivery Status
-        Notifications.''  RFC 1891.  January 1996.
-
-   [RFC-DSN-STAT]
-        K. Moore and G. Vaudreuil, ``An Extensible Message Format for
-        Delivery Status Notifications.''  RFC 1894.  January 1996.
-
-   [RFC-EMSSC]
-        G. Vaudreuil, ``Enhanced Mail System Status Codes.''  RFC
-        1893.  January 1996.
-
-   [RFC-ESMTP]
-        Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N.
-        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.
-        November 1995.
-
-   [RFC-HOSTREQ]
-        R. Braden (ed.), ``Requirements for Internet Hosts --
-        Application and Support.''  STD 3, RFC 1123.  October 1989.
-
-   [RFC-KEYWORDS]
-        S. Bradner, ``Key words for use in RFCs to Indicate
-        Requirement Levels.''  RFC 2119.  March 1997.
-
-   [RFC-LMTP]
-        J. Myers, ``Local Mail Transfer Protocol.''  RFC 2033.
-        October 1996.
-
-   [RFC-MDN]
-        R. Fajman, ``An Extensible Message Format for Message
-        Disposition Notifications.''  RFC 2298.  March 1998.
-
-   [RFC-MIME]
-        N. Freed and N. Borenstein, ``Multipurpose Internet Mail
-        Extensions (MIME) Part One: Format of Internet Message
-        Bodies.''  RFC 2045.  November 1996.
-
-   [RFC-MSGFMT]
-        P. Resnick, editor, ``Internet Message Format.''  RFC 2822.
-        April 2001.
-
-
-
-
-Allman                                                        [Page 8]
-
-Internet Draft          Message/Tracking-Status       November 2, 2001
-
-
-   [RFC-RELATED]
-        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
-        2387.  August 1998.
-
-7.  Author's Address
-
-       Eric Allman
-       Sendmail, Inc.
-       6425 Christie Ave, 4th Floor
-       Emeryville, CA  94608
-       U.S.A.
-
-       E-Mail: eric@Sendmail.COM
-       Phone: +1 510 594 5501
-       Fax: +1 510 594 5429
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allman                                                        [Page 9]
-
diff --git a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt b/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
deleted file mode 100644
index f8198f1a..00000000
--- a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
+++ /dev/null
@@ -1,472 +0,0 @@
-
-
-
-Internet Engineering Task Force                        Motonori Nakamura
-INTERNET-DRAFT                                          Kyoto University
-Expires: May 8, 2002                            Jun-ichiro itojun Hagino
-                                                 IIJ Research Laboratory
-                                                        November 8, 2001
-
-
-                   IPv6 SMTP operational requirements
-            draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as ``work in progress.''
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-Distribution of this memo is unlimited.
-
-The internet-draft will expire in 6 months.  The date of expiration will
-be May 8, 2002.
-
-
-Abstract
-
-This document lists operational requirements for IPv6 SMTP and
-IPv6-capable MX DNS records.  As IPv6 SMTP servers are deployed, it has
-become apparent that certain configurations are necessary in
-IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP
-operation.  This document clarifies the problems that exist in the
-transition period between IPv4 SMTP and IPv6 SMTP.  It also defines
-operational requirements for stable IPv4/v6 SMTP operation.
-
-This document does not define any new protocol.
-
-
-1.  Summary of IPv4 MX operation
-
-For reference purposes, this section outlines how email message delivery
-is performed in an IPv4-only environment [Partridge, 1986] .
-
-
-
-NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 1]
-
-
-DRAFT              IPv6 SMTP operational requirements      November 2001
-
-In IPv4 SMTP operation, the MX record "example.org." would be registered
-as follows:
-
-     example.org.            IN MX   1  mx1.example.org.
-                             IN MX   10 mx10.example.org.
-     mx1.example.org.        IN A    192.0.2.1
-     mx10.example.org.       IN A    192.0.2.2
-
-When an MTA wishes to deliver a message to a particular destination
-(e.g.  "foo@example.org"), the MTA sends DNS queries in the following
-order:
-
-o Lookup MX record for "example.org.".
-
-  o If an MX record is returned, lookup an A record for the right-hand
-    side of the MX record.
-
-  o If a CNAME record is returned, try to chase the CNAME chain.
-    Eventually an A record will be reached.
-
-    NOTE: RFC2181 [Elz, 1997] prohibits MX records from pointing to
-    CNAME records.  However, this was not prohibited in earlier RFCs.
-    [Partridge, 1986] CNAME chasing logic is mentioned here just for
-    backwards compatibility.  Implementers may want to avoid CNAME
-    chasing to better conform with RFC2181.
-
-  o If the MX lookup fails with NO_DATA, it means that there is no MX
-    record, but there may be other records (e.g. "example.org.").
-    Lookup the A record for "example.org.".
-
-  o If the MX lookup fails with HOST_NOT_FOUND, it means that there is
-    no record at all for "example.org.".  This results in a delivery
-    failure.
-
-
-2.  MX records and IPv6 SMTP operation
-
-The following sections explain how to make IPv4 SMTP and IPv6 SMTP
-coexist in a dual-stack environment during the transition period between
-an IPv4-only environment and an IPv6-only environment.  In the future,
-when the migration to an IPv6-only network is complete, IPv4/v6 SMTP
-interaction will be ignored.
-
-Similar to the way RFC's for IPv6 DNS lookup [Thomson, 1995; Crawford,
-2000] use IN class for both IPv4 and IPv6, IN MX records will be used
-for both IPv4 and IPv6.
-
-For simplicity, this document lists DNS records for IPv6 addresses as
-AAAA records, not as A6 records [Crawford, 2000] .  In reality, a chain
-of A6 records can be used, instead of AAAA records.
-
-
-
-
-NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 2]
-
-
-DRAFT              IPv6 SMTP operational requirements      November 2001
-
-There are several technologies defined for the transition from IPv4 to
-IPv6.  This document concentrates on SMTP issues in a dual-stack
-environment.  Afterall, there are no special SMTP considerations for
-translators; If there is SMTP traffic from an IPv6 MTA to an IPv4 MTA
-over an IPv6-to-IPv4 translator, the IPv4 MTA will consider this normal
-IPv4 SMTP traffic.  Protocols like IDENT [StJohns, 1993] , however, may
-require special consideration when translators are used.
-
-This document does not discuss the problems encountered when the sending
-MTA and the receiving MTA have no common protocol (e.g. the sending MTA
-is IPv4-only while the receiving MTA is IPv6-only).  Such a situation
-should be resolved by making either side dual-stack or by making either
-side use a protocol translator.
-
-
-3.  SMTP sender algorithm in a dual-stack environment
-
-In a dual-stack environment MX records for a domain resemble the
-following:
-
-     example.org.            IN MX   1  mx1.example.org.
-                             IN MX   10 mx10.example.org.
-     mx1.example.org.        IN A    192.0.2.1        ; dual-stack
-                             IN AAAA 3ffe:501:ffff::1
-     mx10.example.org.       IN AAAA 3ffe:501:ffff::2 ; IPv6 only
-
-For a single MX record there are many possible final states, including:
-(a) one or more A records for the IPv4 destination, (b) one or more AAAA
-records for the IPv6 destination, (c) a mixture of A and AAAA records.
-Because multiple MX records may be defined using different preference
-values, multiple addresses based on multiple MX's must be traversed.
-Domains without MX records and failure recovery cases must be handled
-properly as well.
-
-The algorithm for an SMTP sender is basically the same as that for an
-IPv4-only sender, but it now includes AAAA lookups of MX records for
-SMTP-over-IPv6 delivery.  IPv4/v6 dual stack destinations should be
-treated just like multihomed destinations as described in RFC2821
-[Klensin, 2001] section 5.  When there is no reachable destionation
-address record found (for example, the sender MTA is IPv4 only and there
-are no A records available) the case should be treated just like MX
-records without address records.
-
-     ; if the sender MTA is IPv4 only, email delivery to a.example.org
-     ; should fail with the same error as deliveries to b.example.org.
-     a.example.org.          IN MX    1  mx1.a.example.org.
-     mx1.a.example.org.      IN AAAA  3ffe:501:ffff::1 ; IPv6 only
-     b.example.org.          IN MX    1  mx1.b.example.org.
-     mx1.b.example.org.      IN HINFO "NO ADDRESS RECORDS"
-
-
-
-
-
-NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 3]
-
-
-DRAFT              IPv6 SMTP operational requirements      November 2001
-
-(1)  Lookup the MX record for the destination domain.  If a CNAME record
-     is returned, go to step (1) with the query's result.  If any MX
-     records are returned, go to step (2) with the query's result.  If
-     NO_DATA is returned, there is no MX record.  Go to step (3).  If
-     HOST_NOT_FOUND is returned, there is no domain.  Raise a permanent
-     email delivery failure.  Finish.
-
-     NOTE:  the previous section contains a note about MX records that
-     point to CNAME records.
-
-(2)  There are multiple MX records.  Sort the MX records in ascending
-     order based on their preference values, and loop over steps (3) to
-     (8).
-
-(3)  If the sending MTA has IPv4 capability, lookup the A record.  Keep
-     the resulting address until step (5).
-
-(4)  If the sending MTA has IPv6 capability, lookup the AAAA record.
-
-(5)  If there is no A or AAAA record present, try the next MX record (go
-     to step (3)).  Sort the query's result based on the
-     implementation's preference of A or AAAA records.  If it is
-     desirable to encourage the transition from IPv4 SMTP to IPv6 SMTP,
-     AAAA records should take precedence.
-
-(6)  For each of the addresses or each part of the list of addresses,
-     loop over steps (7) to (8).  If no reachable destination is found,
-     and if a list of MX records is being traversed, try the next MX
-     record (go to step (3)).  If there is no list of MX records, or if
-     the end of the list of MX records has been reached, raise a
-     temporary email delivery failure.  Finish.
-
-(7)  Try to make a TCP connection to the destination.  If unsuccessful,
-     try the next available address.  If successful, go to step (8).
-
-(8)  Try an SMTP protocol negotiation.  If the SMTP protocol negotiation
-     fails with TEMPFAIL (4xx), try the next MX record (go to step (3)).
-     If successful, SMTP delivery has succeeded.  Finish.
-
-
-4.  MX configuration in the recipient domain
-
-4.1.  Ensuring reachability for both protocol versions
-
-If a site has dual-stack reachability, the site SHOULD configure both A
-and AAAA records for its MX hosts.  This will help both IPv4 and IPv6
-senders to reach the site efficiently.
-
-4.2.  Reachability between the primary and secondary MX
-
-When entering MX records in a DNS database in a dual-stack environment,
-reachability between MX hosts must be considered carefully.  Suppose all
-
-
-NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 4]
-
-
-DRAFT              IPv6 SMTP operational requirements      November 2001
-
-inbound email is to be gathered at the primary MX host,
-"mx1.example.org.":
-
-     example.org.    IN MX   1   mx1.example.org.
-                     IN MX   10  mx10.example.org.
-                     IN MX   100 mx100.example.org.
-
-If "mx1.example.org" is an IPv6-only node, and the others are IPv4-only
-nodes, there is no reachability between the primary MX host and the
-other MX hosts.  When email reaches one of the secondary MX hosts, it
-cannot be relayed to the primary MX host.
-
-     ; This configuration is troublesome.
-     ; No secondary MX can reach mx1.example.org.
-     example.org.    IN MX   1   mx1.example.org.     ; IPv6 only
-                     IN MX   10  mx10.example.org.    ; IPv4 only
-                     IN MX   100 mx100.example.org.   ; IPv4 only
-
-The easiest possible configuration is to configure the primary MX host
-as a dual-stack node.  By doing so, secondary MX hosts will have no
-problem reaching the primary MX host.
-
-     ; This configuration works well.
-     ; The secondary MX hosts are able to relay email to the primary MX host
-     ; without any problems.
-     example.org.    IN MX   1   mx1.example.org.     ; dual-stack
-                     IN MX   10  mx10.example.org.    ; IPv4 only
-                     IN MX   100 mx100.example.org.   ; IPv6 only
-
-There are many other ways to ensure that the primary MX host and the
-secondary MX hosts can reach one another.  For example, it is possible
-to configure the secondary MX hosts to route email statically, i.e.
-without considering the DNS MX configuration.  It is also possible to
-establish an alternate email routing path (e.g. UUCP or an IPv4/v6
-translator) between the secondary MX host and the primary MX host.
-
-
-5.  Operational experience
-
-Many of the existing IPv6-ready MTA's appear to work in the way
-documented in section 3.
-
->From past experiments and operational experience, it is known that most
-of the existing IPv4-only MTA's will not be confused by AAAA records
-that are registered for MX hostnames.  No experiments were conducted
-with A6 records.
-
-There were, however, cases where IPv6-ready MTA's were confused by
-broken DNS servers.  When attempting to canonify a hostname, some broken
-name servers return SERVFAIL, a temporary failure, on AAAA record
-lookups.  Upon this temporary failure, the email is queued for a later
-attempt.  In the interest of IPv4/v6 interoperability, these broken DNS
-
-
-NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 5]
-
-
-DRAFT              IPv6 SMTP operational requirements      November 2001
-
-servers should be fixed.
-
-
-6.  Open issues
-
-o How should scoped addresses in email addresses be interpreted on
-  MTA's?  As email is relayed between MTA's, interpretation of scoped
-  addresses can be different between MTA's.  Afterall, intermediate
-  MTA's may be in different scope zones than the originator.  If a
-  scoped IPv6 address is returned as the result of a DNS lookup, how
-  should MTA's behave?
-
-  If scoped addresses in ``route-addr'' specifications  [Crocker, 1982]
-  are considered, e.g.
-
-                 <@kame.net,@[fec0::1]:itojun@itojun.org>
-
-  it gets even trickier.  Luckily, the route-addr form was obsoleted by
-  RFC2822 [Resnick, 2001] .
-
-
-7.  Security considerations
-
-As mentioned in the ``Open issues'' section, it could be problematic if
-the route-addr email address format is used across multiple scope zones.
-MTA's would need to reject email with improper route-addr email address
-formats.  One example of an improper route-addr format is an email from
-outside the site border which carries a numeric site-local address in
-the route-addr format.
-
-
-References
-
-Partridge, 1986.
-C. Partridge, "Mail routing and the domain system" in RFC974 (January
-1986). ftp://ftp.isi.edu/in-notes/rfc974.txt.
-
-Elz, 1997.
-R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181
-(July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt.
-
-Thomson, 1995.
-S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
-RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
-
-Crawford, 2000.
-M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
-Address Aggregation and Renumbering" in RFC2874 (July 2000).
-ftp://ftp.isi.edu/in-notes/rfc2874.txt.
-
-StJohns, 1993.
-M. StJohns, "Identification Protocol" in RFC1413 (January 1993).
-
-
-NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 6]
-
-
-DRAFT              IPv6 SMTP operational requirements      November 2001
-
-ftp://ftp.isi.edu/in-notes/rfc1413.txt.
-
-Klensin, 2001.
-J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April
-2001). ftp://ftp.isi.edu/in-notes/rfc2821.txt.
-
-Crocker, 1982.
-D. Crocker, "Standard for the format of ARPA Internet text messages" in
-RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt.
-
-Resnick, 2001.
-P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001).
-ftp://ftp.isi.edu/in-notes/rfc2822.txt.
-
-
-Change history
-
-00 -> 01
-     Corrected the email address notation for source-routed emails,
-     based on a comment from Gregory Neil Shapiro.
-
-01 -> 02
-     Change a reference to refer to RFC2822, not 822.  Used
-     "example.org", not "sample.org".  These changes were based on
-     comments from Arnt Gulbrandsen.  Added an ``Operational
-     experiences'' section.  Clarified the case where an MX record
-     points to a CNAME record, based on comments from Mohsen Souissi.
-
-02 -> 03
-     In some cases, IPv6-ready MTA's are troubled by incorrect DNS
-     server responses for AAAA queries.  This change was based on
-     comments from Gregory Neil Shapiro.
-
-03 -> 04
-     Grammar cleanups by JJ Behrens.  More text on the delivery error
-     cases.
-
-
-Acknowledgements
-
-This draft was written based on discussions with Japanese IPv6 users and
-help from the WIDE research group.  Here is a (probably incomplete) list
-of people who contributed to the draft: Gregory Neil Shapiro, Arnt
-Gulbrandsen, Mohsen Souissi, and JJ Behrens.
-
-
-Author's address
-
-
-
-
-
-
-
-NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 7]
-
-
-DRAFT              IPv6 SMTP operational requirements      November 2001
-
-     Motonori NAKAMURA
-     Center for Information and Multimedia Studies, Kyoto University
-     Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN
-     Tel: +81-75-753-9063
-     Fax: +81-75-753-9056
-     Email: motonori@media.kyoto-u.ac.jp
-
-     Jun-ichiro itojun HAGINO
-     Research Laboratory, Internet Initiative Japan Inc.
-     Takebashi Yasuda Bldg.,
-     3-13 Kanda Nishiki-cho,
-     Chiyoda-ku,Tokyo 101-0054, JAPAN
-     Tel: +81-3-5259-6350
-     Fax: +81-3-5259-6351
-     Email: itojun@iijlab.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 8]
-
diff --git a/Documentation/en/I-D/draft-ietf-palme-select-00.txt b/Documentation/en/I-D/draft-ietf-palme-select-00.txt
deleted file mode 100644
index f304bff0..00000000
--- a/Documentation/en/I-D/draft-ietf-palme-select-00.txt
+++ /dev/null
@@ -1,3880 +0,0 @@
-Network Working Group                                      Jacob Palme
-Internet Draft                                Stockholm University/KTH
-draft-ietf-palme-select-00.txt                             Johan Kaers
-Intended-for: Proposed standard                                Starlab
-Expires: December 2000                                       June 2000
-
-
-
-
-
-The SELECT Protocol for Rating and Filtering
-
-
-
-
-Status of this Document
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time.  It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 2000. All Rights Reserved.
-
-Abstract
-
-The SELECT protocol allows Internet users to supply their ratings of
-Internet documents, and to use ratings provided by other users to
-filter and select what to read In particular, SELECT supports so-called
-collaborative filtering. By this is meant that the filtering and
-selection for a particular user is made based on ratings provided by
-special groups of raters, such as peer groups, people with similar
-values, interests and expertise as the person for whom the selecting
-and filtering is done.
-
-The SELECT functionality is downwards compatible with PICS [PICS 1,
-PICS 2], but a major difference is that while PICS is mainly oriented
-towards keeping out unsuitable information from children
-(blackballing), SELECT is mainly oriented towards helping people find
-the best and most valuable information for them on the Internet
-(goldballing). A syntactical difference from PICS is that the encodings
-in SELECT are using the XML encoding format.
-
-More information
-
-More information and links to the most recent versions of this document
-can be found at http://dsv.su.se/jpalme/ietf/selprot.html. A mailing
-list will be started in the middle of June 2000, for information on how
-to subscribe see the above URL.
-
-Table of Contents
-
-1.   Terminology
-2.   Definitions
-3.   Protocol elements summary table
-4.   Handling of anonymous ratings
-5.   Style sheet information in XML encodings
-6.   Submission points
-7.   Protocol elements full specifications
-     7.1 Validation of XML Encodings
-     7.2 The DTD for an atomic rating
-     7.3 Get-Service-Description-List (XML)
-     7.4 Get-Service-Description
-     7.5 Send-Rating
-     7.6 Set-Profile
-     7.7 Get-Profile
-     7.8 Login
-     7.9 Logout
-     7.10Get-Atomic-Ratings
-     7.11Simple-Search Operation
-     7.12Advanced-Search Operation (Not yet ready)
-     7.13Evaluate Operation
-     7.14Exchange-Ratings-Data (not yet ready)
-8.   The SELECT general service description
-     8.1 Example
-9.   Example of file structure on a SELECT server
-10.  Issues for further study
-11.  The SELECT Agent protocol
-12.  Protocol Implemtation Status
-13.  Security considerations
-14.  Copyright
-15.  Acknowledgments
-16.  References
-17.  Author's Addresses
-
-
-1.    Terminology
-
-Term              Description
-----              -----------
-
-Aggregate rating  A rating, which is computed based on one or more
-                  atomic ratings, combined in some way. A SELECT
-                  server may provide several different aggregate
-                  ratings, computed in different ways, for example
-                  based on only non-anonymous ratings, based on only
-                  ratings by certain experts or members of a
-                  specific peer group. Also different aggregation
-                  methods can be used, such as average, median or
-                  lower quartile. (Using the lower quartile will
-                  favour controversial documents, which may
-                  sometimes be desirable.)
-
-Anonymous rating  A rating, where the rater is not idenfied. See
-                  chapter 4.
-
-Atomic rating     A rating provided by one user on one document.
-                  Several atomic ratings of the same document can be
-                  combined to produce an aggregate rating. See
-                  chapter 7.2.
-
-Collaborative     A rating provider for a user, based on ratings
-rating            made by other users in a peer group, which has
-                  shown itself to have the same rating values as the
-                  user getting the rating.
-                  '
-ML                Machine Learning: Technology where a computer
-                  program learns by itself by observation of
-                  reality, for example by observation of human
-                  behaviour.
-
-NLP               Natural Language Processing: Processing of natural
-                  language text with programs, which can in some way
-                  analyze it, for example derive genre information
-                  from the text style.
-
-Non-anonymous     A rating, where the rater has to log in and
-rating            identify itself before being allowed to provide a
-                  non-anonymous rating. See chapter 4.
-
-Rating            Ratings are collections of descriptors of
-                  resources, which can be used as a basis for
-                  filtering.
-
-
-User              An agent providing ratings or using SELECT
-                  services. Can represent a user, but ratings may
-                  also be provided by other ways than direct user
-                  input, such as observation of user behaviour or
-                  linguistic analysis of documents.
-
-2.    Definitions
-
-Any occurence of "http://select/" in this document should in actual
-usage be replaced by the URL of a particular SELECT service.
-
-
-3.    Protocol elements summary table
-
-The SELECT protocols allow a SELECT server to keep a data base of
-ratings made my many different people on a resource, lika a web page.
-This data base can be used to find the aggregate ratings on resources
-and to search, using the aggregate rating as search criterium. Every
-server decides which and how many rating categories it provides.
-
-In addition to manually added ratings, the SELECT data base can also
-store ratings made by a machine, such as an NLP engine, and by
-automatic observation of user behaviour.
-
-The SELECT protocol can be used by Internet User Agents to submit
-ratings, get ratings, search and filter for a user. Such User Agents
-can be user-oriented servers, news servers and clients, web browsers,
-and plug-ins and client-side and server-side proxies.
-
-The SELECT protocol can also be used by autonomous agents, which can
-perform services like NLP rating, finding news of special interest to a
-particular user and e-mailing the user with this, etc.
-
-Name            Task                         Client(s)
-----            ----                         ---------
-
-Get             Find out which rating        Input reader ratings /
-service-descri  services are handled by      Another SELECT version
-ption-list      this server.                 1.0 server / A
-                                             filtering process, a
-                                             user or manager
-
-
-Get-service-de  Find out which rating        Input reader ratings /
-scription       descriptors are handled by   Another SELECT version
-                this rating service.         1.0 server / A
-                                             filtering process, a
-                                             user or manager
-
-
-Send-rating     Send a new atomic rating on  Input reader ratings /
-                a resource.                  Automatic rating agents
-
-
-Set-profile     Self-register a rater with   Input reader ratings, a
-                a server, as well as         user or manager
-                registering someone else as
-                a rater for a closed
-                server, or modifying the
-                profile of an existing
-                user.
-
-
-Get-profile     Get the profile of another   Input reader ratings, a
-                user, subject to access      user or manager
-                controls.
-
-
-Login           Establish credentials for a  All of the above
-                user.
-
-
-Logout          Waive credentials for a      All of the above
-                user.
-
-
-Get-atomic-rat  Get the ratings made by one  All of the above
-ings            or more named users on one
-                or more resources.
-
-
-Simple-Search   Make a search for rated      Rating search client, a
-                resources, HTML search       user.
-                query form.
-
-
-Advanced-Searc  Make a search for            Rating search client,
-h               resources, XML query form.   NLP module (to find
-                                             items which need NLP
-                                             ratings)
-
-
-Evaluate        Get the ratings for a list   Rating search client,
-                of resources.                news client, news
-                                             server, a user.
-
-
-Exchange-ratin  Mirror ratings data between  One SELECT version 1.0
-gs-data         two SELECT version 1.0       server.
-                servers.
-
-
-4.    Handling of anonymous ratings
-
-Ratings can be either identified or anonymous.
-
-All SELECT services may not allow anonymous ratings.
-
-Anonymous ratings are fully anonymous, no raterid of any kind is
-specified.
-
-Anonymous ratings are sent to a different URL (see chapter 6),
-containing /id/, than the URL for non-anonymous ratings. For anonymous
-ratings, the "raterid" has the special value "anonymous".
-
-When combining atomic ratings to aggregate ratings, different weight
-may be given to identified, anonymous ratings, including the weight
-zero to anonymous ratings.
-
-When retrieving atomic ratings, you will get identified ratings only
-for yourself. Other ratings are not returned or are returned only
-unidentifiable format.
-
-
-5.    Style sheet information in XML encodings
-
-The XML encodings produced by SELECT agents may contain style sheet
-information. An agent which does not use this information, should
-ignore it. Such an agent must be capable of receiving and ignoring
-style sheet information, but need not do any other processing of style
-sheet information.
-
-Such style sheet information may be:
-
-(a) A style sheet reference in the processing instruction head of an
-XML document.
-
-(b) A style sheet reference in the DTD file (not valid today, August
-1999, but may become valid in the future).
-
-Example: The following two XML data are semantically equal:
-
-Version 1:                       Version 2:
----------                        ---------
-
-
-<?xml version="1.0"?>            <?xml version="1.0"?>
-
-<!DOCTYPE send-rating-response   <?xml-stylesheet
-SYSTEM                           href="mystyle.css"
-"http://select/v1.0/send-rating- type="text/css">
-response.dtd">
-                                 <!DOCTYPE send-rating-response
-<send-rating-response            SYSTEM
-accepted="false"                 "http://select/v1.0/send-rating-re
-refuse-reason="accesscontrol"/>  sponse.dtd">
-
-                                 <send-rating-response
-                                 accepted="false"
-                                 refuse-reason="accesscontrol"
-                                 class="error"/>
-
-
-6.    Submission points
-
-Below are shown the entry points for access to the SELECT general
-service. For a specialised service, the word "general" below should be
-replaced by the subdirectory for that service.
-
-Operation          Service      Submission point
-
-Get-Service-Descri All          http://select/v1.0/select-service-description
-ption-List         services     s.xml
-
-Get-Service-Descri General      http://select/general/get-services.xml
-ption              service
-
-Send-Rating        General      http://select/v1.0/general/id/input-ratings
-                   service
-                                Note: For use by ratings supplied by
-                                identified raters.
-
-Send-Rating        General      http://select/v1.0/general/id/input-ratings
-                   service
-                                Note: For use for ratings supplied by
-                                identified raters.
-
-Send-Rating        General      http://ano.select/v1.0/general/input-ratings
-                   service      http://id.select/v1.0/general/input-ratings
-
-                                Note: ano.select is used to record anonymous
-                                ratings, id.select to record non-anonymous
-                                ratings. The different domain names are
-                                needed to keep the cookies different.
-
-Set-Profile        General      http://select/v1.0/general/id/profiles
-                   service
-
-Get-Profile        General      http://select/v1.0/general/id/profiles
-                   service
-
-Login              General      http://select/v1.0/general/id/login
-                   service
-
-Logout             General      http://select/v1.0/general/id/logout
-                   service
-
-Get-Atomic-Ratings General      http://select/v1.0/general/id/evaluator
-                   service
-
-Simple-Search      General      http://select//v1.0/general/simple-search
-                   service
-
-Advanced-Search    General      http://select/search
-                   service
-
-Evaluate           General      http://select/evaluator
-                   service
-
-7.    Protocol elements full specifications
-
-7.1   Validation of XML Encodings
-
-The DTDs and XML code in this specification has been validated using
-the XML validation service at
-http://www.stg.brown.edu/cgi-bin/xmlvalid/xmlvalid.pl.
-
-
-7.2   The DTD for an atomic rating
-
-Explanation                          Format of information sent
------------                          --------------------------
-                                     (http://select/v1.0/atomic-rating.dtd)
-
-                                     <!ELEMENT atomic-rating (rating-value+)>
-
-Start of attribute list for          <!ATTLIST atomic-rating
-atomic-rating.
-
-Identification of the rater. For a     raterid-or-pseudonym CDATA #REQUIRED
-pseudonymous rating, the pseudonym
-is specified, for an identified
-user the raterid is supplied. For
-an anonymous rating, the special
-name "anonymous" is entered.
-
-Note: when retrieving ratings made
-by other people than yourself, the
-raterid is given the special value
-"suppressed". You will then get
-ratings with the raterid changed to
-"suppressed" and with only the year
-in the date field.
-
-For aggregate ratings, the
-raterid-or-pseudonym has the
-special value "derived".
-
-IP adress of machine that generates    rated-from-host CDATA #REQUIRED
-the rating.
-
-Identification of the software         rating-engine CDATA #REQUIRED
-which formatted this rating in the
-format of an URL of a page
-describing this rating-engine.
-
-The URI of the rated resource          location CDATA #REQUIRED
-
-The date of the rating. If no date     rating-date CDATA #IMPLIED
-is specified, the server will give
-the record the current date when
-storing it. When returning ratings
-with the Get-Atomic-Ratings
-operation, ratings for other people
-than yourself are supplied with
-only year, not month or day or
-time-of-day.
-
-For aggregate ratings, this date
-has as value the last time its
-value was re-computed.
-
-The rater-competence is an           rater-competence ( author | expert |
-enumerated XML attribute, which can  user | pseudonymous | anonymous |
-only take specified values. The      un-known | multiple ) 'un-known'
-default value, if no tag is
-specified, is "un-nown".
-
-"multiple" is used for aggregate
-ratings based on multiple user's
-atomic ratings.
-
-The verification info for this       rater-trust ( signed | registered |
-rater, default is "anonymous"        pseudonymous | anonymous | multiple )
-                                     'anonymous'
-"multiple" is used for aggregate
-ratings based on multiple user's
-atomic ratings.
-
-Type of agent producing this rating  rater-type (computed | observed |
-value.                               manual) 'manual'
-
-Rating is limited to this context.   context (general | business | leisure |
-                                     shopping | research | politics | all |
-                                     not-available) 'not-available'
-
-The sender can give a globally       message-id CDATA #IMPLIED
-unique message-id to the rating
-sent. If the sender does not give
-such an ID, then the recipient will
-assign such an ID when storing the
-rating.
-
-Note: This is not the Message-ID of
-the rated resource, it is the ID of
-this rating.
-
-End of the list of XML attributes.   >
-
-The value for one rating             <!ELEMENT rating-value EMPTY>
-descriptor.
-
-                                     <!ATTLIST rating-value
-The transmit-as or short-name of       type CDATA #REQUIRED
-the rating category. Note: Only
-descriptors which are defined for
-the rating service, to which the
-connection is made, are allowed!
-
-The value of the rating in the         Value CDATA #REQUIRED
-format specified for this rating
-descriptor. Note: If a user
-specifies more than one keywords
-for a resource, then each keyword
-is sent as a separate rating-value.
-
-End of the list of XML attributes.   >
-
-
-
-7.3   Get-Service-Description-List (XML)
-
-The Get service-description-list operation retrieves a list of SELECT
-version 1.0 service descriptions and their URIs, but does not retrieve
-the actual service descriptions. This will not necessarily be a list of
-all SELECT services over the world, it may usually be a list of SELECT
-services on this particular host, or a list of services recommended by
-the manager of this host.
-
-
-7.3.1 Query format (get service description-list):
-
-An HTTP GET operation is performed on a URI established to return
-SELECT version 1.0 service descriptions.
-
-Example:
-
-This description can be requested from at:
-http://select/v1.0/select-service-descriptions
-
-Explanation                 Information sent
------------                 ----------------
-
-Get the file named          GET /v1.0/select-service-descriptions HTTP/1.1
-"sel-1/select-service-desc
-riptions". Preferred
-language is in English,
-second choice Italian
-
-From the HTTP server        Host: select
-"select" port 80.
-
-Only files in the format    Accept: application/xml
-application/xml are
-accepted.
-
-This user has connected to  Cookie: session="1234567890123456"
-this server before, and a
-cookie identifies the
-session.
-
-
-
-7.3.2 Response format (get service description-list):
-
-Explanation                 Information sent
------------                 ----------------
-
-Standard reply header       HTTP ...
-
-                            <?xml version="1.0"?>
-                            <!DOCTYPE send-rating SYSTEM "services-list.dtd">
-                            <services-list>
-                              <services-list-item
-                                 id         = "test"
-                                 URI        =
-                            "http://samson.aszi.sztaki.hu/SELECT"
-                                 server     = "samson.aszi.sztaki.hu"
-                                 maintainer = "micsik@sztaki.hu" />
-                                 <description language = "en"
-                                              text     = "SELECT service">
-                                 </description>
-                              </services-list-item>
-                            </services-list>
-
-DTD of replied message      <!ELEMENT services-list-item (description+)>
-                            <!ATTLIST services-list-item
-                               id          CDATA #REQUIRED
-                               URI         CDATA #REQUIRED
-                               Server      CDATA #REQUIRED
-                               Maintainer  CDATA #REQUIRED
-                            >
-                            <!ELEMENT description EMPTY>
-                            <!ATTLIST description
-                               language CDATA #REQUIRED
-                               text     CDATA #REQUIRED
-                            >
-
-7.4   Get-Service-Description
-
-Summary: The Get service-description operation will query a SELECT
-version 1.0 server to get a description of some services. The main
-components of this description is a list of descriptors and scales used
-by this service.
-
-Access control: None.
-
-Input data: The names of the services.
-
-Output data: A description of the service, and a list of the
-descriptors supported for ratings in that group.
-
-Base protocol: HTTP combined with XML.
-
-7.4.1 Query format (get service-description):
-
-An HTTP GET operation is performed on a certainURI.
-
-Example (get service-description):
-
-This example retrieves the service description at the URI:
-http://select/v1.0/get-service-descriptions
-
-Explanation                        Information sent
------------                        ----------------
-
-Get the file named                 GET /v1.0/get-service-descriptions HTTP/1.1
-"general/select-service-descripti
-on" which contains a description
-of the SELECT version 1.0 general
-service. The SELECT version 1.0
-general service is a service
-available to everyone, as
-different for service for special
-user groups.
-
-Get the file from the HTTP server  Host: select
-"select" port 80.
-
-Only files in the format           Accept: application/xml
-application/xml are accepted.
-
-This user has connected to this    Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-Request of SELECT test service     <?xml version="1.0"?>
-                                   <!DOCTYPE get-services SYSTEM
-                                   "get-services.dtd">
-                                   <get-services>
-                                      <service-name name = "test"/>
-                                      <service-name name = "iscn"/>
-                                   </get-services>
-
-DTD of message                     <?xml version="1.0" encoding="UTF-8" ?>
-                                   <!ELEMENT get-services (service-name+)>
-                                   <!ELEMENT service-name EMPTY>
-                                   <!ATTLIST service-name
-                                     name  CDATA #REQUIRED
-                                   >
-
-
-7.4.2 Response format (get-service-description):
-
-The response is an XML [XML1], [XML2] resource, containing a SELECT
-version 1.0 service description. The XML Resource Type Declaration for
-this XML page is described in chapter 0
-The SELECT general service description.
-
-
-7.5   Send-Rating
-
-Summary: The send-rating operation will send one or more ratings to a
-SELECT version 1.0 server. This operation can be used both for explicit
-ratings provided by users, for implicit ratings derived by observing
-user behaviour, and for ratings derived through automatic analysis of
-documents using NLP methods.
-
-Access control: If the rater is not identified by a cookie (created by
-a login operation), then either this rating will be handled as
-anonymous or the user will be instructed to login first, or to send the
-ratings to the separate entry-point for anonymous ratings. Some SELECT
-servers may not accept anonymous ratings.
-
-Input data: Information about the rated resource, the rater and the
-rating values.
-
-Output data: Acceptance or rejection.
-
-Base protocol: XML transported through HTTP.
-
-7.5.1 Transmit-Format (send-rating):
-
-A HTTP POST operation, with the content the XML-formatted rating.
-
-The send-rating is an HTTP POST operation, whose body is an XML
-resource containing the rating. Below is a POST sent to the URI
-http://select/v1.0/general/input-ratings
-
-Explanation                        Information sent
------------                        ----------------
-
-Connect to the SELECT server. The  POST /v1.0/general/id/input-ratings
-URI used identifies the rating     HTTP/1.1
-service, to which this rating is
-sent.
-
-To the HTTP server "select" port   Host: select
-80.
-
-Only files in the format           Accept: application/xml
-application/xml are accepted.
-
-The format of the query is XML.    Content-Type: Application/xml
-
-This user has connected to this    Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-The body of the query is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is as follows. Note
-that no Rater-ID is included, because this ID can be derived from the
-Cookie. And no rating-service-description is referred to, because the
-URI, to which this rating is sent, implies a particular rating-service.
-
-Explanation                          Format of information sent
------------                          ---------------------------
-                                     (http://select/v1.0/send-rating.dtd)
-
-Reference to data structure defined  <!ENTITY % atomic-rating SYSTEM
-in a separate DTD file. Further
-information, see section 7.2         "http://select/v1.0/atomic-rating.dtd">
-
-
-A list of ratings are sent.          <!ELEMENT send-rating (atomic-rating+)>
-
-Import DTD from separate DTD file    %atomic-rating;
-atomic-rating.dtd.
-
-Example (send-rating):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/send-rating.xml)
-
-HTTP header                     POST /v1.0/general/id/input-ratings  HTTP/1.1
-                                Host: select
-                                Accept: application/xml
-                                Content-Type: Application/xml
-                                Cookie: session="1234567890123456"
-
-A blank line to mark the end of
-the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE send-rating SYSTEM
-Declaration (DTD) file           "http://select/v1.0/send-rating.dtd">
-specifying the syntax for this
-XML resource.
-                                <send-rating>
-Start with information about    <atomic-rating
-the resource rated and about      raterid-or-pseudonym="jpalme@dsv.su.se"
-the rater.                        rating-engine="http://select/proxy-1"
-                                  location="http://www.body.com/eyes"
-                                  rating-date="31 Jul 1999"
-                                  rater-competence="user"
-                                  rater-type="manual"
-                                  rater-trust="registered"
-                                  message-id="990815113350*jpalme@dsv.su.se">
-
-First rating descriptor         <rating-value
-                                  type="select-reader-interest-rating"
-                                  value="good"/>
-
-Second rating descriptor, note  <rating-value
-that decimal values are allowed   type="select-reader-quality-rating"
-                                  value="1.5"/>
-
-Third rating descriptor         <rating-value
-                                  type="adult"
-                                  value="false"/>
-
-Fourth rating descriptor        <rating-value
-                                  type="context"
-                                  value="leisure"/>
-
-End of data                     </atomic-rating></send-rating>
-
-
-7.5.2 Response format (send-rating-response):
-
-The response is an XML [XML1], [XML2] resource. The XML Resource Type
-Declaration for this XML resource is:
-
-Explanation             Format of information sent
------------             --------------------------
-                        (http://select/v1.0/send-rating-response.dtd)
-
-The evaluations are     <!ELEMENT send-rating-response  (rating-value*)>
-returned, one rating
-service at a time.
-
-Whether all the rating  <!ATTLIST send-rating-response
-labels were accepted,     accepted (all | some | none) 'all'
-or some of them, or
-none of them.
-
-ID of the set-rating.     Message-id CDATA #REQUIRED
-If no message-id was
-given in the
-set-rating operation,
-this ID will tell the
-client which ID the
-set-rating operation
-got assigned by the
-server.
-
-If rating was             Refuse-reason (accepted | bad-syntax |
-rejected, explanation     Missing-info |  unknown-descriptors | wrongtype |
-why. See chapter          Wrong-competence | wrong-trust | wrong-rater-type |
-7.5.2.1 Refusal           Wrong-context | access-control | other |
-reasons for the           Wrong-type) 'accepted'
-send-rating operation.
-
-End of XML attribute    >
-list
-
-If only some of the     <!ELEMENT rating-value EMPTY>
-rating values were
-rejected, this element
-is used to list the
-rejected rating
-values.
-
-                        <!ATTLIST rating-value
-
-See send-rating           type CDATA #REQUIRED
-operation.
-
-See send-rating           value CDATA #REQUIRED
-operation
-
-End of XML attribute    >
-list
-
-
-7.5.2.1     Refusal reasons for the send-rating operation
-
-The following refusal reasons may be used in rejecting a send-rating
-operation by a SELECT server:
-
-Refuse-reason           Explanation
--------------           -----------
-
-none                    Operation was not rejected.
-
-bad-syntax              Wrong syntax of HTTP header or XML data sent.
-
-missing-info            Mandatory-information missing from sent data.
-
-unknown-descriptors     Trying to store a rating for a descriptor not
-                        supported by this server.
-
-wrongtype               Wrong type of a descriptor value, for example text
-                        for a descriptor which must have a numerical value.
-
-wrong-competence        This rater is not allowed to send ratings with this
-                        competence to this service.
-
-wrong-trust             This rater is not allowed to send ratings with this
-                        trust to this service.
-
-wrong-rater-type        This service does not accept ratings of this
-                        rater-type from this user.
-
-wrong-context           This service does not accept ratings with this
-                        context from this user.
-
-access-control          This user is not allowed to send ratings to this
-                        service. (There are no operations in this
-                        specification to give people access rights. Some
-                        SELECT services may want to give only certain people
-                        the right to perform various operations, such as send
-                        ratings. How to do this is not described in this
-                        specification.)
-
-not-logged-in           The user performed an operation which requires login,
-                        but was not logged in.
-
-other                   Other errors.
-
-Example 1 (positive send-rating response):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/send-rating-1.xml)
-
-HTTP response header            HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format
-
-References the Resource Type    <!DOCTYPE send-rating-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/send-rating-response.dtd"
-specifying the syntax for this  >
-XML resource.
-
-Accepted is default.            <send-rating-response
-                                message-id="990815113350*jpalme@dsv.su.se"/>
-
-Example 2 (negative send-rating response):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/send-rating-2.dtd)
-
-HTTP response header.           HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE send-rating-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/send-rating-response.dtd"
-specifying the syntax for this  >
-XML resource.
-
-All ratings were not accepted.  <send-rating-response accepted="some"
-                                refuse-reason="wrong-context"
-                                message-id="990815113350*jpalme@dsv.su.se">
-
-Rating-label rejected, this     <rating-value
-server does not accept ratings    type="context"
-in the leisure context.           value="leisure"/>
-
-End of send-rating-response.    </send-rating-response>
-
-
-7.6   Set-Profile
-
-Summary: The set-profile operation can be used for a rater to register
-him/herself (for services which allow this) and can be used by
-administrators to register raters (for services which do not allow
-self-registration). It can also be used to modify existing
-registrations.
-
-Issues: The format of interest-profile is not specified. The format of
-reward-account is not specified.
-
-Access control: The profile of a person is not modifiable by other
-people, only by that person him/herself, or an agent for that person,
-or certain certified SELECT processes, who will not divulge the profile
-to other people. A SELECT administrator may also usurp super-user
-privileges and perform this operation on anyone.
-
-Input data: User identification and some profile attributes to be set
-or changed.
-
-Output data: Accepted or rejected.
-
-Base protocol: XML
-
-7.6.1 Transmit format (set-profile):
-
-The set-profile operation is an HTTP POST operation, whose body is an
-XML resource containing the profile, sent to the profiles cgi-script in
-the server for this particular rating service. Example:
-"http://select/v1.0/general/id/profiles/".
-
-Note that a user, who is registered in more than one rating service,
-has a separate profile and a separate cookie for each of them.
-
-Explanation                         Information sent
------------                         ----------------
-
-Connect to the SELECT server        POST /v1.0/general/id/set-profile
-                                    HTTP/1.1
-
-To the HTTP server "select" port    Host: select
-80.
-
-Only files in the format            Accept: application/xml
-application/xml are accepted.
-
-The format of the query is XML.     Content-Type: Application/xml
-
-This user has connected to this     Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-The body of the operation is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is:
-
-Explanation                         Format of information sent
------------                         --------------------------
-                                    (http://select/v1.0/set-profile.dtd)
-
-Reference to data structure         <!ENTITY % profile SYSTEM
-defined in a separate DTD file.       "http://select/v1.0/profile.dtd">
-Further information, see section
-7.6.2 The XML DTD for the user
-profile.
-
-The set-profile consists of a       <!ELEMENT set-profile (profile)>
-profile plus two attributes.
-
-Start of XML attribute list.        <!ATTLIST set-profile
-
-Is this a new registration of a       new (true | false) 'false'
-not-yet-registered user?
-
-Whether you are setting the           self (true | false ) 'true'
-registration for yourself, or,
-since you are a superuser, for
-someone else.
-
-                                    >
-
-Profile is taken from the external  %profile;
-ENTITY declared in the first row.
-Further information, see section
-section 7.6.2 The XML DTD for the
-user profile.
-
-
-Note: All attributes of a user profile are not settable for ordinary
-users (example: no-of-docs-rated). They should thus not be used when
-setting a profile.
-
-Pseudonym should include the domain name of the SELECT server. Thus, if
-a user wants the pseudonym foobar, the user should request the
-pseudonym foobar@select when connecting to any of the SELECT servers at
-select. Note that this means that the same pseudonym is not allowed in
-more than one SELECT service, if all the services are on the same
-server. The SELECT server must check suggested pseudonyms in a data
-base which is common to all SELECT services on a particular host.
-
-
-7.6.2 The XML DTD for the user profile
-
-Profile is an XML [XML1], [XML2] resource. The XML Resource Type
-Declaration for profile:
-
-Explanation                        Format of information sent
------------                        --------------------------
-                                   (http://select/v1.0/profile.dtd)
-
-                                   <!ELEMENT profile (language*,
-                                   keyword-manual*, keyword-automatic*,
-                                   interest-profile?, query-history*,
-                                   reward-account*)>
-
-                                   <!ATTLIST profile
-
-E-mail address of the rater. This    raterid CDATA #IMPLIED
-can be omitted for a person who
-is only going to submit
-pseudonymous ratings. One of the
-two values raterid and pseudonym
-must be specified.
-
-A globally unique identification     pseudonym CDATA #IMPLIED
-of the rater, from which the real
-person cannot be found except
-through the SELECT server data
-base. (Such lookups are forbidden
-except when needed to fight
-illegal or harmful usage.)
-
-Password is mandatory except that    password CDATA #IMPLIED
-a new user can omit the password
-at registration, the server will
-then assign a password to that
-user and send it back.
-
-A question to answer for a user      remember-phrase-question CDATA #IMPLIED
-who has forgotten his/her
-password, example "What is my
-mother's maiden name".
-
-The correct answer to this           remember-phrase-answer CDATA #IMPLIED
-question.
-
-A non-unique, user-friendly name     name CDATA #IMPLIED
-of this rater.
-
-Wanted maximum validity time of a    cookie-life-time CDATA #IMPLIED
-session before time out, in
-seconds. Both the client and the
-server are responsible for not
-allowing further interactions
-before logout when the validity
-time has expired. This value is
-dependent on the setting, which
-the user makes on a "Remember my
-password" checkbox in the user
-profile settings user interface.
-
-Open key for signatures. May be      signature-open-key CDATA #IMPLIED
-mandatory, optional or not used,
-depending on SELECT service.
-
-URL of certificate authority,        certificate-authority  CDATA #IMPLIED
-with which the signature-open-key
-can be verified.
-
-A user does not have to specify      birthyear CDATA #IMPLIED
-birthyear or gender. Some SELECT
-services may however require such
-specifications. Birthyear is the
-year AD (counted from the
-commonly assumed birthyear of
-Christ).
-
-                                     gender (male | female ) #IMPLIED
-
-Some users may not have              mayrate (true | false) 'true'
-permission to rate.
-
-Whether other people can search      secret (true | false) 'false'
-for this user's name in the
-SELECT data base.
-
-Latest date when this rater made     latest-rating-date CDATA #IMPLIED
-any rating in this rating
-service.
-
-Number of docs rated by this         no-of-docs-rated CDATA #IMPLIED
-rater in this rating service.
-
-Algorithm not yet defined for how    average-ratings-given CDATA #IMPLIED
-to compute this.
-
-End of the list of XML attributes  >
-
-Language code of languages         <!ELEMENT language (#PCDATA)>
-understood by this user in
-priority order. May be repeated
-once for every language. Language
-codes are taken from RFC 1766 and
-ISO 639.
-
-Keywords specified by this user    <!ELEMENT keyword-manual (#PCDATA)>
-to identify his/her interests.
-
-Keywords automatically derived by  <!ELEMENT keyword-automatic (#PCDATA)>
-observation of this user to
-identify his/her interests.
-
-This syntax is preliminary. We     <!ELEMENT interest-profile (#PCDATA)>
-may assign a more complex syntax
-to this later on, with defined
-subelements and structure like a
-set of instructions in some
-filtering language.
-
-List of previous queries made by   <!ELEMENT query-history (#PCDATA)>
-this user. May influence
-filtering procedure.
-
-To be defined.                     <!ELEMENT reward-account (#PCDATA)>
-
-
-Example (set-profile):
-
-Explanation                  Information sent
------------                  ----------------
-                             (http://select/v1.0/set-profile.xml)
-
-HTTP header.                 POST /v1.0/general/id/set-profile  HTTP/1.1
-                             Host: select
-                             Accept: application/xml
-                             Content-Type: Application/xml
-                             Cookie: session="012345678901234354"
-
-A blank line to mark the
-end of the HTTP header.
-
-Identifies that this is in   <?xml version="1.0"?>
-XML format.
-
-References the Resource      <!DOCTYPE set-profile SYSTEM
-Type Declaration (DTD) file   "http://select/v1.0/set-profile.dtd">
-specifying the syntax for
-this XML resource.
-
-Setting the profile for      <set-profile self="false">
-someone else.
-
-Start of the profile to be   <profile
-set.
-
-List of attributes and         raterid="jpalme@dsv.su.se"
-values.                        pseudonym="xavier-xantico"
-                               password="foobar"
-                               remember-phrase-question="mother's maiden name"
-                               remember-phrase-answer="von Vegesack"
-                               name="Jacob Palme"
-                               cookie-life-time="999999999"
-                               birthyear="1941"
-                               gender="male"
-
-End of profile attributes    >
-
-Embedded elements            <keyword-manual>standards</keyword-manual>
-                             <keyword-manual>computers </keyword-manual>
-                             <keyword-manual>fiction </keyword-manual>
-                             <keyword-automatic>psychiatry
-                             </keyword-automatic>
-                             <interest-profile> Do not filter away any
-                             document containing "IETF"</interest-profile>
-
-End of set-profile           </profile></set-profile>
-
-
-7.6.3 Response format (set-profile):
-
-Explanation                        Format of information sent
------------                        --------------------------
-                                   (http://select/v1.0/set-profile-response.dt
-                                   d)
-
-The evaluation are returned, one   <!ELEMENT set-profile-response
-rating service at a time.
-
-Whether all the new user settings  <!ATTLIST set-profile-response
-were accepted, or some of them,      accepted (all | some | none) 'all'
-or none of them.
-
-XML attributes for refuse-reason.  reason   (cannot-set-for-yourself |
-                                   cannot-set-for-other-user |
-                                   raterid-or-pseudonym-in-use |
-                                   invalid-session-id | not-logged-in |
-                                   database-error | failure | success)
-                                   'failure'
-
-Example 1 (positive set-profile response):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/set-profile-response-1.xm
-                                l)
-
-HTTP response header.           HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE set-profile-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/set-profile-response.dtd"
-specifying the syntax for this  >
-XML resource.
-
-The set-profile was accepted.   <set-profile-response
-                                  accepted = "all"
-                                  reason = "none"
-                                />
-
-Example 2 (negative set-profile response):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/set-profile-response-2.xm
-                                l)
-
-HTTP response header.           HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE set-profile-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/set-profile-response.dtd"
-specifying the syntax for this  >
-XML resource.
-
-The set-profile was not fully   <set-profile-response
-accepted.                         accepted="none"
-                                  reason="raterid-or-pseudonym-in-use"
-                                />
-
-
-7.7   Get-Profile
-
-Summary: The get-profile operation can be used to get the profile
-settings for a particular user in a particular SELECT server. It can be
-used to retrieve a profile, and then send in a modified profile using
-(to the extent this is allowed) using the set-profile operation.
-Filtering agents may use get profile to get information used in the
-filtering for a certain user. ML algorithms may automatically modify a
-user's profile, the profile may indicate limits on what ML algorithms
-may do to it. (Example: "ML may not filter out any articles in
-newsgroup X, since it is very important to me".)
-
-Access control: The profile of a person is not accessible by other
-people, only by that person him/herself, or an agent for that person,
-or certain certified SELECT processes, who will not divulge the profile
-to other people. A SELECT administrator may also usurp super-user
-privileges and perform this operation on anyone.
-
-Input data: Identification of the user or search-info for the user,
-whose profile is wanted.
-
-Output data: The profile of this user, or a rejection error.
-
-Base protocol: application/x-www-form-urlencoded for the request, XML
-for the response.
-
-7.7.1 Query format (get-profile):
-
-The get-profile operation is an HTTP GET operation, with an HTML form:
-
-
-
-<html>
-<head>
-<title>SELECT Login</title>
-<meta http-equiv="Content-Type" content="text/html;
-charset=iso-8859-1">
-</head>
-<body bgcolor="#FFFFFF">
-<h1><font>Get SELECT User
-  Info </h1>
-<form method="get" action="http://www.dsv.su.se/~jpalme/">
-  <table border="0" cellpadding="5">
-    <tr>
-      <td rowspan="2">Fill
-        in either an e-mail<br>
-        address or a search string:</td>
-      <td>
-        <div align="right">The
-          e-mail address<br>
-          of the user:</div>
-      </td>
-      <td>
-        <input type="text" name="e-mail-address"
-               size="50" maxlength="80">
-      </td>
-    </tr>
-    <tr>
-      <td>
-        <div align="right">Search
-          string:</div>
-      </td>
-      <td>
-        <input type="text" name="search-string"
-               size="50" maxlength="80">
-      </td>
-    </tr>
-    <tr>
-      <td>&nbsp;</td>
-      <td>&nbsp;</td>
-      <td>
-        <input type="submit" name="Get" value="Get user info">
-        &nbsp;<font face="Verdana, Arial, Helvetica" size="2">
-        Response format:
-        <input type="radio" name="responseformat" value="html"
-               checked>
-        HTML
-        <input type="radio" name="responseformat" value="xml">
-        XML </td>
-    </tr>
-  </table>
-   </form>
-</body>
-</html>
-
-Example: "http://select/v1.0/general/id/profiles?e-mail-address=&search
-string=Donald+Duck&Get=Get+user+info&responseformat=html".
-
-Example (get-profile):
-
-Explanation                        Information sent
------------                        ----------------
-
-Connect to the SELECT server.      GET
-                                   /v1.0/general/id/profiles?raterid=jpalme
-                                   HTTP/1.1
-
-To the HTTP server "select" port   Host: select
-80.
-
-Only files in the format           Accept: application/xml
-application/xml are accepted.
-
-
-
-7.7.2 Response format (get-profile):
-
-Explanation                  Format of information sent
------------                  --------------------------
-                             (http://select/v1.0/get-profile-response.dtd)
-
-Reference to data structure  <!ENTITY %profile SYSTEM
-defined in a separate DTD      "http://select/v1.0/profile.dtd">
-file. Further information,
-see section 0.
-
-The evaluation are           <!ELEMENT get-profile-response  ( profile+ |
-returned, one rating         error )>
-service at a time.
-
-                             <!ATTLIST get-profile-response
-
-Partial means that some,       success ( full | partial | none ) 'full'
-but not all the requested
-data is returned.
-
-                             >
-
-Profile is taken from the    %profile;
-external ENTITY declared in
-the first row. Further
-information, see section 0.
-Profile may be incomplete,
-in case only some
-attributes are retrievable
-for this requestor (if you
-get profile for someone
-else than yourself).
-
-                             <!ELEMENT error (#PCDATA)>
-
-                             <!ATTLIST error
-
-Reject reason, no default      reason ( not-logged-in | bad-syntax |
-value.                         not-found | authorisation-failure |
-Note: Data for secret          other-reason )
-users, whom the requestor      #IMPLIED
-are not allowed to see, are
-treated as non-existing. A
-search for such a user
-might thus return
-"not-found".
-
-                             >
-
-Example 1 (positive get-profile response):
-
-Explanation                  Information sent
------------                  ----------------
-                             (http://select/v1.0/get-profile-response-1.xml)
-
-HTTP response header.        HTTP/1.1 200 OK
-                             Content-Length: 569
-                             Content-Type: application/xml
-                             Server: Select 1.0
-                             Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate
-the end of the HTTP header.
-
-Identifies that this is in   <?xml version="1.0"?>
-XML format.
-
-References the Resource      <!DOCTYPE get-profile-response SYSTEM
-Type Declaration (DTD) file  "http://select/v1.0/get-profile-response.dtd">
-specifying the syntax for
-this XML resource.
-
-The get-profile was          <get-profile-response>
-accepted.
-
-Start of the profile to be   <profile
-set.
-
-List of attributes and         raterid="jpalme@dsv.su.se"
-values.                        pseudonym="xavier-xantico"
-Note: Password is never        remember-phrase-question="mother's maiden name"
-returned.                      remember-phrase-answer="von Vegesack"
-                               name="Jacob Palme"
-                               cookie-life-time="999999999"
-                               birthyear="1941"
-                               gender="male"
-
-End of profile attributes    >
-
-Embedded elements            <keyword-manual>standards</keyword-manual>
-                             <keyword-manual>computers </keyword-manual>
-                             <keyword-manual>fiction </keyword-manual>
-                             <keyword-automatic>psychiatry
-                             </keyword-automatic>
-                             <interest-profile> Do not filter away any
-                             document containing "IETF"</interest-profile>
-
-End of get-profile           </profile></get-profile-response>
-
-Example 2 (negative get-profile response):
-
-Explanation                      Information sent
------------                      ----------------
-                                 (http://select/v1.0/get-profile-response-2.x
-                                 ml)
-
-HTTP response header.            HTTP/1.1 200 OK
-                                 Content-Length: 569
-                                 Content-Type: application/xml
-                                 Server: Select 1.0
-                                 Date: 17 August 1999 12:22:46 +0200
-
-A blank line to indicate the end
-of the HTTP header.
-
-Identifies that this is in XML   <?xml version="1.0"?>
-format.
-
-References the Resource Type     <!DOCTYPE get-profile-response SYSTEM
-Declaration (DTD) file           "http://select/v1.0/get-profile-response.dtd
-specifying the syntax for this   ">
-XML resource.
-
-The get-profile did not succeed. <get-profile-response success="none">
-                                 <error reason="not-logged-in">
-                                 You cannot do this without first logging in.
-                                 </error></get-profile-response>
-
-
-7.8   Login
-
-Summary: The login operation is used to identify a user, and cause a
-cookie value to be set, which allows this user to perform certain
-access-controlled operations during the validity time of this cookie.
-
-Access control: E-mail address and password. May not be required for
-sending anonymous ratings.
-
-Input data: User identification by either e-mail address or pseudonym
-combined with password or an IMAP authentication.
-
-Output data: Acceptance or rejection.
-
-Base protocol: application/x-www-form-urlencoded for the request, HTML
-or XML for the response.
-
-7.8.1 Query format (login):
-
-The same as if the user has filled in the following HTML form:
-
-
-
-<html>
-<head>
-<title>SELECT Login</title>
-<meta http-equiv="Content-Type" content="text/html;
-charset=iso-8859-1">
-</head>
-<body bgcolor="#FFFFFF">
-<h1>SELECT Login </h1>
-<form method="get" action="http://www.dsv.su.se/~jpalme/">
-  <table border="0" cellpadding="5">
-    <tr>
-      <td>
-        <div align="right">Your e-mail address<br>or pseudonym:</div>
-      </td><td>
-        <input type="text" name="e-mail-address" size="50"
-maxlength="80">
-      </td>
-    </tr>
-    <tr>
-      <td>
-        <div align="right">Your password:</div>
-      </td><td>
-        <input type="password" name="password">
-      </td>
-    </tr>
-    <tr>
-      <td>&nbsp;</td>
-      <td>
-        <input type="submit" name="Submit" value="Login">&nbsp;
-        Response format:
-        <input type="radio" name="responseformat" value="html" checked>
-        HTML
-        <input type="radio" name="responseformat" value="xml">
-        XML
-      </td>
-    </tr>
-  </table>
-   </form>
-</body>
-</html>
-
-Example (login):
-
-Explanation                      Information sent
------------                      ----------------
-
-Connect to the SELECT server     GET /v1.0/general/id/login?e-mail-address=jp
-                                 alme@dsv.su.se&password=select  HTTP/1.1
-
-To the HTTP server "select" port Host: select
-80.
-
-Only files in the format         Accept: application/xml
-application/xml are accepted.
-
-
-
-7.8.2 Response format (login):
-
-Explanation                     Format of information sent
------------                     --------------------------
-                                (http://select/v1.0/login.dtd)
-
-Response to a login             <!ELEMENT login-response  EMPTY>
-
-If ok                           <!ATTLIST login-response
-Session-id for the newly          accepted (ok | wrong_password |unknown_user
-created session                             | failed) 'failed'
-Rater-id of the newly logged in   session-id CDATA #REQUIRED
-user                              rater-id   CDATA #REQUIRED
-
-End of XML attribute list       >
-
-Example (login response):
-
-Explanation             Information sent
------------             ----------------
-                        (http://select/v1.0/login-response.xml)
-
-HTTP header.            HTTP/1.1 200 OK
-                        Date: Sun, 25 Jul 1999 13:32:18 +0200
-                        Server: Apache/1.2.4
-                        Last-Modified: Sun, 25 Jul 1999 13:32:18 +0200
-                        ETag: "437e5-98-3531f2e3"
-                        Content-Length: 152
-                        Accept-Ranges: bytes
-                        Connection: close
-                        Content-Type: application/xml
-
-Set the cookie.         Set-cookie: session="1234567890123456";Domain="select
-                        ";Path="/v1.0/general/id/"
-
-A blank line to mark
-the end of the HTTP
-header.
-
-Identifies that this    <?xml version="1.0"?>
-is in XML format.
-
-References the          <!DOCTYPE login-response SYSTEM
-Resource Type           "http://select/v1.0/login-response.dtd">
-Declaration (DTD) file
-specifying the syntax
-for this XML resource.
-
-Start and end of        <login-response
-login-response for a       accepted="true"
-rejected login.            session-id="1234567890123456"
-                           rater-id = "jpalme"
-                        />
-
-
-7.9   Logout
-
-Summary: The logout operation removes the cookie, which gave the user
-privileges to perform certain commands in logged-in state.
-
-7.9.1 Query format (logout):
-
-The same as if a user clicks on an HTML link:
-
-<A HREF="http://select/v1.0/general/id/logout;">Log out</A>
-
-Example (logout):
-
-Explanation                           Information sent
------------                           ----------------
-                                      (http://select/v1.0logout-response.dtd)
-
-An ordinary HTTP connection.          GET /v1.0/general/id/logout;
-
-To the HTTP server "select" port 80.  Host: select
-
-Only files in the format              Accept: application/xml
-application/xml are accepted.
-
-This user has connected to this       Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-
-
-7.9.2 Response format (logout):
-
-Explanation                      Format of information sent
------------                      --------------------------
-                                 (http://select/v1.0/logout.dtd)
-
-The evaluation are returned, one <!ELEMENT logout-response  EMPTY>
-rating service at a time.
-
-Whether all the rating labels    <!ATTLIST logout-response
-were accepted, or some of them,    accepted (true | false) 'true'
-or none of them.
-
-You tried to logout, but you       not-logged-in (true | false) 'false'
-were not logged in.
-
-End of XML attribute list        >
-
-
-Example (logout response):
-
-Explanation                  Information sent
------------                  ----------------
-                             (http://select/v1.0/logout-response.xml)
-
-HTTP header                  HTTP/1.1 200 OK
-                             Date: Sun, 25 Jul 1999 13:32:18 +0200
-                             Server: Apache/1.2.4
-                             Last-Modified: Sun, 25 Jul 1999 13:32:18 +0200
-                             ETag: "437e5-98-3531f2e3"
-                             Content-Length: 152
-                             Accept-Ranges: bytes
-                             Connection: close
-                             Content-Type: application/xml
-
-Max-age="0" resets the       Set-cookie: session="1234567890123456";Domain="se
-cookie.                      lect";Path="/v1.0/general/id/";Max-age="0"
-
-A blank line to mark the
-end of the HTTP header.
-
-Identifies that this is in   <?xml version="1.0"?>
-XML format.
-
-References the Resource      <!DOCTYPE logout-response SYSTEM
-Type Declaration (DTD) file  "http://select/v1.0/logout-response.dtd">
-specifying the syntax for
-this XML resource.
-
-Start and end of             <logout-response accepted="false"/>
-login-response for a
-rejected login.
-
-
-7.10  Get-Atomic-Ratings
-
-Summary: The get-atomic-ratings operation retrieves atomic ratings done
-by one or more named raters on one or more resources. It can be used by
-a user agent to find out if this user has already rated this resource.
-It might also be used in peer rating, where person A wants to find
-items rated highly by named individuals B and C.
-
-Access control: The ratings made by a certain user can only be seen by
-that user, i.e. after logging in as that user. A person may however, in
-his/her personal profile, specify that other people can see his/her
-ratings. Get-atomic-ratings on a list of people may only be done in the
-following cases (i) all the people have specified in their profile that
-their ratings may be seen by other people, or (ii) the requestor is a
-certified filtering agent which will not divulge the personal ratings
-to a person, or (iii) the list of users is larger than ten, in this
-case, the atomic ratings are returned without identification of who
-made which rating.
-
-Input data: A URI for the rated resource, and a list of one or more
-people, whose atomic ratings on this resource are wanted.
-
-Output data: A list of atomic ratings, with or without identification
-of who made them, or an error code.
-
-Base protocol: XML.
-
-7.10.1      Query format (get-atomic-ratings):
-
-The get-atomic-ratings query is an HTTP POST operation, whose body is
-an XML resource containing the query, sent to
-http://select/v1.0/general/id/evaluator.
-
-Note: You must be logged in, to perform this operation, even if you
-only are going to retrieve anonymous ratings.
-
-Explanation                   Information sent
------------                   ----------------
-
-Connect to the SELECT server  POST /v1.0/general/id/get-ratings HTTP/1.1
-
-To the HTTP server "select"   Host: select
-port 80.
-
-Only files in the format      Accept: application/xml
-application/xml are
-accepted.
-
-The format of the query is    Content-Type: Application/xml
-XML.
-
-This user has connected to    Cookie: session="1234567890123456"
-this server before, and a
-cookie identifies the
-session.
-
-The body of the query is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is:
-
-Explanation                                 Format of information sent
------------                                 --------------------------
-                                            (http://select/v1.0/get-atomic-ra
-                                            tings.dtd)
-
-                                            <!ELEMENT get-atomic-ratings
-                                            (location+, rater+, labelname*)>
-
-Start of attribute list for                 <!ATTLIST get-atomic-ratings
-get-atomic-ratings.
-
-Restrict the retrieval to only ratings        context (general | business |
-done in a certain context.                    leisure | shopping | research |
-                                              politics | all) 'all'
-Whether only ratings made by this rater       whose-ratings ( own | all )
-(identified or pseudonymous) can be         'own'
-retrieved. Note: If you set this setting
-to "all" then you will get back ratings
-without identity or date on them.
-
-End of the list of XML attributes.          >
-
-Each URI to be evaluated is a free text     <!ELEMENT location EMPTY>
-field containing the URI of the resource
-to be evaluated.
-
-Start of attribute list for rater.          <!ATTLIST location
-
-Raterid or pseudonym. If Raterid is given,    uri CDATA #REQUIRED
-only ratings made non-anonymously for this
-user are returned, if pseudonym is given,
-only ratings made under this pseudonym are
-returned. Thus, raterid and pseudonym are
-treated as two different raters. One
-exception: A rater has access rights to
-retrieve own ratings made both anonymously
-and non-anonymously, but the rater must
-then list both raters in two "rater"
-elements in the request.
-
-Note: Possibly, processes with special
-privileges may be allowed to retrieve
-ratings made by different people and
-anonymous ratings?
-
-End of the list of XML attributes.          >
-
-Identify whose ratings are requested.       <!ELEMENT rater EMPTY>
-
-Start of attribute list for rater. Omitted  <!ATTLIST rater
-if you want all ratings, made by anyone,
-in un-identified format.
-
-Raterid or pseudonym or the fixed string      raterid CDATA #REQUIRED
-"anonymous" to retrieve anonymous ratings.
-If Raterid is given, only ratings made
-non-anonymously for this user are
-returned, if pseudonym is given, only
-ratings made under this pseudonym are
-returned. Thus, raterid and pseudonym are
-treated as two different raters. One
-exception: A rater has access rights to
-retrieve own ratings made both anonymously
-and non-anonymously, but the rater must
-then list both raters in two "rater"
-elements in the request.
-
-End of the list of XML attributes.          >
-
-List of requested rating descriptors. If    <!ELEMENT labelname EMPTY>
-no list is specified, this means that all
-available ratings are requested.
-
-Start of attribute list for rater.          <!ATTLIST labelname
-
-Raterid or pseudonym. If Raterid is given,    name CDATA #REQUIRED
-only ratings made non-anonymously for this
-user are returned, if pseudonym is given,
-only ratings made under this pseudonym are
-returned. Thus, raterid and pseudonym are
-treated as two different raters. One
-exception: A rater has access rights to
-retrieve own ratings made both anonymously
-and non-anonymously, but the rater must
-then list both raters in two "rater"
-elements in the request.
-
-To retrieve ratings made by other people
-in de-identified format, enter the name as
-the string "other".
-
-End of the list of XML attributes.          >
-
-Example of a body (get-atomic-ratings):
-
-Explanation             Information sent
------------             ----------------
-                        (http://select/v1.0/get-atomic-ratings.dtd)
-
-Start.                  <?xml version="1.0"?>
-                        <!DOCTYPE get-atomic-ratings SYSTEM
-                        "http://select/v1.0/get-atomic-ratings.dtd">
-                        <get-atomic-ratings context="leisure">
-
-List of locations, for  <location uri="http://www.body.com/toes"/>
-which ratings are       <location uri="http://www.face.com/eyes"/>
-retrieved.
-
-Raters, whose ratings   <rater raterid="jpalme@dsv.su.se"/>
-are requested.          <rater raterid="father.christmas@northpole.com"/>
-
-Which rating labels     <labelname name="select-reader-interest-rating"/>
-are requested.          <labelname name="keywords"/>
-
-End of                  </get-atomic-ratings>
-get-atomic-ratings.
-
-
-7.10.2      Response format (get-atomic-ratings-response):
-
-The response is an XML [XML1], [XML2] document. The XML Resource Type
-Declaration for this XML resource is:
-
-Explanation                      Format of information sent
------------                      --------------------------
-                                 (http://select/v1.0get-atomic-ratings-respon
-                                 se.dtd)
-
-Reference to data structure      <!ENTITY % atomic-rating SYSTEM
-defined in a separate DTD file.    "http://select/v1.0/atomic-rating.dtd">
-Further information, see section
-7.2.
-
-Import DTD from separate DTD     %atomic-rating;
-file atomic-rating.dtd.
-
-The evaluation are returned, one <!ELEMENT get-atomic-ratings-response
-rating service at a time.        (rejection+ | atomic-rating+)>
-
-If only some of the settings     <!ELEMENT rejection (#PCDATA)>
-were accepted, here is a list of
-those not accepted. The #PCDATA
-can contain a human-readable
-description of the refusal
-reason in the preferred language
-of the user doing the
-registration (not always the
-language of the user being
-registered).
-
-XML attributes for               <!ATTLIST rejection
-refuse-reason.
-
-Why the attribute was rejected.    refuse-reason (
-                                   authorisation | bad-syntax |
-                                   no-such-attribute | no-ratings-available |
-                                   not-logged-in | other-reason
-End of refuse-reason.              ) #REQUIRED
-
-Refused value of this attribute.   refused-value CDATA #IMPLIED
-
-End of XML attribute list.       >
-
-Example 1 (get-atomic-ratings-response):
-
-Note: This response is sent in the case where the ISCN server had no
-ratings for any of the resources requested, so that only ratings from
-the select general ratings server are returned.
-
-Explanation             Information sent
------------             ----------------
-
-HTTP response header    HTTP/1.1 200 OK
-                        Content-Length: 569
-                        Content-Type: application/xml
-                        Server: Select 1.0
-                        Date: 7 July 1999 19:58:23 +0200
-
-A blank line to
-indicate the end of
-the HTTP header
-
-Identifies that this    <?xml version="1.0"?>
-is in XML format.
-
-References the          <!DOCTYPE get-atomic-ratings-response SYSTEM
-Resource Type           "http://select/v1.0/get-atomic-ratings-response.dtd">
-Declaration (DTD) file
-specifying the syntax
-for this XML resource.
-
-Start of                <get-atomic-ratings-response>
-get-atomic-ratings-res
-ponse for one
-resource.
-
-First rating returned.  <atomic-rating
-                          raterid-or-pseudonym="jpalme@dsv.su.se"
-                          rating-engine="select/select-proxy-1"
-                          location="http://www.body.com/eyes"
-                          rating-date="31 Jul 1999"
-                          rater-competence="user"
-                          rater-type="manual"
-                          rater-trust="registered"
-                          message-id="990815113350*jpalme@dsv.su.se">
-
-First rating            <rating-value
-descriptor.               type="select-reader-interest-rating"
-                          value="good"/>
-
-Second rating           <rating-value
-descriptor.               type="adult"
-                          value="false"/>
-
-Third rating            <rating-value
-descriptor.               type="context"
-                          value="leisure"/>
-
-End of data.            </atomic-rating>
-
-Second rating           <atomic-rating
-returned.
-                        raterid-or-pseudonym="father.christmas@northpole.com"
-                          rating-engine="select/select-proxy-1"
-                          location="http://www.body.com/eyes"
-                          rating-date="17 Aug 1999"
-                          rater-competence="expert"
-                          rater-type="manual"
-                          rater-trust="registered"
-                          message-id="990815113350*jpalme@dsv.su.se">
-
-First rating            <rating-value
-descriptor.               type="select-reader-interest-rating"
-                          value="87"/>
-
-Second rating           <rating-value
-descriptor.               type="adult"
-                          value="false"/>
-
-Third rating            <rating-value
-descriptor.               type="context"
-                          value="leisure"/>
-
-End of data             </atomic-rating>
-                        </get-atomic-ratings-response>
-
-Example 2 (get-atomic-ratings-response rejection):
-
-Explanation                         Information sent
------------                         ----------------
-
-HTTP response header.               HTTP/1.1 200 OK
-                                    Content-Length: 569
-                                    Content-Type: application/xml
-                                    Server: Select 1.0
-                                    Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the end
-of the HTTP header.
-
-Identifies that this is in XML      <?xml version="1.0"?>
-format.
-
-References the Resource Type        <!DOCTYPE get-atomic-ratings-response
-Declaration (DTD) file specifying   SYSTEM
-the syntax for this XML resource.   "http://select/v1.0/get-atomic-ratings-res
-                                    ponse.dtd">
-Start of server list.               <get-atomic-ratings-response>
-
-Start of ratings for one resource   <rejection refuse-reason="not-logged-in"/>
-to be rated.
-
-End of evaluate-response report     </get-atomic-ratings-response>
-and end of file.
-
-
-7.11  Simple-Search Operation
-
-Issue: Should this really be in the standard? Is this not a user
-interface issue, since it is specified as an HTML search form below?
-
-Summary: Find web pages satisfying a query and which are highly rated.
-
-Access control: No access control for basic rating. Rating based on a
-particular users interest and values may be available only if preceded
-by a login operation for this particular user.
-
-Input data: The user specifies the query by filling in a query form.
-Simple search, when the personalised checkbox is unchecked, is always
-made on the general-rating derived descriptor. When the Personalized
-search checkbox is checked, the general-rating is made using a default
-personal-rating derived descriptor, which actually returns different
-values for each user. If the user is unknown, Personalized search will
-return an error message.
-
-Output data: A HTML page or an XML document with a list of found pages
-sorted according to rating and relevance.
-
-Base protocol: HTML application/x-www-form-urlencoded for the request,
-and HTML or XML for the response.
-
-7.11.1      Query format (simple-search-query):
-
-The simple-search query is an HTTP GET operation with the query after
-"?" in the URI.
-
-The query is the same as would be sent with the following HTML form:
-
-
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
-<HTML>
-<HEAD>
-<TITLE>SELECT Search Query</TITLE>
-<style type="text/css">
-<!--
-p {  font-family: Verdana, Arial, Helvetica, Geneva, sans-serif;
-font-size: 10pt}
-td {  font-family: Verdana, Arial, Helvetica, Geneva, sans-serif;
-font-size: 10pt}
--->
-</style></HEAD>
-<BODY bgcolor="#FFFFFF">
-<FORM ACTION="http://www.dsv.su.se/~jpalme/test/echo.cgi" METHOD=get
-NAME="searchform">
-  <table border="0" cellspacing="0" cellpadding="2" align="center">
-    <tr bgcolor="#6633CC" align="center">
-      <td rowspan=5 valign="top" width="121" align="center">
-        <div align="left"><font color='white'> Search: <br>
-          <input type="checkbox" name="search"
-                 value="internet" checked>
-          Internet <br>
-          <input type="checkbox" name="search" value="select"
-                 checked>
-          Select directory <br>
-          <input type="checkbox" name="search" value="news"
-                 checked>
-          News </font></div>
-        <font color='white'>
-        <hr width="70" align="left">
-        <div align="left">
-          <input type="checkbox" name="unseen" value="yes">
-          Only unseen</div>
-        </font></td>
-      <td colspan=5 rowspan="2"><font color='white'>
-          &nbsp; Search query:
-        <INPUT SIZE=54 MAXLENGTH=256 NAME="query" value="">
-        &nbsp;
-        <input type="submit" name="Search" value="Search">
-        </font></td>
-    </tr>
-    <tr bgcolor="#FFFFCC">
-      <td width="21"><font color="#FFFFFF"></font></td>
-    </tr>
-    <tr bgcolor="#CCFF99">
-      <td valign="top" width="163" align="center" > Limit to
-Country:<br>
-        <input type="text" name="textfield">
-      </td>
-      <td valign="top" width="122" > <b>Limit to Language:</b><br>
-        <select name="lang" size=1>
-          <option value="world" selected>Any
-          <option value="welsh">Cymraeg
-          <option value="dansk">Dansk
-          <option value="deutsch">Deutsch
-          <option value="english">English
-          <option value="espa&ntilde;ol">Espa&ntilde;ol
-          <option value="fran&ccedil;ais">Fran&ccedil;ais
-          <option value="italiano">Italiano
-          <option value="magyar">Magyar
-          <option value="nederlands">Nederlands
-          <option value="norsk">Norsk
-          <option value="portugu&ecirc;s">Portugu&ecirc;s
-          <option value="suomi">Suomi
-          <option value="svenska">Svenska
-        </select>
-      </td>
-      <td valign="top" width="109" >
-        <p align="center"> <b>Result format:</b><br>
-          <input type="radio" name="resultformat"
-                 value="html" checked>
-          HTML
-          <input type="radio" name="resultformat" value="xml">
-          XML </p>
-      </td>
-      <td valign="top" width="24">
-        <div align="right">
-          <input type="checkbox" name="personalized" value="yes">
-        </div>
-      </td>
-      <td valign="top" width="145" >
-        <p>Peer search</p>
-        <p><b>Max no of docs:</b>
-          <input type="text" name="maxno" size="4"
-                 maxlength="20" value="50">
-        </p>
-      </td>
-      <td width="21" bgcolor="#FFFFFF"> </td>
-    </tr>
-    <tr bgcolor="#FFFFCC">
-      <td valign="middle" colspan="5" align="center"> Context:
-        <input type="checkbox" name="context" value="yes" checked>
-        general
-        <input type="checkbox" name="business" value="yes" checked>
-        business
-        <input type="checkbox" name="leisure" value="yes" checked>
-        leisure
-        <input type="checkbox" name="shopping" value="yes" checked>
-        shopping
-        <input type="checkbox" name="research" value="yes" checked>
-        research
-        <input type="checkbox" name="politics" value="yes" checked>
-        politics<br>
-      </td>
-      <td width="21" rowspan="2"><font color="#FFFFFF"></font></td>
-    </tr>
-    <tr bgcolor="#FFFFCC">
-      <td valign="middle" colspan="5" align="center"
-          bgcolor="#6633CC"> <font color="#FFFFFF">
-        <input type="checkbox" name="Use my keywords"
-               value="Keyworduse" checked>
-        Use my interest profile&nbsp;&nbsp;
-        <input type="checkbox" name="usekeywords"
-               value="usemykeywords" checked>
-        &nbsp;Use my keywords&nbsp;&nbsp;
-        <input type="checkbox" name="onlymanual"
-               value="onlymanual">
-        &nbsp;Use only manual keywords and profile</font></td>
-    </tr>
-  </table>
-</FORM>
-</BODY></HTML>
-
-If the user check to "Use my interest profile" or "Use my keywords",
-then that user can, but need not fill in any "Search query". If the
-user does not fill in any "Search Query" but checks "Only unseen" and
-"Use my interest profile" or "Use my keywords", then this will be a
-search for highly-rated new, by this user unseen information. Note that
-by checking "News", a search for news articles is done and the result
-may be presented on the web, even though the rating of these web
-articles was done through a newsreader and not through a web interface.
-
-By "Peer search" is meant search, where higher value is given to
-ratings provided by people with similar interests and values as
-yourself.
-
-Example of query string:
-
-(filter OR "SELECT rating") AND EU&domain=world&language=world
-
-which with URI encoding will become:
-
-search=internet&search=select&search=news&query=%28filter+OR+%22SELECT+
-rating%22%29+AND+EU&Search=Search&textfield=&lang=world&resultformat=ht
-ml&context=yes&business=yes&leisure=yes&shopping=yes&research=yes&polit
-ics=yes
-
-Example of a simple-search query
-
-Query is sent to the following URL for the SELECT general service:
-
-http://select/v1.0/general/simple-search?query=
-
-Explanation             Information sent
------------             ----------------
-
-Connect to the SELECT   GET /v1.0/general/simple-search?search=internet&searc
-server                  h=select&search=news&query=%28filter+OR+%22SELECT+rat
-                        ing%22%29+AND+EU&Search=Search&textfield=&lang=world&
-"format" can be either  resultformat=html&context=yes&business=yes&leisure=ye
-"xml" or "html" and     s&shopping=yes&research=yes&politics=yes HTTP/1.1
-specifies in which
-format the response is
-to be delivered
-
-To the HTTP server      Host: select
-"select" port 80.
-
-Only files in the       Accept: application/xml
-format application/xml
-are accepted.
-
-This user has           Cookie: session="1234567890123456"
-connected to this
-server before, and a
-cookie identifies the
-session.
-
-
-
-7.11.2      Response format (simple-search-response):
-
-The simple-search response can be in either XML or HTML format
-depending on the request. If no format was specified in the request,
-HTML is the default format. The response contains a list of resources
-matching the query and sorted by rating-value. This standard only
-specifies the XML response format, the HTML response format is not
-standardized.
-
-The XML Resource Type Declaration for this XML resource is:
-
-Explanation                     Format of information sent
------------                     --------------------------
-                                (http://select/v1.0/simple-search-response.dt
-                                d)
-
-The evaluation are returned,    <!ELEMENT simple-search-response
-one rating service at a time.   (error | resource+)>
-
-                                <!ELEMENT error (#PCDATA)>
-
-                                <!ATTLIST error
-
-If rating was rejected,           refuse-reason ( bad-syntax |
-explanation why. See              access-control | other) 'access-control'
-
-Refusal reasons, chapter
-7.5.2.1.
-
-End of XML attribute list.      >
-
-If only some of the rating      <!ELEMENT resource (#PCDATA)>
-values were rejected, this
-element is used to list the
-rejected rating values. The
-#PCDATA contains the summary or
-keywords or some other
-description of the found
-resource.
-
-                                <!ATTLIST resource
-
-Some kind of computed rating      rating CDATA #REQUIRED
-value.
-
-                                  title CDATA #IMPLIED
-
-URI of the found resource.        uri CDATA #REQUIRED
-
-End of XML attribute list.      >
-
-
-Example 1 (positive simple-search response):
-
-Explanation                     Information sent
------------                     ----------------
-
-HTTP response header            HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE simple-search-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/simple-search-response.dt
-specifying the syntax for this  d">
-XML resource.
-
-                                <simple-search-response>
-
-                                <resource rating="88"
-                                  title="Kenyan flowers"
-                                  uri="http://www.flowers.com/kenya/">
-
-                                An overview of flowers found in Kenya.
-
-                                </resource>
-
-                                <resource rating="78"
-                                  title="Kiwi flowers"
-                                  uri="http://www.flowers.com/kiwi/">
-
-                                An overview of flowers found in Kiwi.
-
-                                </resource>
-
-                                </simple-search-response>
-
-Example 2 (negative simple-search response):
-
-Explanation                     Information sent
------------                     ----------------
-
-HTTP response header.           HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE simple-search-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/simple-search-response.dt
-specifying the syntax for this  d">
-XML resource.
-
-All ratings were not accepted.  <simple-search-response>
-
-Rating-label rejected, this     <error>You are not allowed to make this
-server does not accept ratings  search.</error>
-in the leisure context.
-
-End of simple-search-response.  </simple-search-response>
-
-
-
-7.12  Advanced-Search Operation (Not yet ready)
-
-Summary: Find web pages satisfying a query and which are highly rated.
-
-Access control: No access control for basic rating. Rating based on a
-particular users interest and values may be available only if preceded
-by a login operation for this particular user.
-
-Input data: Some general-purpose search format, based on SQL or some
-other search language. The advanced search should especially allow the
-needs of other modules.
-
-Required functionality:
-
-1.  It should be possible to search on all derived and
-    atomic ratings. Example of use: The NLP modules need
-    a way of getting a list of which documents are to be
-    rated by the NLP modules. Can this be done through a
-    variant of the advanced-search operation?
-
-2.  It should be possible to retrieve all ratings on
-    resources with a particular author, including ratings
-    with a particular author sent to a particular
-    newsgroup.
-
-Output data: A HTML page or an XML document with a list of found pages
-sorted according to rating and relevance.
-
-Base protocol: HTML application/x-www-form-urlencoded for the request,
-and HTML or XML for the response.
-
-
-7.12.1      Query format (advanced-search-query):
-
-The advanced-search query is an HTTP POST operation, whose body is an
-XML resource containing the profile, sent to the profiles cgi-script in
-the server for this particular rating service. Example:
-"http://select/v1.0/general/id/search".
-
-Explanation                         Information sent
------------                         ----------------
-
-Connect to the SELECT server        POST /v1.0/general/id/search HTTP/1.1
-
-To the HTTP server "select" port    Host: select
-80.
-
-Only files in the format            Accept: application/xml
-application/xml are accepted.
-
-The format of the query is XML.     Content-Type: Application/xml
-
-This user has connected to this     Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-
-The body of the operation is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is:
-
-Explanation             Format of information sent
------------             --------------------------
-                        (http://select/v1.0/advanced-search.dtd)
-
-Not yet ready
-
-Example of a advanced-search query
-
-Explanation             Format of information sent
------------             --------------------------
-                        (http://select/v1.0/advanced-search.dtd)
-HTTP header.            POST /v1.0/general/id/advanced-search  HTTP/1.1
-                        Host: select
-                        Accept: application/xml
-                        Content-Type: Application/xml
-                        Cookie: session="012345678901234354"
-
-A blank line to mark
-the end of the HTTP
-header.
-
-Identifies that this    <?xml version="1.0"?>
-is in XML format.
-
-References the          <!DOCTYPE advanced-search SYSTEM
-Resource Type            "http://select/v1.0/advanced-search.dtd">
-Declaration (DTD) file
-specifying the syntax
-for this XML resource.
-
-Not yet ready
-
-
-7.12.2      Response format (advanced-search-response):
-
-The response format for the advanced-search is the same as the response
-format for the simple search, described in section 0.
-
-
-7.13  Evaluate Operation
-
-Summary: Get the ratings for a list of URIs.
-
-Access control: No access control for basic rating. Rating based on a
-particular user's interest and values may be available only if preceded
-by a login operation for this particular user.
-
-Input data: A list of URIs and a list of services. For each service, a
-list of aggregate rating labels are listed. Note that only aggregate
-ratings, not atomic ratings, can be found with  this operation. If N
-URIs, M services and V label types are listed, then NxMxV rating labels
-are returned.
-
-Output data: A list of rating labels.
-
-Base protocol: HTTP and XML.
-
-Issue: Is a "streaming" version of this operation needed? By streaming
-is meant a version in which the URIs to process are sent to the server
-in parallel with the server returning responses, so that responses for
-the first URIs are returned before the last URIs have been sent to the
-server for evaluation.
-
-
-7.13.1      Query format (evaluate-query):
-
-The evaluate query is an HTTP POST operation, whose body is an XML
-resource containing the query, sent to
-http://select/v1.0/general/evaluator
-
-Explanation                        Information sent
------------                        ----------------
-
-Connect to the SELECT server.      POST /v1.0/general/evaluator  HTTP/1.1
-
-To the HTTP server "select" port   Host: select
-80.
-
-Only files in the format           Accept: application/xml
-application/xml are accepted.
-
-The format of the query is XML.    Content-Type: Application/xml
-
-This user has connected to this    Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-
-The body of the query is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is:
-
-Explanation                    Format of information sent
------------                    --------------------------
-                               (http://select/v1.0/evaluate-query.dtd)
-
-A list of locations to be      <!ELEMENT evaluate-query (location+,
-evaluated, followed by a list  service+)>
-of services to evaluate these
-locations. The returned
-response will be L x S rating
-labels, if L is the number of
-locations and S the number of
-services.
-
-Start of attribute list for    <!ATTLIST evaluate-query
-evaluate-query.
-
-Whether rating are to be         personal (true | false)'false'
-personalised by comparison to
-other people with similar
-views to myself.
-
-True means that the responses    sort (true | false)'true'
-are sorted in rating priority
-order. False means that the
-responses are returned in the
-order they were given in the
-request.
-
-Restrict the evaluation to       context (general | business | leisure
-only ratings done in a          shopping | research | politics | all) 'all'
-certain context.
-
-End of the list of XML         >
-attributes.
-
-Each URI to be evaluated is a  <!ELEMENT location (#PCDATA)>
-free text field containing
-the URI of the resource to be
-evaluated.
-
-Each service description is a  <!ELEMENT service (label* | collection-name)>
-free text field containing
-the URI of the service.
-
-Start of attribute list for    <!ATTLIST service
-service.
-
-Identification of the service    location CDATA #REQUIRED
-by its URI.
-
-End of the list of XML         >
-attributes.
-
-List of requested              <!ELEMENT label (#PCDATA)>
-descriptors. If no list is
-specified, this means that
-all available descriptors are
-requested. Only aggregate
-ratings can be requested, not
-atomic ratings.
-
-Start of attribute list for    <!ATTLIST label
-label.
-
-If match is true, then  all      match ( false | true ) 'false'
-labels whose name begin with
-the given string are
-retrieved. For example, with
-match=true and the label
-value "keywords", labels of
-derived descriptors like
-"keywords-tropical" and
-"keywords-flowers" might be
-retrieved.
-
-End of the list of XML         >
-attributes.
-
-Instead of listing the labels  <!ELEMENT collection-name EMPTY>
-to be retrieved, it is
-possible to just specify the
-name of a collection, to
-retrieve the labels specified
-in this collection.. The
-collection must be a
-collection specified in the
-service-description of the
-service used.
-
-                               <!ATTLIST collection-name
-                                 name CDATA #REQUIRED >
-
-Example of a body (evaluate-query):
-
-Explanation             Information sent
------------             ----------------
-                        (http://select/v1.0/evaluate-query.xml)
-
-Start.                  <?xml version="1.0"?>
-                        <!DOCTYPE evaluate-query SYSTEM
-                        "http://select/v1.0/evaluate-query.dtd">
-                        <evaluate-query>
-
-List of locations to    <location>http://www.body.com/toes</location>
-be evaluated.           <location>http://www.face.com/eyes</location>
-
-List of services whose  <service
-evaluations are
-requested. For each     location="http://select/v1.0/general/general-service-
-service, the            description.xml">
-descriptors requested   <label>select-reader-quality-rating</label>
-are listed. For the     <label>select-reader-interest-rating</label>
-general service,        <label match="true">keywords</label>
-reader-quality and      </service>
-reader-interest-rating  <service
-s are requested, for
-the iscn service, all   location="http://select/v1.0/general/iscn-service-des
-available descriptors   cription.xml"
-are requested.          />
-                        <service
-
-                        location="http://select/v1.0/general/flower-lovers-se
-                        rvice-description.xml">
-                        <collection-name name="instant-ratings"/>
-                        </service>
-
-End of evaluate-query.  </evaluate-query>
-
-
-7.13.2      Response format (evaluate-response):
-
-The response is an XML [XML1], [XML2] document. The XML Resource Type
-Declaration for this XML resource is:
-
-Explanation                  Format of information sent
------------                  --------------------------
-                             (http://select/v1.0/evaluate-response.dtd)
-
-The evaluation are           <!ELEMENT evaluate-response (rejection |
-returned, one rating         resource+)>
-service at a time.
-
-Start of list of attributes  <!ATTLIST evaluate-response
-for the evaluate-service
-element.
-
-URI of the service, only       service CDATA #IMPLIED
-used if all ratings
-returned are from the same
-service.
-
-Whether rating are to be       personal (true | false) 'false'
-personalised by comparison
-to other people with
-similar views to myself.
-
-True means that the            sort (true | false) 'true'
-responses are sorted in
-rating priority order.
-False means that the
-responses are returned in
-the order they were given
-in the request.
-
-End of the list of XML       >
-attributes.
-
-                             <!ELEMENT rejection EMPTY>
-                             <!ATTLIST rejection
-Reject reason, no default      reject-reason ( not-logged-in | bad-syntax |
-value.                         not-found | authorisation-failure |
-                             other-reason )
-                               #IMPLIED
-End of XML attributes for    >
-"rejection".
-
-                             <!ELEMENT resource (label*)>
-
-URI of the rated resource.   <!ATTLIST resource
-                               location CDATA #REQUIRED
-
-End of XML attributes for    >
-"resource".
-
-Start of a ratings label.    <!ELEMENT label EMPTY>
-Note: If no label is
-available, then no labels
-are specified.
-
-Start of attribute list for  <!ATTLIST label
-label.
-
-URI of the service             service CDATA #IMPLIED
-providing this label.
-This attribute may be
-omitted in the following
-two cases:
-
-(a) if all ratings come
-from the same service, and
-this service was specified
-as an attribute to the
-evaluate-response.
-
-(b) in a series of labels
-from the same service on
-the same resource, only the
-first need specify the
-service.
-
-Default descriptor format      format (numerical | words | text | date)
-is numerical. Alternative    'numerical'
-descriptors are words (list
-of keywords etc.) or text
-(any plain UTS-8 text) or
-date (in mail header
-format, for example "29 Jul
-1999".
-
-Name of a descriptor,          name CDATA #REQUIRED
-either its transmit-as or
-short-form name, as
-specified in the rating
-service description for the
-rating service used.
-
-The format of the value        value CDATA #REQUIRED
-depends on the type, as
-specified in the rating
-service description.
-
-The confidence (number of      confidence CDATA #IMPLIED
-evaluators) behind this
-value.
-
-This rating value is only      context ( general | business | leisure |
-valid in a certain context.    shopping | research | politics | all )'all'
-
-End of attribute list.       >
-
-
-Example 1 (evaluate response):
-
-Note: This response is sent in the case where the ISCN server had no
-ratings for any of the resources requested, so that only ratings from
-the select general ratings server are returned.
-
-Explanation                     Information sent
------------                     ----------------
-
-HTTP response header            HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE evaluate-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/evaluate-response.dtd">
-specifying the syntax for this
-XML resource.
-
-Start of evaluate-response for  <evaluate-response>
-one resource.
-
-Start of ratings for one        <resource
-resource to be rated.           location="http://www.body.com/toes">
-
-One rating descriptor value for <label
-this resource.
-
-                                service="http://select/v1.0/general/general-s
-                                ervice-description.xml"
-Confidence of this value.         confidence="12"
-
-Type of label value.              format="numerical"
-
-Name of this label (either        name="select-reader-quality-rating"
-transmit-as or short-name).
-
-Value of this descriptor.         value="88"
-
-Restricted context of this        context="leisure"
-rating value.
-
-End of this label.              />
-
-Another rating descriptor       <label
-value.
-
-Confidence of this label.         confidence="57"
-
-Type of label value.              format="numerical"
-
-A derived attribute containing    name="keywords-tropical"
-a frequency count.
-
-Number of people who have         value="3"
-assigned the keyword "tropical"
-to this resource.
-
-Restricted context of this        context="leisure"
-rating value.
-
-End of this label.              />
-
-Another rating descriptor       <label
-value.
-
-Confidence of this label.         confidence="33"
-
-Type of label value.              format="numerical"
-
-Name of this label (either        name="select-reader-interest-rating"
-transmit-as or short-name).
-
-Value of this label.              value="78"
-
-Restricted context of this        context="leisure"
-rating value.
-
-End of this label.              />
-
-One rating descriptor value for <label
-this resource.
-
-                                service="http://select/v1.0/general/iscn-serv
-                                ice-description.xml"
-
-Type of label value.              format="numerical"
-
-Confidence of this value.         confidence="12"
-
-Name of this label (either        name="scientific-relevance"
-transmit-as or short-name).
-
-Value of this descriptor.         value="88"
-
-Restricted context of this        context="research"
-rating value.
-
-End of this label.              />
-
-End of list of all labels for   </resource>
-this resource.
-
-Start of ratings for one        <resource
-resource to be rated.           location="http://www.body.com/toes">
-
-One rating descriptor value.    <label
-
-                                service="http://select/v1.0/general/general-s
-                                ervice-description.xml"
-
-Confidence of this label.         confidence="55"
-
-Type of label value.              format="numerical"
-
-Name of this label (either        name="select-reader-quality-rating"
-transmit-as or short-name)
-Value of this label.              value="88"
-
-End of this label.              />
-
-One rating descriptor value.    <label
-
-Confidence of this label.         confidence="33"
-
-Default descriptor format is      format="numerical"
-numerical. Alternative
-descriptors are words (list of
-keywords etc.) or text (any
-plain UTS-8 text) or date (in
-mail header format, for example
-"29 Jul 1999".
-
-Name of this label (either        name="select-reader-interest-rating"
-transmit-as or short-name).
-
-Value of this label.              value="78"
-
-End of this label.              />
-
-End of list of all labels for   </resource>
-this resource.
-
-End of evaluate-response report </evaluate-response>
-and end of file.
-
-
-Example 2 (evaluate response rejection):
-
-Explanation                         Information sent
------------                         ----------------
-
-HTTP response header.               HTTP/1.1 200 OK
-                                    Content-Length: 569
-                                    Content-Type: application/xml
-                                    Server: Select 1.0
-                                    Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the end
-of the HTTP header.
-
-Identifies that this is in XML      <?xml version="1.0"?>
-format.
-
-References the Resource Type        <!DOCTYPE evaluate-response SYSTEM
-Declaration (DTD) file specifying   "http://select/v1.0/evaluate-response.dtd"
-the syntax for this XML resource.   >
-
-Start of server list.               <evaluate-response>
-
-Start of ratings for one resource   <rejection reject-reason="not-logged-in"/>
-to be rated.
-
-End of evaluate-response report     </evaluate-response>
-and end of file.
-
-
-
-7.14  Exchange-Ratings-Data (not yet ready)
-
-Summary: This operation is used between two select servers, in order to
-replicate information in their data bases.
-
-Issues:
-
-Access control:
-
-Input data:
-
-Output data:
-
-Base protocol:
-
-
-7.14.1      Query format (exchange-ratings-data):
-
-Example (replicate-ratings):
-
-Explanation                    Information sent
------------                    ----------------
-
-Not ready
-
-
-7.14.2      Response format (exchange-ratings-data):
-
-Explanation             Format of information sent
------------             --------------------------
-                        (http://select/v1.0/exchange-ratings-data.dtd)
-
-Not ready
-Example (replicate-ratings response):
-
-Explanation             Information sent
------------             ----------------
-
-Not ready
-
-8.    The SELECT general service description
-
-A SELECT general service description file contains
-
--  A list of services
--  Per service
--  Admistrative information about the service accessible on the
-   server
--  Name
--  Maintainer
--  Website about the service
--  Textual description in natural language (possible in multiple
-   languages)
--  A list of categories
--  Per category
--  A textual description of the category (possible in multiple
-   languages)
--  A name for the category
--  Rater type (human or computer generated rating)
--  The datatype of the ratings for this category (a label,
-   keyword, value or derived category)
--  Depending on the datatype
--  Value:
-   How the category should be displayed on screen ("none" if not
-   possible)
-   The calculationmethod used to calculate the instant rating
-   value of a resource for this category
-   A minimum and maximum value for the rating values in this
-   category
--  Label :
-   How the category should be displayed on screen ("none" if
-   not possible)
-   The calculationmethod used to calculate the instant rating
-   value of a resource for this category
-   A list of labels for the category. Per Label
--  A value that corresponds to the description contained in the
-   textual or iconic labels.
--  A list of Textual and/or Iconic labels (possible in multiple
-   languages)
--  Derived:
-   The calculationmethod used to calculate the instant rating
-   value of a resource for this category
-   A number of categories from which the value of an instant
-   rating of this category is derived.
-   A list of labels that describe how to map the value of an
-   instant rating of this category back to natural language.
-   Per label
--  A minumum and maximum value. If the rating falls between these
-   2 values, the associated textual label is selected.
--  Keyword:
-   The calculationmethod used to calculate the instant rating
-   value of a resource for this category
--  A list of imported categories : categories of other services
-   that are imported into this service
--  The classname of the Java class that starts the agents
-   associated with the service.
-
-All this translates to the XML document type definition looks like
-this:
-
-<?xml version="1.0" encoding="UTF-8" ?>
-<!ELEMENT services (service*)>
-<!ELEMENT description EMPTY>
-<!ATTLIST description
-   language CDATA #REQUIRED
-   text     CDATA #REQUIRED
->
-<!ELEMENT import EMPTY>
-<!ATTLIST import
-   service  CDATA #REQUIRED
-   category CDATA #REQUIRED
->
-<!ELEMENT service (description+, category+, import*, agentinit?)>
-<!ATTLIST service
-   id          CDATA #REQUIRED
-   URI         CDATA #REQUIRED
-   server      CDATA #REQUIRED
-   maintainer  CDATA #REQUIRED
-   anonymous   (allowed | forbidden) 'allowed'
->
-<!ELEMENT agentinit EMPTY>
-<!ATTLIST agentinit
-  classname CDATA #REQUIRED
->
-<!ELEMENT category (description+, (labelcategory | valuecategory |
-keywordcategory | derivedcategory))>
-<!ATTLIST category
-   id         CDATA #REQUIRED
-   rater-type (human | computer) 'computer'
-   type       (label | value | keyword | derived) 'label'
->
-<!ELEMENT labelcategory (label+)>
-<!ATTLIST labelcategory
-   gui         (buttons | radiobuttons | list | icons | none) 'none'
-   calculation CDATA #REQUIRED
->
-<!ELEMENT label (description*, icon*)>
-<!ATTLIST label
-   value  CDATA #REQUIRED
->
-<!ELEMENT icon EMPTY>
-<!ATTLIST icon
-   language CDATA #REQUIRED
-   text     CDATA #REQUIRED
->
-<!ELEMENT valuecategory EMPTY>
-<!ATTLIST valuecategory
-   gui         (slider | buttons | none) 'none'
-   min         CDATA #IMPLIED
-   max         CDATA #IMPLIED
-   upperlimit  (yes | no) 'no'
-   calculation CDATA #REQUIRED
->
-<!ELEMENT keywordcategory EMPTY>
-<!ATTLIST keywordcategory
-   calculation CDATA #REQUIRED
->
-<!ELEMENT derivedcategory (derivedfrom+, derivedlabel*)>
-<!ATTLIST derivedcategory
-   calculation CDATA #REQUIRED
->
-<!ELEMENT derivedfrom EMPTY>
-<!ATTLIST derivedfrom
-   service    CDATA #REQUIRED
-   category   CDATA #REQUIRED
->
-<!ELEMENT derivedlabel (description*)>
-<!ATTLIST label
-   min  CDATA #REQUIRED
-   max  CDATA #REQUIRED
->
-
-
-8.1   Example
-
-An example of all this is the service description file of the SELECT
-test server:
-
-<?xml version="1.0"?>
-<!DOCTYPE services SYSTEM "services.dtd">
-<services>
-  <!-- The SELECT test service -->
-  <!-- *********************** -->
-  <service
-     id         = "test"
-     URI        = "http://samson.aszi.sztaki.hu/SELECT"
-     server     = "samson.aszi.sztaki.hu"
-     maintainer = "micsik@sztaki.hu"
-     anonymous  = "allowed">
-     <description language = "en" text = "SELECT test service">
-     </description>
-     <description language = "nl" text = "SELECT test dienst">
-     </description>
-     <!-- Quality of the document according to the user -->
-     <category
-        id         = "contents"
-        rater-type = "human"
-        type       = "label">
-        <description language = "en"
-        text = "Quality of the content of the document">
-       </description>
-        <description language = "nl"
-        text = "Kwaliteit van de inhoud van het document">
-       </description>
-        <labelcategory
-           gui         = "buttons"
-           calculation = "average">
-           <label value = "1">
-              <description language = "en"
-              text = "Awful"></description>
-              <description language = "nl" text = "Verschikkelijk">
-              </description>
-              <icon        language = "en" text =
-              "http://samson.aszi.s ztaki.hu/SELECT/icons/1star.gif">
-             </icon>
-           </label>
-           <label value = "2">
-              <description language = "en"
-              text = "Mediocre"></description>
-              <description language = "nl"
-              text = "Middelmatig">
-              </description>
-              <icon        language = "en" text =
-              "http://samson.aszi.sztaki.hu/SELECT/icons/2star.gif">
-             </icon>
-           </label>
-           <label value = "3">
-              <description language = "en" text = "OK"></description>
-              <description language = "nl" text = "OK"></description>
-              <icon        language = "en" text =
-              "http://samson.aszi.sztaki.hu/SELECT/icons/3star.gif">
-             </icon>
-           </label>
-           <label value = "4">
-              <description language = "en" text = "Good"></description>
-              <description language = "nl" text = "Goed"></description>
-              <icon        language = "en" text =
-              "http://samson.aszi.sztaki.hu/SELECT/icons/4star.gif">
-             </icon>
-           </label>
-           <label value = "5">
-              <description language = "en" text = "Great">
-             </description>
-              <description language = "nl" text = "Geweldig">
-             </description>
-              <icon        language = "en" text =
-             "http://samson.aszi.sztaki.hu/SELECT/icons/5star.gif">
-             </icon>
-           </label>
-        </labelcategory>
-     </category>
-     <!-- Style of the document according to NLP -->
-     <category
-        id         = "style"
-        rater-type = "computer"
-        type       = "value">
-        <description language = "en" text =
-        "The quality of the document according to the NLP modules">
-        </description>
-        <description language = "nl" text =
-        "De kwaliteit van het document volgen de NLP modules">
-        </description>
-        <valuecategory
-            gui         = "none"
-            min         = "0"
-            max         = "10"
-            upperlimit  = "yes"
-            calculation = "NLP"/>
-     </category>
-     <!-- Time spent reading the document -->
-     <category
-        id         = "readtime"
-        rater-type = "computer"
-        type       = "value">
-        <description language = "en" text =
-        "The time spent reading this document in seconds">
-        </description>
-        <description language = "nl" text =
-        "De tijd waarin het document gelezen werd in seconden">
-        </description>
-        <valuecategory
-           gui         = "none"
-           min         = "0"
-           max         = "600"
-           upperlimit  = "no"
-           calculation = "median"/>
-     </category>
-     <!-- Human added keywords -->
-     <category
-        id         = "keywords"
-        rater-type = "human"
-        type       = "keyword">
-        <description language = "en"
-        text = "Human added keywords"></description>
-        <description language = "nl"
-        text = "Kernwoorden die door de gebruiker werden toegevoegd">
-        </description>
-        <keywordcategory
-           calculation = "count"/>
-     </category>
-     <!-- Overall quality of the document -->
-     <category
-        id         = "quality"
-        rater-type = "computer"
-        type       = "derived">
-        <description language = "en"
-        text = "Overall quality of the document"></description>
-        <description language = "nl" text =
-       "Algemene kwaliteit van het document"></description>
-        <derivedcategory
-           calculation = "statistics">
-           <derivedfrom service = "test" category = "contents"/>
-           <derivedfrom service = "test" category = "style"/>
-           <derivedlabel min = "0" max = "1">
-              <description language = "en"
-              text = "Awful"></description>
-              <description language = "nl"
-              text = "Verschrikkelijk"></description>
-           </derivedlabel>
-           <derivedlabel min = "1" max = "2">
-              <description language = "en"
-              text = "Mediocre"></description>
-              <description language = "nl"
-              text = "Middelmatig"></description>
-           </derivedlabel>
-           <derivedlabel min = "2" max = "3">
-              <description language = "en" text = "OK"></description>
-              <description language = "nl" text = "OK"></description>
-           </derivedlabel>
-           <derivedlabel min = "3" max = "4">
-              <description language = "en" text = "Good"></description>
-              <description language = "nl" text = "Goed"></description>
-           </derivedlabel>
-           <derivedlabel min = "4" max = "5">
-              <description language = "en"
-              text = "Great"></description>
-              <description language = "nl"
-              text = "Geweldig"></description>
-           </derivedlabel>
-        </derivedcategory>
-     </category>
-     <!-- The Java class that will start the Agents associated
-     with the service -->
-     <agentinit classname = "select.agent.test.TestInit">
-     </agentinit>
-  </service>
-  <!-- The ISCN test service -->
-  <!-- ************************* -->
-  <service
-     id         = "iscn"
-     URI        = "http://www.iscn.com/"
-     server     = "samson.aszi.sztaki.hu"
-     maintainer = "micsik@sztaki.hu"
-     anonymous  = "allowed">
-     <description language = "en" text = "ISCN test
-service"></description>
-     <!-- A simple category -->
-     <category
-        id         = "contents"
-        rater-type = "human"
-        type       = "value">
-        <description language = "en" text = "Example
-category"></description>
-        <valuecategory
-            gui         = "slider"
-            format      = "integer"
-            min         = "1"
-            max         = "5"
-            calculation = "mean"/>
-     </category>
-     <!-- Imported categories -->
-     <import service = "test" category = "quality"/>
-  </service>
-</services>
-
-
-9.    Example of file structure on a SELECT server
-
-Here is an example of a file structure for a SELECT server:
-
-URL                                         Content
----                                         -------
-
-http://select/v1.0/                         Repository of XML format
-                                            specifications (DTDs)
-                                            for SELECT version 1.
-
-http://select/v1.0/services.dtd             XML  format the list of
-                                            services.
-
-http://select/v1.0/service.dtd              XML format for the
-                                            description of one
-                                            SELECT service.
-
-http://select/v1.0/send-rating.dtd          XML format  for the
-                                            send-rating operation.
-
-http://select/v1.0/send-rating-response.dt  XML format for the
-d                                           responses of the
-                                            send-rating operation.
-
-http://select/v1.0/evaluate-query.dtd       XML format for the
-                                            evaluate query request.
-
-http://select/v1.0/evaluate-response.dtd    XML format for the
-                                            response of the evaluate
-                                            operation.
-
-http://select/v1.0/select-service-descript  List of SELECT services
-ions.xml                                    in version 1 of SELECT,
-                                            see 0
-                                            The SELECT general
-                                            service description on
-                                            page 73.
-
-http://select/v1.0/general/                 Version 1 of the select
-                                            general service.
-
-http://select/v1.0/general/common-service-  Description of common
-description.xml                             descriptors to several
-                                            SELECT services.
-
-http://select/v1.0/general/general-service  Description of the
--description.xml                            general SELECT service.
-                                            The general service is
-                                            for everyone, not for
-                                            specialised groups.
-
-http://select/v1.0/general/id/input-rating  Entry point for incoming
-s                                           non-anonymous
-                                            (registered or
-                                            pseudonymous) ratings to
-                                            the select general
-                                            service.
-
-http://select/v1.0/general/ano/input-ratin  Entry point for incoming
-gs                                          anonymous ratings to the
-                                            select general service.
-
-http://select/v1.0/general/search?query=    Entry point for the
-                                            web-based search
-                                            operation.
-
-http://select/v1.0/general/evaluator        Entry point for the
-                                            evaluate operation.
-
-http://select/v1.0/iscn/                    Version 1 of the select
-                                            ISCN service.
-
-http://select/v1.0/iscn/iscn-service-descr  Description of the
-iption.xml                                  special SELECT service
-                                            for ISCN.
-
-
-10.   Issues for further study
-
-These issues are items which are not needed for the base system
-implementations, and which may be modified by experience from the first
-implementation efforts.
-
-  1.    The Advanced Search facility should be specified, based on query
-       by example, SQL or some other standard query language methodology.
-
-  2.    The format of the personal interest profile, and keywords is not
-       ready. In particular, should there be a split between profile set by
-       the user him/herself and set by automatic methods, such as ML
-       algorithms on the user's rating and behaviour. Also, to what extent
-       should this profile be specified in a formal, logical language, like
-       "If newsgroup is alt.culture.sweden then do not filter away anything",
-       etc. In the first implementations, we will just use a simple set of
-       unordered keywords as the personal profile.
-
-  3.    Is security enough? Do we need more security features? If so,
-       which and how?
-
-  4.    Is there a need for NNTP versions of some or all of the
-       operations?
-
-  5.    Is a streaming version needed for the evaluate operation?
-
-  6.    Privacy and security issues for Get-Atomic-Ratings.
-
-  7.    Is more needed for ML support?
-
-  8.    Is more needed for NLP support?
-
-  9.    Exchange-Ratings-Data not ready. No great priority.
-
-  10.   Set-Service-Description not ready. No great priority. Can be done
-       using local or web-based interface.
-
-  11.   Is more needed for thesauri support?
-
-  12.   Should the SELECT protocols be based on SOAP in order to base it
-       on something existing? SOAP is described at
-       http://msdn.microsoft.com/xml/general/soap_white_paper.asp (quick
-       intrduction), and http://www.develop.com/soap/ (useful links).
-
-
-11.   The SELECT Agent protocol
-
-The advanced SELECT platform now supports an agent architecture that
-makes it easy to integrate collaborative or information filtering
-algorithms. The agents can run in the Select server or on a client
-machine over the Network and can perform tasks as maintaining
-datastructures that can speed-up collaborative filtering algorithms,
-perform collaborative filtering, notifying other agents of a change in
-the Select database or using machine learning at the client to derive
-useful user-profile information. The agents can communicate with one
-another and with the Select server using an extension of the original
-XML Select protocol. They can request certain services to be executed
-or can send a notification about the occurrence of a certain event.
-
-The introduction of agent means that the protocol had to be extended to
-support this. This appendix gives an overview of the necessary
-extensions.
-
-
-11.1.1      Entry points
-
-Following new entry points in the Select server have been made:
-
-Entry                              Function
------                              --------
-
-/agent/register-agent.xml          Register an agent with the AgentList
-/agent/deregister-agent.xml        Deregister an agent with the
-                                   AgentList
-/agent/list-agents.xml             Request a remote AgentList
-
-In addition to this, every remote agent and the server have the
-following entry points:
-
-Entry                            Function
------                            --------
-
-/agent/request/"name"            Request an agent a service
-                                 "name" is the name of the agent
-/agent/notify/"name"             Notify an agent of an event.
-                                 "name" is the name of the agent
-
-
-11.1.2      XML Extensions
-
-This is an overview of the new XML document type definitions.
-Registering an agent with the server-side AgentList.
-
-              Register Agent Request (register-agent.dtd)
-
-
-<!ELEMENT register-agent (notification*)>
-                                           name of the agent
-<!ATTLIST register-agent                   network location for
-                                           notifications and requests
-    id            CDATA #REQUIRED          description of the request
-                                           parameters (not used)
-    URL           CDATA #REQUIRED
-                                           name of the notification
-    parameters    CDATA #REQUIRED          type of notification
-
->                                          depends on the type e.g. if
-                                           type is
-<!ELEMENT notification EMPTY>              "update-in-category" it's a
-                                           string of format
-<!ATTLIST notification                     "service,category". If type
-                                           is "changing-profile" it's
-    id        CDATA #REQUIRED              the raterid of the user
-                                           whose profile is monitored
-    type      (new-rate-in-category |
-new-rate-by-user | changing-profile |
-update-in-category | alarm ) 'alarm'
-
-    typedata  CDATA #REQUIRED
-
->
-
-            Register Agent Reply (register-agent-reply.dtd)
-
-<!ELEMENT register-agent-reply EMPTY>
-                                           Positive or negative
-<!ATTLIST register-agent-reply             outcome of the register
-                                           operation
-    ok (yes | no) 'no'
-
->
-
-Deregister an agent with the server-side AgentList
-
-            Deregister Agent Request (deregister-agent.dtd)
-
-
-<!ELEMENT deregister-agent EMPTY>
-                                           Name of the agent to
-<!ATTLIST deregister-agent                 deregister
-
-    id CDATA #REQUIRED
-
->
-
-          Deregister Agent Reply (deregister-agent-reply.dtd)
-
-<!ELEMENT deregister-agent-reply EMPTY>
-                                           Possible or negative
-<!ATTLIST deregister-agent-reply           outcome of the deregister
-                                           operation
-    ok (yes | no) 'no'
-
->
-
-
-Get a remote AgentList for use in a remote agent
-             List Agents Request (list-agents-request.dtd)
-
-<!ELEMENT list-agents-request (session+)>  A list of one or more
-                                           session identifiers
-<!ELEMENT session EMPTY>
-
-<!ATTLIST session                          Identifier of a session
-
-    id CDATA #REQUIRED
-
->
-
-                  List Agents Reply (list-agents.dtd)
-
-<!ELEMENT list-agents (agent*)>            A list of data for one or
-                                           more agents
-<!ELEMENT agent EMPTY>
-
-<!ATTLIST agent
-                                           name of the agent
-    id           CDATA #REQUIRED           network location
-
-    URL          CDATA #REQUIRED           description of the request
-                                           parameters (not used)
-    parameters   CDATA #REQUIRED
-                                           session-id of the owner of
-    session-id   CDATA #REQUIRED           the agent
-
->
-Notify a remote agent of the occurrence of a certain event
-
-                Notify Agent Request (notify-agent.dtd)
-
-<!ELEMENT notify-agent EMPTY>
-
-                                           name of the agent
-<!ATTLIST notify-agent
-                                           name of the notification
-    agent-id  CDATA #REQUIRED
-                                           data of the notification
-    notify-id CDATA #REQUIRED              (depends on type)
-
-    data      CDATA #REQUIRED
-
->
-Request an agent for some service
-
-                   Agent Request (agent-request.dtd)
-
-<!ELEMENT agent-request EMPTY>
-                                           name of the agent
-<!ATTLIST agent-request
-                                           request string (depends on
-    id           CDATA #REQUIRED           type of agent)
-
-    request      CDATA #REQUIRED           request parameters (depends
-                                           on type of agent)
-    parameters   CDATA #REQUIRED
-                                           e.g. request    =
->                                          "get-n-closest-neighbors"
-
-                                                parameters = "raterid"
-
-                     Agent Reply (agent-reply.dtd)
-
-<!ELEMENT agent-reply EMPTY>
-                                           Agent request was
-<!ATTLIST agent-reply                      successful or not
-
-    ok   (yes | no) 'no'                   if ok is "yes" then data
-                                           contains the requested data
-    data CDATA #REQUIRED                   (depends on type of agent)
-
->
-
-
-
-
-11.1.3      Privacy and security policy for agents
-
-When dealing with an architecture where agents can run on the Select
-server or client machines and can communicate and request services of
-one another, it is necessary to have a system in place that limits the
-access to the agents in order to avoid abuse of machine resources
-(server or client) or the exposure of personal profile or other
-database information to unauthorized persons.
-
-First of all, remote agents can only be registered and controlled by
-users that are registered with the Select Server. The user first logs
-in and receives a session-id. This ID is associated with every agent
-the user registers with the AgentList. It's used for authentication in
-a number of cases:
-
--  A remote agent only accepts requests if the requesting agent
-   knows this agent's session id.
-
--  When a remote agent requests a remote AgentList, it must include
-   the session-id(s) of the agents it wants access to. This way, the
-   server only returns information about agents for which the remote
-   agent has proven it's authority of access.
-
-Local agents can be "private" or "public". Private local agents do not
-accept requests from remote agents, only from other local agents.
-Public local agents can accept requests from remote agents. Both local
-agent types can themselves request information from remote agents.
-
--  A public local agent only accepts request when the session-id
-   associated with the request is present in the server. This means
-   that the session that created the agent has not ended yet.
-
-
-12.   Protocol Implemtation Status
-
-Here we provide an overview of the implementation status of the SELECT
-protocol as done by the SELECT EU project.
-
-Get-Service-Description-List
-
-Compelety implemented
-
-Get-Service-Description
-
-Completely implemented
-
-Send-Rating
-
-Completely implemented exept for the
-
-rater-competence
-rater-trust
-message-id
-
-fields of the rating. These are not used anywhere.
-
-Set-Profile
-
-Implemented except for
-
--  The pseudonymous related thing. Pseudonyms are never used in the
-   present system.
-
--  Multiple profiles per user. Every user has 1 profile for all the
-   services, it contains its unique data (name, password,...,languages
-   spoken, reward account) and some data for the SELECT test service
-   filtering algorithms (keywords,...)
-
--  The reward account that is never used.
-
--  A profile must always be replaced as a whole. Single fields
-   cannot be changed separately.
-
-Get-Profile
-
-Completely implemented.
-
-Login & Logout
-
-Completely implemented?
-
-Get Atomic Ratings
-
-Implemented except the only the first combination of rater/URL/category
-is used in the lookup.
-
-All other requested combinations are ignored.
-
-Simple-Search Operation
-
-Completely implemented but the search query is a regular expression.
-This gets matched against the keywords stored with the rated URI's and
-the ones with the best instant ratings are returned.
-
-Evaluator
-
-Implemented except the
-
-personal
-context
-sort
-collection-name
-
-fields that are ignored and used nowhere
-
-
-13.   Security considerations
-
-Not yet ready.
-
-
-14.   Copyright
-
-Copyright (C) The Internet Society 2000. 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.
-
-
-15.   Acknowledgments
-
-Michel Claude, Christopher Lueg, David Mason, Andras Micsik, Massimo
-Vanocchi and Richard Wheeler have participated in the production of
-this document. An earlier attempt to encode PICS in XML format was made
-by O. Lassila as described in [PICS3].
-
-
-16.   References
-
-
-Ref.         Author, title
----------    --------------------------------------------------------
-
-
-[PICS1]      Rating Services and Rating Systems (and Their Machine
-             Readable Descriptions) http://www.w3.org/PICS/services.html
-
-[PICS2]      PICS Distribution Label Syntax and Communication Protocols
-             http://www.w3.org/PICS/labels.html.
-
-[COOKIES]    RFC 2109 HTTP State Management Mechanism. D. Kristol, L.
-             Montulli. February 1997.
-             ftp://sunic.sunet.se/rfc/rfc2109.txt
-[HTTP]       RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1. R.
-             Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee.
-             January 1997. ftp://sunic.sunet.se/rfc/rfc2068.txt
-
-[IMAP]       IMAP4 Authentication Mechanisms. J. Myers. December 1994,
-             RFC 1731.
-
-[IMAP]       RFC 2045-2049 Multipurpose Internet Mail Extensions (MIME).
-             N. Freed & N. Borenstein, November 1996.
-             ftp://sunic.sunet.se/rfc/rfc2045.txt, rfc2046.txt, rfc2047,
-             rfc2048, rfc2049
-
-[URI]        RFC 1738 Uniform Resource Locators (URI).T. Berners-Lee et
-             al, December 1994. ftp://sunic.sunet.se/rfc/rfc1738.txt
-
-[XML1]       Extensible Markup Language (XML) 1.0. W3C REC-xml-19980210,
-             T. Bray, J. Paoli, C.M. Sperberg-McQueen.
-             http://www.w4.org/TR/1998/REC-xml-19980210
-
-[XML2]       A Technical Introduction to XML, N. Walsh, Oct 1998,
-             http://www.xml.com/xml/pub/98/10/guide0.html
-
-[PICS3]      PICS-NG Metadata Model and Label Syntax, O. Lassila,
-             http://www.w3.org/TR/NOTE-pics-ng.metadata
-
-[SELFUNC]    SELECT, Telematics Application Programme, RE4008,
-             Deliverable 2.1 Draft, Functional Specifications Report, by
-             Roland Alton-Scheidl and Richard Wheeler.
-
-[SELARCH]    SELECT System Architecture, by Richard Wheeler
-
-
-17.   Author's Addresses
-
-Jacob Palme                           Phone: +46-8-16 16 67
-Stockholm University and KTH          Fax: +46-8-783 08 29
-Electrum 230                          Email: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
-Johan Kaers                           Phone: +32-2-7400794
-S T A R L A B Research Laboratories   Fax: +32 2 7429654
-Sint-Michielslaan 47                  Email: johan@starlab.net
-B-1040 Etterbeek (Brussels), Belgium
diff --git a/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt b/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt
deleted file mode 100644
index 8131443a..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt
+++ /dev/null
@@ -1,901 +0,0 @@
-
-
-Network Working Group                                           E. Burger 
-Internet Draft                                         SnowShore Networks 
-Document: draft-ietf-vpim-cc-04.txt                                       
-Category: Standards Track                                                 
-Expires September 2001                                     March 30, 2001 
- 
- 
-                   Critical Content of Internet Mail 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC 2026 [1].  
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts.  Internet-Drafts are draft documents valid for a maximum of 
-   six months and may be updated, replaced, or obsoleted by other 
-   documents at any time.  It is inappropriate to use Internet-Drafts 
-   as reference material or to cite them other than as "work in 
-   progress." 
-    
-   One can access the list of current Internet-Drafts at 
-   http://www.ietf.org/ietf/1id-abstracts.txt 
-    
-   One can access the list of Internet-Draft Shadow Directories at 
-   http://www.ietf.org/shadow.html. 
-    
-   This document is a work product of the IETF Voice Profile for 
-   Internet Mail (VPIM) Work Group. 
-    
-    
-1. Abstract 
-    
-   This document describes a mechanism for identifying body parts that 
-   a sender deems critical in a multi-part Internet mail message [10].  
-   The mechanism described is a parameter to Content-Disposition. 
-    
-   By knowing what parts of a message the sender deems critical, a 
-   content gateway can intelligently handle multi-part messages when 
-   gatewaying to systems of lesser capability. Critical content can 
-   help a content gateway to decide what parts to forward.  It can 
-   indicate how hard a gateway should try to deliver a body part.  It 
-   can help the gateway to pick body parts that are safe to silently 
-   delete when a system of lesser capability receives a message.  In 
-   addition, critical content can help the gateway chose the 
-   notification strategy for the receiving system. 
- 
-                           Expires 9/30/01                   [Page 1] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-Table of Contents 
-    
-1. Abstract...........................................................1 
-2. Conventions used in this document..................................2 
-3. Introduction.......................................................3 
-4. Criticality Parameter..............................................3 
-4.1. CRITICAL.........................................................3 
-4.2. IGNORE...........................................................4 
-4.3. Default Values...................................................4 
-4.4. Other Values.....................................................4 
-5. Collected Syntax...................................................5 
-6. Notification.......................................................5 
-6.1. DSN vs MDN Generation............................................5 
-6.2. Summary..........................................................6 
-7. Status Code........................................................6 
-8. Requirements for Critical Content..................................7 
-8.1. Needs............................................................7 
-8.2. Current Approaches...............................................8 
-8.3. Criticality Parameter............................................9 
-9. The Content Gateway................................................9 
-9.1. Integrated Content Gateway.......................................9 
-9.2. Disaggregated Delivery Network..................................10 
-10. Backward Compatibility Considerations............................10 
-11. MIME Interactions................................................10 
-11.1. multipart/alternative..........................................10 
-11.2. multipart/related..............................................11 
-11.3. message/rfc822.................................................11 
-12. Implementation Examples..........................................11 
-12.1. Content Gateways...............................................11 
-12.2. Disaggregated Content Gateway..................................12 
-13. Security Considerations..........................................13 
-14. IANA Considerations..............................................13 
-15. References.......................................................13 
-16. Acknowledgments..................................................15 
-17. Author's Address.................................................15 
-    
-    
-2. Conventions used in this document 
-    
-   This document refers generically to the sender of a message in the 
-   masculine (he/him/his) and the recipient of the message in the 
-   feminine (she/her/hers).  This convention is purely for convenience 
-   and makes no assumption about the gender of a message sender or 
-   recipient. 
-    
-  
-Burger                     Expires 9/30/01                   [Page 2] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC 2119 [2]. 
-    
-   NOTE: Notes, such at this one, provide additional nonessential 
-   information that the reader may skip without missing anything 
-   essential.  The primary purpose of these non-essential notes is to 
-   convey information about the rationale of this document, or to place 
-   this document in the proper historical or evolutionary context.  
-   Readers whose sole purpose is to construct a conformant 
-   implementation may skip such information.  However, it may be of use 
-   to those who wish to understand why we made certain design choices. 
-    
-    
-3. Introduction 
- 
-   The specification of Critical Content is small and compact.  For the 
-   benefit of developers, the specification comes first, the rationale 
-   after. 
-    
-   One concept that an implementer must understand is the content 
-   gateway.  Section 7 describes the content gateway.  In brief, a 
-   content gateway has knowledge of the receiving system's 
-   capabilities.  The content gateway passes messages the receiving 
-   system can render or store.  The content gateway can modify a 
-   message, for example by deleting unrenderable or storable body 
-   parts, for delivery to the receiving system.  Finally, the content 
-   gateway can reject a message that the receiving system cannot 
-   handle. 
-    
-4. Criticality Parameter 
-    
-   The Criticality parameter is a Content-Disposition [3] parameter 
-   inserted by the sending UA to indicate to the content gateway 
-   whether to consider the marked body part critical. 
-    
-   A CRITICAL body part is one the sender requires the receiving system 
-   to deliver for him to consider the message delivered. 
-    
-   An IGNORE body part is one the sender doesn't care whether the 
-   receiving system delivers it or not.  A content gateway can silently 
-   delete such body parts if the receiving system cannot deliver the 
-   part. 
-    
-   The terms "entity" and "body part" have the meanings defined in 
-   [10]. 
-    
-4.1. CRITICAL 
-    
-   "Criticality=CRITICAL" signifies that this body part is critical to 
-   the sender. 
-    
-  
-Burger                     Expires 9/30/01                   [Page 3] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-   If the content gateway cannot pass a body part marked CRITICAL, then 
-   the entire message has failed.  In this case, the content gateway 
-   MUST take the appropriate failure action. 
-    
-   NOTE: We say "appropriate action", because the sender may have 
-   suppressed all notifications.  In this case, the appropriate action 
-   is to silently discard the message. 
-    
-4.2. IGNORE 
-    
-   "Criticality=IGNORE" signifies that the sender does not care about 
-   notification reports for this body part. 
-    
-   If the content gateway cannot pass a body part marked IGNORE, the 
-   receiving system may silently delete the body part.  The receiving 
-   system MUST NOT return a delivery failure, unless parts marked 
-   IMPORTANT or CRITICAL have also failed. 
-    
-4.3. Default Values 
-    
-   The default value for Criticality for a given body part is CRITICAL.  
-   This enables the existing notification mechanisms to work for user 
-   agents that do not know about the content notification entity.  All 
-   body parts are critical, because they have the default marking of 
-   CRITICAL. 
-    
-   NOTE: Remember that critical content processing is a function of the 
-   content gateway, and not the MTA or UA.  Often, the entity 
-   performing content gateway processing is the receiving UA.  However, 
-   it is acting as a content gateway.  Thus the default action for any 
-   Content-Disposition [3]-compliant user agent to ignore unrecognized 
-   disposition parameters ensures that this mechanism is compatible 
-   with the Internet architecture. 
-    
-   NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from 
-   the Internet.  However, these systems are really acting in the 
-   capacity of an Internet Voice Mail system.  In this case, one would 
-   expect the implementation to provide Internet Voice Mail semantics 
-   to Internet Voice Mail messages. 
-    
-    
-    
-4.4. Other Values 
-    
-   The content gateway MUST treat unrecognized values as CRITICAL.  
-   This is to provide backward compatibility with future uses of the 
-   Content-Criticality entity. 
-    
-   NOTE: A possible new value is IMPORTANT.  An IMPORTANT body part is 
-   something the sender wants the receiver to get, but would not want 
-   the message rejected outright if the IMPORTANT body part fails, but 
-   they do want notification of the failure.  However, as no 
-  
-Burger                     Expires 9/30/01                   [Page 4] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-   implementations do IMPORTANT, it is not important to this version of 
-   this document. 
-    
-    
-5. Collected Syntax 
-    
-   The format of the collected syntax is in accordance with the ABNF of 
-   [5].  Note that per RFC 2183 [3], the CRITICALITY Content-
-   Disposition parameter is not case sensitive.  In addition, the 
-   notification-type is not case sensitive. 
-    
-        "criticality" "=" notification-type CRLF 
-    
-        notification-type = "CRITICAL" / "IGNORE" 
-    
-    
- 
-6. Notification 
-    
-   One obvious application of critical content is generating a 
-   (non-)delivery notification.  If the value of the field is IGNORE, 
-   the content gateway MUST NOT generate a notification.  If the value 
-   of the field is CRTITICAL, the content gateway MAY generate a 
-   notification, based on the normal notification request mechanisms.  
-   Normal notification request mechanisms include the SMTP RCPT NOTIFY 
-   command [6] and the Disposition-Notification-To header [8]. 
-    
-   If the sending system requests a notification, and a CRITICAL part 
-   fails, the content gateway will generate a notification for the 
-   whole message.  Conversely, if the gateway cannot pass on a body 
-   part marked IGNORE, the gateway will not generate a notification.  
-    
-   NOTE: This implies that the content gateway must examine the entire 
-   message to determine whether it needs to generate a notification.  
-   However, the content gateway need not examine the message if it 
-   knows it can store and forward all media types.  Said differently, 
-   Internet e-mail MTAs or gateways can, by default, handle any 
-   arbitrary MIME-encapsulated type.  Some voice mail systems, on the 
-   other hand, cannot store binary attachments at all, such as 
-   application/ms-word.  The voice mail content gateway, in this 
-   example, would be scanning for non-renderable body parts in any 
-   event.  
-     
-6.1. DSN vs MDN Generation 
-    
-   The content gateway generates a delivery status notification (DSN) 
-   [7] if it operates as a gateway.  The content gateway generates a 
-   Message Disposition Notification (MDN) [8] if it operates as a user 
-   agent.  Section 7 describes the operating modes of a content 
-   gateway.  In short, if there is a MTA that "delivers" the message to 
-   the content gateway for processing, the MTA takes responsibility for 
-   DSN processing.  In this case, the only option available to the 
-  
-Burger                     Expires 9/30/01                   [Page 5] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-   content gateway is to generate MDNs.  If the content gateway 
-   operates as a MTA, then it generates DSNs.  DSN generation is the 
-   preferred option. 
-    
-    
-6.2. Summary 
-    
-   The following table summarizes the actions expected of a conforming 
-   content gateway. 
-    
-   NOTE: This section is normative: it suggests what to put into the 
-   DSN or MDN.  
-                            +--------------------------------------+ 
-                            |    Sending UA Has Marked Body Part   | 
-                            |---------------------+----------------| 
-                            |      CRITICAL       |     IGNORE     | 
-       +--------------------+---------------------+----------------+ 
-       | Body Part is       |                     |                | 
-       | Deliverable        | Appropriate Action  |     ignore     | 
-       +--------------------+---------------------+----------------+ 
-       | Body Part is       |                     |                | 
-       | Undeliverable      | Fail Entire Message |     ignore     | 
-       +--------------------+--------------------------------------+ 
-    
-    
-   The "Appropriate Action" is the action the content gateway would 
-   take given the context of execution.  For example, if a sender 
-   requests return receipt and the receiver reads a CRITICAL body part, 
-   the receiving UA must generate the appropriate MDN (following the 
-   rules for MDN).  Likewise, if the content gateway cannot deliver the 
-   body part and the body part is critical, the content gateway 
-   generates the appropriate DSN or MDN.  
-    
-   "Ignore" means the content gateway ignores the disposition of the 
-   body part.  The content gateway treats the message as if the body 
-   part was not present in the message. 
-    
-    
-7. Status Code 
-    
-   The critical content indication, in itself, does not guarantee any 
-   notification.  Notification follows the rules described in [7] and 
-   [8]. 
-    
-   NOTE: The content of actual DSNs or MDNs are beyond the scope of 
-   this document.  This document only specifies how to mark a critical 
-   body part.  On the other hand, we do envision sensible DSN and MDN 
-   contents.  For example, DSNs should include the appropriate failure 
-   code as enumerated in [9].  Likewise, MDNs should include the 
-   failure code in the MDN "Failure:" field. 
-    
-  
-Burger                     Expires 9/30/01                   [Page 6] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-   If the receiving system is to generate a notification based on its 
-   inability to render or store the media type, the notification should 
-   use the status code 5.6.1, "Media not supported", from [9]. 
-    
-    
-8. Requirements for Critical Content 
-    
-8.1. Needs 
-    
-   The need for a critical content identification mechanism comes about 
-   because of the internetworking of Internet mail systems with 
-   messaging systems that do not fulfill all of the semantics of 
-   Internet mail.  Such legacy systems have a limited ability to render 
-   or store all parts of a given message.  This document will use the 
-   case of an Internet mail system exchanging electronic messages with 
-   a legacy voice messaging system for illustrative purposes. 
-    
-   Electronic mail has historically been text-centric.  Extensions such 
-   as MIME [10] enable the user agents to send and receive multi-part, 
-   multimedia messages.  Popular multimedia data types include binary 
-   word processing documents, binary business presentation graphics, 
-   voice, and video. 
-    
-   Voice mail has historically been audio-centric.  Many voice-
-   messaging systems only render voice.  Extensions such as fax enable 
-   the voice mail system to send and receive fax images as well as 
-   create multi-part voice and fax messages.  A few voice mail systems 
-   can render text using text-to-speech or text-to-fax technology.  
-   Although theoretically possible, none can today render video. 
-    
-   An important aspect of the interchange between voice messaging 
-   services and desktop e-mail client applications is that the 
-   rendering capability of the voice-messaging platform is often much 
-   less than the rendering capability of a desktop e-mail client.  In 
-   the e-mail case, the sender has the expectation that the recipient 
-   receives all components of a multimedia message.  This is so even if 
-   the recipient cannot render all body parts.  In most cases, the 
-   recipient can either find the appropriate rendering tool or tell the 
-   sender that she cannot read the particular attachment. 
-    
-   This is an important issue.  By definition, a MIME-enabled user 
-   agent, conforming to [11], will present or make available all of the 
-   body parts to the recipient.  However, a voice mail system may not 
-   be capable of storing non-voice objects.  Moreover, the voice mail 
-   system may not be capable of notifying the recipient that there were 
-   undeliverable message parts. 
-    
-   The inability of the receiving system to render a body part is 
-   usually a permanent failure.  Retransmission of the message will not 
-   improve the likelihood of a future successful delivery.  Contrast 
-   this with the case with normal data delivery.  Traditional message 
-  
-Burger                     Expires 9/30/01                   [Page 7] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-   failures, such as a garbled message or disabled link will benefit 
-   from retransmission. 
-    
-   This situation is fundamentally different from normal Internet mail.  
-   In the Internet mail case, either the system delivered the message, 
-   or it didn't.  There is no concept of a system partially delivering 
-   a message. 
- 
-   In addition, there are many situations where the sender would not 
-   mind if the system did not deliver non-critical parts of a message.  
-   For example, the sender's user agent may add body parts to a message 
-   unbeknownst to the sender.  If the receiving system rejected the 
-   message because it could not render a hidden body part, the sender 
-   would be understandably confused and upset. 
-    
-   Thus, there is a need for a method of indicating to a Mail Transfer 
-   Agent (MTA) or User Agent (UA) that the sender considers parts of a 
-   message to be critical.  From the sender's perspective, he would not 
-   consider the message delivered if the system did not deliver the 
-   critical parts. 
-    
-8.2. Current Approaches 
-    
-   One method of indicating critical content of a message is to define 
-   a profile.  The profile defines rules for silently deleting mail 
-   body parts based on knowledge of the UA capabilities.  Citing the 
-   example above, a voice profile can easily declare that MTAs or UAs 
-   can silently delete TNEF data and yet consider the message 
-   successfully delivered.  This is, in fact, the approach taken by 
-   VPIMv2 [12]. 
-    
-   Since one aspect of the issue is deciding when to notify the sender 
-   that the system cannot deliver part of a message, one could use a 
-   partial non-delivery notification mechanism to indicate a problem 
-   with delivering a given body part.  However, this requires the user 
-   request a delivery notification.  In addition, the sender may not be 
-   aware of parts added by the sending user agent.  In this case, a 
-   failure notice would mystify the sender. 
-    
-   A straightforward alternative implementation method for marking a 
-   body part critical is to use a Critical-Content MIME entity.  This 
-   has the benefit that criticality is meta information for the body 
-   part.  However, IMAP servers in particular would need to either put 
-   Critical-Content into the BODYSTRUCTURE method or create a new 
-   method to retrieve arbitrary MIME entities.  Given the experience of 
-   trying to get Content-Location accepted by IMAP vendors, we chose 
-   not to go that route. 
-    
-   What we need is a way of letting the sender indicate what body-parts 
-   he considers to be critical.  The mechanism must not burden the 
-   sender with failure notifications for non-critical body parts.  The 
-   mechanism must conform to the general notification status request 
-  
-Burger                     Expires 9/30/01                   [Page 8] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-   mechanism for positive or negative notification.  When requested, 
-   the mechanism must indicate to the sender when a receiving system 
-   cannot deliver a critical body part. 
-    
-    
-8.3. Criticality Parameter 
-    
-   The criticality marking mechanism satisfies these needs.  This 
-   document introduces the CRITICALITY parameter to Content-
-   Disposition.  Values for this parameter are CRITICAL or IGNORE. 
-    
-    
-9. The Content Gateway 
-    
-   In this section, we use the definition of [13] for the term 
-   "gateway." 
-    
-   A content gateway is a gateway that connects a first network to a 
-   second network.  The second network often has lesser capability than 
-   the first network.  The canonical topology follows.  The "[MTA]" 
-   signifies an optional component. 
-    
-                             +---------+ 
-   +---------+     +-----+   |         |     +-------+   +-----------+ 
-   | Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving | 
-   |   UA    |     +-----+   | Gateway |     +-------+   |    UA     | 
-   +---------+               |         |                 +-----------+ 
-                             +---------+ 
-          First Network                         Second Network 
-    
-    
-   The content gateway can be the last hop before the receiving MTA.  
-   The content gateway can be between networks, and thus not the last 
-   hop before the receiving MTA.  The content gateway can be the first 
-   MTA the sending UA contacts.  Finally, the content gateway can be an 
-   integrated component of the receiving MTA. 
-    
-    
-9.1. Integrated Content Gateway 
-    
-   In this situation, the receiving user agent is integrated with the 
-   content gateway. The integrated content gateway knows the 
-   capabilities of the user agent.  The topology is as follows. 
-    
-                             +---------------------+ 
-   +---------+     +-----+   |         :           | 
-   | Sending |=...=|[MTA]|===| Content : Receiving | 
-   |   UA    |     +-----+   | Gateway :    UA     | 
-   +---------+               |         :           | 
-                             +---------------------+ 
-          First Network           Second Network 
-    
-  
-Burger                     Expires 9/30/01                   [Page 9] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-    
-9.2. Disaggregated Delivery Network 
-    
-   A degenerate case, although one that does occur, is where the 
-   content gateway sits behind the final MTA.  This happens when one 
-   implements the content gateway as a post-processing step to a normal 
-   delivery.  For example, one could configure a mail handling system 
-   to deliver the message to a queue or directory, where the content 
-   gateway process picks up the message.  If there were any directives 
-   for DSN processing, the delivering MTA would execute them.  For 
-   example, the message could have requested notification on successful 
-   delivery.  The delivering MTA, having delivered the message to the 
-   queue, would consider the message delivered and thus notify the 
-   sender of such.  However, the content gateway process could then 
-   discover that the receiving UA cannot render the message.  In this 
-   case, the content gateway generates a NDN, as it is the only option 
-   available. 
-    
-                           Delivered 
-                               |      +---------+ 
-   +---------+     +-----+     v      |         |     +-----------+ 
-   | Sending |=...=| MTA |--> File -->| Content |=...=| Receiving | 
-   |   UA    |     +-----+            | Gateway |     |    UA     | 
-   +---------+                        |         |     +-----------+ 
-                                      +---------+ 
-          First Network              Second Network 
-    
-    
-    
-10. Backward Compatibility Considerations 
-    
-   DSN requires ESMTP.  If MTAs in the path from the sending UA to the 
-   receiving UA do not support ESMTP, then that MTA will reject the DSN 
-   request.  In addition, the message will default to notification on 
-   delay or failure.  While not ideal, the sender will know that DSN is 
-   not available, and that critical content that fails will get 
-   notification. 
-    
- 
-11. MIME Interactions 
-    
-11.1. multipart/alternative 
-    
-   As is true for all Content-Disposition parameters, criticality is 
-   only in effect for the selected alternative.  If the selected 
-   alternative has the critical content indicator, then the entire 
-   alternative takes on the criticality indicated.  That is, if the 
-   alternative selected has CRITICALITY=IGNORE, then the content 
-   gateway MUST NOT generate any delivery notifications. 
-    
-   NOTE: This statement explicitly shows that CRITICALITY overrides the 
-   DSN and MDN request mechanisms. 
-  
-Burger                     Expires 9/30/01                  [Page 10] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-    
-   It is unlikely for a selected alternative to fail, as the content 
-   gateway presumably picks the alternative specifically because it can 
-   render it.  
-    
-   If the selected alternative is a message/rfc822 that encloses a 
-   multipart MIME message or the selected alternative is itself a 
-   multipart MIME type, the individual top-level body parts follow the 
-   CRITICALITY mechanism described in this document. 
-    
-11.2. multipart/related 
-    
-   Criticality fits in rather well with the multipart/related 
-   construction.  For example, consider a multipart/related message 
-   consisting of a Macintosh data fork and a Macintosh resource fork.  
-   For a Microsoft Word document, the data fork is likely to be 
-   critical.  The receiving system can safely ignore the resource fork. 
-    
-11.3. message/rfc822 
-    
-   Criticality only affects the outermost level of the message or, in 
-   the case of multipart/alternative, the outermost level of the 
-   selected alternative.  Specifically, the receiving system ignores 
-   criticality indicators in embedded body parts.  This avoids the 
-   situation of a forwarded message triggering or suppressing undesired 
-   reporting.  This simply implements the procedures described in [3]. 
-    
-    
-12. Implementation Examples 
-    
-   This section is not a normative part of the definition of 
-   Criticality.  However, we hope it helps implementers to understand 
-   the mechanics of the Criticality mechanism. 
-    
-   We will examine two cases.  They are how a content gateway processes 
-   a message and how a disaggregated content gateway processes a 
-   message. 
-    
-12.1. Content Gateways 
-    
-   Content gateways examine the contents of a message from a first 
-   network before the gateway forwards the message to a second network.  
-   For the purposes of this example, we assume the second network has 
-   less capability than the first network.  In particular, we expect 
-   there will be certain message body types that the gateway cannot 
-   pass onto the second network. 
-    
-   Consider a gateway between the Internet and a text-only short 
-   message service.  A message comes through the gateway containing a 
-   text part and a tnef part.  The sender marks the text part CRITICAL.  
-   The gateway, knowing the capability of the short message service, 
-   silently deletes the non-critical, tnef part, passing the critical 
-  
-Burger                     Expires 9/30/01                  [Page 11] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-   content to the short message service network.  Any subsequent 
-   notifications, such as failure notices or delivery notices, follow 
-   the normal rules for notification. 
-    
-   Note the gateway, by silently deleting non-critical content, may 
-   affect proprietary message correlation schemes.  One can envision 
-   the sending UA inserting a body part for tracking purposes.  By 
-   deleting non-critical content, the content gateway will break such a 
-   scheme.  If a sending UA understands how to mark critical content, 
-   it should use Internet standard mechanisms for tracking messages, 
-   such as Message-ID [14]. 
-    
-   What if no body parts have critical content indicators?  In this 
-   case, the entire message is critical.  Thus, when the gateway sees 
-   the tnef part, it will reject the entire message, generating a DSN 
-   with a status code 5.6.1, "Media not supported". 
-    
-   Likewise, consider a three part message with a text annotation (part 
-   1) to a voice message (part 2) with a vCard [15] (part 3).  The 
-   sender marks the first two parts CRITICAL.  Now, let us assume the 
-   receiving MTA (gateway) is a voice mail only system, without even 
-   the capability to store text.  In this case, the gateway, acting as 
-   the receiving MTA, will reject the message, generating a DSN with 
-   the status code 5.6.1, "Media not supported". 
- 
-12.2. Disaggregated Content Gateway 
-    
-   For this example, we will examine the processing of a three-part 
-   message.  The first part is a text annotation of the second part, an 
-   audio message.  The third part is the sender's vCard.  The sender 
-   marks the first and second parts CRITICAL.  In addition, the sender 
-   marks the message for read receipt. 
-    
-   For the purposes of example, the telephone user interface (TUI) does 
-   not perform text-to-speech conversion.  A TUI is a mail user agent 
-   (UA) that uses DTMF touch-tone digits for input and audio for output 
-   (display). 
-    
-   The TUI is unable to render the first part of the message, the text 
-   part.  In addition, it is unable to render the third part of the 
-   message, the vCard part.  Since the sender did not mark the third 
-   part of the message CRITICAL, the system ignores the failure of the 
-   TUI to render the third part of the message.  However, since the 
-   sender did mark the first part CRITICAL, and the TUI is unable to 
-   render text, the message fails. 
-    
-   What happens next is implementation dependent.  If the TUI is part 
-   of a unified messaging system, a reasonable action is to hold the 
-   message for the user.  The user can access the message at a later 
-   time from a terminal that can render all of the critical body parts.  
-   It would be reasonable for the TUI to notify the user about the 
-   undeliverable body part. 
-  
-Burger                     Expires 9/30/01                  [Page 12] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-    
-   If the TUI is part of a voice messaging system, or if the user does 
-   not subscribe to a text-to-speech service, a reasonable action is 
-   for the TUI to return a MDN with the disposition "failed" and the 
-   failure modifier "5.6.1 (Media not supported)". 
-    
-    
-13. Security Considerations 
- 
-   Receiving systems and users should not place any authentication 
-   value on the Content-Criticality entity.  Just because a message has 
-   a particular Content-Criticality value doesn't mean that the message 
-   really originated at a given type of system. 
-    
-    
-14. IANA Considerations 
-    
-   Per section 9 of [3], here is the IANA registration for Criticality. 
-    
-   To: IANA@IANA.ORG 
-   Subject: Registration of new Content-Disposition parameter 
-    
-   Content-Disposition parameter name: 
-   CRITICALITY 
-    
-   Allowable values for this parameter: 
-   IGNORE 
-   CRITICAL 
-    
-   Description: 
-   Marks the body part as required for delivery (CRITICAL) or can be 
-   silently discarded (IGNORE).  See RFC <this document>. 
-   Per RFC 2183, the Content-Disposition parameter name is not case 
-   sensitive.  Per RFC <this document>, the values of the parameter are 
-   also not case sensitive. 
-    
-    
-    
-15. References 
-    
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997. 
-    
-   3  Troost, R., Dorner, S., Moore, K. (ed), "Communicating 
-      Presentation Information in Internet Messages: The Content-
-      Disposition Header Field", RFC 2183, New Century Systems, 
-      QUALCOMM, and U. Tennessee, August 1997. 
- 
-  
-Burger                     Expires 9/30/01                  [Page 13] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
- 
-    
-   4  Moore, K., "SMTP Service Extension for Delivery Status 
-      Notifications", RFC 1981, University of Tennessee, January 1996. 
-    
-   5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
-      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
-      Demon Internet Ltd., November 1997. 
-    
-   6  Moore, K., "SMTP Service Extension for Delivery Status 
-      Notifications", RFC 1981, University of Tennessee, January 1996. 
-    
-   7  Moore, K. and Vaudreuil, G., "An Extensible Message Format for 
-      Delivery Status Notifications", RFC 1894, University of Tennessee 
-      and Octel Network Services, January 1996. 
-     
-   8  Fajman, R., "An Extensible Message Format for Message Disposition 
-      Notifications", RFC 2298, National Institutes of Health, March 
-      1998. 
-    
-   9  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 
-      Octel Network Services, January 1996. 
-    
-   10  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
-      Extensions (MIME) Part One: Format of Internet Message Bodies", 
-      RFC 2045, Innosoft and First Virtual, November 1996. 
-    
-   11  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
-      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 
-      First Virtual, November 1996. 
-    
-   12  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail 
-      - version 2", RFC 2421, Lucent Technologies and Nortel Networks, 
-      September 1998. 
-    
-   13 Kille, S. "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 
-      between X.400 and RFC 822/MIME", RFC 2156, Isode, January 1998. 
-    
-   14 Crocker, D., "Standard for the Format of ARPA Internet Text 
-      Messages", RFC 822, University of Delaware, August 1982. 
-    
-   15 Dawson, F. and Howes, T., "vCard MIME Directory Profile", RFC 
-      2426, Lotus Development Corporation and Netscape Communications, 
-      September 1998. 
-    
-   16 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
-      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
-      Demon Internet Ltd., November 1997. 
-    
-    
-    
-    
-  
-Burger                     Expires 9/30/01                  [Page 14] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-16. Acknowledgments 
-    
-   Emily Candell of Comverse Network Systems was instrumental in 
-   helping work out the base issues in the “00 draft in Adelaide. 
-    
-   Ned Freed pointed out that this mechanism was about criticality, not 
-   notification.  That insight made the concept and descriptions 
-   infinitely more straightforward.  If it's still confusing, it's my 
-   fault! 
-    
-   Keith Moore for helped tighten-up the explanations, and he approved 
-   of the use of Content-Disposition. 
-    
-   Dropping the IMPORTANT critical content type took away one of the 
-   reasons for partial non-delivery notification.  That makes Jutta 
-   Degener very happy! 
-    
-   Harald Alvestrand and Chris Newman suggested some implementation 
-   examples. 
-    
-   Greg White asked THE key question that let us realize that critical 
-   content processing was a gateway function, and not a MTA or UA 
-   function. 
-    
-   Any errors, omissions, or silliness are my fault. 
-    
-    
-17. Author's Address 
-    
-   Eric Burger 
-   SnowShore Networks, Inc. 
-   285 Billerica Rd. 
-   Chelmsford, MA  01824-4120 
-   USA 
-    
-   Phone: +1 978 367 8403 
-   Fax:   +1 603 457 5944 
-   Email: e.burger@ieee.org 
-    
-    
-    
-    
-  
-Burger                     Expires 9/30/01                  [Page 15] 
- 
-                  Critical Content of Internet Mail        March 2001 
- 
- 
-Full Copyright Statement 
- 
-   The IETF takes no position regarding the validity or scope of any 
-   intellectual property 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; neither does it represent that it 
-   has made any effort to identify any such rights.  Information on the 
-   IETF's procedures with respect to rights in standards-track and 
-   standards-related documentation can be found in BCP-11.  Copies of 
-   claims of rights made available for publication 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 Secretariat. 
-    
-   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 practice 
-   this standard.  Please address the information to the IETF Executive 
-   Director. 
-    
-   Copyright (C) 2000, 2001 The Internet Society.  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. 
-  
-Burger                     Expires 9/30/01                  [Page 16] 
- 
-
diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt
deleted file mode 100644
index 707e4333..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt
+++ /dev/null
@@ -1,999 +0,0 @@
-
-
-Network Working Group                                           E. Burger 
-Internet Draft                                         SnowShore Networks 
-Document: draft-ietf-vpim-hint-07.txt                          E. Candell 
-Category: Standards Track                                        Comverse 
-Expires December 2001                                            C. Eliot 
-                                                    Microsoft Corporation 
-                                                                 G. Klyne 
-                                                   Baltimore Technologies 
-                                                             June 5, 2001 
- 
- 
-                   Message Context for Internet Mail 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1].  
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-    
-   Internet-Drafts are draft documents valid for a maximum of six 
-   months and may be updated, replaced, or obsoleted by other documents 
-   at any time. It is inappropriate to use Internet-Drafts as reference 
-   material or to cite them other than as "work in progress." 
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt . 
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html . 
-    
-   This document is a work product of the IETF Voice Profile for 
-   Internet Mail (VPIM) Work Group. 
-    
-    
-    
-1. Abstract 
-    
-   This memo describes a new RFC2822 message header, "Message-Context".  
-   This header provides information about the context and presentation 
-   characteristics of a message. 
-    
-   A receiving user agent (UA) may use this information as a hint to 
-   optimally present the message. 
-    
-
-
-
-
-
- 
-                           Expires 12/05/01                   [Page 1] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-Table of Contents 
-    
-1. Abstract...........................................................1 
-2. Introduction.......................................................3 
-3. Conventions used in this document..................................3 
-4. Motivation.........................................................4 
-5. Functional Requirements............................................5 
-6. Determining the Message Context....................................6 
-7. Message-Context Reference Field....................................7 
-7.1. Message-Context Syntax...........................................7 
-7.2. message-context-class Syntax.....................................7 
-7.2.1. voice-message..................................................8 
-7.2.2. fax-message....................................................8 
-7.2.3. pager-message..................................................8 
-7.2.4. multimedia-message.............................................8 
-7.2.5. text-message...................................................8 
-7.2.6. none...........................................................9 
-8. Security Considerations............................................9 
-9. IANA Considerations................................................9 
-9.1. Message Content Type Registrations..............................10 
-9.2. Registration Template...........................................10 
-9.3. Message-Context Registration....................................11 
-10. APPENDIX: Some messaging scenarios...............................11 
-10.1. Internet e-mail................................................11 
-10.2. Pager service..................................................12 
-10.3. Facsimile......................................................13 
-10.4. Voice mail.....................................................13 
-10.5. Multimedia message.............................................13 
-11. References.......................................................14 
-12. Acknowledgments..................................................15 
-13. Author's Addresses...............................................15 
-14. Full Copyright Statement.........................................17 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Burger et. al.             Expires 12/05/01                   [Page 2] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-2. Introduction 
-    
-   This document describes a mechanism to allow senders of an Internet 
-   mail message to convey the message's contextual information.  Taking 
-   account of this information, the receiving user agent (UA) can make 
-   decisions that improve message presentation for the user in the 
-   context the sender and receiver expects. 
-    
-   In this document, the "message context" conveys information about 
-   the way the user expects to interact with the message.  For example, 
-   a message may be e-mail, voice mail, fax mail, etc.  A smart UA may 
-   have specialized behavior based on the context of the message. 
-    
-   This document specifies a RFC2822 header called "Message-Context".  
-   The mechanism is in some ways similar to the use of the Content-
-   Disposition MIME entity described in [2].  Content-Disposition gives 
-   clues to the receiving User Agent (UA) for how to display a given 
-   body part.  Message-Context can give clues to the receiving UA for 
-   the presentation of the message.  This allows the receiving UA to 
-   present the message in a meaningful and helpful way to the 
-   recipient. 
-    
-   Typical uses for this mechanism include: 
-   o    Selecting a special viewer for a given message. 
-   o    Selecting an icon indicating the kind of message in a displayed 
-        list of messages. 
-   o    Arranging messages in an inbox display. 
-   o    Filtering messages the UA presents when the user has limited 
-        access. 
- 
- 
-3. Conventions used in this document 
-    
-   This document refers generically to the sender of a message in the 
-   masculine (he/him/his) and the recipient of the message in the 
-   feminine (she/her/hers).  This convention is purely for convenience 
-   and makes no assumption about the gender of a message sender or 
-   recipient. 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [3]. 
-    
-   FORMATTING NOTE: Notes, such at this one, provide additional 
-   nonessential information that the reader may skip without missing 
-   anything essential.  The primary purpose of these non-essential 
-   notes is to convey information about the rationale of this document, 
-   or to place this document in the proper historical or evolutionary 
-   context.  Readers whose sole purpose is to construct a conformant 
-   implementation may skip such information.  However, it may be of use 
-   to those who wish to understand why we made certain design choices. 
-    
-  
-Burger et. al.             Expires 12/05/01                   [Page 3] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-    
-4. Motivation 
-    
-   Multimedia messaging systems receive messages that a UA may present 
-   in variety of ways.  For example, traditional e-mail uses simple 
-   text messages that the recipient displays and edits.  One UA may 
-   automatically print Fax images.  Another UA may play voice messages 
-   through a telephone handset.  Likewise, a receiving desktop computer 
-   may process or present documents transferred over e-mail using a 
-   local application.  Emerging and future developments may deliver 
-   other forms of information that have their own characteristics for 
-   user presentation, such as video messages and pager messages. 
-    
-   An often-requested characteristic for multimedia messaging systems 
-   is to collect received messages in a "universal inbox", and to offer 
-   them to the user as a combined list. 
-    
-   In the context of "unified messaging", different message contexts 
-   may have different implied semantics.  For example, some users may 
-   perceive voicemail to have an implicit assumption of urgency.  Thus 
-   they may wish to gather them together and process them before other 
-   messages.  This results in the end-user receiving agent needing to 
-   be able to identify voicemail and distinguish it from other 
-   messages. 
-    
-   The uses of this kind of presentation characteristic for each 
-   message is multi-fold: 
-    
-   o    Display an indication to the user (e.g., by a suitably 
-        evocative icon along with other summary fields), 
-    
-   o    Auto-forward a given message type into another messaging 
-        environment (e.g., a page to a mobile short message service), 
-    
-   o    Prioritize and group messages in an inbox display list, 
-    
-   o    Suggest appropriate default handling for presentation, 
-    
-   o    Suggest appropriate default handling for reply, forward, etc., 
-        and 
-    
-   A problem faced by multimedia messaging systems is that it is not 
-   always easy to decide the context of a received message.  For 
-   example, consider the following scenarios. 
-    
-   o    A message that contains audio and image data:  Is this a fax 
-        message that happens to have some voice commentary?  Is it a 
-        voice message that is accompanied by some supplementary 
-        diagrams?  Is it a fully multimedia message, in which all parts 
-        are expected to carry equal significance? 
-    
-
-  
-Burger et. al.             Expires 12/05/01                   [Page 4] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-   o    A message containing text and audio data:  Is this e-mail with 
-        an MP3 music attachment?  Is it a voice message that happens to 
-        have been generated with an initial text header for the benefit 
-        of non-voice-enabled e-mail receivers? 
-    
-   The message context does relate to the message media content.  
-   However, it is not the same thing.  As shown above, the media type 
-   used in a message is not sufficient to indicate the message context.  
-   One cannot determine a priori which media types to use in 
-   alternative (gateway) message.  Also, what if the user cares about 
-   distinguishing traditional e-mail text from SMS messages?  They are 
-   both the same media type, text, but they have different user 
-   contexts. 
-    
-    
-5. Functional Requirements 
-    
-   The goals stated above lead to the following functional 
-   requirements. 
-    
-   For receivers: 
-   o    Identify a message as belonging to a message class. 
-    
-   o    Incorrect or invalid message classification must not result in 
-        failure to transfer or inability to present a message. 
-    
-    
-   For senders: 
-   o    Specify message classes by the originating user's choice of 
-        authoring tool or simple user interaction. 
-    
-    
-   For both: 
-   o    Specify a well-defined set of message classes to make 
-        interoperability between mail user agents (UAs) possible. 
-    
-   o    Message classification information has to be interpretable in 
-        reasonable fashion by many different user agent systems. 
-    
-   o    The mechanism should be extensible to allow for the 
-        introduction of new kinds of messages. 
-    
-   NOTE: We specifically do not specify user agent behavior when the 
-   user agent forwards a message.  Clearly, the user agent, being 
-   message-context-aware, should provide a meaningful message-context.  
-   It is obvious what to do for the easy cases.  Messages that the user 
-   simply forwards will most likely keep the context unchanged.  
-   However, it is beyond the scope of this document to specify the user 
-   agent behavior for any other scenario. 
-    
-
-
-  
-Burger et. al.             Expires 12/05/01                   [Page 5] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-6. Determining the Message Context 
-    
-   One method of indicating the interpretation context of a message is 
-   to examine the media types in the message.  However, this requires 
-   the UA to scan the entire message before it can make this 
-   determination.  This approach is particularly burdensome for the 
-   multi-media mail situation, as voice and especially video mail 
-   objects are quite large. 
-    
-   We considered indicating the message context by registering a 
-   multipart/* MIME subtype (Content-Type).  For example, the VPIM Work 
-   Group has registered multipart/voice-message to indicate that a 
-   message is primarily voice mail [4].  However, multipart/voice-
-   message is identical in syntax to multipart/mixed.  The only 
-   difference is that VPIM mail transfer agents and user agents 
-   recognize that they can perform special handling of the message 
-   based on it being a voice mail message.  Moreover, Content-Type 
-   refers to a given MIME body part, not to the message as a whole. 
-    
-   We wish to avoid scanning the entire message.  In addition, we wish 
-   to avoid having to create multiple aliases for multipart/mixed every 
-   time someone identifies a new primary content type.  Multiple 
-   aliases for multipart/mixed are not desirable as they remove the 
-   possibility for specifying a message as multipart/alternate, 
-   multipart/parallel, or multipart/encrypted, for example. 
-    
-   Since the message context is an attribute of the entire message, it 
-   is logical to define a new top-level (RFC2822 [5]) message 
-   attribute.  To this end, this document introduces the message 
-   attribute "Message-Context". 
-    
-   Message-Context only serves to identify the message context.  It 
-   does not provide any indication of content that the UA must be 
-   capable of delivering.  It does not imply any message disposition or 
-   delivery notification.  There is a related effort to define Critical 
-   Content of Internet Mail [6] that one might use to perform these 
-   tasks. 
-    
-   Message-Context is only an indicator.  We do not intend for it to 
-   convey information that is critical for presentation of the message.  
-   One can conceive of goofy situations, such as a message marked 
-   "voice-message" but without an audio body part.  In this case, the 
-   fact that the contents of a message donËt match its context does not 
-   mean the receiving system should generate an error report or fail to 
-   deliver or process the message.  
-    
-    
-
-
-
-
-
-  
-Burger et. al.             Expires 12/05/01                   [Page 6] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-7. Message-Context Reference Field 
-    
-   The Message-Context reference field is a top-level header inserted 
-   by the sending UA to indicate the context of the message. 
-    
-   A receiving user agent MUST NOT depend on the indicated message-
-   context value in a way that prevents proper presentation of the 
-   message.  If the value is incorrect or does not match the message 
-   content, the receiving user agent MUST still be capable of 
-   displaying the message content at least as meaningfully as it would 
-   if no Message-Context value were present. 
-    
-   One can envision situations where a well-formed message ends up not 
-   including a media type one would expect from the message-context. 
-   For example, consider a voice messaging system that records a voice 
-   message and also performs speech-to-text processing on the message.  
-   The message then passes through a content gateway, such as a 
-   firewall, that removes non-critical body parts over a certain 
-   length.  The receiving user agent will receive a message in the 
-   voice-message context that has only a text part and no audio.  Even 
-   though the message does not have audio, it is still in the voice 
-   message context. 
-    
-   Said differently, the receiving UA can use the message-context to 
-   determine whether, when, and possibly where to display a message.  
-   However, the message-context should not affect the actual rendering 
-   or presentation.  For example, if the message is in the voice-
-   message context, then don't try to send it to a fax terminal.  
-   Conversely, consider the case of a message in the voice-message 
-   context that gets delivered to a multimedia voice terminal with a 
-   printer.  However, this message only has fax content.  In this 
-   situation, the "voice-message" context should not stop the terminal 
-   from being properly rendering the message. 
-    
- 
-7.1. Message-Context Syntax 
-    
-   The syntax of the Message-Context field, described using the ABNF 
-   [7] is as follows.  Note that the Message-Context header field name 
-   and message-context-class values are not case sensitive. 
-    
-        "Message-Context" ":" message-context-class CRLF 
-    
-7.2. message-context-class Syntax 
-    
-   The message-context-class indicates the context of the message.  
-   This is an IANA registered value.  Current values for message-
-   context-class are as follows. 
-    
-
-
-
-  
-Burger et. al.             Expires 12/05/01                   [Page 7] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-        message-context-class =  (   "voice-message" 
-                                   | "fax-message" 
-                                   | "pager-message" 
-                                   | "multimedia-message" 
-                                   | "text-message" 
-                                   | "none" 
-                                   | extension-type ) 
-    
-        extension-type = token  ; Defined and registered per Section 8 
-                       / vnd.token ; Experimental, private use 
-    
-        token = <syntax as defined by [8],  
-                 but not starting with the characters "vnd."> 
-    
-        vnd.token = <Vendor-specific, private token> 
-    
-   Note: The values for Message-Context must be either IANA registered 
-   values or experimental, vendor tokens.  This ensures that user 
-   agents from different vendors will interoperate and perform in a 
-   uniform manner without an undue burden on the vendors. 
-    
-7.2.1. voice-message 
-    
-   The voice-message class states the message is a voice mail message. 
-    
-7.2.2. fax-message 
-    
-   The fax-message class states the message is a facsimile mail 
-   message. 
-    
-7.2.3. pager-message 
-    
-   The pager-message class states the message is a page, such as a text 
-   or numeric pager message or a traditional short text message service 
-   (SMS) message. 
-    
-7.2.4. multimedia-message 
-    
-   The multimedia-message class states the message is an aggregate 
-   multimedia message, such as a message specified by [9].  This helps 
-   identify a message in a multimedia context.  For example, a MIME 
-   multipart/related [10] data part and resource part looks the same as 
-   a multimedia MHTML multipart/related.  However, the semantics are 
-   quite different. 
-    
-7.2.5. text-message 
-    
-   The text-message class states the message is a traditional internet 
-   mail message.  Such a message consists of text, possibly richly 
-   formatted, with or without attachments. 
-    
-
-  
-Burger et. al.             Expires 12/05/01                   [Page 8] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-7.2.6. none 
-    
-   The none class states there is no context information for this 
-   message. 
-    
-   If a message has no Message-Context reference field, a receiving 
-   user agent MUST treat it the same as it would if the message has a 
-   "none" value. 
-    
-    
-8. Security Considerations 
-   The intention for this header is to be an indicator only of message 
-   context.  One can imagine someone creating an "Application" Message-
-   Context.  A poorly designed user agent could blindly execute a 
-   mailed program based on the Message-Context.  Don't do that! 
-    
-   One can envision a denial of service attack by bombing a receiver 
-   with a message that has a Message-Context that doesn't fit the 
-   profile of the actual body parts.  This is why the receiver 
-   considers the Message-Context to be a hint only. 
-    
-    
-9. IANA Considerations 
-    
-   Section 9.3 is a registration for a new top-level RFC2822 [5] 
-   message header, "Message-Context".   
-    
-   This document creates an extensible set of context types.  To 
-   promote interoperability and coherent interpretations of different 
-   types, we need a central repository for well-known context types. 
-    
-   IANA will create a repository for context types called "Internet 
-   Message Context Types".  Following the policies outlined in [11], 
-   this repository is "Specification Required" by RFC.  Section 9.1 
-   describes the initial values for this registry. 
-    
-   To create a new message context type, you MUST publish an RFC to 
-   document the type.  In the RFC, include a copy of the registration 
-   template found in Section 9.2 of this document.  Put the template in 
-   your IANA Considerations section, filling-in the appropriate fields.  
-   You MUST describe any interoperability and security issues in your 
-   draft. 
-    
-    
-    
-
-
-
-
-
-
-
-  
-Burger et. al.             Expires 12/05/01                   [Page 9] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-9.1. Message Content Type Registrations 
-    
-   Internet Message Content Types 
-   ============================== 
- 
-   Value              Description                           Reference 
-   -----              -----------                           --------- 
-   voice-message      Indicates a message whose primary     This RFC 
-                      content is a voice mail message.  The 
-                      primary content is audio data.  The 
-                      context is usually a message recorded 
-                      from a voice telephone call. 
-                                                             
-   fax-message        Indicates a message whose primary     This RFC 
-                      content is a fax mail message.  The 
-                      primary content is image data.  The 
-                      context is usually a message recorded 
-                      from a facsimile telephone call. 
-                                                             
-   pager-message      Indicates a message whose primary     This RFC 
-                      content is a page.  The primary 
-                      content is text data.  The context is 
-                      an urgent message usually of a 
-                      limited length. 
-                                                             
-   multimedia-message Indicates a message whose primary     This RFC 
-                      content is a multimedia message.  The 
-                      primary content is multimedia, most 
-                      likely MHTML.  The context is often 
-                      spam or newsletters. 
-                                                             
-   text-message       Indicates a classic, text-based,      This RFC 
-                      Internet message. 
-                                                             
-   None               Indicates an unknown message context. This RFC 
-    
-    
-9.2. Registration Template 
-    
-   In the following template, a pipe symbol, "|", precedes instructions 
-   or other helpful material.  Be sure to replace "<classname>" with 
-   the class name you are defining. 
-    
-    
-   Message-Context class name: 
-   <classname> 
-    
-   Summary of the message class: 
-       | Include a short (no longer than 4 lines) description or summary 
-       | Examples: 
-       |   "Palmtop devices have a 320x160 pixel display, so we can..." 
-       |   "Color fax is so different than black & white that..." 
-  
-Burger et. al.             Expires 12/05/01                  [Page 10] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
- 
-   Person & email address to contact for further information: 
-       | Name & e-mail 
-    
-    
-9.3. Message-Context Registration 
-    
-   To: iana@iana.org 
-   Subject: Registration of New RFC 2822 Header 
-    
-   RFC 2822 Header Name: 
-   Message-Context 
-    
-   Allowable values for this parameter: 
-   Please create a new registry for Primary Context Class 
-   registrations.  See section 9.1 of this document for the initial 
-   values. 
-    
-   RFC 2822 Section 3.6 Repeat Value: 
-   Field             Min Number   Max Number   Notes 
-   Message-Context       0            1         
-    
-   Person & email address to contact for further information: 
-   Eric Burger 
-   e.burger@ieee.org                                           
-    
-    
-10. APPENDIX: Some messaging scenarios 
-    
-   This section is not a normative part of this document.  We include 
-   it here as a historical perspective on the issue of multimedia 
-   message types. 
-    
-   These scenarios are neither comprehensive nor fixed.  For example, 
-   e-mails being typically text-based do not mean that they cannot 
-   convey a voice-message.  This very mutability serves to underline 
-   the desirability of providing some explicit message context hint. 
-    
-10.1. Internet e-mail 
-    
-   Internet e-mail carries textual information.  Sometimes it conveys 
-   computer application data of arbitrary size. 
-    
-   Typically, one uses e-mail for non-urgent messages, which the 
-   recipient will retrieve and process at a time convenient to her. 
-    
-   The normal device for receiving and processing e-mail messages is 
-   some kind of personal computer.  Modern personal computers usually 
-   come with a reasonably large display and an alphanumeric keyboard.  
-   Audio, video, and printing capabilities are not necessarily 
-   available. 
-    
-  
-Burger et. al.             Expires 12/05/01                  [Page 11] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-   One can use E-mail for communication between two parties (one-to-
-   one), a small number of known parties (one-to-few) or, via an e-mail 
-   distribution list, between larger numbers of unknown parties (one-
-   to-many). 
-    
-   One of the endearing characteristics of e-mail is the way that it 
-   allows the recipient to forward all or part of the message a to 
-   another party, with or without additional comments.  It is quite 
-   common for an e-mail to contain snippets of content from several 
-   previous messages. Similar features apply when replying to e-mail. 
-    
-10.2. Pager service 
-    
-   One uses a pager message to convey notifications and alerts.  For 
-   the most part, these notifications are textual information of 
-   limited size.  The typical limit is 160 characters.  People use 
-   pages for relatively urgent messages, which the sender wishes the 
-   receiver to see and possibly respond to within a short time period.  
-   Pager messages are often used as a way of alerting users to 
-   something needing their attention.  For example, a system can use a 
-   page to notify a subscriber there is a voicemail message requiring 
-   her attention.   
-    
-   Example devices for sending and receiving a pager message are a 
-   mobile telephone with a small character display or a text pager.  
-   Personal computers and personal digital assistants (PDAs) can also 
-   participate in pager messaging. 
-    
-   Currently, the most common use of pager messages are between just 
-   two parties (one-to-one). 
-    
-   One delivery method for pager messages is the short text messaging 
-   service (SMS).  SMS is a facility that has evolved for use with 
-   mobile telephones, and has an associated per-message transmission 
-   charge.  Note that the focus here is on the notification aspect of 
-   SMS.  From the beginning, SMS was envisioned to be more than a 
-   simple pager service.  Operators can use SMS to provision the phone, 
-   for example.  From the subscriber point of view, SMS has evolved 
-   considerably from its origins as a pure pager replacement service.  
-   For example, with mobile originate service, people can have two-way 
-   text chat sessions using SMS and a mobile phone.  In addition, there 
-   are SMS-enabled handsets that can display pictures.  However, for 
-   the purposes of this document, there is still a need to capture the 
-   essence of a "highly urgent, short-text, notification or alert" 
-   service. 
-    
-   Users often send pager messages in isolation, rather than as part of 
-   a longer exchange.  One use for them is as a prompt or invitation to 
-   communicate by some more convenient and content-rich method, such as 
-   a telephone call. 
-    
-
-  
-Burger et. al.             Expires 12/05/01                  [Page 12] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-10.3. Facsimile 
-    
-   People use facsimile to convey image information of moderate size, 
-   typically a small number of pages.  Sometimes people use facsimile 
-   for larger documents. 
-    
-   Facsimile is a facility that usually uses circuit-switched telephone 
-   circuits, with connection-time charges.  Message transfer takes 
-   place in real-time.  Thus, people often use facsimile for urgent 
-   communication. 
-    
-   The normal device for sending and receiving a facsimile is a self-
-   contained scanning and printing device connected to a telephone line 
-   or a desktop computer. 
-    
-   Most facsimiles are between just two parties (one-to-one).  However, 
-   a significant portion of facsimile service is broadcast between 
-   multiple parties (one-to-many). 
-    
-   Most facsimile exchanges are in isolation, rather than as part of a 
-   longer exchange.  Facsimile data is typically not suitable for 
-   further processing by computer. 
-    
-10.4. Voice mail 
-    
-   People use voice mail to convey audio information, almost 
-   exclusively human speech. 
-    
-   Voice mail is a facility that usually uses circuit-switched 
-   telephone circuits, with modest connection-time charges, often used 
-   for moderately urgent messages.  A common use for them is as a 
-   prompt or invitation to communicate by some more convenient method, 
-   such as a telephone call. In most, but not all cases, the sender of 
-   a voice message does not want to send a message at all.  Rather, 
-   they wished to engage in a real-time conversation. 
-    
-   The normal device for sending and receiving a voice mail is a 
-   telephone handset. 
-    
-   Voice messages are usually sent between just two parties (one-to-
-   one). 
-    
-   Voice mail data is not generally suitable for further processing by 
-   computer. 
-    
-10.5. Multimedia message 
-    
-   We define a multimedia message as a message containing more than one 
-   basic media type (text, image, audio, video, model, application). 
-    
-   The following are some characteristics of a multimedia message. 
-    
-  
-Burger et. al.             Expires 12/05/01                  [Page 13] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-   In some cases, a multimedia message is just e-mail with an 
-   attachment that a multimedia display application presents.  For 
-   example, I can send you an MP3 of something I recorded in my garage 
-   today. 
-    
-   In other cases, a multimedia message represents a convergence 
-   between two or more of the scenarios described above.  For example, 
-   a voice message with an accompanying diagram or a talking head video 
-   message is a multimedia message. 
-    
-   The characteristics will vary somewhat with the intent of the 
-   sender.  This in turn may affect the user agent or application used 
-   to render the message. 
-    
-    
-    
-11. References 
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Troost, R., Dorner, S., and Moore, K., "Communicating 
-      Presentation Information in Internet Messages: The Content-
-      Disposition Header Field", RFC 2183, New Century Systems, 
-      QUALCOMM Incorporated, and University of Tennessee, August 1997. 
-    
-   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997. 
-    
-   4  Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type 
-      Registration", RFC 2423, Lucent Technologies and Northern 
-      Telecom, September 1998. 
-    
-   5  Resnick, P., "Internet Message Format", RFC 2822, Qualcomm, April 
-      2001. 
-    
-   6  Burger, E., "Critical Content of Internet Mail", draft-ietf-vpim-
-      cc-04.txt, Work in Progress. 
-    
-   7  Crocker, D. and Overell, P. (Editors), "Augmented BNF for Syntax 
-      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
-      Demon Internet Ltd., November 1997. 
-    
-   8  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
-      Extensions (MIME) Part One: Format of Internet Message Bodies", 
-      RFC 2045, Innosoft and First Virtual, November 1996. 
-    
-   9  Palme, J., Hopmann, A., Shelness, N., "MIME Encapsulation of 
-      Aggregate Documents, such as HTML (MHTML)", RFC 2557, Stockholm 
-      University/KTH, Microsoft, and Lotus Development Corporation, 
-      March 1999. 
- 
-  
-Burger et. al.             Expires 12/05/01                  [Page 14] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
- 
-    
-   10 Levinson, E., "The MIME Multipart/Related Content-type", RFC 
-      2387, August 1998. 
-    
-   11 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 
-      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 
-    
-    
-    
-12. Acknowledgments 
-    
-   Many of the ideas here arose originally from a discussion with Jutta 
-   Degener. 
-    
-   We'd also like to thank Keith Moore for helping us tighten-up our 
-   explanations. 
-    
-   In the last round, we got some rather good advise from Caleb Clausen 
-   and Dave Aronson.  
-    
-   Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae 
-   helped distil the essence of the pager service vis a vis SMS. 
-    
-   We offer an extra special thanks to Greg Vaudreuil for pulling RFC 
-   2557 out of his hat. 
-    
-    
-    
-13. Author's Addresses 
-    
-   Eric Burger 
-   SnowShore Networks, Inc. 
-   285 Billerica Rd. 
-   Chelmsford, MA  01824-4120 
-   USA 
-    
-   Phone: +1 978 367 8403 
-   Fax:   +1 603 457 5944 
-   Email: e.burger@ieee.org 
-    
-    
-   Emily Candell 
-   Comverse Network Systems 
-   200 Quannapowitt Pkwy. 
-   Wakefield, MA  01880 
-   USA 
-    
-   Phone: +1 781 213 2324 
-   Email: emily.candell@comverse.com 
-    
-    
-  
-Burger et. al.             Expires 12/05/01                  [Page 15] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-   Graham Klyne 
-   Baltimore Technologies Ltd. 
-   1310 Waterside 
-   Arlington Business Park 
-   Theale 
-   Reading, RG7 4SA 
-   United Kingdom 
-    
-   Telephone: +44 118 930 8000 
-   Facsimile: +44 118 930 9000 
-   E-mail:    GK@ACM.ORG 
-    
-    
-   Charles Eliot 
-   Microsoft Corporation 
-   One Microsoft Way  
-   Redmond WA 98052  
-   USA 
-    
-   Telephone: +1 425 936 9760 
-   E-Mail:    charle@Microsoft.com 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Burger et. al.             Expires 12/05/01                  [Page 16] 
- 
-
-                  Message Context for Internet Mail         June 2001 
- 
- 
-14. Full Copyright Statement 
- 
-   The IETF takes no position regarding the validity or scope of any 
-   intellectual property 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; neither does it represent that it 
-   has made any effort to identify any such rights.  Information on the 
-   IETF's procedures with respect to rights in standards-track and 
-   standards-related documentation can be found in BCP-11.  Copies of 
-   claims of rights made available for publication 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 Secretariat. 
-    
-   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 practice 
-   this standard.  Please address the information to the IETF Executive 
-   Director. 
-    
-   Copyright (C) 2001 The Internet Society.  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. 
- 
-
-
-
-
-  
-Burger et. al.             Expires 12/05/01                  [Page 17] 
- 
-
diff --git a/Documentation/en/I-D/draft-ietf-vpim-pndn-01.txt b/Documentation/en/I-D/draft-ietf-vpim-pndn-01.txt
deleted file mode 100644
index bdcd591f..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-pndn-01.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-E. Burger: e.burger@ieee.org                                                       

-

-

diff --git a/Documentation/en/I-D/draft-jones-msgtrk-def-02.txt b/Documentation/en/I-D/draft-jones-msgtrk-def-02.txt
deleted file mode 100644
index d09a2ded..00000000
--- a/Documentation/en/I-D/draft-jones-msgtrk-def-02.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-This Internet-Draft has expired and is no longer available.
-
-Unrevised documents placed in the Internet-Drafts directories have a
-maximum life of six months. After that time, they must be updated, or
-they will be deleted. This document was deleted on March 20, 2000.
diff --git a/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt b/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt
deleted file mode 100644
index 0c1a4091..00000000
--- a/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-
-This Internet-Draft has been deleted. Unrevised documents placed in the
-Internet-Drafts directories have a maximum life of six months. After
-that time, they are deleted. This Internet-Draft was not published as
-an RFC.
-
-Internet-Drafts are not an archival document series, and expired
-drafts, such as this one, are not available; please do not ask for
-copies... they are not available. The Secretariat does not have
-information as to future plans of the authors or working groups WRT the
-deleted Internet-Draft.
-
-For more information or a copy of the document, contact the author directly.
-
-Draft Author(s):
-
-K. Khanna: gauravkhanna@mailandnews.com                                            
-
-
diff --git a/Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt b/Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt
deleted file mode 100644
index 4217b315..00000000
--- a/Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-Network Working Group                                           G. Klyne
-Internet-Draft                                         MIMEsweeper Group
-Expires: July 5, 2002                                        Jan 4, 2002
-
-
-              Registration procedures for message headers
-                     draft-klyne-msghdr-registry-01
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 5, 2002.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This specification defines registration procedures for the message
-   headers used by Internet mail, newsgroup feeds, HTTP and other
-   Internet applications.
-
-Discussion of this document
-
-   Please send comments to <ietf-822@imc.org>.  To subscribe to this
-   list, send a message with the body 'subscribe' to <ietf-822-
-   request@imc.org>.
-
-
-
-
-
-
-Klyne                     Expires July 5, 2002                  [Page 1]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   1.1   Structure of this document . . . . . . . . . . . . . . . . .  3
-   1.2   Document terminology and conventions . . . . . . . . . . . .  4
-   2.    Message headers  . . . . . . . . . . . . . . . . . . . . . .  4
-   2.1   Standard and non-standard headers  . . . . . . . . . . . . .  4
-   2.2   Definitions of message headers . . . . . . . . . . . . . . .  5
-   2.2.1 Application-specific message headers . . . . . . . . . . . .  5
-   3.    Registration procedure . . . . . . . . . . . . . . . . . . .  5
-   3.1   Header specification . . . . . . . . . . . . . . . . . . . .  6
-   3.2   Registration templates . . . . . . . . . . . . . . . . . . .  6
-   3.2.1 Normative header template  . . . . . . . . . . . . . . . . .  6
-   3.2.2 Provisional header template  . . . . . . . . . . . . . . . .  7
-   3.3   Submission of registration . . . . . . . . . . . . . . . . .  8
-   3.4   Change control . . . . . . . . . . . . . . . . . . . . . . .  8
-   3.5   Comments on header definitions . . . . . . . . . . . . . . .  8
-   3.6   Location of message header registry  . . . . . . . . . . . .  9
-   4.    Initial registrations  . . . . . . . . . . . . . . . . . . .  9
-   5.    IANA considerations  . . . . . . . . . . . . . . . . . . . .  9
-   6.    Security considerations  . . . . . . . . . . . . . . . . . .  9
-   7.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
-         References . . . . . . . . . . . . . . . . . . . . . . . . .  9
-         Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
-   A.    Revision history . . . . . . . . . . . . . . . . . . . . . . 12
-   A.1   draft-klyne-msghdr-registry-01 . . . . . . . . . . . . . . . 12
-   A.2   draft-klyne-msghdr-registry-00 . . . . . . . . . . . . . . . 12
-   B.    Todo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-         Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klyne                     Expires July 5, 2002                  [Page 2]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-1. Introduction
-
-   This specification defines registration procedures for the message
-   headers used by Internet mail, newsgroup feeds, HTTP and other
-   Internet applications.
-
-   Benefits of a central registry for message headers include:
-
-   o  to provide a single point of reference for standardized headers;
-
-   o  to provide a central point of discovery for established headers,
-      and easy location of their defining documents;
-
-   o  to discourage multiple definitions of a header name for different
-      purposes;
-
-   o  to help those proposing new headers discern established trends and
-      conventions, and avoid names that might be confused with existing
-      ones;
-
-   o  to encourage convergence of header name usage across multiple
-      applications/protocols.
-
-   The primary specification for Internet message headers is the
-   Internet mail message format specification, RFC 2822 [22], but there
-   are many other Internet standards track documents that define
-   additional headers within the same namespace, notably MIME [7] and
-   related specifications.  Other Internet applications that use MIME,
-   such as newsgroup feeds (RFC 1036 [1]) and HTTP web access (RFC 2616
-   [19]), also use many of the same headers.
-
-   Although in principle each application defines its own set of valid
-   headers, exchange of messages between applications (e.g.  mail to
-   news gateways), common use of MIME encapsulation, and the possibility
-   of common processing for various message types (e.g.  a common
-   message archive and retrieval facility) makes it desirable to have a
-   single point of reference for standardized headers.  The message
-   header registry defined here serves that purpose.
-
-1.1 Structure of this document
-
-   Section Section 2 discusses the purpose of this specification, and
-   indicates some sources of information about defined message headers.
-
-   Section Section 3 defines the message header registry, and sets out
-   requirements and procedures for creating entries in it.
-
-
-
-
-
-Klyne                     Expires July 5, 2002                  [Page 3]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-1.2 Document terminology and conventions
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [10].
-
-      NOTE: indented comments like this provide additional nonessential
-      information about the rationale behind this document.
-
-   [[[Editorial comments and questions about outstanding issues are
-   provided in triple brackets like this.  These working comments should
-   be resolved and removed prior to final publication.]]]
-
-2. Message headers
-
-2.1 Standard and non-standard headers
-
-   Many message headers are defined in standards-track documents, which
-   means they have been subjected to a process of community review and
-   achieved consensus that they provide a useful and well-founded
-   capability.  Many other headers have been defined and adopted for
-   private use; some of these have found widespread use.
-
-   The registry defined here is intended to cater for all of these
-   headers, while maintaining a clear distinction and status for those
-   which have community consensus.  To this end, the registry is defined
-   in two parts (or maybe as two separate registries):
-
-   o  Normative Message Headers, intended for headers defined in IETF
-      standards-track documents, or those that have achieved a
-      comparable level of community review.  The assignment policy for
-      such registration is "IETF Consensus", as defined by RFC 2434
-      [18].
-
-   o  Provisional Message Headers, intended for any header proposed by
-      any developer, without making any claim about the usefulness
-      quality of its definition.  The assignment policy for registration
-      of these is "Private Use", per RFC 2434 [18].
-
-   Note that there exist at least two other sources information about
-   message headers:
-
-   o  RFC 2076 [8], as updated [25], contains a list of commonly used
-      message headers, and
-
-   o  Dan Bernstein maintains a list of standard and non-standard mail
-      message headers [26].
-
-
-
-
-Klyne                     Expires July 5, 2002                  [Page 4]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-2.2 Definitions of message headers
-
-   RFC 2822 [22] defines a general syntax for Internet message headers.
-   It also defines a number of headers for use with Internet mail.
-   Additional header names are defined in a variety of standards-track
-   RFC documents, including: RFC 1036 [1], RFC 1496 [2], RFC 1505 [3],
-   RFC 1766 [5], RFC 1864 [6], RFC 2156 [12], RFC 2183 [13], RFC 2045
-   [7], RFC 2110 [9], RFC 2298 [14], RFC 2369 [15], RFC 2421 [17], RFC
-   2616 [19], RFC 2821 [21], RFC 2912 [23] and RFC 2919 [24].
-
-2.2.1 Application-specific message headers
-
-   Internet applications that use message headers include Internet mail
-   [21][22], NNTP newsgroup feeds [1], HTTP web access [19] and any
-   other that uses MIME [7] encapsulation of message content.
-
-   In some cases (notably HTTP [19]), the header syntax and usage is
-   redefined for the specific application.  This registration is
-   concerned only with the allocation and specification of header names,
-   and not with the details of header implementation in specific
-   protocols.
-
-   In some cases, the same header name may be specified differently (by
-   different documents) for use with different application protocols
-   [[[example?]]].  In other cases, a header name may have a common
-   specification across multiple protocols (ignoring protocol-specific
-   lexical and character set conventions);  e.g.  this is generally the
-   case for MIME headers with names of the form 'Content-*'.
-
-   Thus, we need to accommodate application-specific headers, while
-   recognizing the commonality of other headers across multiple
-   applications.  Common registries are used for all applications, and
-   each registered header specifies the application protocol(s) for
-   which the registered definition applies.  A given header name may
-   have multiple registry entries for different protocols; in the
-   Normative Message Headers registry, a given header name may be
-   registered only once for any given protocol.
-
-3. Registration procedure
-
-   The procedure for registering a message header is:
-
-   1.  Construct a header specification
-
-   2.  Prepare a registration template
-
-   3.  Submit the registration template
-
-
-
-
-Klyne                     Expires July 5, 2002                  [Page 5]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-3.1 Header specification
-
-   Registration of a new message header starts with construction of a
-   proposal that describes the syntax, semantics and intended use of the
-   header.  This proposal MUST be published as an RFC.
-
-   A registered header name MUST conform at least to the syntax defined
-   by RFC 2822, section 3.6.8, for "field name".
-
-   Further, the "." character is reserved to indicate a naming sub-
-   structure and MUST NOT be included in any registered header name.
-   Currently, no specific sub-structure is defined; if used, any such
-   structure MUST be defined by a standards track RFC document.
-
-   It is further RECOMMENDED that characters in a registered message
-   header name are restricted to those characters that can be used
-   without escaping in a URI [16] or URN [11], namely upper- or lower-
-   case ASCII letters, decimal digits, "(", ")", "+", ",", "-", "=",
-   "@", ";", "$", "_", "!", "*" and "'".  Of course, a header name must
-   also conform to any applicable rules of the protocol(s) with which it
-   may be used.  Many headers names may find some use in conjunction
-   with XML, in which case the name characters should be further
-   restricted to just letters, digits, hyphen ('-') and underscore ('_')
-   characters, with the first character being a letter or underscore.
-
-3.2 Registration templates
-
-   The registration template for a message header may be contained in
-   the defining document, or prepared separately.
-
-3.2.1 Normative header template
-
-   An header registered as a Normative Message Header MUST be defined
-   according to "IETF Consensus" rules (per RFC 2434 [18]), and MUST
-   have a name which is unique among all the Normative Message Headers
-   that may be used with the same application protocol(s).  The header
-   name MUST NOT start with "X-" or "x-".
-
-   The registration template contains the following information:
-
-   NORMATIVE HEADER REGISTRATION TEMPLATE:
-
-   Header name:
-      The name requested for the new header.  This MUST conform to the
-      header specification details above.
-
-   Applicable protocol(s):
-      Specify "mail", "news", "http", or cite any other standards-track
-
-
-
-Klyne                     Expires July 5, 2002                  [Page 6]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-      RFC defining the protocol with which the header is intended to be
-      used.
-      Alternatively, specify "any" to indicate that there is no
-      specified restriction on the protocol with which the registered
-      header may be used; in this case, the header name must be unique
-      within the Normative Message Header registry.
-
-   Specification document(s):
-      Reference to the RFC(s) that specify the header for use with the
-      indicated protocol(s).
-
-   Related information:
-      Optionally, citations to additional documents containing further
-      relevant information.
-
-
-3.2.2 Provisional header template
-
-   Registration as a Provisional Message Header does not imply any kind
-   of endorsement by the IETF, IANA or any other body.
-
-   The only requirement for a header to be registered as a Provisional
-   Message Header is that it MUST have a citable specification.
-
-   The registration template contains the following information:
-
-   PROVISIONAL HEADER REGISTRATION TEMPLATE:
-
-   Header name:
-      The name requested for the new header.  This SHOULD conform to the
-      header specification details above.
-
-   Applicable protocol(s):
-      Specify "mail", "news", "http", or cite any other standards-track
-      RFC defining the protocol with which the header is intended to be
-      used.
-      Alternatively, specify "any" to indicate that there is no
-      specified restriction on the protocol with which the registered
-      header may be used.
-
-   Specification document(s):
-      Reference to document(s) that specifies the header for use with
-      the indicated protocol(s).
-
-   Related information:
-      Optionally, citations to additional documents containing further
-      relevant information.
-
-
-
-
-Klyne                     Expires July 5, 2002                  [Page 7]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-
-      The name and email address of the author, and person who may
-      authorize changes to or retraction of the registration.
-
-
-3.3 Submission of registration
-
-   The registration is submitted for incorporation in the IANA message
-   header registry by one of the following means:
-
-   o  An IANA considerations section in a defining RFC, calling for
-      registration of the message header and referencing the
-      registration template within the same document.  Registration of
-      the header is processed as part of the RFC publication process.
-
-   o  Sending the registration template in an email to the designated
-      email address [27].  IANA will register the message header if the
-      requested name and the specification document meet the criteria
-      stated.
-
-
-3.4 Change control
-
-   Change control of a header registration is subject to the same
-   condition as the initial registration; i.e.  publication of an IESG-
-   approved RFC for a Normative Message Header, or on request of the
-   indicated author/cgange controller for a Provisional Message Header.
-
-   In addition, retraction of Provisional Message Header registration
-   may be requested by the IESG.
-
-   It is intended that entries in the Normative Header Registry may be
-   used in the construction of URNs (per RFC 2141 [11]) which have
-   particular requirements for uniqueness and persistence (per RFC 1737
-   [4]).  Therefore, once an entry is made in the Normative Message
-   Header registry, the combination of the header name and any
-   applicable protcol MUST NOT subsequently be registered for any other
-   purpose.  (This is not to preclude revision of the applicable
-   specification(s) within the appropriate IETF Consensus rules, and
-   corresponding updates to the specification citation in the header
-   registration.)
-
-3.5 Comments on header definitions
-
-   [[[Review this]]]
-
-   Comments on registered Normative Message Headers should be sent to
-   the IETF-822 email discussion list [27].
-
-
-
-Klyne                     Expires July 5, 2002                  [Page 8]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-   Comments on proposed message headers should preferably be sent to the
-   discusion forum for the specification concerned.  They may also be
-   sent to the IETF-822 list [27] if they concern wider implications
-   than are addressed by the specification document.
-
-3.6 Location of message header registry
-
-   The message header registry is accessible from IANA's web site [28].
-
-4. Initial registrations
-
-   [[[I am currently minded to prepare two companion documents that
-   template the normative and provisional headers from RFC 2076, rather
-   than try to have them all in this document.]]]
-
-   This specification calls for initial registration of all message
-   headers defined in existing standards-track documents.  A list of
-   such headers can be found in RFC 2076 [8] and updates [25].  Section
-   Section 2.2 of this document contains a list of standards-track
-   specifications that define message headers.
-
-   [[[Need to provide list of headers+documents here for initial
-   registration?]]]
-
-5. IANA considerations
-
-   This specification calls for:
-
-   o  A new two-part IANA registry for message headers per section
-      Section 3 of this document.  The policies for inclusion in the
-      registry are described in sections Section 3.1 and Section 3.2.
-
-   o  [[[Details TBD: Initial message header registrations, per section
-      Section 4 of this document.]]]
-
-
-6. Security considerations
-
-   No security considerations are introduced by this specification
-   beyond those already inherrent in the use of message headers.
-
-7. Acknowledgements
-
-   The author gratefully acknowledges the contributions of: Charles
-   Lindsey, [[[...]]]
-
-References
-
-
-
-
-Klyne                     Expires July 5, 2002                  [Page 9]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-   [1]   Horton, M. and R. Adams, "Standard for interchange of USENET
-         messages", RFC 1036, December 1987.
-
-   [2]   Alvestrand, H., Jordan, K. and J. Romaguera, "Rules for
-         downgrading messages from X.400/88 to X.400/84 when MIME
-         content-types are present in the messages", RFC 1496, August
-         1993.
-
-   [3]   Costanzo, A., Robinson, D. and R. Ullmann, "Encoding Header
-         Field for Internet Messages", RFC 1505, August 1993.
-
-   [4]   Masinter, L. and K. Sollins, "Functional Requirements for
-         Uniform Resource Names", RFC 1737, December 1994.
-
-   [5]   Alvestrand, H., "Tags for the Identification of Languages", RFC
-         1766, March 1995.
-
-   [6]   Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC
-         1864, October 1995.
-
-   [7]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-         Extensions (MIME) Part One: Format of Internet Message Bodies",
-         RFC 2045, November 1996.
-
-   [8]   Palme, J., "Common Internet Message Headers", RFC 2076,
-         February 1997.
-
-   [9]   Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
-         Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
-         1997.
-
-   [10]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [11]  Moats, R., "URN Syntax", RFC 2141, May 1997.
-
-   [12]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
-         between X.400 and RFC 822/MIME", RFC 2156, January 1998.
-
-   [13]  Moore, K., Troost, R. and S. Dorner, "Communicating
-         Presentation Information in Internet Messages: The Content-
-         Disposition Header Field", RFC 2183, August 1997.
-
-   [14]  Fajman, R., "An Extensible Message Format for Message
-         Disposition Notifications", RFC 2298, March 1998.
-
-   [15]  Baer, J. and G. Neufeld, "The Use of URLs as Meta-Syntax for
-         Core Mail List Commands and their Transport through Message
-
-
-
-Klyne                     Expires July 5, 2002                 [Page 10]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-         Header Fields", RFC 2369, July 1998.
-
-   [16]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
-         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
-         1998.
-
-   [17]  Parsons, G. and G. Vaudreuil, "Voice Profile for Internet Mail
-         - version 2", RFC 2421, September 1998.
-
-   [18]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434, October
-         1998.
-
-   [19]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
-         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
-         HTTP/1.1", RFC 2616, June 1999.
-
-   [20]  Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
-         August 1999.
-
-   [21]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
-         2001.
-
-   [22]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
-   [23]  Klyne, G., "Indicating Media Features for MIME Content", RFC
-         2912, September 2000.
-
-   [24]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field and
-         Namespace for the Identification of Mailing Lists", RFC 2919,
-         April 2001.
-
-   [25]  Palme, J., "Common Internet Message Header Fields", Internet
-         draft draft-palme-mailext-headers-05, May 2001,
-         <http://search.ietf.org/internet-drafts/draft-palme-mailext-
-         headers-05.txt>.
-
-   [26]  Bernstein, D., "Internet mail field name index",
-         <http://cr.yp.to/immhf/index.html>.
-
-   [27]  "Mail address for submission of header registration template",
-         <mailto:[[[ietf-message-headers]]]@iana.org>.
-
-   [28]  "IANA list of registered message headers",
-         <http://www.iana.org/[[[ToBeDefined]]]>.
-
-
-
-
-
-
-Klyne                     Expires July 5, 2002                 [Page 11]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-Author's Address
-
-   Graham Klyne
-   MIMEsweeper Group
-   1310 Waterside
-   Arlington Business Park
-   Theale, Reading  RG7 4SA
-   UK
-
-   Phone: +44 118 903 8000
-   Fax:   +44 118 903 9000
-   EMail: Graham.Klyne@MIMEsweeper.com
-
-Appendix A. Revision history
-
-   (This section to be removed on final publication)
-
-A.1 draft-klyne-msghdr-registry-01
-
-   01a 04-Jan-2002:
-
-      *  In response to feedback from interested parties, expanded the
-         registry to cover Normative and Provisional message header
-         registrations.
-
-      *  Defined a formal role for the applicable protocol(s) in the
-         registry:  the combination of header name and any applicable
-         protocol must be unique for a Normative Message Header.
-
-      *  Noted further constraints to the header name format for XML
-         name compatibility.
-
-      *  Fixed registration policy for a Normative Message Header to be
-         "IETF Consensus".
-
-
-A.2 draft-klyne-msghdr-registry-00
-
-   00a 27-Sep-2001:
-
-      *  Document initially created.
-
-
-Appendix B. Todo
-
-   (This section to be removed on final publication)
-
-   o  Finalize initial registrations.
-
-
-
-Klyne                     Expires July 5, 2002                 [Page 12]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-   o  Finalize email address for submission of registration templates.
-
-   o  Finalize web address for registry.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klyne                     Expires July 5, 2002                 [Page 13]
-
-Internet-Draft         Message header registration              Jan 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klyne                     Expires July 5, 2002                 [Page 14]
-
diff --git a/Documentation/en/I-D/draft-melnikov-esmtp-lang-00.txt b/Documentation/en/I-D/draft-melnikov-esmtp-lang-00.txt
deleted file mode 100644
index 607b2bb3..00000000
--- a/Documentation/en/I-D/draft-melnikov-esmtp-lang-00.txt
+++ /dev/null
@@ -1,275 +0,0 @@
-Network Working Group                     A. Melnikov, Messaging Direct

-Internet Draft

-Document: draft-melnikov-smtp-lang-00.txt                     June 1999

-

-

-                          SMTP Language Extension

-

-

-Status of this Memo

-

-   This document is an Internet-Draft and is in full conformance with

-   all provisions of Section 10 of RFC2026.  Internet-Drafts are

-   working documents of the Internet Engineering Task Force (IETF), its

-   areas, and its working groups.  Note that other groups may also

-   distribute working documents as Internet-Drafts.

-

-   Internet-Drafts are draft documents valid for a maximum of six

-   months and may be updated, replaced, or obsoleted by other documents

-   at any time.  It is inappropriate to use Internet- Drafts as

-   reference material or to cite them other than as "work in progress."

-

-   The list of current Internet-Drafts can be accessed at

-   http://www.ietf.org/ietf/1id-abstracts.txt

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html.

-

-

-   This document  suggests  a  proposed  protocol  for  the   Internet

-   community,    and   requests   discussion   and   suggestions   for

-   improvements. Distribution of this draft is unlimited.

-

-   The protocol discussed in this document is experimental and subject

-   to change.  Persons planning on either implementing or using this

-   protocol are STRONGLY URGED to get in touch with the author before

-   embarking on such a project.

-

-

-1. Abstract

-

-   The Simple Mail Transfer Protocol [RFC-821] allows server

-   responses to include human-readable text that in many cases needs to

-   be presented to the user.  This document specifies a way for a

-   client to negotiate which language the server should use when

-   sending human-readable text.

-

-

-2. Conventions used in this document

-

-   In examples, "C:" and "S:" indicate lines sent by the client and

-   server respectively.   If such lines are wrapped without a new "C:"

-   or "S:" label, then the wrapping is for editorial clarity and is not

-   part of the command.

-

-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in

-   this document are to be interpreted as described in [KEYWORDS].

-

-

-3. Framework for the Language SMTP service extension

-

-   The Language SMTP  service  extension  uses the  SMTP  service  extension  

-   mechanism described in [ESMTP].  The following SMTP service extension is 

-   therefore defined:

-

-  (1) The name of the SMTP service extension is "Language".

-

-  (2) The EHLO keyword value associated with this service extension is

-      "LANGUAGE".

-

-  (3) The AUTH EHLO keyword contains as a parameter a space separated

-      list of the names of supported language tags. This list is optional. 

-      If the language tag argument is omitted, this means that server is 

-      unable to enumerate the list of languages it supports.

-

-  (4) A new SMTP verb "LANG" is defined

-

-  (5) No additional SMTP parameters to either MAIL FROM or RCPT TO commands 

-      are defined by this extension.

-

-

-4. Requirements

-

-   A server that supports this extension SHOULD use the language "i-

-   default" as described in [CHARSET-POLICY] as its default language

-   until another supported language is negotiated by the client.  A

-   server MUST support and include "i-default" in EHLO response.

-

-

-5. LANG Command

-

-   LANG [language-tag]

-

-     Arguments:

-         Zero or one language tag as defined by [RFC-1766].

-

-     Restrictions:

-         The LANG command is permitted throughout a mail connection.

-

-     Reply Codes:

-         Success:

-            250 LANG command completed successfully

-         Error: 

-            504 Language tag is unknown

-            421 <domain> Service not available, closing transmission channel

-

-     Discussion:

-         The LANG command requests that human-readable text emitted by

-         the server be localized to the language specified in the language

-         tag argument.

-

-         If the command succeeds, the server will return human-readable

-         responses in the specified language starting with the successful

-         250 response to the LANG command.  These responses will be in UTF-8

-         [RFC-2044]. In particular, LANG command MAY affect the result of 

-         a HELP command.

-

-         If the command fails, the server will continue to return human-

-         readable responses in the language it was previously using.

-

-     Example:

-

-        < The server defaults to using English responses until the user

-          explicitly changes the language. >

-

-         S: 220 smtp.example.com ESMTP server ready

-         C: EHLO main.example.com

-         S: 250-smtp.example.com

-         S: 250-AUTH CRAM-MD5 DIGEST-MD5

-         S: 250 LANGUAGE EN DE RU i-default

-

-         C: HELP

-         S: 214-This is Sendmail version X.X.X

-         S: 214-Topics:

-         S: 214-    HELO    EHLO    MAIL    RCPT    DATA

-         S: 214-    RSET    NOOP    QUIT    HELP    VRFY

-         S: 214-    EXPN    VERB    ETRN    DSN

-         S: 214-For more info use "HELP <topic>".

-         S: 214 End of HELP info

-

-        < Once the client changes the language, all responses will be in

-          that language starting with 250 response to the LANG command. >

-

-         C: LANG FR

-         S: 250 La Language commande a ete executee avec success

-

-         C: HELP

-         S: 214-C'est le programme Sendmail version X.X.X

-         S: 214-Topics:

-         S: 214-    HELO    EHLO    MAIL    RCPT    DATA

-         S: 214-    RSET    NOOP    QUIT    HELP    VRFY

-         S: 214-    EXPN    VERB    ETRN    DSN

-         S: 214-Pour obtenir l'information supplementaire utiliser "HELP <topic>".

-         S: 214 La fin de l'information 

-

-        < If a server does not support the requested language, responses

-          will continue to be returned in the current language the server is

-          using. >

-

-         C: LANG DE

-         S: 250 Ce Language n'est pas supporte

-

-

-5. Formal Syntax

-

-   The following syntax specification uses the augmented Backus-Naur

-   Form (BNF) as described in [ABNF].

-

-   Except as noted otherwise, all alphabetic characters are case-

-   insensitive.  The use of upper or lower case characters to define

-   token strings is for editorial clarity only.  Implementations MUST

-   accept these strings in a case-insensitive fashion.

-

-   CR              = %x0C           ;; ASCII CR, carriage return

-

-   CRLF            = CR LF

-

-   LF              = %x0A           ;; ASCII LF, line feed

-

-   SPACE           = %x20           ;; ASCII SP, space

-

-   LANG_Command = "LANG" SPACE language_tag CRLF

-

-   LANGUAGE_List = "LANGUAGE" *(SPACE <language_tag>) CRLF

-      ; Note: the server is required to support the language i-default

-      ; and as such i-default must appear in the language response.

-      ; When "i-default" is used, all responses MUST contain only 

-      ; English text.

-

-   language_tag =  <language_tag> as defined in [RFC-1766]

-

-

-6. Security Considerations

-

-   This extension allows the negotiation of a language for the human-

-   readable text returned by a server.  A user is able to query the

-   languages that a server supports.

-

-

-7. References

-

-   [RFC-821], Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC

-   821, August 1982, <ftp://ftp.isi.edu/in-notes/rfc821.txt>

-

-   [RFC-1766], Alvestrand, H., "Tags for the Identification of

-   Languages", RFC 1766, UNINETT, March 1995,

-   <ftp://ftp.isi.edu/in-notes/rfc1766.txt>

-

-   [RFC-2044], Yergeau, F., "UTF-8, a transformation format of Unicode

-   and ISO 10646, RFC 2044, Alis Technologies, October 1996,

-   <ftp://ftp.isi.edu/in-notes/rfc2044.txt>

-

-   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate

-   Requirement Levels", RFC 2119, March 1997,

-   <ftp://ftp.isi.edu/in-notes/rfc2119.txt>

-

-   [IMAP-LANGUAGE], Gahrns, M., McCown, A., "IMAP4 Language Extension", 

-   draft-gahrns-imap-language-00.txt (work in progress), Microsoft, 

-   Mitsubishi Electric ITA, November 1997

-

-   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:

-   ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd.,

-   November 1997, <ftp://ftp.isi.edu/in-notes/rfc2234.txt>

-

-   [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 

-   Languages", RFC 2277, January 1998, <ftp://ftp.isi.edu/in-notes/rfc2277.txt>

-

-

-8.  Acknowledgments

-

-   This document is derived from [IMAP-LANGUAGE]. The authors would thank 

-   Mike Gahrns and Andrew McCown for their perfect work.

-

-

-9.  Copyright

-

-   Copyright (C) The Internet Society 1999. 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.

-

-10. Author's Address

-

-    Alexey Melnikov

-    Messaging Direct, Inc.

-

-    Home address :

-    121293, Russia, Moscow,

-    general Ermolov street, 6 - 90

-

-    Email: alexey.melnikov@messagingdirect.com

-

-    Fax (San Diego, CA) : 1 (619) 8393837

-

diff --git a/Documentation/en/I-D/draft-melnikov-smtp-lang-04.txt b/Documentation/en/I-D/draft-melnikov-smtp-lang-04.txt
deleted file mode 100644
index 9c04ae58..00000000
--- a/Documentation/en/I-D/draft-melnikov-smtp-lang-04.txt
+++ /dev/null
@@ -1,574 +0,0 @@
-Network Working Group                            Mike Gahrns, Microsoft 
-Internet Draft           Alexey Melnikov, ACI WorldWide/MessagingDirect
-Document: draft-melnikov-smtp-lang-04.txt                     July 2001
-
-
-                          SMTP Language Extension
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.  Internet-Drafts are
-   working documents of the Internet Engineering Task Force (IETF), its
-   areas, and its working groups.  Note that other groups may also
-   distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time.  It is inappropriate to use Internet- Drafts as
-   reference material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This document  suggests  a  proposed  protocol  for  the   Internet
-   community, and requests discussion and suggestions for improvements.
-   Distribution of this draft is unlimited.
-
-   The protocol discussed in this document is experimental and subject to
-   change.  Persons planning on either implementing or using this protocol
-   are STRONGLY URGED to get in touch with the author before embarking on
-   such a project.
-
-
-0. Meta Information on this draft 
-    
-   This information is intended to facilitate discussion.  It will be
-   removed when this document leaves the Internet-Draft stage.
-    
-
-   Changes since -00 
-    
-1). Corrected grammar error in LANG command description section
-
-2). Included Mark Crispin's suggestion of allowing the server to substitute
-    a primary language if the sublanguage asked for is not available.
-
-3). Added section 5 that describes extended LANG reply
-
-4). Corrected example, more examples
-
-5). Added extension mechanism
-
-6). Specified interaction with RFC-2034 ("SMTP Service Extension for
-    Returning Enhanced Error Codes")
-
-7). LANG command must always have language-tag as a parameter. Only EHLO
-    response could be used to examine list of supported languages.
-
-
-   Changes since -01 
-    
-1). Corrected ABNF for CR
-
-2). Updated Copyright section
-
-3). Other minor bugfixes
-
-
-   Changes since -02 
-    
-1). Extended DSN format to include language tag
-
-2). Fixed few typos.
-
-
-   Changes since -03 
-    
-1). Changed DSN format to include language tag and translation of text part of
-    diagnostic-code-field. Don't use diagnostic-code-field for a non English text.
-
-2). Added LANG parameter to MAIL FROM.
-
-
-   Open issues
-
-1). What a server should send in LANGUAGE EHLO response if it can't
-    enumerate all of the supported languages but only some of them?
-
-
-1. Abstract
-
-   The Simple Mail Transfer Protocol [RFC-821] allows server responses to
-   include human-readable text that in many cases needs to be presented to
-   the user.  This document specifies a way for a client to negotiate which
-   language the server should use when sending human-readable text. It also
-   extends DSN format to include language field for the human-readable text.
-
-
-2. Conventions used in this document
-
-   In examples, "C:" and "S:" indicate lines sent by the client and server
-   respectively.  If such lines are wrapped without a new "C:" or "S:"
-   label, then the wrapping is for editorial clarity and is not part of the
-   command.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [KEYWORDS].
-
-
-3. Framework for the Language SMTP service extension
-
-   The Language SMTP service extension uses the SMTP service extension
-   mechanism described in [ESMTP]. The following SMTP service extension is
-   therefore defined:
-
-  (1) The name of the SMTP service extension is "Language".
-
-  (2) The EHLO keyword value associated with this service extension is
-      "LANGUAGE".
-
-  (3) The LANGUAGE EHLO keyword contains as a parameter a space separated
-      list of the names of supported language tags. This list is optional. 
-      If the language tag argument is omitted, this means that server is
-      unable to enumerate the list of languages it supports.
-
-  (4) A new SMTP verb "LANG" is defined by this document.
-
-  (5) One optional parameter is added to the MAIL command:
-
-      An optional parameter for the MAIL command, using the esmtp-keyword
-      "LANG", (used to propagate a language that should be used in human
-      readable part and/or localized-diagnostic-text-field field of
-      "message/delivery-status" part (see section 8.) of a delivery status
-      notification for the message), is defined in section 7.
-
-  An additional document may define an extension to LANGUAGE ESMTP
-  extension.  Any such extension MUST use ESMTP extension name that starts
-  with LANGUAGE prefix. This document doesn't specify any LANG command
-  extension.
-
-
-4. Requirements
-
-   Any server that supports this extension MUST support the language
-   "i-default".  It SHOULD use the language "i-default" as described in
-   [CHARSET-POLICY] as its default language until another supported language
-   is negotiated by the client.  If a server is able to enumerate supported
-   languages it MUST include "i-default" in EHLO response. Otherwise it MUST
-   NOT return any language in LANGUAGE EHLO response.
-
-
-5. LANG Command
-
-   LANG language-tag [*extension]
-
-     Arguments:
-         language tag as defined by [RFC-1766].
-         optional extension specific parameters 
-
-     Restrictions:
-         The LANG command is permitted throughout a mail connection.
-
-     Reply Codes:
-         Success:
-            250 LANG command completed successfully
-         Error: 
-            504 Language is not supported
-            421 <domain> Service not available, closing transmission channel
-
-     Discussion: 
-         The LANG command requests that human-readable text emitted by the
-         server be localized to the language specified in the language tag
-         argument.
-
-         If a sublanguage was asked for and not available but the primary
-         language is available, the server SHOULD switch to the primary
-         language and MUST use an extended LANG reply containing the
-         identifier of the primary language it switched to as described in
-         section 5.
-
-         It is also recommended that server recognizes languages that have
-         multiple different tags (for example "ru" and "rus").
-
-         Note 1. Client MUST NOT use MUL (Multiple languages) and UND
-         (Undetermined) language tags and server MUST return error code 504
-         to the LANG command that is used with such parameter.
-
-         Note 2. [RFC-1766] warns that there is no guaranteed relationship
-         between languages whose tags start out with the same series of
-         subtags. However it is believed that for the purpose of this
-         document it is safe to treat all languages, whose tags starts with
-         primary language described in ISO 639-1 and ISO 639-2 (i.e. all 2
-         or 3 letters primary languages) as hierarchical.  For all languages
-         with other primary tags described fallback rule MUST NOT be used.
-         In particular, language tags starting with 'i-' and 'x-' SHOULD NOT
-         be treated as hierarchical.
-
-         If the command succeeds, the server will return human-readable
-         responses in the specified language starting with the successful
-         250 response to the LANG command.  These responses will be in UTF-8
-         [RFC-2044]. In particular, LANG command MAY affect the result of a
-         HELP command.
-
-         If the command fails, the server will continue to return human-
-         readable responses in the language it was previously using.
-
-         An additional document may define an extension to LANGUAGE ESMTP
-         extension.  Any such extension MUST use ESMTP extension name that
-         starts with LANGUAGE prefix. This document doesn't specify any
-         LANGUAGE extension.
-
-         LANGUAGE extension document may define additional parameters to LANG
-         command.  Client MUST NOT issue the optional extension parameters
-         unless a server has indicated in its EHLO response that it supports
-         that extension. In case when server doesn't support requested
-         parameter(s) or any parameters, it MUST respond with 504 code.
-
-     Example 1:
-
-        < The server defaults to using responses in "i-default" language
-          until the user explicitly changes the language. >
-
-         S: 220 smtp.example.com ESMTP server ready
-         C: EHLO main.example.com
-         S: 250-smtp.example.com
-         S: 250-AUTH CRAM-MD5 DIGEST-MD5
-         S: 250 LANGUAGE EN FR RU i-default
-         C: HELP
-         S: 214-This is Sendmail version X.X.X
-         S: 214-Topics:
-         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
-         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
-         S: 214-    EXPN    VERB    ETRN    DSN
-         S: 214-For more info use "HELP <topic>".
-         S: 214 End of HELP info
-
-        < Once the client changes the language, all responses will be in
-          that language starting with 250 response to the LANG command. >
-
-         C: LANG FR
-         S: 250 La Language commande a ete execute avec success
-
-         C: HELP
-         S: 214-C'est le programme Sendmail version X.X.X
-         S: 214-Topics:
-         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
-         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
-         S: 214-    EXPN    VERB    ETRN    DSN
-         S: 214-Pour obtenir l'information supplementaire utilisez "HELP <topic>".
-         S: 214 La fin de l'information 
-
-        < If a server does not support the requested language, responses
-          will continue to be returned in the current language the server is
-          using. >
-
-         C: LANG DE
-         S: 504 Ce Language n'est pas supporte
-
-     Example 2:
-
-        < The client tries to select MUL language that couldn't be used with
-          described extension>
-
-         C: LANG MUL
-         S: 504 It is not allowed to use MUL language.
-
-     Example 3:
-
-        < The client tries to use LANG extension not supported by server>
-
-         C: LANG i-default (blah blah)
-         S: 504 LANG extension blah is not recognized.
-
-
-6. "LANG" extended reply
-
-   Extended reply is the reply that contains additional information in the
-   text part. Extended reply allows to pass additional information from
-   server to client.  Client may choose to ignore additional information in
-   an extended reply. Thus client that doesn't recognize an extended reply
-   would treat it as a regular SMTP reply.
-
-     Example 4:
-
-        < The client tries to select the language, but it is unavailable. 
-          However primary language is available>
-
-         C: LANG FR-ca
-         S: 250 [LANG FR]La Language commande a ete execute avec success
-
-   Client that supports LANGUAGE extension must recognize Enhanced Error
-   Codes defined in [RFC-2034]. When server supports both LANGUAGE and
-   ENHANCEDSTATUSCODES extensions, Extended reply data MUST follow Enhanced
-   Error Code in reply.
-
-     Example 5:
-
-        < The server supports both LANGUAGE and ENHANCEDSTATUSCODES>
-
-         S: 220 smtp.example.com ESMTP server ready
-         C: EHLO main.example.com
-         S: 250-smtp.example.com
-         S: 250-LANGUAGE EN FR RU i-default
-         S: 250 ENHANCEDSTATUSCODES
-         C: LANG FR-ca
-         S: 250 2.0.0 [LANG FR]La Language commande a ete execute avec success
-
-
-7. The LANG parameter of the ESMTP MAIL command
-
-   Then LANG esmtp-keyword on the extended MAIL command specifies what
-   language should be used in human readable part and/or
-   localized-diagnostic-text-field field of "message/delivery-status" part
-   (see section 8.) of a delivery status notification for the message.
-
-   If the LANG esmtp-keyword is used, it MUST have an associated
-   esmtp-value. The ABNF for the LANG parameter is:
-
-     lang-parameter = "LANG=" language-tag
-
-   If the message is relayed to another SMTP server that supports LANGUAGE
-   ESMTP extension, the MTA acting as the client MUST check if the receiving
-   MTA lists the language specified in lang-param ("requested language") in
-   the list of supported language tags in LANGUAGE EHLO response.  If the
-   receiving MTA either lists the requested language or doesn't list any
-   language tag (i.e. the receiving MTA is unable to list languages it
-   supports) the sender MUST issue LANG command for the requested language.
-   After that, regardless of the result of LANG command, the client MTA MUST
-   specify LANG parameter in MAIL command.
-
-   The receiving MTA SHOULD use the language specified in LANG parameter if
-   it has to generates a DSN for the message. Human readable part in
-   generated DSN SHOULD contain the description of the event in both English
-   and requested language. If the server MTA doesn't support the requested
-   language, it MUST act as if the client didn't specify LANG parameter in
-   MAIL command.
-
-     Example 6:
-
-        < Relaying of the message >
-
-         S: 220 smtp.example.com ESMTP server ready
-         C: EHLO main.example.com
-         S: 250-smtp.example.com
-         S: 250-DSN
-         S: 250-8BITMIME
-         S: 250 LANGUAGE
-         C: LANG RU
-         S: 504 Unsupported language
-         C: MAIL FROM:<Katerina@example.ru> LANG=ru
-         S: 250 <Katerina@example.ru> sender ok
-         C: DATA
-         S: 354 okay, send message
-         C: (message goes here)
-         C: .
-         S: 250 message accepted
-         C: QUIT
-         S: 221 goodbye
-
-
-8. Delivery status notifications and extension
-
-   The format of delivery status notifications (DSNs) is specified in [DSN]. 
-   This memo extends the per-recipient-fields of [DSN] to include two new
-   DSN fields, Localized-Diagnostic-Text, that is equivalent to text part of
-   Diagnostic-Code but contains text in any language other than English, and
-   Language, indicating the language tag for Localized-Diagnostic-Text
-   field. In the augmented BNF of RFC 822 [ABNF], per-recipient-fields is
-   therefore extended as follows:
-
-     per-recipient-fields =
-          [ original-recipient-field CRLF ]
-          final-recipient-field CRLF
-          action-field CRLF
-          status-field CRLF
-          [ remote-mta-field CRLF ]
-          [ [language-field CRLF
-            localized-diagnostic-text-field CRLF ]
-            diagnostic-code-field CRLF ]
-          [ last-attempt-date-field CRLF ]
-          [ will-retry-until-field CRLF ]
-          *( extension-field CRLF )
-
-    language-field = "Language" ":" language
-
-    localized-diagnostic-text-field = "Localized-Diagnostic-Text" ":" *text
-
-   where language is a language tag as described in [RFC-1766].
-
-   An SMTP server that supports both DSN and LANGUAGE extensions SHOULD
-   include localized-diagnostic-text-field. If
-   localized-diagnostic-text-field is present, language-field MUST be
-   present too. diagnostic-code-field MUST NOT contain text in any language
-   other than English.
-
-
-8. Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur Form
-   (BNF) as described in [ABNF].
-
-   Except as noted otherwise, all alphabetic characters are
-   case-insensitive.  The use of upper or lower case characters to define
-   token strings is for editorial clarity only.  Implementations MUST accept
-   these strings in a case-insensitive fashion.
-
-   CR              = %x0D     ;; ASCII CR, carriage return
-
-   CRLF            = CR LF
-
-   LF              = %x0A     ;; ASCII LF, line feed
-
-   SPACE           = %x20     ;; ASCII SP, space
-
-   LANG_Command = "LANG" SPACE language_tag [*extension] CRLF
-      ; A client MUST NOT issue the optional extension parameter 
-      ; unless a server has indicated in its EHLO response that it 
-      ; supports that extension 
-
-   extension = SP "(" lang-ext-name SP lang-ext-values ")" 
-
-   lang-ext-name = text
-      ; Name of LANG extension
-
-   lang-ext-values = "(" lang-ext-value *(SP lang-ext-value)")"
-      ; List of LANG extension specific values 
-
-   lang-ext-value = text
-
-   LANGUAGE_List = "LANGUAGE" *(SPACE <language_tag>) CRLF
-      ; Note 1: the server is required to support the language i-default and
-      ; as such i-default MUST appear in the language response.  When
-      ; "i-default" is used, all responses MUST contain only ASCII text.
-      ;
-      ; Note 2: Language tags MUL (Multiple languages) and UND
-      ; (Undetermined) MUST NOT be used.
-
-
-   language_tag =  <language_tag> as defined in [RFC-1766]
-
-   Reply-line |= Lang-Reply-line
-      ; Reply-line is defined in [SMTP-UPD]
-      ; See section 6 for description of Lang-Reply-line
-
-   Lang-Reply-line = Reply-code [ SP ext-text ] CRLF
-      ; Reply line for LANG command
-
-   ext-text = ext-data text
-
-   ext-data = "[" ext-name SP ext-value "]"
-      ; Note 1: In the case of multiline response the same ext-data SHOULD
-      ; appear on every line.
-      ;
-      ; Note 2: In case when server also supports "SMTP Service Extension
-      ; for Returning Enhanced Error Codes" [RFC-2034], ext-data MUST follow
-      ; Enhanced Error Code.
-
-   ext-name = "LANG"
-
-   ext-value = Primary-tag
-      ; Primary tag as defined by [RFC-1766]  
-
-
-9. Security Considerations
-
-   This extension allows the negotiation of a language for the human-
-   readable text returned by a server.  A user is able to query the
-   languages that a server supports.
-
-
-10. References
-
-   [RFC-821], Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-   821, August 1982, <ftp://ftp.isi.edu/in-notes/rfc821.txt>
-
-   [SMTP-UPD], Klensin, J., "Simple Mail Transfer Protocol",
-   draft-ietf-drums-smtpupd-10.txt (work in progress), February 1999. 
-
-   [RFC-1766], Alvestrand, H., "Tags for the Identification of
-   Languages", RFC 1766, UNINETT, March 1995,
-   <ftp://ftp.isi.edu/in-notes/rfc1766.txt>
-
-   [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 
-   Languages", RFC 2277, January 1998, <ftp://ftp.isi.edu/in-notes/rfc2277.txt>
-
-   [RFC-2044], Yergeau, F., "UTF-8, a transformation format of Unicode
-   and ISO 10646, RFC 2044, Alis Technologies, October 1996,
-   <ftp://ftp.isi.edu/in-notes/rfc2044.txt>
-
-   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", RFC 2119, March 1997,
-   <ftp://ftp.isi.edu/in-notes/rfc2119.txt>
-
-   [IMAP-LANGUAGE], Gahrns, M., Melnikov, A., "IMAP4 Language Extension", 
-   draft-gahrns-imap-language-xx.txt (work in progress), Microsoft, 
-   ACI WorldWide/MessagingDirect
-
-   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
-   ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd.,
-   November 1997, <ftp://ftp.isi.edu/in-notes/rfc2234.txt>
-
-   [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced
-   Error Codes", RFC 2034, Innosoft, October 1996
-
-   [DSN]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
-   Delivery Status Notifications", RFC 1894, January 1996.
-
-11.  Acknowledgments
-
-   This document is based on the early version of [IMAP-LANGUAGE]. 
-   Thus the work of Andrew McCown is appreciated.
-
-   Many thanks to the following people who gave feedback on the document:
-   Brad Knowles and Paul Hoffman.
-
-
-12.  Copyright
-
-   Copyright (C) The Internet Society 1999-2001. 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.
-
-
-13. Author's Address
-
-    Mike Gahrns
-    Microsoft
-    One Microsoft Way
-    Redmond, WA, 98072
-
-    Phone: (425) 936-9833
-    Email: mikega@microsoft.com 
-
-    Alexey Melnikov
-    ACI WorldWide/MessagingDirect
-    #900, 10117 Jasper Avenue,
-    Edmonton, Alberta, T5J 1W8
-
-    Phone: (780) 424-4922 Ext 357
-    Email: mel@messagingdirect.com
-
diff --git a/Documentation/en/I-D/draft-meyer-reqbehaviors-manager-00.txt b/Documentation/en/I-D/draft-meyer-reqbehaviors-manager-00.txt
deleted file mode 100644
index 2a07b3ae..00000000
--- a/Documentation/en/I-D/draft-meyer-reqbehaviors-manager-00.txt
+++ /dev/null
@@ -1,191 +0,0 @@
-draft-meyer-reqbehaviors-manager-00.txt                     Mike Meyer
-Category: Informational                               Meyer Consulting
-Expires: September, 2002                                   March, 2002
-
-           Required behaviors for mail list managers
-
-Status of this Memo
-
-       This document is an Internet-Draft and is subject to        
-       all provisions of Section 10 of RFC2026.
-
-       Internet-Drafts are working documents of the Internet 
-       Engineering Task Force (IETF), its areas, and its 
-       working groups.  Note that other groups may also 
-       distribute working documents as Internet-Drafts.
-
-       Internet-Drafts are draft documents valid for a maximum 
-       of six months and may be updated, replaced, or obsoleted 
-       by other documents at any time.  It is inappropriate to 
-       use Internet-Drafts as reference material or to cite 
-       them other than as "work in progress."
-
-       The list of current Internet-Drafts can be accessed at     
-       http://www.ietf.org/1id-abstracts.html
-
-       The list of Internet-Draft Shadow Directories can be 
-       accessed at http://www.ietf.org/shadow.html
-
-Abstract
-
-       The behavior of mail lists on the Internet has become 
-       much more sophisticated than the alias expanders 
-       discussed in the standards for Internet messages 
-       formats. The lack of standard behavior for this part of 
-       the Internet messaging system creates confusion among 
-       users, resulting in misdirected or inappropriately 
-       duplicated messages. This document lists required 
-       behaviors for mail list managers derived from [RFC2821] 
-       and [RFC2822] in hopes of reducing the confusion, 
-       misdirected and duplicated mail, while at the same time 
-       simplifying the configuration process for mail list 
-       managers.
-
-1. Introduction
-
-1.1. Scope
-
-       Mail list managers - henceforth MLMs - have become 
-       complex software programs, with a multitude of 
-       configuration options that can result in behavior that 
-       subscribers may find confusing, undesirable, and 
-       possibly even hostile when considered as a whole.
-
-       This standard specifies how the headers defined in 
-       [RFC2822] and the envelope specified in [RFC2821] should 
-       be used by mail list managers to provide flexibility in 
-       the MLM configuration while avoiding the behaviors 
-       mentioned above. Justification for these requirements is 
-       also provided where it is deemed necessary.
-
-1.2. Requirements Notation
-
-       This document occasionally uses terms that appear in 
-       capital letters. When the terms "MUST", "SHOULD", 
-       "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" 
-       appear capitalized, they are being used to indicate 
-       particular requirements of this specification.  A 
-       discussion of the meanings of these terms appears in 
-       [RFC2119].
-
-1.3 Structure of this document
-
-       This section, section 1, is a short introduction to the 
-       document.
-
-       Section 2 covers the use of envelope information 
-       described in [RFC2821].
-
-       Section 3 covers the various mail headers that MLMs 
-       change, when and how they may be changed, and what 
-       requirements are placed on an MLM when it changes those 
-       headers.
-
-       Section 4 and 5 provide references and contact 
-       information, respectively.
-
-2. Envelope return path
-
-       The envelope return path MUST be set to the address of a 
-       manager of the mail list in question. This behavior is 
-       specified in 3.10.2 of [RFC2821], and the reasons for 
-       doing so may be found there.
-
-3. Message headers
-
-3.1 Relays
-
-       If the MLM relays the message body unaltered, then it is 
-       acting as a simple alias expander, and section 3.10 
-       "Mailing Lists and Aliases" of [RFC2821] specifies that 
-       the headers MUST be left unchanged, except for the 
-       addition of "Received" headers and loop detection, as 
-       per section 3.7 "Relaying" of [RFC2821].
-
-3.2 MLMs that change the content
-
-       Few modern MLMs simply relay the body of the message 
-       unaltered. Most of them add information to the body, and 
-       possibly add headers to the existing headers, tag the 
-       subject line, and otherwise modify the message.
-
-       This action has two effects according to [RFC2822]. 
-       First, it makes the message a collaborative effort 
-       between the original author and the MLM. Second, it 
-       means this is a new message.
-
-       By becoming a collaborator on the message, the MLM 
-       becomes an originator of the message, and can thus 
-       legitimately change the originator fields listed in 
-       section 3.6.2 "Originator fields" of [RFC2822]. Those 
-       fields are the "From", "Sender" and "Reply-To" fields. 
-       According to [RFC2822], a collaborative effort normally 
-       lists all authors in the "From" field, and the actual 
-       sender in the "Sender" field. Few, if any, MLMs do this. 
-       Many leave these three fields untouched, or add a 
-       "Sender" field if one wasn't present. Others add a 
-       "Reply-To" field containing the list address.
-
-       Since an [RFC2822] "Message-id" field refers to a 
-       particular version of a particular message, the new 
-       message created by the MLM should get a new "Message-id" 
-       field.
-
-       Given these three sets of behaviors, the following two 
-       options are provided for MLMs to meet the requirements 
-       of this RFC.
-
-3.2.1 Enhanced mail relay
-
-       The MLM may consider itself to be nothing more than an 
-       enhanced mail relay. In this case, all messages going to 
-       a list MUST receive the same modifications. The only 
-       header modifications allowed are that an MLM MAY add a 
-       "Sender" field if one is not already present, and MAY 
-       add a tag to the "Subject" field. If added, the field 
-       should refer to the manager of the list the message is 
-       passing through. The MLM MUST NOT alter either "From" or 
-       "Reply-To" in any way, and MUST NOT add them if they are 
-       not present.
-
-3.2.2 Collaborative list manager
-
-       The MLM may consider itself a collaborator of the 
-       message for purposes of the originator fields. To 
-       operate in this mode, the MLM MUST create a new 
-       "Message-id" field for the message. If a "Message-id" 
-       field is already present, the message ID in it SHOULD be 
-       copied to the "References" field as per section 3.6.5 
-       "Identification Fields" of [RFC2822]. If there is no 
-       "Sender" field, the MLM SHOULD add the list owner as the 
-       sender of the message. The MLM MAY create a "Reply-to" 
-       field that refers to the original list. If there is 
-       already a "Reply-to" field, it MAY add the list to that 
-       field, but it MUST NOT remove any addresses from the 
-       existing "Reply-to" field. It SHOULD leave the "From" 
-       field unmodified.
-
-4. References
-
-       [RFC2119]  Bradner, S., "Key words for use in RFCs to 
-                  Indicate Requirement Levels", BCP 14, RFC 
-                  2119, March 1997.
-
-       [RFC2821]  Klensin, J., Editor, "Simple Mail Transfer 
-                  Protocol", RFC 2821, April 2001.
-
-       [RFC2822]  Resnick, P., Editor, "Internet Message 
-                  Format", RFC 2822, April 2001.
-
-                     2821, March 2001.
-
-5. Author's Contact Information
-
-       Mike Meyer                       Phone: +1 405 326 6665
-       288 E. Chestnut Rd.              EMail: mwm@mired.org
-       Goldsby, OK 73093-9108
-       USA
-
---
-Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
-Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
diff --git a/Documentation/en/I-D/draft-moore-auto-email-response-00.txt b/Documentation/en/I-D/draft-moore-auto-email-response-00.txt
deleted file mode 100644
index 77e9135c..00000000
--- a/Documentation/en/I-D/draft-moore-auto-email-response-00.txt
+++ /dev/null
@@ -1,768 +0,0 @@
-Internet-Draft                                                  K. Moore
-Expires: 5 December 2002                         University of Tennessee
-                                                             5 June 2002
-
-
-       Recommendations for Automatic Responses to Electronic Mail
-
-                   draft-moore-auto-email-response-00
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is subject to all provisions of
-Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-This document is not currently associated with any working group.
-Comments on this internet-draft should be sent to the mailing list
-<ietf-822@imc.org>, or to the author.  Such comments should cite the
-Internet-Draft identifier draft-moore-auto-email-response-00 so others
-can be sure you are commenting on the same version they read.
-
-Abstract
-
-This memo makes recommendations for software that automatically responds
-to incoming electronic mail messages, including "out of the office"
-response generators, mail filtering software, email-based information
-services, and other automatic responders.  The purpose of these
-recommendations is to discourage undesirable behavior which is caused or
-aggravated by such software, to encourage uniform behavior (where
-appropriate) among automatic mail responders, and to clear up some
-sources of confusion among implementors of automatic email responders.
-
-
-
-
-
-Moore                  Automatic E-Mail Responses               [Page 1]
-Internet-Draft                                               5 June 2002
-
-
-1. Introduction
-
-Many programs which automatically respond to email are currently in use.
-Although these programs vary widely in their function, several problems
-with this class of programs have been observed, including: significant
-numbers of useless or unwanted response and responses sent to
-inappropriate addresses, and occasional incidences of mail loops or
-"sorcerer's apprentice" syndrome.  This memo recommends behavior for
-programs that automatically respond to electronic mail in order to
-reduce the number of problems caused by such programs.
-
-1.1 Types of automatic responses
-
-There are several different types of automatic responses.  At least two
-types of automatic responses have been defined in IETF standards -
-Delivery Status Notifications [1] which are intended to report the
-status of a message delivery by the message transport system, and
-Message Disposition Notifications [2] which are intended to report of
-the disposition of a message after it reaches a recipient's mailbox.
-These responses are defined elsewhere and are generally not within the
-purview of this document, except that this document recommends specific
-cases where they should or should not be used.
-
-Other types of automatic response in common use include:
-
--    "Out of office" or "vacation" notices, which are intended to inform
-     the sender of a message that the message is unlikely to be read, or
-     acted on, for some amount of time;
-
--    Email-based information services, which accept requests (presumably
-     from humans) via email, provide some service, and issue responses
-     via email also.  (Mailing lists which accept subscription requests
-     via email fall into this category);
-
--    Information services similar to those mentioned above except that
-     they are intended to accept messages from other programs;
-
--    Various kinds of mail filters (including "virus scanners") which
-     act on behalf of a recipient to alter the content of messages
-     before forwarding them to that recipient, and issue responses in
-     the event a message is altered; and
-
--    Responders designed to filter unsolicited messages from programs
-     (e.g. a program that responds to any message from an unknown or
-     unverifiable source and requires that party to "demonstrate signs
-     of intelligent life" before the original message can be read.)
-
-
-
-
-
-Moore                  Automatic E-Mail Responses               [Page 2]
-Internet-Draft                                               5 June 2002
-
-
-Recognizing the wide variety of response types in use, these
-recommendations distinguish between several classes of automatic
-responders according to the party or service on whose behalf the
-responder acts:
-
--    "Service Responders" exist to provide access to some service via
-     email requests and responses.  These are permanently associated
-     with an email address, and when sending to such an address the
-     sender presumably expects an automatic response.  An email-based
-     file retrieval service is an example of a Service Responder.
-
--    "Personal Responders" exist to make automatic responses on behalf
-     of a single human recipient, in advance of, or in lieu of, that
-     recipient reading the message.  These responders operate according
-     to criteria specified by the individual recipient.  The UNIX
-     "vacation" program is an example of a Personal Responder.
-
--    "Group Responders" exist to make automatic responses on behalf of
-     any of a group of human recipients, in advance of, or in lieu of, a
-     response from the actual recipient.  Group Responders are similar
-     to Personal Responders except that in the case of a Group Responder
-     the criteria for responding are not set by the individual
-     recipient.  A "virus scanner" program that filtered all mail sent
-     to a group of recipients (say, every recipient in a particular DNS
-     domain) and sent responses when a message was rejected or delivered
-     in an altered form, would be an example of a Group Responder.
-
-Appropriate behavior for a responder varies from one class to another.
-A behavior which might be appropriate from a Service Responder (where
-the sender is expecting an automatic response) might not be appropriate
-from a Personal Responder.  For example, a Service Responder might send
-a very long response to a request, or one that is not in a human-
-readable format, according to the needs of that service.  However a
-Personal Responder should assume that a human being is reading the
-response and send only brief responses in plain text.
-
-1.2. Notation
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in [3].
-
-2. Format of automatic responses
-
-The following sections specify details of the contents of automatic
-responses, including the header of the response message, the content of
-the response, and the envelope in which the response is transmitted to
-the email transport system.
-
-
-
-Moore                  Automatic E-Mail Responses               [Page 3]
-Internet-Draft                                               5 June 2002
-
-
-2.1 Message header
-
-The fields in the message header SHOULD be set as follows:
-
-2.1.1 From field
-
-In correspondence between humans, the From field serves multiple
-purposes: It identifies the author of the message (or in some cases, the
-party or parties on whose behalf the message was sent), and it is the
-default destination of replies from humans.  Also, unfortunately some
-mail systems still send nondelivery reports and other kinds of automatic
-responses to the From address.
-
-For automatic responses, the role of the From field in determining the
-destination of replies from humans is less significant, because in most
-cases it is not useful or appropriate for a human (or anyone) to reply
-to an automatic response. (The exception is when there is some problem
-with the response; it should be possible to provide feedback to the
-person operating the responder).
-
-So the From address in an automatic response needs to be chosen
-according to the following criteria:
-
--    To provide an indication of the party or agent on whose behalf the
-     response was sent,
-
--    To provide an address to which a recipient of an inappropriate
-     response can request that the situation be corrected, and
-
--    To diminish the potential for mail loops.
-
-The following behavior is thus recommended:
-
--    For responses sent by Service Responders, the From field SHOULD
-     contain an address which can be used to reach the (human)
-     maintainer of that service, and the human-readable portion of the
-     From field (the phrase preceding the address) SHOULD contain a name
-     or description of the service to identify the service to humans.
-
--    For responses sent by Personal Responders, the From field SHOULD
-     contain the name of the recipient and an address chosen by the
-     recipient to be recognizable to correspondents. Normally this would
-     be the same address that was used to send mail to that recipient.
-
-     In the case of a recipient having multiple mail addresses forwarded
-     to the same mailbox (and responder), a Personal Responder MAY use
-     heuristics to guess, based on the information available in various
-     message header fields, which of several addresses for that
-
-
-
-Moore                  Automatic E-Mail Responses               [Page 4]
-Internet-Draft                                               5 June 2002
-
-
-     recipient the sender is likely to have used, and use that address
-     in the From field of the response.  However any address chosen by
-     this method MUST have been explicitly allowed by the recipient on
-     whose behalf the responder is operating.
-
-     Note: Due to privacy reasons it may be inappropriate for responders
-     to disclose an address that is derived, say, from the recipient's
-     login information (e.g. POP or IMAP user name or account name on a
-     multiuser computer) or which discloses the specific name of the
-     computer where the response was generated.  Furthermore these do
-     not necessarily produce a valid public email address for the
-     recipient.  For this reason the From field of a Personal Response
-     SHOULD be settable by the recipient on whose behalf the responder
-     is acting.
-
--    For Group Responders, the From address SHOULD contain an email
-     address which could be used to reach the maintainer of that Group
-     Responder.  Use of the Postmaster address for this purpose is NOT
-     RECOMMENDED.
-
-     The human-readable portion of the From address (the phrase before
-     the address) SHOULD contain an indication of the function performed
-     by the Group Responder and on whose behalf it operates (e.g.
-     "Example Agency virus filter")
-
-2.1.2 To field
-
-The To header field SHOULD indicate the recipient of the response.  In
-general there SHOULD only be one recipient of any automatic response.
-This minimizes the potential for sorcerer's apprentice syndrome and
-denial-of-service attacks.
-
-2.1.3 Date field
-
-The Date header field SHOULD indicate the date and time at which the
-response was composed.   This MUST NOT be taken as any indication of the
-delivery date of the subject message, nor of the time at which the
-response was sent.
-
-2.1.4 Subject field
-
-The Subject field SHOULD contain a brief indication that the message is
-an automatic response, followed by contents of the Subject field (or a
-portion thereof) of the subject message.  The prefix "Auto-Re:" MAY be
-used as such an indication.
-
-NOTE: Just as the prefix "Re:" (presumably an abbreviation of the
-English word "reply") is sometimes translated to other languages by mail
-
-
-
-Moore                  Automatic E-Mail Responses               [Page 5]
-Internet-Draft                                               5 June 2002
-
-
-readers, or otherwise interpreted by mail readers as indication that the
-message is a reply, so the prefix "Auto-Re:" may also be translated or
-used as a generic indication that the message is an automatic response.
-However the "Auto-Re:" indication is intended only as an aid to humans
-in processing the message.  The validity of "Auto-Re:" SHOULD NOT be
-assumed by mail processing software.
-
-2.1.5 In-Reply-To field
-
-The In-Reply-To field SHOULD be included in the header of the response
-message if there was a Message-ID field in the subject message.  If
-present in the response, the In-Reply-To field SHOULD contain the
-message-id of the subject message.   A References field MAY also be
-supplied.
-
-2.1.6 Auto-Submitted field
-
-The Auto-Submitted field, with a value of "auto-replied", SHOULD be
-included in the message header of any automatic response.  See section
-5.
-
-2.2 Message content
-
-In general, messages sent by Personal or Group Responders SHOULD be
-brief, and in text/plain format.  A multipart/alternative construct MAY
-be used to communicate responses in multiple languages if it is
-desirable to use multiple charsets.
-
-Response messages SHOULD NOT include significant content from the
-subject message. In particular responses SHOULD NOT contain non-
-text/plain attachments from the subject message.
-
-2.2.1 Use of DSNs and MDNs for automatic responses
-
-An exception to the above policy can be made for responders whose
-purpose is to filter out harmful content from incoming email.  In such
-cases it may be appropriate to issue a delivery status notification
-(DSN) or a message disposition notification (MDN) to indicate that such
-mail has been refused, deleted, or altered.  Such a responder MAY issue
-a DSN if the responder is operating as a part of the mail transport
-system and has access to the message envelope, and the response is
-generated on or prior to delivery to the recipient's mailbox.
-Alternatively, a response MAY use the MDN format, provided the response
-is generated on or after delivery to a recipient's mailbox.  An MDN
-SHOULD NOT be issued as an automatic response unless the subject message
-contains a Disposition-Notification-To field.  In all cases such
-responses MUST conform to the DSN or MDN specifications.
-
-
-
-
-Moore                  Automatic E-Mail Responses               [Page 6]
-Internet-Draft                                               5 June 2002
-
-
-For example, in the case of a DSN, the Action per-recipient field SHOULD
-be set to "failed" with a Status code of 5.7.1 (Delivery not authorized,
-message refused) if the message was not delivered due to security
-reasons, and the Action field SHOULD be set to "relayed" or "delivered"
-(as appropriate) with a Status code of 2.6.4 (conversion with loss
-performed) if the message was modified to remove significant (presumably
-harmful) content before relay or delivery but the remainder of the
-message was relayed or delivered to its destination.
-
-In the case of an MDN, a disposition mode of "automatic-action/-
-MDN-sent-automatically" would be appropriate, with a disposition-type of
-"deleted" or "denied" with a disposition modifier of "error" for
-messages which were automatically discarded, and a disposition-type of
-"processed" with a disposition modifier of "warning" for messages which
-were filtered before being presented to the recipient.  The Failure: or
-Warning: MDN fields could be used to supply additional information about
-the reason for refusal or alteration of the message.
-
-2.3 Message envelope
-
-The SMTP MAIL FROM address, or other envelope return address used to
-send the message, SHOULD be chosen in such a way as to make mail loops
-unlikely.  A loop might occur, for instance, if both sender and
-recipient of a message each have automatic responders - the recipient's
-responder sends mail to the sender's responder, which sends mail back to
-the recipient's responder.
-
-The primary purpose of the MAIL FROM address is to serve as the
-destination for delivery status messages and other automatic responses.
-Since in most cases it is not appropriate to respond to an automatic
-response, and the responder is not interested in delivery status
-messages, a MAIL FROM address of <> MAY be used for this purpose.  A
-MAIL FROM address which is specifically chosen for the purpose of
-sending automatic responses, and which will not automatically respond to
-any message sent to it, MAY be used instead of <>.
-
-The RCPT TO address should be the address of the intended recipient of
-the response.  It is RECOMMENDED that the NOTIFY=NEVER parameter of the
-RCPT command be specified if the SMTP server supports the DSN option
-[4].
-
-3. When to send automatic responses
-
-An automatic responder MUST NOT send a response for every message
-received.  In practice there are always reasons to refuse to respond to
-requests.  The criteria for deciding whether to respond will differ from
-one responder to another, according to the responder's purpose.  In
-general, care should be taken to avoid sending useless or redundant
-
-
-
-Moore                  Automatic E-Mail Responses               [Page 7]
-Internet-Draft                                               5 June 2002
-
-
-responses, and to avoid contributing to mail loops and facilitating
-denial-of-service attacks.
-
-Here are some broad guidelines:
-
--    Automatic responses SHOULD NOT be issued in response to any message
-     which contains an Auto-Submitted header field with a value of
-     "auto-replied" or "auto-generated".
-
--    Personal and Group responses whose purpose is to notify the sender
-     of a message of a temporary absence of the recipient (e.g.
-     "vacation" and "out of the office" notices) SHOULD NOT issue the
-     same response to the same sender more than once within a period of
-     several days, even though that sender may have sent multiple
-     messages.  A 7-day period is RECOMMENDED as a default.
-
--    Personal and Group responses whose purpose is to notify the sender
-     of a message of a temporary absence of the recipient (e.g.
-     "vacation" and "out of the office" notices) SHOULD NOT be issued
-     unless a valid address for the recipient is explicitly included in
-     the To, CC, or Bcc field of the subject message.  Since a recipient
-     may have multiple addresses forwarded to the same mailbox,
-     recipients SHOULD be able to specify a set of addresses to the
-     responder which it will recognize as valid for that recipient.
-
--    Responders SHOULD NOT generate responses for any null address.
-     Responders MAY refuse to generate responses for addresses commonly
-     used as return addresses by responders - e.g. those with local-
-     parts matching "owner-*", "*-request", "MAILER-DAEMON", etc.
-     Responders SHOULD check the destination address for validity before
-     generating the response, to avoid cluttering up the local mail
-     queues with messages that cannot be delivered or are unlikely to be
-     useful.
-
--    In order to avoid responding to spam and to certain kinds of
-     attacks, automatic responses from Service Responders should be sent
-     only for well-formed requests.  This may include checking that the
-     message resulting in the response has a content-type and content
-     appropriate to that service.
-
-4. Where to send automatic responses (and where not to send them)
-
-In general, automatic responses SHOULD be sent to the address given in
-the Return-Path field, or if the responder has access to the message
-envelope, the reverse-path from the SMTP MAIL command, or (in a non-SMTP
-system) another envelope return address which serves as the destination
-for nondelivery reports.
-
-
-
-
-Moore                  Automatic E-Mail Responses               [Page 8]
-Internet-Draft                                               5 June 2002
-
-
-If the Return-Path field is not present in the subject message, there is
-a bug in the SMTP server that delivered the message, or that SMTP server
-is improperly configured.  A Personal or Group responder SHOULD NOT
-deliver a response to any address other than that in the Return-Path
-field, even if the Return-Path field is missing.  It is better to fix
-the problem with the mail delivery system than to rely on heuristics to
-guess the appropriate destination of the response.
-
-A Service Responder MAY deliver the response to the address from the
->From field, or to another address from the request payload, provided
-this behavior is precisely defined in the specification for that
-service.  The Reply-To field SHOULD NOT be used for this purpose.
-
-The Reply-To field SHOULD NOT be used as the destination for automatic
-responses from Personal or Group Responders.  In general, this field is
-set by a human sender based on his/her anticipation of how human
-recipients will respond to the specific content of that message.  Even
-for replies from humans, there are cases where it is not appropriate to
-respond to the Reply-To address, especially if the sender has asked that
-replies be sent to a group and/or mailing list.  Since a Personal or
-Group Responder operates on behalf of a human recipient, it is safer to
-assume that any Reply-To field present in the message was set by a human
-sender on the assumption that any reply would come from a human who had
-some understanding of the roles of the sender and other recipients.  An
-automatic responder lack the information necessary to understand those
-roles.  Sending automatic responses to Reply-To addresses can thus
-result in a large number of people receiving a useless or unwanted
-message; it can also contribute to mail loops.
-
-Use of the From field as the destination for automatic responses has
-some of the same problems as use of Reply-To.  In particular, the From
-field may list multiple addresses, while automatic responses should only
-be sent to a single address.  In general, the From and Reply-To
-addresses are used in a variety of ways according to differing
-circumstances, and for this reason Personal or Group Responders cannot
-reliably assume that an address in the From or Reply-To field is an
-appropriate destination for the response.
-
-Similarly, the Sender field SHOULD NOT be used as the destination for
-automatic responses.  This field is intended only to identify the person
-or entity that sent the message, and is not required to contain an
-address that is valid for replies.
-
-The Return-Path address is really the only one from the message header
-that can be expected, as a matter of protocol, to be suitable for
-automatic responses that were not anticipated by the sender.
-
-
-
-
-
-Moore                  Automatic E-Mail Responses               [Page 9]
-Internet-Draft                                               5 June 2002
-
-
-5. The Auto-Submitted header field
-
-The purpose of the Auto-Submitted header field is to indicate that the
-message was originated by an automatic process, or an automatic
-responder, rather than by a human; and to facilitate automatic filtering
-of messages from signal paths for which automatically generated messages
-and automatic responses are not desirable.
-
-5.1 Syntax
-
-The syntax of Auto-Submitted is as follows:
-
-     auto-submitted-field     = "Auto-Submitted:" CFWS
-                                auto-submitted [CFWS] CRLF
-
-     auto-submitted           = ( "no" / "auto-generated" /
-                                "auto-replied" / extension )
-                       opt-parameter-list
-
-     extension                = token
-
-     opt-parameter-list       = *( [CFWS] ";" [CFWS] LWSP parameter )
-
-
-The symbols "token", and "parameter" are as defined in [5].
-
-5.2 Semantics
-
-The Auto-Submitted header field SHOULD NOT be supplied for messages that
-were manually submitted by a human.  Such a field MAY be supplied for a
-manually sent message that is intended to test the response of other
-mail system components to the presence of an Auto-Submitted field in a
-message.
-
-The auto-generated keyword:
-
--    SHOULD be used on messages generated by automatic (often periodic)
-     processes (such as UNIX "cron jobs"),
-
--    MUST NOT be used on manually generated messages,
-
--    MUST NOT be used on a message issued in direct response to another
-     message.
-
-The auto-replied keyword:
-
--    SHOULD be used on messages sent in direct response to another mes-
-     sage,
-
-
-
-Moore                  Automatic E-Mail Responses              [Page 10]
-Internet-Draft                                               5 June 2002
-
-
--    MUST NOT be used on manually-generated messages,
-
--    MUST NOT be used on messages generated by automatic or periodic
-     processes.
-
-The "no" keyword may be used to explicitly indicate that a message was
-originated by a human.
-
-Extension keywords may be defined in the future, though it seems
-unlikely.  The syntax and semantics of such keywords must be published
-as RFCs and approved using the IETF Consensus process [6].  Keywords
-beginning with "x-" are reserved for experiments and use among consent-
-ing parties.
-
-Optional parameters may also be defined by an IETF Consensus process.
-The syntax of optional parameters is given here to allow for future def-
-inition should they be needed.  Implementations of Auto-Submitted con-
-forming to this specification MUST NOT fail to recognize an Auto-Submit-
-ted field and keyword that contains syntactically valid optional parame-
-ters, but such implementations MAY ignore those parameters if they are
-present.  Parameter names beginning with "x-" are reserved for experi-
-ments and use among consenting parties.
-
-The "comment" syntactical construct can be used to indicate a reason why
-this message was auto-submitted.
-
-6. Security Considerations
-
-Automatic responders introduce the possibility for several kinds of
-attack, including:
-
--    Use of such responders to relay harmful or abusive content (worms,
-     viruses, spam, and spymail) for the purpose of wider distribution
-     of the content or masking the source of such content;
-
--    Use of such responders to mount denial-of-service attacks by using
-     responders to relay messages to large numbers of addresses, or to
-     flood individual mailboxes with a large amount of unwanted content,
-     or both;
-
--    Deliberate or accidental use of such responders to construct mail
-     loops or "sorcerer's apprentice syndrome", thus taxing the
-     resources of the mail transport system;
-
--    In addition, the responder itself may be subject to attack by
-     sending it large numbers of requests.
-
-
-
-
-
-Moore                  Automatic E-Mail Responses              [Page 11]
-Internet-Draft                                               5 June 2002
-
-
-This document attempts to reduce the vulnerability of responders to such
-attack, in particular by
-
--    Recommending that responders not relay significant content from the
-     subject message (thus minimizing the potential for abusive content)
-
--    Recommending that responders clearly mark responses with the "Auto-
-     Submitted: auto-replied" header field to distinguish them from
-     messages originated by humans (in part, to minimize the potential
-     for loops and denial-of-service attacks),
-
--    Recommending that Personal and Group Responders limit the number of
-     responses sent to any individual per period of time (also limiting
-     the potential damage caused by loops),
-
--    Recommending that responders respond to at most one address per
-     incoming message (to minimize the potential for deliberate or
-     accidental denial-of-service via "multiplication" or sorcerer's
-     apprentice syndrome),
-
--    Recommending that responses should be brief and in plain text
-     format (to minimize the potential for mail responders to be used as
-     mechanisms for transmitting harmful content and/or disguising the
-     source of harmful content).
-
-However, because email addresses are easily forged, attacks are still
-possible for any email responder which does not limit access and require
-authentication before issuing a response.  The above measures attempt to
-limit the damage which can be done, but they cannot entirely prevent
-attacks.
-
-This section describes vulnerabilities inherent in automatically
-responding to mail.  Other vulnerabilities are associated with some
-mail-based services which automatically respond to email messages, but
-these are not caused by the fact that the server automatically responds
-to incoming messages.  In general, all network based services (including
-those accessed by email) need to provide security that is sufficient to
-protect the resources that are accessible by the service against
-inappropriate use.
-
-7. IANA Considerations
-
-Section 5 of this document defines two new extension mechanisms - new
-keywords for the auto-submitted header field, and new optional
-parameters for the auto-submitted field.  If at any point in the future
-new keywords or paramters are approved (through an IETF Consensus
-process) it may be appropriate for IANA to create a registry of such
-keywords or paramters.
-
-
-
-Moore                  Automatic E-Mail Responses              [Page 12]
-Internet-Draft                                               5 June 2002
-
-
-8. Acknowledgments
-
-In the mid-1990s Jeroen Houttuin of TERENA authored a series of
-internet-drafts on "Behavior of Mail Based Servers", and in particular,
-one document on "Answering Servers" [7].  While these documents were (to
-this author's knowledge) never formally published, they provided the
-first well-reasoned argument (known to this author) as to the best way
-for such servers to interface with email systems and protocols.
-
-The idea for the auto-submitted field comes from the X.400/MHS mail
-system [8].  [9] defined an "Autosubmitted" field for use when
-gatewaying between X.400 and Internet mail.  Jacob Palme wrote an
-internet-draft [10] defining use of the "Auto-Submitted" field for
-Internet mail, which made it through Last Call without significant
-objections, but got stalled in an attempt to resolve non-substantial
-objections.  The definition of Auto-Submitted in this document is
-derived (i.e. slightly simplified) from the one in that document, with
-some text stolen outright.
-
-Thanks are also due to those who contributed suggestions to this
-document: (so far) Eric Hall, Florian Weimer, and Dan Wing.
-
-9. Author's Address
-
-Keith Moore
-Innovative Computing Laboratory
-University of Tennessee, Knoxville
-1122 Volunteer Blvd, #203
-Knoxville, TN 37996-3450
-
-moore@cs.utk.edu
-
-
-10. References
-
-[1]  Moore, K. Vaudreuil, G.  An Extensible Message Format for Delivery
-     Status Notifications.  RFC 1894, January 1996. (non-normative ref-
-     erence)
-
-[2]  Fajman, R.  An Extensible Message Format for Message Disposition
-     Notifications. RFC 2298, March 1998.  (non-normative reference)
-
-[3]  Bradner, S. Key words for use in RFCs to Indicate Requirement Lev-
-     els.  RFC 2119, March 1997.  (normative reference)
-
-[4]  Moore, K.  SMTP Service Extension for Delivery Status Notifica-
-     tions.  RFC 1891, January 1996.  (normative reference, but only
-     barely)
-
-
-
-Moore                  Automatic E-Mail Responses              [Page 13]
-Internet-Draft                                               5 June 2002
-
-
-[5]  Freed, N. Borenstein, N.  Multipurpose Internet Mail Extensions
-     (MIME) Part One: Format of Internet Message Bodies.  RFC 2045,
-     November 1996.  (normative reference)
-
-[6]  Narten, T., Alvestrand, H.  Guidelines for Writing an IANA Consid-
-     erations Section in RFCs.  RFC 2434, October 1998.  (normative ref-
-     erence)
-
-[7]  Houttuin, J. BoMBS series: Behavior of Mail Based Servers / Part 2:
-     A-BoMBS / Answering Servers.  Expired Internet-Draft draft-rare-
-     msg-a-bombs-01.txt, December 1994.  Available at http://google.com/
-     (non-normative reference, work apparently no longer in progress,
-     included only for attribution)
-
-[8]  X.400.  (perhaps someone can supply the correct reference for the
-     first version of the X.400 document to define autosubmitted?)
-     (non-normative reference)
-
-[9]  Kille, S.  MIXER (Mime Internet X.400 Enhanced Relay): Mapping
-     between X.400 and RFC 822/MIME.  RFC 2156, January 1998.  (non-nor-
-     mative reference)
-
-[10] Palme, J.  "The Auto-Submitted and Expires Headers in E-mail".
-     Expired Internet-Draft "draft-ietf-mailext-new-fields-15.txt",
-     February 1999. (non normative reference, work apparently no longer
-     in progress, included only for attribution)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore                  Automatic E-Mail Responses              [Page 14]
-
diff --git a/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-01.txt b/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-01.txt
deleted file mode 100644
index acda401d..00000000
--- a/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-01.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-
-This Internet-Draft has been deleted. Unrevised documents placed in the
-Internet-Drafts directories have a maximum life of six months. After
-that time, they are deleted. This Internet-Draft was not published as
-an RFC.
-
-Internet-Drafts are not an archival document series, and expired
-drafts, such as this one, are not available; please do not ask for
-copies... they are not available. The Secretariat does not have
-information as to future plans of the authors or working groups WRT the
-deleted Internet-Draft.
-
-For more information or a copy of the document, contact the author directly.
-
-Draft Author(s):
-
-M. Nakamura: motonori@econ.kyoto-u.ac.jp                                             
-J. Hagino: itojun@jilab.net                                                        
-
-
diff --git a/Documentation/en/I-D/draft-myers-smtp-auth-12.txt b/Documentation/en/I-D/draft-myers-smtp-auth-12.txt
deleted file mode 100644
index 044891e7..00000000
--- a/Documentation/en/I-D/draft-myers-smtp-auth-12.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-
-
-A new Request for Comments is now available in online RFC libraries.
-
-
-        RFC 2554: 
-
-        Title:	    SMTP Service Extension for Authentication
-	Author(s):  J. Myers
-        Status:     Proposed Standard
-	Date:       March 1999
-        Mailbox:    jgmyers@netscape.com
-	Pages:      11
-        Characters: 20534
-        Updates/Obsoletes/See Also: None  
-        I-D Tag:    draft-myers-smtp-auth-12.txt
-
-        URL:        ftp://ftp.isi.edu/in-notes/rfc2554.txt
-
-
-This document defines an SMTP service extension [ESMTP] whereby
-an SMTP client may indicate an authentication mechanism to the server,
-perform an authentication protocol exchange, and optionally negotiate
-a security layer for subsequent protocol interactions.  This extension
-is a profile of the Simple Authentication and Security Layer [SASL].
-
-This is now a Proposed Standard Protocol.
-
-This document specifies an Internet standards track protocol for
-the Internet community, and requests discussion and suggestions
-for improvements.  Please refer to the current edition of the
-"Internet Official Protocol Standards" (STD 1) for the
-standardization state and status of this protocol.  Distribution
-of this memo is unlimited.
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
-help: ways_to_get_rfcs.  For example:
-
-        To: rfc-info@RFC-EDITOR.ORG
-        Subject: getting rfcs
-
-        help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.echo 
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
-Authors, for further information.
-
-
-Joyce K. Reynolds and Alegre Ramos
-USC/Information Sciences Institute
-
diff --git a/Documentation/en/I-D/draft-newman-datetime-02.txt b/Documentation/en/I-D/draft-newman-datetime-02.txt
deleted file mode 100644
index f818256a..00000000
--- a/Documentation/en/I-D/draft-newman-datetime-02.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-C. Newman: chris.newman@innosoft.com                                               

-

-

diff --git a/Documentation/en/I-D/draft-palme-MHRegistry-00.txt b/Documentation/en/I-D/draft-palme-MHRegistry-00.txt
deleted file mode 100644
index 2bffb377..00000000
--- a/Documentation/en/I-D/draft-palme-MHRegistry-00.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-
-
-This Internet-Draft <draft-palme-MHRegistry-00.txt>
-has been replaced by another Internet-Draft 
-<draft-ietf-drums-MHRegistry-00.txt>
diff --git a/Documentation/en/I-D/draft-palme-autosub-03.txt b/Documentation/en/I-D/draft-palme-autosub-03.txt
deleted file mode 100644
index 4a49e80d..00000000
--- a/Documentation/en/I-D/draft-palme-autosub-03.txt
+++ /dev/null
@@ -1,151 +0,0 @@
-Network Working Group                           Jacob Palme
-Internet Draft                     Stockholm University/KTH
-<draft-palme-autosub-03.txt>                         Sweden
-Category-to-be: Experimental standard             July 1997
-Expires January 1998
-
-
-
-    Loop control for the Auto-Submitted e-mail header
-
-
-Status of this Memo
-
-This document is an Internet-Draft. Internet-Drafts are
-working documents of the Internet Engineering Task Force
-(IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-
-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of
-six months and may be updated, replaced, or obsoleted by
-other documents at any time. It is inappropriate to use
-Internet- Drafts as reference material or to cite them
-other than as ``work in progress.''
-
-To learn the current status of any Internet-Draft, please
-check the ``1id-abstracts.txt'' listing contained in the
-Internet- Drafts Shadow Directories on ftp.is.co.za
-(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
-Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
-West Coast).
-
-This memo provides information for the Internet community.
-This memo does not specify an Internet standard of any
-kind, since this document is mainly a compilation of
-information taken from other RFC-s.. Distribution of this
-memo is unlimited.
-
-
-Abstract
-
-This memo introduces certain advanced features for the
-Auto-Submitted e-mail header.
-
-
-Changes from the previous version of this IETF draft
-
-The specification of the Auto-Submitted header itself has
-been moved to draft-ietf-mailext-new-fields-08-txt.
-However, the controversial loop control feature has been
-removed from that document, and is instead specified here.
-The intention is that Auto-Submitted without loop control
-is to become a proposed standard, while the loop-control
-feature is to become an experimental standard.
-
-
-1.    Introduction
-
-This memo introduces loop control features for the Auto-
-Submitted header defined in [8].
-
-
-2.    New syntax for the Auto-Submitted header
-
-Syntax:
-
-     auto-submitted-field = "Auto-Submitted ":" auto-
-submitted
-
-     auto-submitted           = ( "no" / "auto-generated" /
-                                "auto-replied" /
-                                "inter-application" /
-                                "x-" <private-extension> /
-                                "<future-extension> )
-                                <optional-parameter-list>
-
-    <optional-parameter-list> = *( ";" <optional-parameter> )
-
-    <optional-parameter>      = "loopstep: <number> /
-                                <other-optional-parameter>
-
-     <number> =                 *DIGIT
-
-The added syntax as compared to [8] is the new value
-"inter-application" and the new parameter "loopstep:"
-followed by a positive number. These are used in the
-following ways:
-
-inter-application is used when it is known that both the
-sender and the recipient of this message is an automatic
-process.
-
-When an Auto-Submitted message is sent in response to
-another Auto-Submitted message, the value of loopstep is
-increased by 1. A message without any loopstep parameter
-is assumed to have "loopstep: 1". The value of loopstep
-can be used to stop loops by not producing automatic
-responses to messages if loopstep has a value above a
-certain limit. The size of this limit is application-
-dependent.
-
-
-3.    Security considerations
-
-This proposal raises no new security concerns, instead, it
-reduces the risk to security of certain kinds of loops.
-
-
-4.    Acknowledgments
-
-Keith Moore and Uzi Paz have influenced this document with
-valuable suggestions.
-
-
-5.    References
-
-[1]  D. Crocker: "Standard for the format of ARPA Internet text
-     messages." STD 11, RFC 822, August 1982.
-
-[2]  S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021
-     and RFC 822",  RFC 1327 May 1992.
-
-[3]  ISO/ITU: "Message Handling Systems", ISO
-international standard
-     10021, ITU  recommendation X.400.
-
-[4]  ISO/ITU: "Message Handling Systems, Part 7: Interpersonal
-     Messaging System, ISO international standard 10021-7, ITU
-     recommendation X.420.
-
-[5]  N. Borenstein, N. Freed: "MIME (Multipurpose Internet Mail
-     Extensions)", RFC 1521, September 1993.
-
-[6]  K. Moore, G. Vaudreuil, "An Extensible Message Format for
-     Delivery Status Notifications", RFC 1894, January
-1996.
-
-[7]  K. Moore, "SMTP Service Extension for Delivery Status
-     Notifications", RFC 1891, January 1996.
-
-[8]  J. Palme, "The Auto-Submitted, Supersedes and Expires E-mail
-     Headers. drafti-ietf-mailext-new-fields-08.txt. July 1997.
-
-
-6.    Author's address
-
-Jacob Palme                          Phone: +46-8-16 16 67
-Stockholm University/KTH             Fax: +46-8-783 08 29
-Electrum 230                         E-mail: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
diff --git a/Documentation/en/I-D/draft-palme-autosub-07.txt b/Documentation/en/I-D/draft-palme-autosub-07.txt
deleted file mode 100644
index 2cc38fc0..00000000
--- a/Documentation/en/I-D/draft-palme-autosub-07.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-J. Palme: jpalme@dsv.su.se                                                        

-

-

diff --git a/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt b/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
deleted file mode 100644
index 71075584..00000000
--- a/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
+++ /dev/null
@@ -1,1487 +0,0 @@
-Network Working Group                          Jacob Palme
-Internet Draft                                   Stockholm
-draft-palme-e-mail-translation-03.txt       University/KTH
-                                                     Sweden
-Category-to-be: Proposed standard      Date: December 2001
-                                         Expires: June 2001
-
-
-
-                   Support for Language Translation
-                        in E-Mail and Netnews
-
-                         Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time.  It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be
-accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 2001, 2002. All
-Rights Reserved.
-
-
-1.1  Abstract
-
-This memo specifies extensions to e-mail and netnews
-standards, to allow for the submission of translations of
-messages, not only at initial submission time, but also at
-later time, and made by other translators than the original
-author of the message. Three new e-mail/netnews header
-fields are proposed, "Content-Translation-Of, "Content-
-Translator" and "Translation-Request".
-
-
-1.2  Mailing list
-
-To write
-
-  Further discussion of this memo can take place in the
-mailing list
-  LANGTRANS@SU.SE.
-
-  Comments on less important details may also be sent to the
-editor,
-  Jacob Palme <jpalme@dsv.su.se>.
-
-To subscribe
-
-  To subscribe to this mailing list, send a message to
-  LISTSERV@SU.SE
-  which contains the text
-  SUB[SCRIBE] LANGTRANS <your name (not your email address)>
-
-To unsubscribe
-
-  To unsubscribe from this list, send a message to
-  LISTSERV@SU.SE
-  which contains the text
-  UNS[UBSCRIBE] LANGTRANS
-
-To access mailing list archives
-
-  The archives are available for browsing from
-  http://salut.nu/forum/uno/6/1/
-  Use the browsing command "All messages" to get everything
-written on a
-  single web page.
-
-
-Table of Contents
-     1.1 Abstract
-     1.2 Mailing list
-   Table of Contents
-2   Language Support in Existing Standards
-3   Multi-Language Scenario
-4   The Content-Translation-Of Header Field
-5   The Content-Translator Header Field
-6   USE of The Multipart/Choices MIME Content Type
-7   The Translation-Request Header
-8   Examples
-     8.1 Separate Original and Translated Messages
-     8.2 Sending a Message to a Translator for
-     Translation
-     8.3 Resending of the Message in 8.2 After
-     Translation
-9   For Further Study
-10  Security Considerations
-11  Copyright and Disclaimer
-12  Acknowledgments
-13  References
-14  Author's Address
-Appendix B: An Investigation of Handling of
-Multipart/Alternative in some Common Mailers in
-November 2000
-
-
-2    Language Support in Existing Standards
-
-The "Content-Language:" e-mail content header specified in
-RFC 1766 [6] can be used to specify one or a list of
-natural languages used in that message body.
-
-The "Content-Type: Multipart/alternative" defined in MIME
-[4] might be used to send the same text in more than one
-language. Each part would then be marked with the "Content-
-Language:" header to indicate its language, and the
-recipient might choose the body part according to his or
-her language preferences. The combination of
-Multipart/alternative with Content-Language is however not
-commonly supported and gives disastrous results with most
-mailers, so this solution is not recommended in this
-specification.
-
-In HTTP [7], a request operation can indicate a list of
-preferred languages, and the server can then deliver the
-resource in the preferred language. The request operation
-can also indicate how good each language is for a
-particular user, in the format:
-
-           Accept-Content-Language: da, en-gb;q=0.8,
-en;q=0.7
-
-HTTP also has facilities for the server to tell the client
-which alternatives are available in different languages,
-letting the client choose between them. It is also
-possible, with HTTP, to deliver a resource in the
-"Multipart/alternative" format, if the recipient wants to
-store the resource in all available language versions.
-These HTTP features are however not commonly supported
-(November 2000).
-
-All of these methods of transmitting information is based
-on the assumption that all language versions are ready and
-available when a message is sent.
-
-
-3    Multi-Language Scenario
-
-John Smith writes a message in English and submits it to a
-mailing list or to a Usenet newsgroup. The mailing list
-expander sends this message to an automatic translation
-agent which translates it into other languages and returns
-the translations to the mailing list expander. The mailing
-list expander might then either forward all translations to
-each member of the list, or forward to each member only the
-translation preferred by this member. Ernst D’rrenmatt has
-requested the mailing list to send him all language
-versions, but reads this message in English, because he has
-indicated that he prefers English original documents to
-automatic German translations. Hilda Schmidt reads the
-message in both English and German, decides that the
-automatic German translation is not very good, and cleans
-it up, submitting a new better translation to German. Ernst
-D’rrenmatt checks this translation, makes some corrections,
-and submits a final corrected version of the German
-translation of the original message.
-
-
-4    The Content-Translation-Of Header Field
-
-The "Content-Translation-Of" header field is used when
-submitting a translation to a message, which earlier has
-been sent in another language. The syntax for this header
-field is similar to the syntax for the "In-Reply-To"
-header, but only one value is allowed, since every
-translation can only be the translation of one previous
-message. The value contains the Message-ID of the original
-message or of a body part containing the original text
-before translation. If a message is available in
-more than one language, "Content-Translation-Of" should
-always reference the original message, even if the
-translation was actually based on a translated version. If
-the original message is available in more than one version,
-with "Supersedes" or "Replaces" references between the
-versions, then the "Content-Translation-Of" should
-reference the version which was the basis of this
-translation.
-
-Translation is applied to the body content, and to the
-content of the "Subject:" header, but not to any other
-header contents. When a "Subject:" is translated, the
-language code enclosed in parenthesis" can be added to the
-beginning of the "Subject". Example:
-
-Subject: (en) This is the English version
-
-If more than one translation is available of the same
-original message, the "Supersedes" or "Replaces" header
-field should not be used between them. "Supersedes" or
-"Replaces" are only to be used when the original message is
-revised.
-
-
-5    The Content-Translator Header Field
-
-The "Content-Translator" header field indicates who made
-the translation. When a translation is submitted, the
-"From" header field should still indicate the original
-author, but the "Content-Translator" header field should
-indicate who made the translation.
-
-The syntax of the "Content-Translator" header field is:
-
-Content-Translator   = "Content-Translator:"
-                        ( CFWS mailbox-list / Phrase )
-                        *(";" translator-parameter) CFWS
-                        CRLF
-
-translator-parameter = art / fluency / future-extension
-
-art                  = "Human" / "Machine" / "Original"
-
-fluency              = "Expert" / "Native" / "Other"
-
-The meaning of these parameters are:
-
-Human    = Translation was made or revised/approved by a human
-            translator.
-
-Machine  = Translation was entirely automatic, with no human
-            checking of the translation. In this case, the
-            "Auto-Submitted" [8] header should also be added
-            to the message heading.
-
-Original = This is the original before translation. Absence
-            of a "Content-Translator" also indicates that the
-            message is not translated, but
-            "Content-Translator: None;Original" can be
-            used to explicitly specify that this is not
-            translated.
-
-Expert   = Translation was made by an expert translator or
-            by an expert in the topic of the message, such as a
-            medical expert for a message on a medical topic.
-
-Native   = Translation was made by a native speaker of the
-            target language.
-
-
-Other    = Translation was made by someone who is not an
-            expert nor a native speaker of the target language.
-
-
-6    Use of The Multipart/Choices MIME Content Type
-
-When several translations of the same message are sent in
-the same message, the content-type multipart/choices, as
-defined in [9]. An alternative is to use
-mulitpart/alternative in the way described in Appendix A.4
-below.
-
-If translation is desired also of the "Subject" header,
-then the translated body parts have to be of content-type
-Message/rfc822, since only that content-type allows
-different subject in different body parts.
-
-It is recommended to add information about translation at
-the top of each body part (example, see section 8.3 below),
-because some mailers display multiple body parts in
-sequence inline with no indication of the Differences
-between them. This recommendation may be lifted at some
-future time when most mailers have support for
-Multipart/choices.
-
-It is also recommended to add a blank line at the end of
-each translation, since this will show up neater on some
-old mailers, which display all body parts in sequence to
-the recipient.
-
-
-7    The Translation-Request Header
-
-The Translation-Request header is used when sending a
-message for translation to a human or machine translator.
-Its value is a list of the languages to which translation
-is requested. The languages are specified according to [6].
-The language of the original can be included in the
-Translation-Request header, this tells the translator to
-include the original of the message when it is forwarded
-after translation, together with the translations to other
-languages.
-
-When the Translation-Request header is used, the content-
-type should always be "Message/rfc822" [5] and the content
-should be the message to be translated. When the
-translation is ready, the translator is instructed to send
-the translation to the recipients in the "To:", "Cc:" and
-"Bcc:" headers and to leave non-translated headers of the
-message/rfc822 body as they were before the translation.
-When the translator resends the translation, Resent-From"
-is added with the name of the translator, and "Resent-Date"
-with the date of the translation. If translation to
-multiple languages is requested, the result is sent using
-the content-type multipart/choices.
-
-Syntax: "Translation-Request:" CFWS language 1*(, CFWS
-         language) CFWS CRLF
-
-
-8    Examples
-
-8.1  Separate Original and Translated Messages
-
-     Message-ID: A@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Content-Translator: None; Original
-     Content-Language: en
-
-     Message-ID: B@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Content-Translation-Of: A
-     Content-Translator: Erika Ernst <eernst@foo.bar.de>;
-     human; native
-     Content-Language: de
-
-     Message-ID: C@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Content-Translation-Of: A
-     Content-Translator: Tomas D’rrenmatt
-     <tdurrenmatt@foo.bar.de>;
-                          expert
-     Content-Language: de
-
-     Message-ID: D@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Content-Language: en
-     Supersedes: A
-
-     Message-ID: E@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Content-Translation-Of: D
-     Content-Translator: Supertrans Translation Engine
-                         <supertrans@foo.bar>; machine
-     Auto-Submitted: Auto-generated
-     Content-Language: de
-     Supersedes: A
-
-
-8.2  Sending a Message to a Translator for Translation
-
-     Message-ID: Z@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     Translation-Request: en, fr, de
-     Content-Type: Message/rfc822
-
-     Message-ID: Z-en@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Content-Translator: None; Original
-     Content-Language: en
-     Subject: Orchids
-
-     Orchids are beautiful.
-
-
-8.3  Resending of the Message in 8.2 After Translation
-
-     Resent-From: Supertrans Translation Engine
-     <supertrans@foo.bar>
-     Message-ID: Z@supertrans.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     Content-Type: Multipart/choices; boundary="boundary 1"
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Subject: (en) Orchids
-
-     --boundary 1
-     Message-ID: Z-@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     Translation-Request: en, fr, de
-     Content-Type: Message/rfc822
-
-     Message-ID: Z-en@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Content-Translator: None; Original
-     Content-Language: en
-     Subject: (en) Orchids
-
-     Original English Text
-     ---------------------
-
-     Orchids are beautiful.
-
-     --boundary 1
-     Content-Type: Message/rfc822
-
-     Message-ID: Z-de@supertrans.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     Content-Translation-Of: A
-     Content-Translator: Supertrans Translation
-                         Engine <supertrans@foo.bar>;
-     machine
-     Content-Language: de
-     Subject: (de) Orchideen
-
-     Deutsche ›bersetzung
-     --------------------
-
-     Orchideen sind sch÷n.
-
-     --boundary 1
-     Content-Type: Message/rfc822
-
-     Message-ID: Z-fr@supertrans.bar.net
-     Content-Translation-Of: A
-     Content-Translator: Supertrans Translation Engine
-                         <supertrans@foo.bar>; machine
-     Content-Language: fr
-     Subject: (fr) Orchid‰e
-
-     Traduction fran‡ais
-     -------------------
-
-     Orchid‰e sont beau.
-
-     --boundary 1--
-
-
-9    For Further Study
-
-The following is not yet resolved in this draft:
-
--  How a user can register its language preferences with a
-     mail server or a mailing list expander.
-
--  Whether POP/IMAP should be extended with commands to
-    request messages in only a certain language.
-
--  How to handle translation in Usenet News. One might for
-    example have a set of co-ordinated newsgroups, with the
-    same articles in different languages. A newsgroup
-    "alt.cultures.multiple" might be provided with English
-    in "alt.cultures.multiple.en", German in
-    "alt.cultures.multiple.de", etc., with automatic or
-    manual translation of the messages between these
-    newsgroups.
-
--  Handling of signatures and seals.
-
-
-10   Security Considerations
-
-Translations made by other people than the original
-author of a message will of course entail the risk
-of intentional or unintentional incorrectness of
-the translation. But this is a risk we must accept
-if we want to have translations, and if everyone is
-not fluent in every language.
-
-Some people claim that machine translation
-technology is so bad, that it should not be used at
-all. However, machine translation will often give a
-good understanding of the intent of the original
-text even if the translation is not perfect. And if
-the recipient has a choice of either not
-understanding a message at all, or getting a
-machine translation, the recipient may still prefer
-the automatic translation. Based on this, the
-recipient might decide whether the message is of
-enough interest to be willing to pay for a human to
-make a better translation.
-
-The risk can be reduced, if the receiving user
-agent clearly shows that a message is a translator,
-who made the translation, and allows the user to
-check the original text and compare it with the
-translation.
-
-A translation will invalidate any digital
-signatures or seals, but the translator might add
-its own signature and seals to ensure that the
-translation is not corrupted when sent from
-translator to readers. These signatures and seals
-will not promise any correspondence with the
-original text, except the promise which a
-translator might give of the correctness of its
-translations.
-
-
-11   Copyright and Disclaimer
-
-The IETF takes no position regarding the validity
-or scope of any intellectual property 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;
-neither does it represent that it has made any
-effort to identify any such rights. Information on
-the IETF's procedures with respect to rights in
-standards-track and standards-related documentation
-can be found in BCP-11. Copies of claims of rights
-made available for publication 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 implementors or users of this specification can
-be obtained from the IETF Secretariat."
-
-The IETF invites any interested party to bring to
-its attention any copyrights, patents or patent
-applications, or other proprietary rights which may
-cover technology that may be required to practice
-this standard. Please address the information to
-the IETF Executive Director.
-
-Copyright (C) The Internet Society (2000). 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.
-
-
-12   Acknowledgments
-
-Suggestions during the development of this memo has been
-given by Harald Alvestrand, Bill Jansson, Larry Masinter,
-Keith Moore and Henry Spencer.
-
-13   References
-
-Ref.   Author, title                            IETF
-                                                 status
-----   -------------------------------------    --------
-
-[1]    J. Klensin: "Simple Mail Transfer        Proposed
-        Protocol", RFC 2821, April 2001.         Standard
-
-[2]    P. Resnick: "Internet Message Format"    Proposed
-        STD 11, RFC 2822, April 2001.            Standard
-
-[3]    M.R. Horton, R. Adams: "Standard for     Not an
-        interchange of USENET messages", RFC     official
-        1036, December 1987.                     IETF
-                                                 standard,
-                                                 but in
-                                                 reality a
-                                                 de-facto
-                                                 standard
-                                                 for Usenet
-                                                 News
-
-[4]    N. Freed & N. Borenstein:                Draft
-        "Multipurpose Internet Mail              Standard,
-        Extensions (MIME) Part One: Format of    elective
-        Internet Message Bodies." RFC 2045.
-        November 1996.
-
-[5]    N. Freed & N. Borenstein:                Draft
-        "Multipurpose Internet Mail              Standard,
-        Extensions (MIME) Part Two: Media        elective
-        Types." RFC 2046. November 1996.
-
-[6]    H. Alvestrand: "Tags for the             Proposed
-        Identification of Languages", RFC        standard,
-        1766, February 1995.                     elective
-
-[7]    R. Fielding, J. Gettys, J. Mogul, H.     Draft
-        Frystyk, T. Berners-Lee: Hypertext       standard
-        Transfer Protocol -- HTTP/1.1, RFC
-        2616, June 1999.
-
-[8]    J. Palme: The Auto-Submitted,            Work in
-        Supersedes and Expires Headers in        progress
-        E-mail and Netnews, draft-ietf-
-        mailext-new-fields-14.txt, November
-        1998.
-
-[9]    J. Palme: The multipart/choices          Work in
-        Content-Type. draft-palme-multipart-     progress
-        choices-00.txt, December 2000.
-
-[10]   R. Troost, S. Dorner, K. Moore:          Proposed
-        Communicating Presentation               standard
-        Information in Internet Messages: the
-        Content-Disposition Header field, RFC
-        2183, August 1997.
-
-
-14   Author's Address
-
-Jacob Palme                Phone: +46-8-16 16 67
-Stockholm University/KTH   Fax: +46-8-783 08 29
-Skeppargatan 73            E-mail: jpalme@dsv.su.se
-S-115 30 Stockholm,
-Sweden
-
-
-Appendix A: A Discussion of Alternative Ways of Handling
-Translation in E-Mail
-
-
-A.1 Use Multipart/alternative
-
-The most natural solution might be to send a message in
-multiple languages as a multipart/alternative, with each
-body part in a different language.
-
-However, this solution downgrades disastrously bad with
-many existing mail clients, as is shown in Appendix B. Most
-existing mail clients will either show only the first or
-only the last body part in such a multipart/alternative.
-Thus, users will not have the option of getting the message
-in their preferred language, they will instead get the
-message in a language which they might not understand.
-
-
-A.2 Use Multipart/mixed
-
-Another solution would be to use multipart/mixed, and with
-a Content-Disposition file-name containing the language.
-Most mailers will then show the message as a list of
-attachments, listing their file names. The recipients can
-then click on the name of the attachment which contains
-their preferred languages.
-
-The disadvantage with this solution is that it does not
-support future mailers which really do support multiple
-languages and can select the language part according to the
-user's preferences.
-
-
-A.3 Use multipart/choices
-
-A third solution would be to use a new Content-Type
-"multipart/choices". Since the MIME standard says that a
-mailer should handle "multipart/xxx" where "xxx" is an
-unkown subtype, as multipart/mixed. So this solution has
-all the advantages but not the disadvantage of using
-multipart/mixed. If multipart/choices becomes a standard,
-mailers of the future can support it better than
-multipart/mixed.
-
-
-A.4 Use multipart/alternative with additional first
-     and last body part.
-
-A fourth solution would be to send the message as a
-multipart/alternative with the following contents:
-
-First body part: A plain text version of all the
-translations after each other.
-
-Last body part: A HTML version with all the translations
-after each other, and with a list of languages at the top.
-The user seeing this part can just click on one of the
-languages to get this message in that language.
-
-All the other body parts, between the first and the last,
-contains the text in each of the available languages.
-
-The advantage with this is that it will downgrade well with
-existing mailers, they will show either the first or the
-last part, which both contains the text in all the
-languages.
-
-At the same time, a mailer which understands the combinaton
-of multipart/alternative with Content-Language can let the
-user select a language or automatically select language
-based on user preferences.
-
-A third advantage is that no new subtype to Multipart have
-to be defined.
-
-The disadvantage is that the message will be longer, each
-translation is repeated three times, in the first body
-part, in one of the middle body part and in the last body
-part.
-
-
-Appendix B: An Investigation of Handling of
-Multipart/Alternative in some Common Mailers in November
-2000 and November 2001
-
-As a basis for possible work on developing standards for
-language-translation in e-mail, I tested how some common
-mailers handled multipart/alternative with different
-Content-Language in the body parts in November 2000. The
-tests on the Windows Explorer 5.0 were done in November
-2001.
-
-I used the following test messages:
-
-Test message 1: First part English, second part German
-
-Test message 2: Same as test message 1, but first part
-German, second part English
-
-Test message 3: Same as test message 2, but multipart/mixed
-instead of multipart/alternative.
-
-Test message 4: Same as test message 3, but with Content-
-Disposition: Attachment on all but the first body part.
-
-Test message 5: Multipart/mixed on an outer level, with the
-first part a directory of attachments, and the second part
-a multipart/alternative with the German and English parts
-as the two alternatives.
-
-Test message 6: Multipart/alternative with the first part
-containing all the translations in one body part, and the
-second part a multipart/alternative with one translation in
-each alternative.
-
-I tested this with the following mailers:
-Eudora 5 Macintosh, Pine 4.21 on Unix, Netscape 4.7
-Macintosh, Outlook Express 5 Macintosh, First Class 5.611
-Macintosh, KOM 2000 (our own system), and Hotmail.
-
-Result: None of the mailers seemed to test on the Content-
-Language value, and make a selection based on this.
-
-Eudora, Outlook Express, KOM 2000 and Hotmail only showed
-the first body part. Netscape only showed the second body
-part. Pine only showed the second body part, but provided a
-user command to see also the first body part. First Class
-displayed both body parts in sequence, i.e. i treated
-multipart/alternative as identical to multipart/mixed.
-
-The conclusion of this is that if IETF makes a standard,
-specifying that different translations of the same message
-should be sent with multipart/alternative with different
-Content-Language on the different body parts, then most
-mailers will not show a user the version in the preferred
-language of that user.
-
-Since backwards compatibility with existing mailers is very
-important, this seems to indicate that an IETF standard for
-handling of language translation in e-mail has to use some
-other format than multipart/alternative to indicate
-translations.
-
-I also tested some more complex messages. In test message
-4, I used multipart/mixed with three body parts, the first
-a list of the rest of the body parts, which contained the
-message in different languages. This format was not ideal
-either with the existing mailers. Most of them showed all
-three body parts in sequence inline (even though all except
-the first were marked as Content-Disposition: Attachment)
-and some of them without any visible marker between the
-body parts.
-
-In test message 5, on the top level is a multipart/mixed
-with two body parts, the first a list of the body parts,
-the second a multipart/alternative with the different
-language parts. This had the same problem as all the other
-multipart/alternative test examples: Many of the mailers
-arbitrarily chooses one of the multipart/alternatives and
-only shows this, some mailers choose the first alternative,
-some the second.
-
-In test message 6, I had on the top level a
-multipart/alternative where the first body part was a
-text/plain with all the language versions in one text. The
-second body part was another multipart/alternative with the
-different language parts as body parts. A mailer which
-cannot discriminate between languages, should for this
-message only display body part 1. Only Outlook Express and
-KOM 2000 did this. Pine, Netscape and Hotmail arbitrarily
-showed only one language version.
-
-In test message 7, I tested the format proposed in this
-ietf-draft, as shown in section 8.3 above.
-
-Test message 8 uses a first body part with all language
-versions in plain text, a last body part with all language
-versions in HTML, and in-between separate body parts for
-each translation. This seems to work very well with
-existing mailers.
-
-
-Test message 1:
----------------
-
-      Message-ID: <language-test-1@dsv.su.se>
-      Date: Wed, 21 Nov 2001 09:55:00 +0100
-      From: Jacob Palme <jpalme@dsv.su.se>
-      MIME-Version: 1.0
-      To: jpalme@dsv.su.se, jptest@dsv.su.se
-      Subject: Language test message no. 1 v1
-      Content-Type: multipart/alternative;
-      boundary="==boundary-2"
-
-      Text displayed only to non-MIME-compliant mailers
-
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: en
-
-      Message in English.
-
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: de
-
-      Nachricht auf deutsch.
-      --==boundary-2--
-
-
-Test message 2:
----------------
-
-      Message-ID: <language-test-2@dsv.su.se>
-      Date: Wed, 21 Nov 2001 09:55:00 +0100
-      From: Jacob Palme <jpalme@dsv.su.se>
-      MIME-Version: 1.0
-      To: jpalme@dsv.su.se, jptest@dsv.su.se
-      Subject: Language test message no. 2
-      Content-Type: multipart/alternative;
-      boundary="==boundary-2"
-
-      Text displayed only to non-MIME-compliant mailers
-
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: de
-
-      Nachricht auf deutsch.
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: en
-
-      Message in English.
-      --==boundary-2--
-
-
-Test message 3:
----------------
-
-      Message-ID: <language-test-3@dsv.su.se>
-      Date: Wed, 21 Nov 2001 09:55:00 +0100
-      From: Jacob Palme <jpalme@dsv.su.se>
-      MIME-Version: 1.0
-      To: jpalme@dsv.su.se,jptest@dsv.su.se
-      Subject: Language test message no. 3
-      Content-Type: multipart/mixed; boundary="==boundary-2"
-
-      Text displayed only to non-MIME-compliant mailers
-
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: de
-
-      Nachricht auf deutsch.
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: en
-
-      Message in English.
-      --==boundary-2--
-
-
-Test message 4:
----------------
-
-      Message-ID: <language-test-4@dsv.su.se>
-      Date: Wed, 21 Nov 2001 09:55:00 +0100
-      From: Jacob Palme <jpalme@dsv.su.se>
-      MIME-Version: 1.0
-      To: jpalme@dsv.su.se,jptest@dsv.su.se
-      Subject: Language test message no. 4
-      Content-Type: multipart/mixed; boundary="==boundary-2"
-
-      Text displayed only to non-MIME-compliant mailers
-
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-
-      Attachment 1: Deutsch
-      Attachment 2: English
-
-      Nachricht auf deutsch.
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Disposition: Attachment
-      Content-Language: de
-
-      Nachricht auf deutsch.
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Disposition: Attachment
-      Content-Language: en
-
-      Message in English.
-      --==boundary-2--
-
-
-Test message 4b:
----------------
-
-      Message-ID: <language-test-4@dsv.su.se>
-      Date: Wed, 21 Nov 2001 09:55:00 +0100
-      From: Jacob Palme <jpalme@dsv.su.se>
-      MIME-Version: 1.0
-      To: jpalme@dsv.su.se,jptest@dsv.su.se
-      Subject: Language test message no. 4
-      Content-Type: multipart/mixed; boundary="==boundary-2"
-
-      Text displayed only to non-MIME-compliant mailers
-
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-
-      Attachment 1: Deutsch
-      Attachment 2: English
-
-      Nachricht auf deutsch.
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Disposition: Attachment
-      Content-Language: en
-
-      Message in English.
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Disposition: Attachment
-      Content-Language: de
-
-      Nachricht auf deutsch.
-      --==boundary-2--
-
-Test message 5:
----------------
-
-      Message-ID: <language-test-5@dsv.su.se>
-      Date: Mon, 13 Nov 2000 12:12:00 +0100
-      From: Jacob Palme <jpalme@dsv.su.se>
-      MIME-Version: 1.0
-      To: jpalme@dsv.su.se,jptest@dsv.su.se
-      Subject: Language test message no. 5 v1
-      Content-Type: multipart/mixed; boundary="==boundary-2"
-
-      Text displayed only to non-MIME-compliant mailers
-
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-
-      Attachment 1: Deutsch
-      Attachment 2: English
-
-      --==boundary-2
-      Content-Type: Multipart/alternative; boundary="==boundary-
-      1"
-
-      --==boundary-1
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: de
-
-      Nachricht auf deutsch.
-      --==boundary-1
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: en
-
-      Message in English.
-      --==boundary-1--
-      --==boundary-2--
-
-
-Test message 6:
----------------
-
-      Message-ID: <language-test-6@dsv.su.se>
-      Date: Wed, 21 Nov 2001 09:55:00 +0100
-      From: Jacob Palme <jpalme@dsv.su.se>
-      MIME-Version: 1.0
-      To: jpalme@dsv.su.se,jptest@dsv.su.se
-      Subject: Language test message no. 6 v1
-      Content-Type: multipart/alternative;
-      boundary="==boundary-1"
-
-      Text displayed only to non-MIME-compliant mailers
-
-      --==boundary-1
-      Content-Type: text/plain; charset=iso-8859-1
-
-      **** This message in English ***
-
-      Message in English.
-
-      **** Diese Nachricht auf deutsch
-
-      Nachricht auf deutsch.
-      --==boundary-1
-      Content-Type: multipart/alternative;
-      boundary="==boundary-2"
-
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: en
-
-      Message in English.
-
-      --==boundary-2
-      Content-Type: text/plain; charset=iso-8859-1
-      Content-Transfer-Encoding: 8bit
-      Content-Language: de
-
-      Nachricht auf deutsch.
-      --==boundary-2--
-      --==boundary-1--
-
-Test message 7:
---------------
-
-Same as in section 8.3 above.
-
-Test message 8:
---------------
-
-     From: Jacob Palme <jpalme@dsv.su.se>
-     Content-Type: Multipart/alternative; boundary="boundary
-     1"
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Subject: Test message 8
-
-     --boundary 1
-
-     Message-ID: Z-en@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Content-Translator: None; Original
-     Content-Language: en
-     Subject: (en) Orchids
-
-     --boundary 1
-     Content-Type: text/plain; charset=iso-8859-1
-     Content-Language: en, de, fr
-
-     This message will be shown in English, German and
-     French
-
-     **** This message in English ***
-
-     Orchids are beautiful.
-
-     **** Traduction fran‡ais ***
-
-     Orchids sind sch÷n.
-
-     *** This message in French ***
-
-     Orchid‰e sont beau.
-     --boundary 1
-     Content-Type: text/plain
-     Content-Language: fr
-
-     Orchid‰e sont beau.
-     --boundary 1
-     Content-Type: text/plain
-     Content-Language: en
-
-     Orchids are beautiful.
-
-     --boundary 1
-     Content-Type: text/plain
-     Content-Language: de
-
-     Orchids sind sch÷n.
-
-     --boundary 1
-     Content-Type: text/html
-     Content-Language: en, fr, de
-
-     <p>This message will be shown in <a
-     href="#en">English</a>,
-     <a href="#de">German</a>   and <a
-     href="#fr">French</a></p>
-     <p><a name="en"></a>**** This message in English ***
-     </p>
-     <p> Orchids are beautiful.
-     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
-     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
-     <p> <a name="fr"></a>**** Traduction fran&ccedil;ais
-     ***
-     <p> Orchid&eacute;e sont beau.
-     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
-     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
-     p> <a name="de"></a>*** Deutsche &Uuml;bersetzung: ***
-     <p> Orchids sind sch&ouml;n.
-     --boundary 1--
-
-Test message 8:
---------------
-
-     From: Jacob Palme <jpalme@dsv.su.se>
-     Content-Type: Multipart/alternative; boundary="boundary
-     1"
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Subject: Test message 8
-
-     --boundary 1
-
-     Message-ID: Z-en@foo.bar.net
-     From: John Smith <jsmit@foo.bar.net>
-     To: Tropical Flowers Mailing List
-     <tropflow@foo.bar.net>
-     Content-Translator: None; Original
-     Content-Language: en
-     Subject: (en) Orchids
-
-     --boundary 1
-     Content-Type: text/plain; charset=iso-8859-1
-     Content-Language: en, de, fr
-
-     This message will be shown in English, German and
-     French
-
-     **** This message in English ***
-
-     Orchids are beautiful.
-
-     **** Traduction fran‡ais ***
-
-     Orchid‰e sont beau.
-
-     *** Deutsche ’bersetzung: ***
-
-     Orchids sind sch÷n.
-
-     --boundary 1
-     Content-Type: message/rfc822
-     Subject: Traduction fran‡ais
-     Content-Language: fr
-
-     Content-Type: text/plain
-     Content-Language: fr
-
-     Orchid‰e sont beau.
-     --boundary 1
-     Content-Type: message/rfc822
-     Subject: This message in English
-     Content-Language: en
-
-     Content-Type: text/plain
-     Content-Language: en
-
-     Orchids are beautiful.
-
-     --boundary 1
-     Content-Type: message/rfc822
-     Subject: Deutsche =?iso-8859-1?Q?=FCbersetzung=3A?=
-     Content-Transfer-Encoding: 8bit
-     Content-Language: de
-
-     Content-Type: text/plain
-     Content-Language: de
-
-     Orchids sind sch÷n.
-
-     --boundary 1
-     Content-Type: text/html
-     Content-Language: en, fr, de
-
-     <p>This message will be shown in <a
-     href="#en">English</a>,
-     <a href="#de">German</a>   and <a
-     href="#fr">French</a></p>
-     <p><a name="en"></a>**** This message in English ***
-     </p>
-     <p> Orchids are beautiful.
-     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
-     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
-     <p> <a name="fr"></a>**** Traduction fran&ccedil;ais
-     ***
-     <p> Orchid&eacute;e sont beau.
-     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
-     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
-     p> <a name="de"></a>*** Deutsche &Uuml;bersetzung: ***
-     <p> Orchids sind sch&ouml;n.
-     --boundary 1--
-
-
-Mailer       Test message 1&2    Test message 3
-------       -----------------   ---------------
-
-Eudora 5     Only displayed the  Both shown in
-Macintosh    first alternative,  sequence, Content-
-version      did not even        headers shown, but
-              indicate that       not Content-
-              there was any       Language! No
-              other alternative.  indication that
-                                  the different
-                                  language of the
-                                  two body parts.
-
-Pine 4.21 on Only the second     Both versions are
-a Unix       alternative is      listed in sequence
-platform     shown directly,     with a divider
-              but the user can    indication in-
-              ask to see the      between, no
-              first alternative   indication that
-              with the VIEW       the different
-              command. Nothing    language of the
-              is said to          two body parts.
-              indicate that the
-              two alternatives
-              contain the same
-              text in two
-              languages.
-
-Netscape 4.7 Only the second     Both versions are
-on a         alternative is      listed in sequence
-Macintosh    shown, did not      with a horizontal
-              even indicate that  rule in-between,
-              there was any       no indication that
-              other alternative.  the different
-                                  language of the
-                                  two body parts.
-
-Outlook      Only displayed the  Both shown in
-Express 5,   first alternative,  sequence, on the
-Macintosh    did not even        Macintosh no
-and Windows  indicate that       divider and no
-98 edition   there was any       indication that
-              other alternative.  the different
-                                  language of the
-                                  two body parts, in
-                                  Windows a
-                                  horizontal divider
-                                  line between the
-                                  two parts.
-
-First Class  Both versions are   Both versions are
-5.611,       listed in sequence  listed in sequence
-Macintosh    with no divider in- with no divider in-
-client       between, no         between, no
-              indication that     indication that
-              the different       the different
-              language of the     language of the
-              two body parts.     two body parts.
-
-KOM 2000     Only displayed the  Both versions are
-              first alternative,  listed in sequence
-              did not even        with a blank line
-              indicate that       in-between, no
-              there was any       indication that
-              other alternative.  the different
-                                  language of the
-                                  two body parts.
-
-Hotmail      Only displayed the  Both shown in
-              first alternative,  sequence, blank
-              did not even        line in-between.
-              indicate that
-              there was any
-              other alternative.
-
-
-Mailer       Test message 4      Test message 5
-------       ---------------     ---------------
-
-Eudora 5     All three body      First and second
-Macintosh    parts in sequence.  body part shown
-version                          inline.
-
-Pine 4.21 on First message       First message
-a Unix       shown inline, the   shown inline, the
-platform     rest available by   rest available by
-              commands to         commands to
-              retrieve            retrieve
-              attachments.        attachments.
-
-Netscape 4.7 All three body      Only first and
-on a         parts in sequence   third body part
-Macintosh    with a horizontal   shown in sequence
-              rule in-between.    with two
-                                  horizontal rules
-                                  in-between.
-
-Outlook      All three body      First and third
-Express 5,   parts in sequence   body parts in
-Macintosh    on the Macintosh.   sequence.
-and Windows  In Windows, only
-edition      first and third
-              body part shown in
-              sequence.
-              Reordering the
-              second and third
-              body parts with
-              the German version
-              last gave the same
-              result: first and
-              third (German)
-              part shown only.
-
-First Class  All three body
-5.611,       parts listed in
-Macintosh    sequence.
-client
-
-KOM 2000     All three body      First and third
-              parts in sequence,  body part in
-              horizontal rule in  sequence,
-              between.            horizontal rule in
-                                  between.
-
-Hotmail      All three body      First and third
-              parts in sequence.  body part in
-                                  sequence.
-
-
-Mailer       Test message 6      Test message 7
-------       --------------      --------------
-
-Eudora 5     The first and the   All translations
-Macintosh    second, but not     inline in sequence
-version      the third body      with all headers,
-              part is shown.      including
-                                  translation-
-                                  headers shown on
-                                  each body part.
-
-Pine 4.21 on Last body part      All translations
-a Unix       (the German         listed as
-platform     variant) shown      attachments.
-              inline, the other
-              body parts
-              available as
-              attachments.
-
-Netscape 4.7 Only the last body  All translations
-on a         part (the German    inline with some
-Macintosh    variant shown,      headers shown on
-              nothing indicates   each body parts.
-              to the reader that
-              anything more is
-              available.)
-
-Outlook      Only the first      All translations
-Express 5,   body part shown,    inline with some
-Macintosh    with both language  headers shown on
-and Windows  text within a       each body parts on
-version      single body part    the Macintosh. On
-              on the Macintosh!   Windows,
-              In Windows, only
-              the second body
-              part is shown.
-
-First Class                      All translations
-5.611,                           inline in sequence
-Macintosh                        with all headers,
-client                           including
-                                  translation-
-                                  headers shown on
-                                  each body part.
-
-KOM 2000     Only the first      All translations
-              body part is        inline with some
-              shown, containing   headers shown on
-              both language       each body parts.
-              versions in one
-              body part.
-
-Hotmail      Only the second     All translations
-              body part is        inline with some
-              shown, no           headers shown on
-              indication that     each body parts.
-              any more text is
-              available.
-
-Mailer       Test message 8
-------       --------------
-
-Eudora 5     Only last part
-Macintosh    shown, user has to
-version      manually scroll
-              down to his
-              preferred
-              language, clicking
-              on the languages
-              in the first line
-              does not work.
-
-              Note: User can use
-              the Eudora-command
-              "Open in Browser"
-              and then clicking
-              on the language
-              links will work!
-
-Pine 4.40 on Last body part
-a Unix       shown in-line with
-platform     simulated clicking
-              to view each
-              language. The
-              other body parts
-              shown as
-              attachments.
-
-Netscape 4.7 Last body part
-on Windows   shown, clicking on
-98           links will get the
-              readers to the
-              language they
-              prefer.
-
-Outlook      Last body part
-Express 5,   shown, clicking on
-Macintosh    links will get the
-and Windows  readers to the
-version      language they
-              prefer.
-
-First Class  Only the first
-5.611,       body part is
-Macintosh    shown.
-client
-
-KOM 2000     Last body part
-              only shown,
-              clicking on links
-              to select language
-              works.
-
-Hotmail      Last body part
-              only shown,
-              clicking on links
-              to select language
-              works.
diff --git a/Documentation/en/I-D/draft-palme-int-print-04.txt b/Documentation/en/I-D/draft-palme-int-print-04.txt
deleted file mode 100644
index 6b65e556..00000000
--- a/Documentation/en/I-D/draft-palme-int-print-04.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-
-
-A new Request for Comments is now available in online RFC libraries.
-
-
-        RFC 2346:
-
-        Title:      Making Postscript and PDF International
-	Author(s):  J. Palme
-	Status:     Informational
-	Date:       May 1998
-        Mailbox:    jpalme@dsv.su.se
-   	Pages:      6
-        Characters: 12382
-        Updates/Obsoletes: None
-
-	
-        URL:        ftp://ftp.isi.edu/in-notes/rfc2346.txt
-
-Certain text formats, for example Postscript (MIME-Type:
-application/postscript; file extension .ps) and Portable Document
-Format (MIME-Type: application/pdf; file extension .pdf) specify
-exactly the page layout of the printed document. The commonly used
-paper format is different in North America and the rest of the world.
-North America uses the \'Letter' format, while the rest of the world
-mostly uses the ISO-standard \'A4' format. This means that documents
-formatted on one continent may not be easily printable on another
-continent. This memo gives advice on how to produce documents which
-are equally well printable with the Letter and the A4 formats. By
-using the advice in this document, you can put up a document on the
-Internet, which recipients can print without problem both in and
-outside North America.
-
-This memo provides information for the Internet community.  It does
-not specify an Internet standard of any kind.  Distribution of this
-memo is unlimited.
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@ISI.EDU.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@ISI.EDU with the message body 
-help: ways_to_get_rfcs.  For example:
-
-        To: rfc-info@ISI.EDU
-        Subject: getting rfcs
-
-        help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to RFC-Manager@ISI.EDU.  Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.
-
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@ISI.EDU.  Please consult RFC 2223, Instructions to RFC
-Authors, for further information.
-
-
-Joyce K. Reynolds and Alegre Ramos
-USC/Information Sciences Institute
diff --git a/Documentation/en/I-D/draft-palme-mailext-headers-06.txt b/Documentation/en/I-D/draft-palme-mailext-headers-06.txt
deleted file mode 100644
index d8862390..00000000
--- a/Documentation/en/I-D/draft-palme-mailext-headers-06.txt
+++ /dev/null
@@ -1,2078 +0,0 @@
-Network Working Group                          Jacob Palme
-Internet Draft                                   Stockholm
-draft-palme-mailext-headers-06.txt          University/KTH
-Category: Informational                             Sweden
-Revision of: RFC 2076                  Date: November 2001
-                                        Expires: April 2002
-
-
-
-                   Common Internet Message Header Fields
-
-                         Status of this Memo
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time.  It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 2001. All Rights Reserved.
-
-
-                             Abstract
-
-This memo contains tables of commonly occurring header
-fields in headings of e-mail messages. The document
-compiles information from other RFCs such as RFC 822, RFC
-1036, RFC 1123, RFC 2156, RFC 1496, RFC 1766, RFC 2183, RFC
-1864, RFC 2421 and RFC 2045. A few commonly occurring
-header fields which are not defined in RFCs are also
-included. For each header field, the memo gives a short
-description and a reference to the RFC in which the header
-field is defined.
-
-The latest, revised version of this document can be found
-at URL
-http://www.dsv.su.se/jpalme/ietf/mail-headers/.
-The version at that URL may be more recent than the version
-published as an RFC.
-
-Another list of headers can be found at URL
-http://www.hut.fi/~jkorpela/headers.html [28]
-
-
-                   Changes since previous version
-
-This document is a revision of RFC 2076. The following new
-header fields, not included in RFC 2076, have been added:
-Abuse-Reports-To:, Also-Control, Approved-By, Content-
-Alias, Content-Alternative, Content-Class, Content-
-Conversion, Content-Features, Content-ID, Delivered-To,
-Disposition-Notification-Options, Disposition-Notification-
-To, Expiry-Date, For-Approval, List-Archive, List-Digest,
-List-Help, List-ID, List-Owner, List-Post, List-Software,
-List-Subscribe, List-Unsubscribe, List-URL, Mail-Copies-
-To:, Original-Recipient, Originator, Originator-Info, Path,
-PICS-Label, NNTP-Posting-Host, Posted-To:, Read-Receipt-To,
-Received, Registered-Mail-Reply-Requested-By, Replaces,
-Return-Receipt-Requested, Speech-Act, Translated-By.
-Translation-Of, User-Agent, X-Confirm-Reading-To, X-
-Complaints-To:, X-Envelope-From, X-Envelope-To, X-Face, X-
-List-Host, X-Listserver, X-Loop, X-MIME-Autoconverted, X-No-
-Archive, X-OriginalArrivalTime, X-Priority, X-Report-Abuse-
-To, X-Sender, X-X-Sender, X-UIDL, X-URL, X-URI.
-
-
-                          Table of contents
-
-     Abstract                                              1
-     Changes since previous version                        2
-1. Introduction                                           3
-2. Use of gatewaying header fields                        4
-3. Table of header fields                                 5
-     **** 3.1 Phrases used in the tables                   5
-     **** 3.2 Trace information                            6
-     **** 3.3 Format and control information               7
-     **** 3.4 Sender and recipient indication              8
-     **** 3.5 Response control                            14
-     **** 3.6 Message identification and referral
-              header fields                               16
-     **** 3.7 Other textual header fields                 19
-     **** 3.8 Header fields containing dates and
-              times                                       20
-     **** 3.9 Quality information                         20
-     **** 3.10 Language information                       22
-     **** 3.11 Size information                           22
-     **** 3.12 Conversion control                         22
-     **** 3.13 Encoding information                       23
-     **** 3.14 Resent-header fields                       24
-     **** 3.15 Security and reliability                   25
-     **** 3.16 Mailing list control                       25
-     **** 3.17 Miscellaneous                              27
-4. Acknowledgments                                       28
-Copyright and disclaimer                                 29
-5. References                                            30
-6. Author's address                                      32
-Appendix A: Header fields sorted by Internet RFC
-             document in which they appear.               33
-     RFC 822                                              33
-     RFC 976                                              33
-     RFC 1049                                             33
-     RFC 1036                                             33
-     RFC 1123                                             34
-     RFC 2156                                             34
-     RFC 1505                                             34
-     RFC 1766                                             35
-     RFC 2183                                             35
-     RFC 1864                                             35
-     RFC 2045                                             35
-     RFC 2110                                             35
-     RFC 2298                                             35
-     RFC 2369                                             35
-     RFC 2421                                             36
-     son-of-RFC1036 [21]                                  36
-     RFC 2912                                             36
-     RFC 2919:                                            36
-     World Wide Web Consortium (W3C) Recommendations      36
-     Not Internet standard (as of May 2001)               36
-Appendix B: Alphabetical index                           38
-
-
-                          1. Introduction
-
-Many different Internet standards and RFCs define header
-fields which may occur on Internet Mail Messages and Usenet
-News Articles. The intention of this document is to list
-all such header fields in one document as an aid to people
-developing message systems or interested in Internet Mail
-standards.
-
-The document contains all header fields which the author
-has found in the following Internet standards: RFC 822 [2],
-RFC 1036 [3], RFC 1123 [5], RFC 2156 [7], RFC 1496 [8], RFC
-2045 [11], RFC 1766 [12], RFC 2183 [14], RFC 1864[17] and
-RFC 2421[20]. Note in particular that heading attributes
-defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 [16]) are
-not included. PEM and MOSS header fields only appear inside
-the body of a message, and thus are not header fields in
-the RFC 822 sense. Mail attributes in envelopes, i.e.
-attributes controlling the message transport mechanism
-between mail and news servers, are not included. This means
-that attributes from SMTP [1], UUCP [18] and NNTP [15] are
-mainly not covered either. Headings used only in HTTP [19]
-are not included yet, but may be included in future version
-of this memo. Some additional header fields which often can
-be found in e-mail headings but are not part of any
-Internet standard are also included.
-
-The author does not promise that this document contains a
-complete list of all heading fields which are specified in
-any standard or used by any mailer.
-
-For each header field, the document gives a short
-description and a reference to the Internet standard or
-RFC, in which they are defined.
-
-The header field names given here are spelled the same way
-as when they are actually used. This is usually American
-but sometimes English spelling.  One header field in
-particular, "Organisation/Organization", occurs in e-mail
-header fields sometimes with the English and other times
-with the American spelling.
-
-The following words are used in this memo with the meaning
-specified below:
-
-heading        Formatted text at the top of a message,
-                ended by a blank line
-
-header field   One field in the heading, beginning with a
-                field name, colon, and followed by the
-                field value(s). The words "heading field"
-                and "header" are also sometimes used with
-                this meaning.
-
-It is my intention to continue updating this document after
-its publication as an RFC. The latest version, which may be
-more up-to-date (but also less fully checked out) will be
-kept available for downloading from URL
-http://www.dsv.su.se/jpalme/ietf/mail-headers
-
-Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you
-have noted header fields which should be included in this
-memo but are not.
-
-
-                  2. Use of gatewaying header fields
-
-RFC 2156 defines a number of new header fields in Internet
-mail, which are defined to map header fields which X.400
-has but which were previously not standardized in Internet
-mail. The fact that a header field occurs in RFC 2156
-indicates that it is recommended for use in gatewaying
-messages between X.400 and Internet mail, but does not mean
-that the header field is recommended for messages wholly
-within Internet mail. Some of these header fields may
-eventually see widespread implementation and use in
-Internet mail, but at the time of this writing (2001) they
-are not widely implemented or used.
-
-Header fields defined only in RFC 1036 for use in Usenet
-News sometimes appear in mail messages, either because the
-messages have been gatewayed from Usenet News to e-mail, or
-because the messages were written in combined clients
-supporting both e-mail and Usenet News in the same client.
-These header fields are not standardized for use in
-Internet e-mail and should be handled with caution by e-
-mail agents.
-
-
-                       3. Table of header fields
-
-**** 3.1 Phrases used in the tables
-
-"not for general    Used to mark header fields which are
-usage"              defined in RFC 2156 for use in
-                     messages from or to Internet
-                     mail/X.400 gateways. These header
-                     fields have not been standardized for
-                     general usage in the exchange of
-                     messages between Internet mail-based
-                     systems.
-
-"not standardized   Used to mark header fields defined
-for use in e-       only in RFC 1036 for use in Usenet
-mail"               News. These header fields have no
-                     standard meaning when appearing in e-
-                     mail, some of them may even be used in
-                     different ways by different software.
-                     When appearing in e-mail, they should
-                     be handled with caution. Note that RFC
-                     1036, although generally used as a de-
-                     facto standard for Usenet News, is not
-                     an official IETF standard or even on
-                     the IETF standards track.
-
-"non-standard"      This header field is not specified in
-                     any of referenced RFCs which define
-                     Internet protocols, including Internet
-                     Standards, draft standards or proposed
-                     standards. The header field appears
-                     here because it often appears in e-
-                     mail or Usenet News. Usage of these
-                     header fields is not in general
-                     recommended. Some header field
-                     proposed in ongoing IETF standards
-                     development work, but not yet
-                     accepted, are also marked in this way.
-
-"discouraged"       This header field, which is non-
-                     standard, is known to create problems
-                     and should not be generated. Handling
-                     of such header fields in incoming mail
-                     should be done with great caution.
-
-"controversial"     The meaning and usage of this header
-                     field is controversial, i.e. different
-                     implementors have chosen to implement
-                     the header field in different ways.
-                     Because of this, such header fields
-                     should be handled with caution and
-                     understanding of the different
-                     possible interpretations.
-
-"experimental"      This header field is used for newly
-                     defined header fields, which are to be
-                     tried out before entering the IETF
-                     standards track. These should only be
-                     used if both communicating parties
-                     agree on using them. In practice, some
-                     experimental protocols become de-facto-
-                     standards before they are made into
-                     IETF standards.
-
-
-**** 3.2 Trace information
-
-Trace of distribution lists   DL-           RFC 2156, not
-passed.                       Expansion-    for general
-                               History:      usage.
-
-List of MTAs passed.          Path:         RFC 1036:
-                                             2.1.6, only in
-                                             Usenet News,
-                                             not in e-mail.
-
-Trace of MTAs which a         Received:     RFC 822: 4.3.2,
-message has passed.                         RFC 1123:
-                                             5.2.8.
-
-Used to convey the            Return-       RFC 821,
-information from the MAIL     Path:         RFC 1123:
-FROM envelope attribute in                  5.2.13.
-final delivery, when the
-message leaves the SMTP
-environment in which "MAIL
-FROM" is used.
-
-The netnews host, to which    NNTP-         Non-standard,
-this article was originally   Posting-      common in
-posted. Useful for finding    Host:         netnews
-the sender of spams. Since
-this header is added by the
-news server, it is a little
-more difficult to forge than
-other header fields.
-
-
-**** 3.3 Format and control information
-
-Special Usenet News commands  Also-         son-of-RFC1036
-and a normal article at the   Control:      [21], non-
-same time.                                  standard, only
-                                             in Usenet News,
-                                             not in e-mail
-
-Controls whether this         Alternate-    RFC 2156, not
-message may be forwarded to   Recipient:    for general
-alternate recipients such as                usage.
-a postmaster if delivery is
-not possible to the intended
-recipient. Default: Allowed.
-
-Whether a MIME body part is   Content-      RFC 2183,
-to be shown inline or is an   Disposition   experimental
-attachment; can also          :
-indicate a suggested
-filename for use when saving
-an attachment to a file.
-
-Can have the values "voice-   Message-      Non-standard
-message", "fax-message",      Context:
-"pager-message", "multimedia-
-message", "text-message",
-"none"
-
-Only in Usenet News,          Control:      RFC 1036:
-contains commands to be                     2.1.6, only in
-performed by News agents.                   Usenet News,
-                                             not in e-mail.
-
-Whether recipients are to be  Disclose-     RFC 2156, not
-told the names of other       Recipients:   for general
-recipients of the same                      usage.
-message. This is primarily
-an X.400 facility. In X.400,
-this is an envelope
-attribute and refers to
-disclosure of the envelope
-recipient list. Disclosure
-of other recipients is in
-Internet mail done via the
-To:, cc: and bcc: header
-fields.
-
-An indicator that this        MIME-         RFC 2045: 4.
-message is formatted          Version:
-according to the MIME
-standard, and an indication
-of which version of MIME is
-utilized.
-
-Which body part types occur   Original-     RFC 2156, not
-in this message.              Encoded-      for general
-                               Information-  usage.
-                               Types:
-
-
-**** 3.4 Sender and recipient indication
-
-Inserted by Sendmail when     Apparently-   Non-standard,
-there is no "To:" recipient   To:           discouraged,
-in the original message,                    mentioned in
-listing recipients derived                  RFC 1211.
-from the envelope into the
-message heading. This
-behavior is not quite
-proper, MTAs should not
-modify headings (except
-inserting Received lines),
-and it can in some cases
-cause Bcc recipients to be
-wrongly divulged to non-Bcc
-recipients.
-
-Name of the moderator of the  Approved:     RFC 1036:
-newsgroup to which this                     2.2.11, not
-article is sent; necessary                  standardized
-on an article sent to a                     for use in e-
-moderated newsgroup to allow                mail.
-its distribution to the
-newsgroup members. Also used
-on certain control messages,
-which are only performed if
-they are marked as Approved.
-
-Name of the moderator of a    Approved-     Non-standard,
-mailing list, and who has     By:           used by some
-approved this message for                   mailing list
-distribution to the members                 expansion
-of the list.                                systems.
-
-Recipients not to be          bcc:          RFC 822: 4.5.3,
-disclosed to other                          RFC 1123:
-recipients. (bcc = Blind                    5.2.15-16,
-Carbon Copy).                               5.3.7.
-
-Secondary, informational      cc:           RFC 822: 4.5.2,
-recipients. (cc = Carbon                    RFC 1123.
-Copy)                                       5.2.15-16,
-                                             5.3.7.
-
-Geographical or               Distributio   RFC 1036:
-organizational limitation on  n:            2.2.7, not
-where this article can be                   standardized
-distributed. Value can be a                 for use in e-
-compete or incomplete domain                mail.
-names, also various special
-values are accepted like
-"world", "usenet", "USA",
-etc.
-
-Fax number of the             Fax:,         Non-standard.
-originator.                   Telefax:
-
-Primary recipients, who are   For-          Non-standard
-requested to approve the      Approval:
-information in this message
-or its attachments.
-
-Primary recipients, who are   For-          Non-standard
-requested to comment on the   Comment:
-information in this message
-or its attachments.
-
-Primary recipients, who are   For-          Non-standard
-requested to handle the       Handling:
-information in this message
-or its attachments.
-
-(2) Used in Usenet News mail  From          RFC 976: 2.4
-transport, to indicate the    or            for use in
-path through which an         >From         Usenet News
-article has gone when         (not
-transferred to a new host.    followed by
-                               a colon)
-Sometimes called "From_"
-header field.
-
-(1) This header field should  From (not     not
-never appear in e-mail being  followed by   standardized
-sent, and should thus not     a colon)      for use in e-
-appear in this memo. It is                  mail
-however included, since
-people often ask about it.
-
-This header field is used in
-the so-called Unix mailbox
-format, also known as
-Berkely mailbox format or
-the MBOX format. This is a
-format for storing a set of
-messages in a file. A line
-beginning with "From " is
-used to separate successive
-messages in such files.
-
-This header field will thus
-appear when you use a text
-editor to look at a file in
-the Unix mailbox format.
-Some mailers also use this
-format when printing
-messages on paper.
-
-The information in this
-header field should NOT be
-used to find an address to
-which replies to a message
-are to be sent.
-
-Authors or persons taking     From:         RFC 822: 4.4.1,
-responsibility for the                      RFC 1123:
-message.                                    5.2.15-16,
-                                             5.3.7,
-Note difference from the                    RFC 1036 2.1.1
-"From " header field (not
-followed by ":") below.
-
-
-Information about the client  Mail-System-  Non-standard.
-software of the originator.   Version:,
-                               Mailer:,
-                               Originating-
-                               Client:, X-
-                               Mailer, X-
-                               Newsreader,
-                               X-MimeOLE:,
-                               User-Agent:
-
-In Usenet News: group(s) to   Newsgroups:   RFC 1036:
-which this article was                      2.1.3, not
-posted.                                     standardized
-Some systems provide this                   and
-header field also in e-mail                 controversial
-although it is not                          for use in e-
-standardized there.                         mail.
-
-Unfortunately, the header
-field can appear in e-mail
-with three different and
-contradictory meanings:
-
-(a) Indicating the newsgroup
-recipient of an
-article/message sent to both
-e-mail and Usenet News
-recipients.
-
-(b) In a message adressed to
-some mail to news gateways,
-indicates the newsgroup(s)
-that the message is to be
-posted to.
-
-(c) In a personally
-addressed reply to an
-article in a news-group,
-indicating the newsgroup in
-which this discussion
-originated.
-
-See also: "Posted-To:".
-
-Sometimes used in Usenet      Originator:   Non-standard in
-News in similar ways to                     Usenet News,
-"Sender:"                                   Experimental in
-                                             RFC 1528.
-Also used in printing
-protocols.
-
-Contains information about    Originator-   Non-standard
-the authentication of the     Info:         [25]
-originator in a format which
-is not easily used to send
-email to, to avoid the
-problems with "Sender" and
-"X-Sender".
-
-Phone number of the           Phone:        Non-standard.
-originator.
-
-The person or agent           Sender:       RFC 822: 4.4.2,
-submitting the message to                   RFC 1123:
-the network, if other than                  5.2.15-16,
-shown by the From: header                   5.3.7, RFC
-field. Should be                            1036.
-authenticated,
-according to RFC 822, but
-what
-kind of authentication is
-not
-clear. Some implementations
-expect that the e-mail
-address used in this field
-can be used to reach the
-sender, others do not. See
-also "X-Sender".
-
-Primary recipients.           To:           RFC 822: 4.5.1,
-                                             RFC 1123:
-                                             5.2.15-16,
-                                             5.3.7.
-
-If the sender in the          X-Envelope-   Non-standard.
-envelope (SMTP "RCTP TO") is  From:
-not the same as the senders
-in the "From" or "Sender"
-RFC822 header fields, some
-mail servers add this to the
-RFC822 header fields as an
-aid to clients which would
-otherwise not be able to
-display this information.
-
-If the recipient in the       X-Envelope-   Non-standard.
-envelope (SMTP "MAIL FROM")   To:,
-is not included in the CC     Envelope-
-list, some mail servers add   To:
-this to the RFC822 header
-field as an aid to clients
-which would otherwise not be
-able to display the envelope
-recipients.
-
-48x48 bitmap with picture of  X-Face:       Non-Standard
-the sender of this message.
-
-Indication in the mail        X-RCPT-TO:    Non-standard
-header of recipient on the
-SMTP envelope.
-
-Some mail software expect     X-Sender:     Non-standard
-"Sender:" to be an e-mail
-address which you can send
-mail to. However, some mail
-software has as the best
-authenticated sender a POP
-or IMAP account, which you
-might not be able to send
-to. Because of this, some
-mail software put the POP or
-IMAP account into an X-
-sender header field instead
-of a Sender header field, to
-indicate that you may not be
-able to send e-mail to this
-address. See also "X-X-
-Sender".
-
-Another use of" X-Sender:"
-is that some e-mail
-software, which wants to
-insert a "Sender:" header,
-will first change an
-existing "Sender:" header to
-"X-Sender". This use is
-actually often the same as
-that described in the
-previous paragraph, since
-the new "Sender:" is added
-because it is better
-authenticated than the old
-value.
-
-Even though some systems put  X-X-Sender:   Non-standard
-the POP or IMAP account name
-into the "X-Sender:" instead
-of the Sender header field,
-some mail software tries to
-send to the "X-Sender:" too.
-To stop this, some systems
-have begun to use "X-X-
-Sender:" to indicate an
-authentication of the sender
-which might not be useable
-to send e-mail to. See also
-"Originator-Info:"
-
-When a message is sent both   Posted-To:    Non-standard
-to netnews and e-mail, this
-header is used in the e-mail
-version of the message to
-indicate which newsgroup it
-was sent to. This header
-thus contains the same
-information as the
-"Newsgroups:" header in the
-netnews version of the
-message.
-
-E-mail address of             X-Admin:      Non-standard
-administrator of a server,
-through which this message
-was submitted.
-
-
-**** 3.5 Response control
-
-Indicates whether the         Content-      RFC 2156, not
-content of a message is to    Return:       for general
-be returned with non-                       usage.
-delivery notifications.
-
-For future options on         Disposition-  RFC 2298
-disposition notifications.    Notificatio
-                               n-Options:
-
-
-Indicate that the sender      Disposition-  RFC 2298
-wants a dispoisition          Notificatio
-notification when this        n-To:
-message is received (read,
-processed, etc.) by its
-receipents.
-
-Address to which              Errors-To:,   Non-standard,
-notifications are to be sent  Return-       discouraged,
-and a request to get          Receipt-      some of them
-delivery notifications.       To:,          widely used.
-Internet standards            Read-
-recommend, however, the use   Receipt-
-of MAIL FROM and Return-      To:, X-
-Path, not Errors-To, for      Confirm-
-where delivery notifications  reading-
-are to be sent.               to:, Return-
-                               Receipt-
-                               Requested,
-                               Register-
-                               Mail-Reply-
-                               Requested-
-                               By:
-
-Used in Usenet News to        Followup-     RFC 1036:
-indicate that future          To:           2.2.3, not
-discussions (=follow-up) on                 standardized
-an article should go to a                   for use in e-
-different set of newsgroups                 mail.
-than the replied-to article.
-The most common usage is
-when an article is posted to
-several newsgroups, and
-further discussions is to
-take place in only one of
-them.
-
-In e-mail, this header field
-may occur in a message which
-is sent to both e-mail and
-Usenet News, to show where
-follow-up in Usenet news is
-wanted. The header field
-does not say anything about
-where follow-up in e-mail is
-to be sent.
-
-The value of this header
-field should be one or more
-newsgroup names.
-
-The special value "poster"
-as in "Followup-To: poster"
-means that replies are to be
-sent as e-mail to the author
-only.
-
-Whether a delivery report is  Generate-     RFC 2156, not
-wanted at successful          Delivery-     for general
-delivery. Default is not to   Report:       usage.
-generate such a report.
-
-Original Recipient            Original-     RFC 2298
-information for inclusion in  Recipient
-disposition notifications.
-
-Whether non-delivery report   Prevent-      RFC 2156, not
-is wanted at delivery error.  NonDelivery-  for general
-Default is to want such a     Report:       usage.
-report.
-
-This header field is meant    Reply-To:     RFC 822: 4.4.3,
-to indicate where the sender                RFC 1036: 2.2.1
-wants replies to go.                        controversial.
-Unfortunately, this is
-ambiguous, since there are
-different kinds of replies,
-which the sender may wish to
-go to different addresses.
-In particular, there are
-personal replies intended
-for only one person, and
-group replies, intended for
-the whole group of people
-who read the replied-to
-message (often a mailing
-list, anewsgroup name cannot
-appear here because of
-different syntax, see
-"Followup-To" below.).
-
-Some mail systems use this    Reply-To2
-header field to indicate a
-better form of the e-mail
-address of the sender. Some
-mailing list expanders puts
-the name of the list in this
-header field. These
-practices are controversial.
-The personal opinion of the
-author of this RFC is that
-this header field should be
-avoided except in special
-cases, but this is a
-personal opinion not shared
-by all specialists in the
-area.
-
-Indicates where to send       Abuse-        non-standard
-complains if you get a        Reports-
-message which you think is    To:, X-
-against the laws or rules.    Complaints-
-                               To:, X-
-                               Report-
-                               Abuse-To:
-
-Used in netnews articles to   Mail-Copies-  non-standard,
-indicate that followup        To:           but commonly
-(=replies) should be sent to                supported by
-the indicated e-mail                        newsreaders
-address.
-
-Possible future change of     X400-         non-standard
-name for "Content-Return:"    Content-
-                               Return:
-
-
-**** 3.6 Message identification and referral header fields
-
-Reference to specially        Article-      son-of-RFC1036
-important articles for a      Names:        [21], non-
-particular Usenet Newsgroup.                standard
-
-Only in Usenet News, similar  Article-      son-of-RFC1036
-to "Supersedes:" but does     Updates:      [21], non-
-not cause the referenced                    standard
-article to be physically
-deleted.
-
-Used in addition to Content-  Content-      Work in
-Location if this content      Alias:        progress
-part can be retrieved
-through more than one URI.
-Only one of them is allowed
-in the Content-Location, the
-other can be specified in
-Content-Alias.
-
-Base to be used for           Content-      RFC 2110
-resolving relative URIs       Base:
-within this content part.
-
-Unique ID of one body part    Content-ID:   RFC 2045: 7.
-of the content of a message.
-
-URI with which the content    Content-      RFC 2110
-of this content part might    Location:
-be retrievable.
-
-Used by some automatic        Delivered-    non-standard
-services (mainly MLMs and     To:
-autoresponders) for the       or
-purpose of loop detection.    X-Loop:
-The service adds the
-Delivered-To header to
-outgoing messages, with its
-e-mail address as a value,
-and discards incoming
-messages which already have
-it.
-
-Reference to message which    In-Reply-     RFC 822: 4.6.2.
-this message is a reply to.   To:
-
-Unique ID of this message.    Message-ID:   RFC 822: 4.6.1
-                                             RFC 1036:
-                                             2.1.5.
-
-Reference to previous         Obsoletes:    RFC 2156, not
-message being corrected and                 for general
-replaced. Compare to                        usage.
-"Supersedes:" below. This
-field may in the future be
-replaced with "Supersedes:".
-
-In e-mail: reference to       References:   RFC 822: 4.6.3
-other related messages, in                  RFC 1036:
-Usenet News: reference to                   2.1.5.
-replied-to-articles.
-
-Still another name for        Replaces:     non-standard,
-similar functionality as for                proposed in
-"Obsoletes:" and                            IETF USEFOR
-"Supersedes:". This may                     working group
-become the most recommended
-header in the future, but is
-still under discussion in
-IETF standards development
-work.
-
-References to other related   See-Also:     Son-of-RFC1036
-articles in Usenet News.                    [21], non-
-                                             standard
-
-Commonly used in Usenet News  Supersedes:   son-of-RFC1036
-in similar ways to the                      [21], non-
-"Obsoletes" header field                    standard
-described above. In Usenet
-News, however, Supersedes
-causes a full deletion of
-the replaced article in the
-server, while "Supersedes"
-and "Obsoletes" in e-mail is
-implemented in the client
-and often does not remove
-the old version of the text.
-
-Mailbox of the person who     Translated-   non-standard
-made the translation.         By:
-
-Reference to the Message-ID   Translation-  non-standard
-of a message, which the       Of:
-current message is a
-translation of.
-
-Unique identifier for a       X-UIDL:       non-standard
-message, local to a
-particular local mailbox
-store. The UIDL identifier
-is defined in the POP3
-standard, but not the "X-
-UIDL:" header.
-
-Similar usage as "X-URL".     X-URI:        Non-standard
-The URI can be either a URL
-or a URN. URNs are meant to
-become more persistent
-references to resources than
-URLs.
-
-Sometimes used with the same  X-URL:        Non-standard
-meaning as "Content-
-Location:", sometimes to
-indicate the web home page
-of the sender or of his
-organisation.
-
-The UID, as defined in the    X-IMAP:       Non-standard
-IMAP standard. Only used in
-internal mailbox storage in
-some mail systems, should
-never be visible to a user.
-
-
-**** 3.7 Other textual header fields
-
-Comments on a message.        Comments:     RFC 822: 4.7.2.
-
-Description of a particular   Content-      RFC 2045: 8.
-body part of a message, for   Description
-example a caption for an      :
-image body part.
-
-A text string which           Content-      RFC 2156, not
-identifies the content of a   Identifier:   for general
-message.                                    usage.
-
-Search keys for data base     Keywords:     RFC 822: 4.7.1
-retrieval.                                  RFC 1036:
-                                             2.2.9.
-
-See Organization above.       Organisatio   Non-standard.
-                               n:
-
-Organization to which the     Organizatio   RFC 1036:
-sender of this article        n:            2.2.8, not
-belongs.                                    standardized
-                                             for use in e-
-                                             mail.
-
-Title, heading, subject.      Subject:      RFC 822: 4.7.1
-Often used as thread                        RFC 1036:
-indicator for messages                      2.1.4.
-replying to or commenting on
-other messages.
-
-Short text describing a       Summary:      RFC 1036:
-longer article. Warning:                    2.2.10, not
-Some mail systems will not                  standardized
-display this text to the                    for use in e-
-recipient. Because of this,                 mail,
-do not use this header field                discouraged.
-for text which you want to
-ensure that the recipient
-gets.
-
-
-**** 3.8 Header fields containing dates and times
-
-In Internet, the date when a  Date:         RFC 822: 5.1,
-message was written, in                     RFC 1123:
-X.400, the time a message                   5.2.14
-was submitted. Some Internet                RFC 1036:
-mail systems also use the                   2.1.2.
-date when the message was
-submitted.
-
-The time when a message was   Delivery-     RFC 2156, not
-delivered to its recipient.   Date:         for general
-                                             usage.
-
-A suggested expiration date.  Expires:      RFC 1036:
-Can be used both to limit                   2.2.4, not
-the time of an article which                standardized
-is not meaningful after a                   for use in e-
-certain date, and to extend                 mail.
-the storage of important
-articles.
-
-Time at which a message       Expiry-       RFC 2156, not
-loses its validity. This      Date:         for general
-field may in the future be                  usage.
-replaced by "Expires:".
-
-Latest time at which a reply  Reply-By:     RFC 2156, not
-is requested (not demanded).                for general
-                                             usage.
-
-Time when this message was    X-OriginalA   Non-standard
-delivered into the message    rrivalTime:
-transport system (usually
-the same time as in the last
-"Received:" header)
-
-
-**** 3.9 Quality information
-
-A hint from the originator    Importance:   RFC 2156 and
-to the recipients about how                 RFC 2421,
-important a message is.                     proposed
-Values: High, normal or low.
-Not used to control
-transmission speed.
-
-Body parts are missing.       Incomplete-   RFC 2156, not
-                               Copy:         for general
-                                             usage.
-
-Ratings label to control      PICS-Label:   REC-PICS-
-selection (filtering) of                    labels, W3C
-messages according to the                   document [23].
-PICS protocol.
-
-Sometimes used as a priority  Precedence:   Non-standard,
-value which can influence                   controversial,
-transmission speed and                      widely used.
-delivery. Common values are
-"bulk" and "first-class".
-Other uses is to control
-automatic replies and to
-control return-of-content
-facilities, and to stop
-mailing list loops.
-
-Can be "normal", "urgent" or  Priority:     RFC 2156, not
-"non-urgent" and can                        for general
-influence transmission speed                usage.
-and delivery.
-
-How sensitive it is to        Sensitivity   RFC 2156 and
-disclose this message to      :             RFC 2421,
-other people than the                       proposed
-specified recipients.
-Values: Personal, private,
-company confidential. The
-absence of this header field
-in messages gatewayed from
-X.400 indicates that the
-message is not sensitive.
-
-Yet another priority          X-MSMail-     Non-standard
-indication.                   Priority:
-
-Values: 1 (Highest), 2        X-Priority:   Non-standard
-(High), 3 (Normal), 4 (Low),                [24]
-5 (Lowest). 3 (Normal) is
-default if the field is
-omitted.
-
-
-**** 3.10 Language information
-
-Can include a code for the    Content-      RFC 1766,
-natural language used in a    Language:     proposed
-message, e.g. "en" for                      standard.
-English.
-
-Can include a code for the    Language:     RFC 2156, not
-natural language used in a                  for general
-message, e.g. "en" for                      usage.
-English.
-
-
-**** 3.11 Size information
-
-Inserted by certain mailers   Content-      Non-standard,
-to indicate the size in       Length:       discouraged.
-bytes of the message text.
-This is part of a format
-some mailers use when
-showing a message to its
-users, and this header field
-should not be used when
-sending a message through
-the net. The use of this
-header field in transmission
-of a message can cause
-several robustness and
-interoperability problems.
-
-Size of the message.          Lines:        RFC 1036:
-                                             2.2.12, not
-                                             standardized
-                                             for use in e-
-                                             mail.
-
-
-**** 3.12 Conversion control
-
-Information on where an       Content-      Non-standard
-alternative variant of this   Alternative   [27].
-document might be found.      :
-
-Non-standard variant of       Content-      Non-standard.
-Conversion: with the same     Conversion:
-values.
-
-The body of this message may  Conversion:   RFC 2156, not
-not be converted from one                   for general
-character set to another.                   usage.
-Values: Prohibited and
-allowed.
-
-The body of this message may  Conversion-   RFC 2156, not
-not be converted from one     With-Loss:    for general
-character set to another if                 usage.
-information will be lost.
-Values: Prohibited and
-allowed.
-
-
-**** 3.13 Encoding information
-
-Type information of the       Content-      non-standard
-content in some class         Class:
-hierarchy. Class hierarchies
-are commonly used to
-classify data structures in
-software development.
-
-Can give more detailed        Content-      Proposed
-information about the         Features:     Standard, RFC
-Content-Type. Example:                      2912
-
-Content-features:
-   (& (Type="image/tiff")
-   (color=Binary)
-   (image-file-structure=TIFF-
-S)
-   (dpi=200)
-   (dpi-xyratio=200/100)
-   (paper-size=A4)
-   (image-coding=MH) (MRC-
-mode=0)
-   (ua-media=stationery) )
-
-This header is meant to be
-used when you can choose
-between different versions of
-a resource, such as when
-using multipart/atlernative.
-
-Information from the SGML     Content-      non-standard
-entity declaration            SGML-
-corresponding to the entity   Entity:
-contained in the body of the
-body part.
-
-Coding method used in a MIME  Content-      RFC 2045: 6.
-message body.                 Transfer-
-                               Encoding:
-
-Format of content (character  Content-      RFC 1049,
-set etc.) Note that the       Type:         RFC 1123:
-values for this header field                5.2.13,
-are defined in different                    RFC 1766: 4.1
-ways in RFC 1049 and in MIME                RFC 2045: 5.
-(RFC 2045), look for the
-"MIME-version" header field
-to understand if Content-
-Type is to be interpreted
-according to RFC 1049 or
-according to MIME. The MIME
-definition should be used in
-generating mail. RFC 1049
-has "historic" status.
-
-RFC 1766 defines a parameter
-"difference" to this header
-field.
-
-Various other Content-Type
-define various additional
-parameters. For example, the
-parameter "charset" is
-mandatory for all textual
-Content-Types.
-
-Used in several different     Encoding:     RFC 1154,
-ways by different mail                      RFC 1505,
-systems. Some use it for a                  experimental.
-kind of content-type
-information, some for
-encoding and length
-information, some for a kind
-of boundary information,
-some in other ways.
-
-Only used with the value      Message-      RFC 2156, not
-"Delivery Report" to          Type:         for general
-indicates that this is a                    usage.
-delivery report gatewayed
-from X.400.
-
-Information about conversion  X-MIME-       non-standard
-of this message on the path   Autoconverte
-from sender to recipient,     d:
-like conversion between MIME
-encoding formats. Note: Auto-
-conversion may invalidate
-digital seals and
-signatures.
-
-
-**** 3.14 Resent-header fields
-
-When manually forwarding a    Resent-       RFC 822: C.3.3.
-message, header fields        Reply-To:,
-referring to the forwarding,  Resent-
-not to the original message.  From:,
-Note: MIME specifies another  Resent-
-way of resending messages,    Sender:,
-using the "Message" Content-  Resent-
-Type.                         From:,
-                               Resent-
-                               Date:,
-                               Resent-To:,
-                               Resent-cc:,
-                               Resent-
-                               bcc:,
-                               Resent-
-                               Message-ID:
-
-
-**** 3.15 Security and reliability
-
-Checksum of content to        Content-      RFC 1864,
-ensure that it has not been   MD5:          proposed
-modified.                                   standard.
-
-Used in Usenet News to store  Xref:         RFC 1036:
-information to avoid showing                2.2.13, only in
-a reader the same article                   Usenet News,
-twice if it was sent to more                not in e-mail.
-than one newsgroup. Only for
-local usage within one
-Usenet News server, should
-not be sent between servers.
-
-
-**** 3.16 Mailing list control
-
-Contains URL to use to        List-         RFC 2369 [26]
-browse the archives of the    Archive:
-mailing list from which this
-message was relayed.
-
-URL to use to get a           List-         Non-standard
-subscription to the digest    Digest:
-version of the mailing list
-from which this message was
-relayed.
-
-Contains URL to use to get a  List-Help:    RFC 2369 [26]
-information about the
-mailing list from which this
-message was relayed.
-
-Stores an identification of   List-ID:      RFC 2919 [27].
-the mailing list, through
-which this message was
-distributed.
-
-Non-standard precursors to    Mailing-      Non-standard
-List-ID and List-Post.        List:, X-
-                               Mailing-
-                               List:
-
-Contains URL to send e-mail   List-Owner:   RFC 2369 [26]
-to the owner of the mailing
-list from which this message
-was relayed.
-
-Contains URL to use to send   List-Post:    RFC 2369 [26]
-contributions to the mailing
-list from which this message
-was relayed.
-
-Information about the         List-         Non-standard,
-software used in a mailing    Software:     has been
-list expander through which                 considered for
-this message has passed.                    inclusion in
-                                             [26].
-Contains URL to use to get a  List-         RFC 2369 [26]
-subscription to the mailing   Subscribe:
-list from which this message
-was relayed.
-
-Contains URL to use to        List-         RFC 2369 [26]
-unsubscribe the mailing list  Unsubscribe
-from which this message was   :
-relayed.
-
-Contains URL where            List-URL:     Non-standard
-information of various kinds
-about the mailing list from
-which this message was
-relayed.
-
-Information about the server  X-            Non-standard.
-and software used in a        Listserver:   Recommended to
-mailing list expander         , X-List-     use "List-
-through which this message    Host:         Software"
-has passed. Warning:                        instead.
-"Listserv" is a trademark
-and should not be used for
-other than the "Listserv"
-product. Use, instead the
-"List-Software" header
-field.
-
-
-**** 3.17 Miscellaneous
-
-Has been automatically        Autoforward   RFC 2156, not
-forwarded.                    ed:           for general
-                                             usage.
-
-Can be used in Internet mail  Discarded-    RFC 2156, not
-to indicate X.400 IPM         X400-IPMS-    for general
-extensions which could not    Extensions:   usage.
-be mapped to Internet mail
-format.
-
-Can be used in Internet mail  Discarded-    RFC 2156, not
-to indicate X.400 MTS         X400-MTS-     for general
-extensions which could not    Extensions:   usage.
-be mapped to Internet mail         
-format.
-
-Name of file in which a copy  Fcc:          Non-standard.
-of this message is stored.
-
-Speech act categoriztion of   Speech-Act:   Non-standard
-a message, examples of
-speeach acts are Question,
-Idea, More, Promise, Sad,
-Happy, Angry, summary,
-Decision
-This field is used by some    Status:       Non-standard,
-mail delivery systems to                    should never
-indicate the status of                      appear in mail
-delivery for this message                   in transit.
-when stored. Common values
-of this field are:
-
-U    message is not
-downloaded
-      and not deleted.
-
-R    message is read or
-      downloaded.
-
-O    message is old but not
-      deleted.
-
-D    to be deleted.
-
-N    new (a new message also
-      sometimes is
-distinguished
-      by not having any
-"Status:"
-      header field.
-
-Combinations of these
-characters can occur, such
-as "Status: OR" to indicate
-that a message is downloaded
-but not deleted.
-
-Do not archive this message   X-No-         Non-standard
-in publicly available         Archive:
-archives.                     Yes
-
-
-
-                           4. Acknowledgments
-
-Harald Tveit Alvestrand, Neil Carpenter, William C.
-Carpenter, Rob Chandhok, Ned Freed, Olle Järnefors, Jukka
-Korpela, Usi Paz, Martin Platt, Keith Moore, Robert A.
-Rosenberg, Mark Symons, Nick Smith Michael C. Tiernan and
-several other people have helped me with compiling this
-list. I especially thank Ned Freed and Olle Järnefors for
-their thorough review and many helpful suggestions for
-improvements. I alone take responsibility for any errors
-which may still be in the list.
-
-An earlier version of this list has been published as part
-of [13].
-
-
-                  Copyright and disclaimer
-
-The IETF takes no position regarding the validity
-or scope of any intellectual property 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; neither does it represent that it has
-made any effort to identify any such rights.
-Information on the IETF's procedures with respect
-to rights in standards-track and standards-
-related documentation can be found in BCP-11.
-Copies of claims of rights made available for
-publication 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 implementors or
-users of this specification can be obtained from
-the IETF Secretariat."
-
-The IETF invites any interested party to bring to
-its attention any copyrights, patents or patent
-applications, or other proprietary rights which
-may cover technology that may be required to
-practice this standard. Please address the
-information to the IETF Executive Director.
-
-Copyright (C) The Internet Society (date). 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 implmentation 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.
-
-
-                             5. References
-
-Ref.   Author, title                            IETF
-                                                 status
-----   -------------------------------------    (Dec 2000)
--      --------                                 ----------
-                                                 -
-[1]    J. Klensin: "Simple Mail Transfer        Proposed
-        Protocol", RFC 2821, April 2001.         Standard
-
-[2]    P. Resnick: "Internet Message Format"    Proposed
-        STD 11, RFC 2822, April 2001.            Standard
-
-[3]    M.R. Horton, R. Adams: "Standard for     Not an
-        interchange of USENET messages", RFC     offi-cial
-        1036, December 1987.                     IETF
-                                                 standard,
-                                                 but in
-                                                 reality a
-                                                 de-facto
-                                                 standard
-                                                 for Usenet
-                                                 News
-
-[4]    M. Sirbu: "A Content-Type header         Historic
-        field header field for internet
-        messages", RFC 1049, March 1988.
-
-[5]    R. Braden (editor): "Requirements for    Standard,
-        Internet Hosts -- Application and        Required
-        Support", STD-3, RFC 1123, October
-        1989.
-
-[6]    D. Robinson, R. Ullman: "Encoding        Non-
-        Header field for Internet Messages",     standard
-        RFC 1505, August 1993.
-
-[7]    S. Hardcastle-Kille: "Mapping between    Proposed
-        X.400(1988) / ISO 10021 and RFC 822",    standard,
-        RFC 2156 January 1998.                   elective
-
-[8]    H. Alvestrand & J. Romaguera: "Rules     Proposed
-        for Downgrading Messages from            standard,
-        X.400/88 to X.400/84 When MIME           elective
-        Content-Types are Present in the
-        Messages", RFC 1496, August 1993.
-
-[9]    A. Costanzo: "Encoding Header field      Non-
-        Header field for Internet Messages",     standard
-        RFC 1154, April 1990.
-
-[10]   A. Costanzo, D. Robinson: "Encoding      Experiment
-        Header field Header field for            al
-        Internet Messages", RFC 1505, August
-        1993.
-
-[11]   N. Freed & N. Borenstein: "MIME          Draft
-        (Multipurpose Internet Mail              Standard,
-        Extensions) Part One: Format of          elective
-        Internet Message Bodies. RFC 2045.
-        November 1996.
-
-[12]   H. Alvestrand: "Tags for the             Best
-        Identification of Languages", RFC        Current
-        3066, January 2001.                      Practice,
-                                                 elective
-
-[13]   J. Palme: "Electronic Mail", Artech      Non-
-        House publishers, London-Boston          standard
-        January 1995.
-
-[14]   R. Troost, S. Dorner: "Communicating     Experimental
-        Presentation Information in Internet
-        Messages: The Content-Disposition
-        Header field", RFC 2183, June 1995.
-
-[15]   B. Kantor, P. Lapsley, "Network News     Proposed
-        Transfer Protocol: "A Proposed           standard
-        Standard for the Stream-Based
-        Transmission of News", RFC 977,
-        January 1986.
-[16]   1848  PS   S. Crocker, N. Freed, J.      Proposed
-        Galvin, S. Murphy, "MIME Object          standard
-        Security Services", RFC 1848, March
-        1995.
-
-[17]   J. Myers, M. Rose: The Content-MD5       Draft
-        Header field Header field, RFC 1864,     standard
-        October 1995.
-
-[18]   M. Horton, UUCP mail interchange         Not an
-        format standard, RFC 976, Januari        offi-cial
-        1986.                                    IETF
-                                                 standard,
-                                                 but in
-                                                 reality a
-                                                 de-facto
-                                                 standard
-                                                 for Usenet
-                                                 News
-
-[19]   R. Fielding, J. Gettys, J. Mogul, H.     Draft
-        Frystyk, L. Masinter, P. Leach, T.       standard
-        Berners-Lee: Hypertext Transfer
-        Protocol -- HTTP/1.1, June 1999.
-[20]   G. Vaudreuil: Voice Profile for          Proposed
-        Internet Mail, RFC 2421 Feburary
-        1998.
-
-[21]   H. Spencer: News Article Format and      Not even an
-        Transmission, June 1994,                 RFC, but
-        FTP://zoo.toronto.edu/pub/news.ps.Z      still
-        FTP://zoo.toronto.edu/pub/news.txt.Z     widely used
-                                                 and partly
-        This document is often referenced        almost a de-
-        under the name "son-of-RFC1036".         facto
-                                                 standard
-                                                 for Usenet
-                                                 News
-
-[23]   PICS Label Distribution Label Syntax     Other
-        and Communication Protocols, World       standard
-        Wide Web Consortium, October 1996.
-
-[24]   Eudora Pro Macintosh User Manual,        Non-
-        Qualcomm Inc., 1988-1995.                standard
-
-[25]   C. Newman: Originator-Info Message       Non-
-        Header field. work in progress, July     standard
-        1997.
-
-[26]   Grant Neufeld and Joshua D. Baer: The    Proposed
-        Use of URLs as Meta-Syntax for Core      standard
-        Mail List Commands and their
-        Transport through Message Header
-        fields, RFC 2369, July 1998.
-
-[27]   G. Klyne (ed.): Content Negotiation      Non-
-        for Facsimile Using Internet Mail,       standard
-        Work in progress, March 2000.
-
-[27]   R. Chandhok, G. Wenger: List-IDE: A      Proposed
-        Structured Field and Namespace for       standard
-        the Identification if Mailing Lists,
-        RFC 2919, March 2001.
-
-[28]   Jukka "Yucca" Korpela: Quick             Non-
-        reference to Internet message            standard
-        headers,
-        http://www.cs.tut.fi/~jkorpela/header
-        s.html, October 2001.
-
-
-                           6. Author's address
-
-Jacob Palme                Phone: +46-8-16 16 67
-Stockholm University/KTH   Fax: +46-8-783 08 29
-Electrum 230               E-mail: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
-
-                              Appendix A:
-Header fields sorted by Internet RFC document in which
-they appear.
-
-RFC 822
--------
-
-bcc
-cc
-Comments
-Date
-From
-In-Reply-To
-Keywords
-Message-ID
-Received
-References
-Reply-To
-Resent-
-Resent-bcc
-Resent-cc
-Resent-Date
-Resent-From
-Resent-From
-Resent-Message-ID
-Resent-Reply-To
-Resent-Sender
-Resent-To
-Return-Path
-Sender
-Subject
-To
-
-RFC 976
--------
-
-"From " (followed by space, not colon (:")
-
-RFC 1049
---------
-
-Content-Type
-
-RFC 1036
---------
-
-Approved
-Control
-Distribution
-Expires
-Followup-To
-Lines
-Newsgroups
-Organization
-Path
-Summary
-Xref
-
-RFC 1123
---------
-
-Content-Type
-
-RFC 2156
---------
-
-Alternate-recipient
-Auto-forwarded see Autoforwarded
-Autoforwarded
-Content-Identifier
-Content-Return
-Conversion
-Conversion-With-Loss
-Delivery-Date
-Discarded-X400-IPMS-Extensions
-Discarded-X400-MTS-Extensions
-Disclose-Recipients
-DL-Expansion-History
-Expiry-Date
-Generate-Delivery-Report
-Importance
-Incomplete-Copy
-Language
-Message-Type
-Obsoletes
-Original-Encoded-Information-Types
-Prevent-NonDelivery-Report
-Priority
-Reply-By
-Sensitivity
-
-RFC 1505
---------
-
-Encoding
-
-RFC 1766
---------
-
-Content-Language
-
-RFC 2183
---------
-
-Content-Disposition
-
-RFC 1864
---------
-
-Content-MD5
-
-RFC 2045
---------
-
-Content-Description
-Content-ID
-Content-Transfer-Encoding
-Content-Type
-MIME-Version
-
-RFC 2110
---------
-
-Content-Base
-Content-Location
-
-RFC 2298
---------
-
-Disposition-Notification-To
-Disposition-Notification-Options
-Original-Recipient
-
-RFC 2369
---------
-
-List-Archive
-List-Help
-List-Owner
-List-Post
-List-Software
-List-Subscribe
-List-Unsubscribe
-
-RFC 2421
---------
-
-Importance
-Sensitivity
-
-son-of-RFC1036 [21]
--------------------
-
-Also-Control
-Article-Names
-Article-Updates
-See-Also
-Supersedes
-
-RFC 2912
---------
-
-Content-Features
-
-RFC 2919:
---------
-
-List-ID
-
-World Wide Web Consortium (W3C) Recommendations
------------------------------------------------
-
-Pics-Label
-
-Not Internet standard (as of May 2001)
--------------------------------------------
-
-"From " (not followed by ":")
-Abouse-Reports-To
-Apparently-To
-Approved-By
-Content-Alias
-Content-Alternative
-Content-Class
-Content-Conversion
-Content-Length
-Content-SGML-Entity
-Delivered-To
-Encoding
-Errors-To
-Fax
-Fcc
-For-Approval
-For-Comment
-For-Handling
-List-Digest
-List-URL
-Mailing-List
-Mail-Copies-To
-Mail-System-Version
-Mailer
-Message-Context
-NNTP-Posting-Host
-Organisation
-Originating-Client
-Originator
-Originator-Info
-Phone
-Posted-To
-Precedence
-Registered-Mail-Reply-Requested-By
-Replaces
-Return-Receipt-Requested
-Return-Receipt-To
-Read-Receipt-To
-Speech-Act
-Status
-Supersedes
-Telefax
-Translated-By
-Translation-Of
-User-Agent
-X-Admin
-X-Confirm-Reading-To
-X-Complaints-To
-X-Envelope-From
-X-Envelope-To
-X-Face
-X-IMAP
-X-Loop
-X-List-Host
-X-Listserver
-X-Mailer
-X-Mailing-List
-X-MIME-Autoconverted
-X-MIMEOLE
-X-MSMail-Priority
-X-Newsreader
-X-No-Archive
-X-OriginalArrivalTime
-X-Priority
-X-RCPT-TO
-X-Report-Abuse-To
-X-Sender
-X-UIDL
-X-URI
-X-URL
-X-X-Sender
-X400-Content-Return
-
-                    Appendix B: Alphabetical index
-
-Sectio Header field
-n      ------------
-------
--
-
-3.5    Abuse-Reports-To
-3.3    Also-Control
-3.3    Alternate-Recipient
-3.4    Apparently-To
-3.4    Approved
-3.4    Approved-By
-3.6    Article-Names
-3.6    Article-Updates
-        Auto-Forwarded see Autoforwarded
-3.17   Autoforwarded
-3.4    bcc
-3.4    cc
-        Client, see Originating-Client
-        Comment, see For-Comment
-3.7    Comments
-3.6    Content-Alias
-3.12   Content-Alternative
-3.6    Content-Base
-3.13   Content-Class
-3.12   Content-Conversion
-3.7    Content-Description
-3.3    Content-Disposition
-3.13   Content-Features
-3.6    Content-ID
-3.7    Content-Identifier
-3.10   Content-Language see also Language
-3.11   Content-Length
-3.6    Content-Location
-3.15   Content-MD5
-3.4    Content-Return
-3.13   Content-SGML-Entity
-3.13   Content-Transfer-Encoding
-3.13   Content-Type
-3.3    Control
-3.12   Conversion
-3.12   Conversion-With-Loss
-        Copy, see Incomplete-Copy
-3.8    Date, see also Delivery-Date, Received, Expires,
-        Expiry-Date
-3.6    Delivered-To
-3.8    Delivery-Date
-        Delivery-Report, see Generate-Delivery-Report,
-        Prevent-Delivery-Report, Non-Delivery-Report,
-        Content-Type
-        Description, see Content-Description
-3.17   Discarded-X400-IPMS-Extensions
-3.17   Discarded-X400-MTS-Extensions
-3.3    Disclose-Recipients
-        Disposition, see also Content-Disposition
-3.5    Disposition-Notification-Options
-3.5    Disposition-Notification-To
-3.4    Distribution
-3.2    DL-Expansion-History
-3.13   Encoding see also Content-Transfer-Encoding
-3.4    Errors-To
-3.8    Expires
-3.8    Expiry-Date
-        Extension see Discarded-X400-IPMS-Extensions,
-        Discarded-X400-MTS-Extensions
-3.4    Fax see also Telefax
-3.17   Fcc
-3.4    Followup-To
-3.4    For-Approval
-3.4    For-Comment
-3.4    For-Handling
-        Forwarded, see Autoforwarded
-3.4    From (not followed by (":" or preceded by ">")
-3.4    From (followed by ":")
-3.4    Generate-Delivery-Report
-        Handling, see For-Handling
-        History, see DL-Expansion-History
-        ID, see Content-ID and Message-ID
-        Identifier, see Content-ID and Message-ID
-3.9    Importance
-3.6    In-Reply-To
-3.9    Incomplete-Copy
-3.7    Keywords
-        Label, see PICS-Label
-3.10   Language see also Content-Language
-        Length see Content-Length
-3.11   Lines
-3.16   List-Archive
-3.16   List-Digest
-3.16   List-Help
-3.16   List-ID
-3.16   List-Owner
-3.16   List-Post
-3.16   List-Software
-3.16   List-Subscribe
-3.16   List-URL
-3.16   List-Unsubscribe
-        Loss, see Conversion-With-Loss
-3.16   Mailing-List, see also X-Mailing-List
-3.5    Mail-Copies-To
-3.4    Mail-System-Version see also X-mailer
-3.4    Mailer
-        MD5 see Content-MD5
-3.3    Message-Context
-3.6    Message-ID
-3.13   Message-Type
-3.3    MIME-Version
-3.4    Newsgroups
-        Newsreader, see X-Newsreader
-3.3    NNTP-Posting-Host
-3.6    Obsoletes
-3.7    Organisation
-3.7    Organization
-3.3    Original-Encoded-Information-Types
-3.6    Original-Recipient
-3.4    Originating-Client
-3.4    Originator
-3.4    Originator-Info see also Sender
-3.2    Path
-3.4    Phone
-3.9    PICS-Label
-3.4    Posted-To
-3.9    Precedence
-3.4    Prevent-NonDelivery-Report
-3.9    Priority
-3.5    Read-Reciept-To
-3.2    Received
-        Recipient, see To, cc, bcc, Alternate-Recipient,
-        Disclose-Recipients
-3.6    References
-3.5    Registered-Mail-Reply-Requested-By
-3.6    Replaces
-3.8    Reply-By
-3.4    Reply-To, see also In-Reply-To, References
-3.14   Resent-
-        Return see Content-Return
-3.2    Return-Path
-3.5    Return-Receipt-Requested
-3.5    Return-Receipt-To
-3.6    See-Also
-3.4    Sender
-3.9    Sensitivity
-3.17   Speech-Act
-3.17   Status
-3.7    Subject
-3.7    Summary
-3.6    Supersedes
-3.4    Telefax see also Fax
-3.4    To
-        Transfer-Encoding see Content-Transfer-Encoding
-3.6    Translated-By
-3.6    Translation-Of
-        Type see Content-Type, Message-Type, Original-
-        Encoded-Information-Types
-3.4    User-Agent
-        Version, see MIME-Version, X-Mailer
-3.4    X-Admin
-3.4    X-Complaints-To
-3.5    X-Confirm-Reading-To
-3.4    X-Envelope-From
-3.4    X-Envelope-To
-3.4    X-Face
-3.6    X-IMAP
-3.16   X-List-Host
-3.16   X-Listserver
-3.6    X-Loop
-3.16   X-Mailing-List, see also Mailing-List
-3.4    X-Mailer see also Mail-System-Version
-3.13   X-MIME-Autoconverted
-3.4    X-MimeOLE
-3.9    X-MSMail-Priority
-3.4    X-Newsreader
-3.17   X-No-Archive
-3.8    X-OriginalArrivaltime
-3.9    X-Priority
-3.4    X-Report-Abuse-To
-3.4    X-RCPT-TO
-3.4    X-Sender see also Originator-Info
-3.6    X-UIDL
-3.6    X-URI
-3.6    X-URL see also Content-Location
-3.4    X-X-Sender see also Originator-Info
-3.4    X400-Content-Return
-3.15   Xref
-
diff --git a/Documentation/en/I-D/draft-palme-maillist-01.txt b/Documentation/en/I-D/draft-palme-maillist-01.txt
deleted file mode 100644
index 444ff5c3..00000000
--- a/Documentation/en/I-D/draft-palme-maillist-01.txt
+++ /dev/null
@@ -1,580 +0,0 @@
-INTERNET-DRAFT                                      Jacob Palme
-Network Working Group                  Stockholm University/KTH
-draft-palme-maillist-01.txt                              Sweden
-Expires November 2001                                  May 2001
-
-
-
-
-
-Appropriate Mailing List Behaviour
-
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time.  It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 2001. All Rights Reserved.
-
-
-
-Abstract
-
-This memo summarizes common ideas on how good mailing lists should
-behave. Some of this is taken from IETF standards, some is not. This
-memo is not intended, itself, to become a standard, but might, if
-accepted by the IETF, be published as informational RFC or as a Best
-Current Practice (BCP) document.
-
-
-Table of contents
-
-1.   Terminology and Scope
-2.   Reserved E-mail Addresses
-3.   Sending Requests to a List Expander
-  3.1   Subscription Control
-    3.1.1  To Subscribe
-    3.1.2  To Unsubscribe
-  3.2   To Get Information about a List
-4.   Who may Post to a Mailing List
-5.   SMTP Envelope
-6.   Delivery Status Notifications
-7.   Nested Lists
-8.   Loop Control
-9.   List Headers
-10.  Header Munging
-11.  Spam Control
-12.  Mail Bombing
-13.  Groupware
-14.  Security Considerations
-15.  Copyright and Disclaimer
-16.  Acknowledgments
-17.  References
-18.  Author's address
-
-
-1.    Terminology and Scope
-
-By a mailing list is in this specification meant an automatic agent
-which has an e-mail address, and which will resend messages, sent to
-this address via SMTP [RFC2821], to all e-mail addresses in a list of
-subscribers to the mailing list. This process of resending is
-designated "expansion" of the mailing list. Note that lists which are
-expanded by the sender's client before submission to the mail
-transport system are not covered by this specification, even though
-the word "mailing list" is sometimes used also for such lists.
-
-This memo summarizes customary ideas on how good mailing lists should
-behave. Some of this is taken from IETF standards, some is not.
-
-
-2.    Reserved E-mail Addresses
-
-Every mailing list has an e-mail address, named according to the same
-conventions as for personal mailboxes, and reachable through the same
-mail transport system as for personal mailboxes.
-
-If the e-mail address of a mailing list is "flowers@foo.bar.net" then
-the following e-mail addresses are also reserved:
-
-flowers-request@foo.bar.net
-flowers-owner@foo.bar.net
-flowers-errors@foo.bar.net
-
-Messages sent to "flowers-request@foo.bar.net" are usually handled by
-an automatic process which performs common actions as requested in the
-message. Sometimes all, or some, such messages are sent to a human
-administrator of the list.
-
-Messages sent to "flowers-owner@foo.bar.net" are sent to a human
-administrator of the list, or cause a non-delivery notification (see
-section 6. Delivery Status Notifications) in accordance with [RFC1891]
-and [RFC1894], if the list administrator is not willing to handle
-messages sent to this e-mail address.
-
-Messages sent to "flowers-errors@foo.bar.net" are usually handled by a
-person or a process which handles routine maintenance of a list, such
-as removal of list members who persistently (for at least 3-4 days)
-return negative Delivery Status Notifications. The e-mail address
-"flowers-errors@foo.bar.net" should in this case also be put as the
-SMTP sender when expanding messages from the mailing lists to its
-members. If there is no person or process doing such maintenance, the
-SMTP sender for expanded messages may instead be empty.
-
-
-3.    List Headers
-
-A mailing list expander should add headers to the mailing list
-according to [RFC2369] and [RFC2919]. Examples:
-
-List-Help: <mailto:flowers@foo.net?subject=help> (List Instructions)
-List-Unsubscribe: <mailto: flowers@foo.net?subject=unsubscribe>
-List-Subscribe: <mailto: flowers@foo.net?subject=subscribe>
-List-Archive: <http://www.foo.net/flowers-archive>
-List-Post: <mailto:moderator@foo.net> (Postings are Moderated)
-List-Owner: <mailto:grant@foo.net> (Grant Neufeld)
-List-Id: List Header Mailing List <list-header.nisto.com>
-
-Note that the "List-" headers can either contain an e-mail address, to
-which requests are sent in a format specified in the "List-" command,
-for example
-
-   List-Unsubscribe: <mailto: flowers@foo.net?subject=unsubscribe>
-
-Or can contain an URL of a web page, on which a subscription request
-can be made.
-
-
-4.    Sending Requests to a List Expander
-
-Some, but not all, mailing lists accept commands sent in messages to
-an automatic agent representing the list expander. The most common
-address for such an agent is "flowers-request@foo.bar.net", but other
-addresses occur, such as "list-handler@foo.bar.net".
-
-There is no agreed standard on the format of commands in such
-messages, so it is good practice to accept a number of common variants
-in either the subject or the text of the message to the agent. Such
-commands are case-insensitive. Information about which format is used
-by a particular mailing list expander is specified in the "List-"
-headers, see section 3 List Headers above.
-
-Common such commands are:
-
-4.1   Subscription Control
-
-The subscription control commands handle the subscription of the SMTP
-sender of the request (not the subscription for name in the From: or
-Sender: header). The mailing list expander may however find the name
-of the requestor from the "From:" or "Sender:" field, in order to
-register the name. This name is however not used in normal list
-expansion. The actual address for this agent or web page is specified
-in "List-" headers, see section 3 List Headers above.
-
-4.1.1 To Subscribe
-
-Common commands are: sub, subscribe, join. Best is to support all of
-them.
-
-Sometimes the name of the requestor (not the e-mail address) is
-specified after this command, for example "Subscribe Mary Woodfence".
-Other systems require the e-mail address to be specified in the
-subscribe command, or a full e-mail user-friendly name and address in
-the format used in From: e-mail header, like
-"Subscribe Mary Woodfence <maryw@foo.bar>"
-
-4.1.2 To Unsubscribe
-
-Common unsubscribe commands are: uns, unsubscribe, signoff, sign-off,
-sign off, delete, leave, cancel, remove, rem, del. Best is to support
-all of them.
-
-4.2   To Get Information about a List
-
-Common commands to retrieve information about a list are: help,
-review, query, info, information. Best is to support all of them.
-
-The information returned may include a textual description of the
-purpose of the list and of which postings are acceptable to the list.
-It may also include description of how to subscribe and unsubscribe
-and where archives of the mailing list are kept. Some lists also
-return a list of the subscribers of the list.
-
-The actual address for the agent or web page returning such
-information is specified in "List-" headers, see section 3 List
-Headers above.
-
-
-5.    Mail Bombing
-
-Some people will add other people's e-mail addresses to mailing lists
-without their permission, causing them to be bombarded with mail they
-do not want. To counteract this, good practice is that a mailing list
-expander, which receives a request to add an e-mail address to the
-mailing list, should send a message to this e-mail address, asking if
-the recipient really wants to be added to the list, and putting a
-secret codeword in the "Subject:". If no confirmatory reply arrives
-with this codeword in its "Subject:" then the person is not
-permanently added to the list.
-
-
-6.    Who may Post to a Mailing List
-
-There may be different kinds of restrictions on who may submit
-messages to a list. Common cases are:
-
-- Anyone:           Anyone can submit messages to the list (warning,
-                     see section 12. Spam Control below).
-- Subscribers only: Only subscribers are allowed to submit to the list.
-- Moderators only:  Only one or more designated moderators may
-                     submit to the list.
-
-Other cases, such as geographical or domain name restrictions, or that
-only a program, agent or filter may post, also occur. A sublist in a
-nested mailing list structure can be set to reject all postings which
-do not come from its superlist.
-
-The checking on who may submit to a list is usually done on the SMTP
-sender of the message, not on the names in From: or Sender: fields in
-the heading, because this name is a little more difficult to fake.
-Note however, that mail which is forwarded through nested mailing
-lists, will have the administrator of the previous list as SMTP
-sender. If the previous list does not perform filtering, and a list
-often gets messages from other mailing lists, filtering inom the From:
-header may be necessary.
-
-If a message is sent to a list, by someone who is not allowed to
-submit to the list, this can be handled in either of two ways:
-
-(a) Forward the message to the moderator of the list, who decides
-     whether to accept or reject the message. This option should
-     only be used if there really does exist a moderator who really
-     performs this task on a regular basis.
-
-(b) Send a non-delivery notification to the SMTP sender of the
-     rejected message, in accordance with [RFC1891] and [RFC1894].
-
-
-7.    SMTP Envelope
-
-The SMTP sender [RFC2821] of a message after expansion should be the
-list owner or maintainer [RFC1123], not the original sender, for
-exmaple the mailing list flowers@foo.bar.net may set flowers-
-errors@foo.bar.net as the SMTP sender of expanded messages.
-
-When several mailing lists are nested, each list in sequence, which
-expands a message, should set its owner or maintainer as SMTP sender,
-so that the SMTP sender always indicates the owner of the latest list
-expander, through which the message has passed.
-
-For small, closed lists, the option of retaining the SMTP sender of
-the original sender can also occur.
-
-The SMTP recipients should be the subscribers of the mailing list
-doing the expansion. A mailing list may send to all recipients in one
-envelope (SMTP submission) or may split the recipients into multiple
-submissions, like one submission for each recipient. For large lists,
-it may be best to split the recipients with only 99 RCPT TO for each
-submission, since some SMTP servers may not accept more than 99
-recipients.
-
-Some mailing list have a facility that a subscriper can stay a
-subscriber, but not get submissions sent. Other mailing list allow
-subscribers to get submissions in different formats, such as digests
-of all messages once a day or once a week, or only a list of URLs to
-retrieve the new messages, not the full text. Such options will mean
-that the content of the messages sent via SMTP is different for
-different subscribers.
-
-
-8.    Delivery Status Notifications
-
-Delivery Status Notification [RFC1891], [RFC1894] requests are usually
-not forwarded by mailing list expanders. Instead, notifications are
-sent when the message arrives at the list, and the list maintainer can
-request notifications when the messages are delivered to list
-subscribers.
-
-An exception to this is small, closed lists, where sometimes Delivery
-Status Notification requests are forwarded through the list, and the
-notifications are sent back to the original sender.
-
-
-9.    Nested Lists
-
-A subscriber of a mailing list can be another mailing list. This is
-called "nested lists". Nested lists are used for efficiency reasons
-and in order to distribute the management of different parts of the
-subscriber space.
-
-Nested lists can have a hierarchical structure or be looped, see
-Figure 7.1:
-
-
-   Figure 7.1   Examples of hierarchical and looped nesting
-
-                   Hierarchical                  Looped
-
-                      Top list               +---<-List A-<-+
-                         V                   V         ^    ^
-             +-----<-----+----->-----+     List B--->--+--<-+
-             V           V           V       V              ^
-          Sublist A  Sublist B  Sublist C    +---->------List C
-             V
-      +--<---+---->---+
-      V               V
-   SubList A1  Sublist A2
-
-
-With a hierarchical structure, contributions intended for all
-subscribers of the whole set of lists must be sent to the top list.
-Theoretically, messages intended for only a brach of the tree might be
-sent to the top of that branch, but this is usually not recommended,
-because users have difficulty understanding it.
-
-A way to stop contributions to other branches than the top list is to
-designated that the sublists will only accept contributions from their
-immediate superior in the nesting structure.
-
-Looped nesting can cause loops, where the same message circles
-indefinitely between the lists. How such loops can be avoided is
-described in section 8. Loop Control. Another alternative is to only
-use hierarhically nested lists. It is, however, sometimes desirable to
-allow looped nesting, for example when one or more of the nested lists
-is a groupware system which accepts local contributions using other
-submission methods than e-mail (see section 12 Mail Bombing). Looped
-nesting will also avoid the problem with contributions submitted to
-the wrong branch of a hierarchical structure.
-
-A common practice is to accept contributions only to the top list in a
-nested structure of mailing lists. This would mean that sublists will
-only accept contributions coming from the superior list.
-
-In a few cases, submissions are acceted to sublists, intended only to
-a subset of the main list, but this practice is usually not
-recommended.
-
-
-10.   Loop Control
-
-Loops can occur because lists are nested (see section 7. Nested
-Lists). Even if lists are not intended to be nested, it is advisable
-to employ loop control techniques, because nesting of lists can happen
-by mistake.
-
-Mailing lists commonly employ one or more of the following techniques
-for avoiding loops and duplicates. It is better to employ more than
-one of these techniques:
-
-(1) Add a "Received:" header to all messages passing the list. If a
-     mailing list recognizes its own "Received:" header in an incoming
-     message, such a message is dropped. No non-delivery notification
-     should be sent in this case (since it might cause another loop).
-
-     Note: The content of the Received header should be different from
-     what is added by the mail transport agent during ordinary routing
-     of e-mail, since otherwise a message routed by this mail transport
-     agent may at a later time be rejected by the mailing list, even
-     though it has not actually passed the list.
-
-(2) A variant of this which is *not* recommended is to use "Resent-"
-     headers or "List-" headers. A problem with such headers is that
-     they may not always correctly show the whole path which the
-     message has gone through. It is normally not desirable that
-     mailing lists add "Resent-" headers to messages, see section
-     11: Header Munging and [RFC2822].
-
-(3) Store a list of the Message-ID-s of messages which have passed
-     the list, and reject incoming messages whose Message-ID is on
-     this list. To achieve loop control, this list need not be kept
-     for a long time, a week may be enough in most cases.
-
-(4) Store a list of the content or checksum of messages which have
-     passed this list, and use it in the same way as the Message-ID.
-     The advantage with this is that it may work even when a message
-     did not have any Message-ID or when some badly behaving list
-     expander has removed or modified the Message-ID.
-
-
-11.   Header Munging
-
-Apart from what is specifed in sections 9. Loop Control and 10. List
-Headers, a mailing list expander should not in any way modify the
-heading of a message. In particular, the list should not change the
-Message-ID, not add "Resent-", "From:", "Sender:", "Auto-Submitted:"
-or "Reply-To:", and should not remove or modify "Received:" headers
-(but may add an additional "Received:" header with information about
-the mailing list expansion). The practice to add the e-mail address of
-the list in a "Reply-To:" header is common, but is not recommended.
-Instead, use the "List-Post:" command from [RFC2369].
-
-
-12.   Spam Control
-
-Many mailing list expanders employ various methods to counteract
-spamming. Examples of such methods are:
-
-(1) Do not allow non-subscribers to post to the list.
-
-(2) Check all submissions by a human moderator before acceptance.
-
-(3) Employ various filtering techniques to recognize spams, such as
-     multiple occurence of the same message sent to different mailing
-     lists. Since such techniques may reject legitimate messages,
-     rejected messages should be passed to a human moderator for
-     checking.
-
-
-13.   Groupware
-
-A groupware product may appear as a mailing list to people accessing
-it via e-mail, and may at the same time appear as a forum to people
-accessing it via other user interfaces, such as HTTP [RFC2068]/HTML
-[RFC1866] or own protocols for this particular groupware.
-
-Such groupware products may allow addition of e-mail addresses as
-subscribers to a forum in the same way as groupware users are added as
-members of the forum.
-
-A message created in a groupware system, and sent out via e-mail,
-should include the e-mail address of the forum (groupware discussion
-group) in a "To:" och "Cc:" header, as well as in the List-headers
-according to [RFC2369] and [RFC 2919].
-
-One particular class of Groupware is Usenet News. This document is not
-written to specially cater to the issues of gatewaying between e-mail
-and Usenet News. Such gatewaying is a complex issue, which requires
-special consideration for that particular case.
-
-
-14.   Security Considerations
-
-Allowing people to retrieve lists of subscribers of mailing lists may
-be misused by spammers and other people using these names for no-goood
-purposes.
-
-Allowing anyone to post to a list may be misused by spammers. See see
-section 12. Spam Control.
-
-Loop control may incur some risk of messages disappearing, but this
-should normally not happen.
-
-Loop control with Message-ID can be misused to stop unwanted messages,
-but this would be difficult, since the offender must send the false
-message with the same Message-ID before the message to be stopped.
-
-Spam control may incur some risk of messages disappearing. A way to
-reduce this risk is to forward rejected messages to a human moderator
-for checking.
-
-A well-known problem with moderated mailing lists is that if the
-moderator is sick, on holiday, or otherwise occupied, the list ceases
-to work. Some mailing list try to solve this problem by having
-multiple moderators, so that another moderator can take over when one
-of them cannot perform the moderating task.
-
-
-15.   Copyright and Disclaimer
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property 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; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-rights made available for publication 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 implementors or users of this specification can be obtained from
-the IETF Secretariat."
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary
-rights which may cover technology that may be required to practice
-this standard. Please address the information to the IETF Executive
-Director.
-
-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 implmentation 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.
-
-
-16.   Acknowledgments
-
-Many people have helped with the production of this document. Of
-special value have been .....
-
-
-17.   References
-
-[RFC821]    Simple Mail Transfer Protocol. J. Postel. Aug-01-
-             1982. (Format: TXT=124482 bytes) (Obsoletes
-             RFC0788) (Also STD0010) (Status: STANDARD)
-
-[RFC822]    Standard for the format of ARPA Internet text
-             messages. D. Crocker. Aug-13-1982. (Format:
-             TXT=109200 bytes) (Obsoletes RFC0733) (Updated by
-             RFC1123, RFC1138, RFC1148, RFC1327, RFC2156) (Also
-             STD0011) (Status: STANDARD)
-
-[RFC1123]   Requirements for Internet hosts - application and
-             support. R.T. Braden. Oct-01-1989. (Format:
-             TXT=245503 bytes) (Updates RFC0822) (Updated by
-             RFC2181) (Status: STANDARD)
-
-[RFC1866]   Hypertext Markup Language - 2.0. T. Berners-Lee &
-             D. Connolly. November 1995. (Format: TXT=146904
-             bytes) (Status: PROPOSED STANDARD)
-
-[RFC1891]   SMTP Service Extension for Delivery Status
-             Notifications. K. Moore. January 1996. (Format:
-             TXT=65192 bytes) (Status: PROPOSED STANDARD)
-
-[RFC1894]   An Extensible Message Format for Delivery Status
-             Notifications. K. Moore & G. Vaudreuil. January
-             1996. (Format: TXT=77462 bytes) (Status: PROPOSED
-             STANDARD)
-
-[RFC2068]   Hypertext Transfer Protocol -- HTTP/1.1. R.
-             Fielding, J. Gettys, J. Mogul, H. Frystyk, T.
-             Berners-Lee. January 1997. (Format: TXT=378114
-             bytes) (Status: PROPOSED STANDARD)
-
-[RFC2369]   The Use of URLs as Meta-Syntax for Core Mail List
-             Commands and their Transport through Message
-             Header Fields. G. Neufeld, J. Baer. July 1998.
-             (Format: TXT=30853 bytes) (Status: PROPOSED
-             STANDARD)
-
-[RFC2919]   List-Id: A Structured Field and Namespace for the
-             Identification of Mailing Lists, By R. Chandhok
-             and G. Wegner, March 2001 (Status: PROPOSED
-             STANDARD).
-
-[RFC2821]   Simple Mail Transfer Protocol, by J. Klensin,
-             April 2001.
-
-[RFC2822]   Internet Message Format, by P. Resnick, April
-             2001.
-
-
-
-18.   Author's address
-
-Jacob Palme                          Phone: +46-8-16 16 67
-Stockholm University/KTH             Fax: +46-8-783 08 29
-Skeppargatan 73                      E-mail: jpalme@dsv.su.se
-S-115 30 Stockholm, Sweden
diff --git a/Documentation/en/I-D/draft-palme-mhtml-info-01.txt b/Documentation/en/I-D/draft-palme-mhtml-info-01.txt
deleted file mode 100644
index 6535bacd..00000000
--- a/Documentation/en/I-D/draft-palme-mhtml-info-01.txt
+++ /dev/null
@@ -1,1446 +0,0 @@
-Network Working Group                        Jacob Palme
-Internet Draft                                 Stockholm
-draft-palme-mhtml-info-01.txt             University/KTH
-                                            December 2001
-Category-to-be:
-Informational
-Expires: June 2001
-
-
-
-              Sending HTML in MIME,
-     an informational supplement to the RFC:
-     MIME Encapsulation of Aggregate Documents,
-              such as HTML (MHTML)
-
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full
-conformance with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet
-Engineering Task Force (IETF), its areas, and its working
-groups.  Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of
-six months and may be updated, replaced, or obsoleted by
-other documents at any time.  It is inappropriate to use
-Internet- Drafts as reference material or to cite them
-other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be
-accessed at http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 2001. All Rights
-Reserved.
-
-
-1.   Abstract
-
-The memo "MIME Encapsulation of Aggregate Documents, such
-as HTML (MHTML)" [RFC 2557] specifies how to send packaged
-aggregate HTML objects in MIME format. This memo is an
-accompanying informational document, intended to be an aid
-to developers. This document is not an Internet standard.
-
-Issues discussed are implementation methods, caching
-strategies, problems with rewriting of URIs, making
-messages suitable both for mailers which can and which
-cannot handle Multipart/related and handling recipients
-which do not have full Internet connectivity.
-
-
-2.   Table of Contents
-
-1.  Abstract
-2.  Table of Contents
-3.  Introduction
-4.  Implementation Methods
-4.1   Method 1: Combining Viewer And MIME Receiving Program
-4.2   Method 2: Rewriting The HTML
-4.3   Method 3: Using A Translation Table
-4.4   Method 4: Using A Proxy HTTP Server To Retrieve
-       Referenced Body Parts
-4.5   Method 5: Putting The Mail Client Into A Proxy HTTP
-       Server
-4.6   Other Methods
-4.7   Combined Methods
-4.8   Communication Between Document Viewer And Mail Client
-5.  Problems with Rewriting URIs when Copying HTML
-     Documents
-6.  Caching of Body Parts
-7.  "Save as" Command
-8.  Recipients which cannot Handle the Multipart/related
-     Content-Type
-9.  Use of the Content-Type: Multipart/alternative
-9.1   Multipart/alternative inside Multipart/related
-9.2   Multipart/alternative outside Multipart/related
-9.3   Comparing the Two Methods
-9.4   Reducing the Download Time
-10. Writing Readable HTML
-11. Textual Alternatives to HTML Forms
-11.1  Form in HTML Format
-11.2  The same Form In Textual Format
-12. Recipient may not have Full Internet Connectivity
-13. Encoding of Non-Ascii Characters
-14. Conversion from HTTP to MIME
-15. Default Font Size
-16. Copyright and Disclaimer
-17. Acknowledgments
-18. References
-19. Author's Address
-
-
-Mailing List Information
-
-Further discussion on this document should be done through
-the mailing list MHTML@SEGATE.SUNET.SE.
-
-To subscribe to this list, send a message to
-    LISTSERV@SEGATE.SUNET.SE
-which contains the text
-SUB MHTML <your name (not your email address)>
-
-Archives of this list are available by anonymous ftp from
-    FTP://SEGATE.SUNET.SE/lists/MHTML/
-The archives are also available by email. Send a message to
-LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get
-a list of the archive files, and then a new message "GET
-<file name>" to retrieve the archive files.
-
-Comments on less important details may also be sent to the
-editor, Jacob Palme <jpalme@dsv.su.se>.
-
-More information may also be available at URL:
-HTTP://dsv.su.se/jpalme/ietf/mhtml.html
-
-
-3.   Introduction
-
-[MHTML] specifies how to send packaged aggregate HTML
-objects in MIME multipart format. This memo is an
-accompanying informational document, intended to be an aid
-to developers. This document is not an Internet standard.
-
-The latest revised version of this document can be find in
-plain text
-and HTML format at
-http://dsv.su.se/jpalme/ietf/mhtml.html#info.
-
-
-4.   Implementation Methods
-
-The [MHTML] standard has been intentionally written to be
-implementable both in cases where a HTML document viewer
-(web browser) and a program receiving MIME objects, such as
-an email program, are combined, and when they are separate
-programs. Implementation is of course easier if the
-document viewer is combined with the MIME receiving client.
-
-Below are described different implementation methods. Real
-implementations may sometimes combine ideas from more than
-one of the different methods described below.
-
-Note: Some document viewers can take a whole document of
-"Content-Type: message" or "Content-Type: multipart" as one
-single file to be displayed. When such viewers are known to
-be used, the problems described below become much easier to
-handle, just submit the whole combined MIME message as a
-single file to the viewer.
-
-4.1  Method 1: Combining Viewer And MIME Receiving Program
-
-This is the architecturally simplest approach. A
-web-browser with a built in MIME receiving program (such as
-an email program) will be able to use its own document
-viewer capabilities to display HTML-formatted messages.
-Since it is the same program, that program will more easily
-be able to connect a URL in the HTML text to a body part in
-the message.
-
-4.2  Method 2: Rewriting The HTML
-
-     +----------+                          +--------+
-     | Document |                          | Mail   |
-     | viewer   |                          | client |
-     +-------+--+                          +-+------+
-             |                               |
-          +--+-------------------------------+--+
-          | +----------+  +--+  +--+            |
-          | | Start    |  |  |  |  | Related    |    Figure 1
-          | | HTML     |  |  |  |  | body part  |
-          | | document |  |  |  |  | parts      |
-          | +----------+  +--+  +--+            |
-          +-------------------------------------+
-
-If the document viewer is separate from the MIME receiving
-client, the MIME client might turn over the HTML body part
-to the document viewer and ask it to display it (Figure 1).
-One way of doing this is to store the HTML body part in a
-file, and ask the document viewer to display this file. If
-multipart/related is used, this can be implemented by
-storing all the body parts within the multipart/related in
-an otherwise empty folder/directory.
-
-The mail client may have to rewrite the HTML, replacing
-URI-s with (possibly relative) URL-s which the Document
-viewer can resolve as file names in the same
-directory/folder where the HTML document itself is stored
-when turning it over to the Document viewer. Problems with
-such rewriting of URIs is discussed in section 5 below.
-
-4.3  Method 3: Using A Translation Table
-
-     +----------+                         +--------+
-     | Document |                         | Mail   |
-     | viewer   |                         | client |
-     +-------+--+                         +-+------+
-             |                              |
-          +--+------------------------------+-+
-          | +--------+  +--+  +--+            |
-          | | Trans-
-  |  |  |  |  | Related    |        Figure 2
-          | | lation |  |  |  |  | body part  |
-          | | table  |  |  |  |  | parts      |
-          | +--------+  +--+  +--+            |
-          +-----------------------------------+
-
-An alternative to rewriting the HTML file before turning it
-over to the Document viewer may be to use a translation
-table, in case the Document viewer has the capability to
-use such a table to rewrite URL-s on the fly while
-displaying the document (Figure 2). This requires that the
-Document viewer is capable of receiving CID: URL-s and
-resolving them using this translation table in the same way
-as for other URL-s.
-
-4.4  Method 4: Using A Proxy HTTP Server To Retrieve
-Referenced Body Parts
-
-     +--------+       +-----------+       +--------+
-     | Proxy  |       | Data base |       | Mail   |
-     | web    |-------| of cached |-------| server |
-     | server |       | objects   |       |        |
-     +----+---+       +-----------+       +----+---+
-          |                                    |
-     +----+-----+                         +----+---+
-     | Document |                         | Mail   |
-     | viewer   |                         | client |
-     +-------+--+                         +-+------+
-             |                              |
-          +--+------------------------------+-+
-          |         Start HTML object         |  Figure 3
-          +-----------------------------------+
-
-Yet another method is to use a proxy web server, to which
-the document viewer requests are sent, and which will then
-use the cached body parts instead of normal web retrieval
-from the network (Figure 3). If the Document viewer is set
-to use this proxy server for all URL-s, including CID
-URL-s, no rewriting of the HTML will be necessary.
-
-4.5  Method 5: Putting The Mail Client Into A Proxy HTTP
-Server
-
-      +--------+--------+
-      | Proxy  | Mail   |
-      |  HTTP  | client |
-      | server |        |
-      +--------+--------+
-               |
-         HTTP protocol              Figure 4
-               |
-          +----+-----+
-          | Document |
-          | Viewer   |
-          +----------+
-
-A mail client can also be included in an HTTP server
-(Figure 4). The user will then not have to install any mail
-client software in his personal computer; all the mail
-functionality is mapped on HTTP and HTML elements.
-
-4.6  Other Methods
-
-The mail client and the document viewer can of course
-communicate in other ways, such as using inter-process
-communication.
-
-4.7  Combined Methods
-
-Several of the methods described above can also be
-combined. The mailer might for example display simpler HTML
-documents itself, but automatically or manually transfer
-the HTML documents to a separate HTML viewer for more
-complex documents.
-
-A common practice in HTML viewers is to simply ignore all
-markups which the viewer does not understand. This
-practice, if implemented in a mailer with limited HTML
-viewing capabilities, might mean that the user is shown a
-very incomplete message without any warning that
-information is missing. In this case, it is better to give
-the user some kind of warning, combined with a command to
-view the letter with a separate HTML viewer, or turn the
-document over automatically to a separate viewer when the
-document contains markup which the mailer cannot render
-itself.
-
-4.8  Communication Between Document Viewer And Mail Client
-
-Many document viewers (web browsers) have API-s to allow
-other programs to communicate with them. There is however
-no accepted real or de-facto standard for such API-s, which
-means that a mail program which relies on such API-s will
-only be able to use those document viewers, whose API they
-support.
-
-Note however, that most of the methods described above can
-be implemented with a very minimal such API. The only API
-function needed is to be able to tell a document viewer,
-when it is started, to open a particular file. And this API
-function is a standardized part of the operating system on
-most platforms. In particular, method 1 and 3 above uses
-the functionality that a relative URL is resolved with the
-location of the base document as base. This means that if
-the base document is a file, relative URL-s will be
-resolved as FILE URL-s in the same directory/folder where
-the HTML document itself is placed.
-
-There is a need for buttons in the Web page which the user
-can use to get back to the mail program again after reading
-the mail with the document viewer. A common technique to
-achieve this is to define a new MIME data type for this
-button. The document viewer is then configured to transfer
-control to the mail client when the user pushes this
-button; i.e. downloads a file of this new MIME type.
-
-
-5.   Problems with Rewriting URIs when Copying HTML
-Documents
-
-Sending of HTML-formatted messages is based on the
-assumption that an HTML documents, together with in-line
-objects like images, applets and frames, can be copied into
-a MIME message. Such copying may require rewriting of URIs
-containing references between the different message parts.
-The MHTML standard [MHTML] has been carefully prepared to
-allow existing web pages to be copied without such
-rewriting, through the use of the Content-Location MIME
-content heading field.
-
-There is however a problem if the source HTML document
-contains relative URIs in parameters to objects and
-applets, such as in the example below:
-From: foo1@bar.net
-To: foo2@bar.net
-Subject: A simple example
-Mime-Version: 1.0
-Content-Type: multipart/related;
-boundary="boundary-example-1";
-                  type=Text/HTML
-Content-Base: "http://www.ietf.cnri.reston.va.us"
-
---boundary-example 1
-Content-Type: Text/HTML; charset=US-ASCII
-
-   ... text of the HTML document...
-<OBJECT
-    CLASSID = "clsid:5220cb21-c88d-11cf-b347-00aa00a28331">
-    <PARAM NAME="imageurl" VALUE="image.gif">
-</OBJECT>
-...etc...
-
---boundary-example-1
-Content-Location: "image.gif"
-Content-Type: IMAGE/GIF
-Content-Transfer-Encoding: BASE64
-
-R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk
-5
-..etc...
-
---boundary-example-1--
-
-From: foo1@bar.net
-To: foo2@bar.net
-Subject: A simple example
-Mime-Version: 1.0
-Content-Type: multipart/related;
-boundary="boundary-example-1";
-                  type=Text/HTML
-Content-Base: "http://www.ietf.cnri.reston.va.us"
-
---boundary-example 1
-Content-Type: Text/HTML; charset=US-ASCII
-
-   ... text of the HTML document...
-<OBJECT
-    CLASSID = "clsid:5220cb21-c88d-11cf-b347-00aa00a28331">
-    <PARAM NAME="imageurl" VALUE="image.gif">
-</OBJECT>
-...etc...
-
---boundary-example-1
-Content-Location: "image.gif"
-Content-Type: IMAGE/GIF
-Content-Transfer-Encoding: BASE64
-
-R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk
-5
-..etc...
-
---boundary-example-1--
-
-
-
-Only the object might know that the imageurl parameter is
-a relative URI. It's nearly impossible for the HTML parser
-to understand that the parameter is a relative URI.  Simply
-searching for "image.gif" is not robust, as the string
-"image.gif" may be used elsewhere. URIs in scripts can also
-have similar problems.
-
-One might envisage even more difficult cases, an applet
-might take a parameter "subject" and another parameter
-"range" and when subject="auto" and range="1-5" it could
-compute, and try to use auto1.gif, auto2.gif ... auto5.gif
-as relative URLs.
-
-Some implementation methods described in section 4 above,
-for example method 2 described in section 4.2, may require
-rewriting of the URIs in the HTML document.
-
-There is no perfect solution to this problem.
-
-One way of alleviating the problem is to produce the
-original document using only absolute URIs, preferably of
-the CID type, since they are more easily identifiable.
-
-Another way of alleviating the problem is to make all URIs
-and Content-Locations into simple relative URIs containing
-file names only (without paths, preferably using a file
-name format common to most platforms, i.e. 1-6 ascii
-letters or digits, a period, and 1-3 extension ascii
-letters or digits). An implementation using method 2
-described in section 4.2 above can then just store the
-parts as files in an empty directory on the recipient
-computer with the Content-Locations as file names. It can
-then turn the start HTML file over to a document viewer,
-and need not rewrite the URIs at all. This simple variant
-of use of the MHTML standard is probably most robust, and
-those implementors who can control the production of the
-HTML documents to be sent are thus recommended to use this
-variant.
-
-
-6.   Caching of Body Parts
-
-Suppose a message contains body parts with the
-Content-Location header as defined in [MHTML]. A receiving
-agent might then put this body part into a web cache, with
-the URI in the Content-Location as its name, so that later
-retrievals of this URI use the cached body parts. There is
-however no guarantee that such a cached item is correct.
-Such caching is thus not recommended for use in other ways
-than for resolution of links within one particular MIME
-message.
-
-The MHTML standard does not cover links between different
-messages, but if you want to implement this, use of Content-
-ID and/or Message-ID, rather than Content-Location, is
-recommended.
-
-If incoming messages are stored in a store where messages
-can be automatically deleted (purged), purging of body
-parts should not occur before purging of the whole message,
-to which they belong.
-
-If an incoming message contains a body part which is linked
-via Content-Location, then no HTTP lookup should be
-performed to check if the body part is recent. The message
-should thus still contain the old HTML document, even if
-the HTTP-available document has been revised. (Example:
-"Here is the weather map of October 29, 1997"). Exception
-from this is:
-
-(a) If the linked document is not enclosed in the message,
-but referred
-     to via Content-Type: message/external-body, then the
-latest version
-     should be shown using ordinary HTTP caching
-conventions.
-
-(b) If a new message is sent with a Supersedes reference to
-the old
-     message, the old message should still show the old
-version of all
-     the body parts, but it might be wise to inform the user
-that a
-     superseding message is available.
-
-
-7.   "Save as" Command
-
-Many HTML viewers have a "Save as" command to save an HTML
-document in a local file. Usually, this command has two
-variants, "Save as text" which converts the HTML document
-to plain text before saving it, and "Save as source" which
-saves the HTML document as an HTML-formatted document.
-
-These two variants may not be enough in the case of MHTML
-documents. There is a third option, which might be named
-"Save as aggregate". This option would save the HTML plus
-all related parts in a file with the Content-Type:
-Multipart/related. The file would thus begin with the
-heading of the Multipart/related body part.
-
-There are two variants of this: Saving the document as it
-looked like when you got it, or saving the document
-including all inline body parts, even those you had to
-retrieve from the Internet when showing the message to the
-user. The second format is of special value, because it
-provides an archiving format of the full document, allowing
-the user to view it in the future as it looked like at one
-particular time, even though web content may change in the
-future.
-
-Finally, a user may also want to save the e-mail or http
-heading fields of an incoming message. This is sometimes
-the same as "Save as aggregate", but may include additional
-body parts before or outside of the mulitpart/related
-aggregate.
-
-To indicate whether such a saved document was received by e-
-mail or http, it might be saved with an additional
-surrounding body part of content-type message/rfc822 or
-message/http.
-
-Example, suppose you receive by e-mail the following
-message:
-
-    MAIL FROM:<alice@bar.net>
-    RCPT TO:<bob@foo.net>
-    DATA
-    From: Alice <alice@bar.net>
-    To: Bob <bob2@foo.net>
-    Date: 23 Jan 1998 10:51
-    Subject: A simple example
-    Mime-Version: 1.0
-    Content-Type: multipart/related; boundary="boundary-example-1";
-                  type="text/html"; start=<foo3@foo1@bar.net>
-
-    --boundary-example-1
-       Content-Type: text/html;charset=US-ASCII
-       Content-ID: <foo3@foo1@bar.net>
-
-       Here is the IETF logo with white background:
-       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
-        ietflogo.gif"
-        ALT="IETF logo with white background">
-       And here is the IETF logo with transparent background:
-       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
-        ietflogo2e.gif"
-       <ALT="IETF logo with transparent background">
-
-    --boundary-example-1
-        Content-Location: ietflogo.gif
-        Content-Base: http://www.ietf.cnri.reston.va.us/images/
-       Content-Type: IMAGE/GIF
-       Content-Transfer-Encoding: BASE64
-
-
-       R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
-
-       NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
-       etc...
-
-    --boundary-example-1--
-
-
-
-Saving the above message as text might give the following
-file:
-
-    From: Alice <alice@bar.net>
-    To: Bob <bob2@foo.net>
-    Date: 23 Jan 1998 10:51
-    Subject: A simple example
-
-       Here is the IETF logo with white background:
-       IETF logo with white background
-       And here is the IETF logo with transparent
-background:
-       IETF logo with transparent background
-
-Saving the same text as html source might give the
-following file:
-
-       Here is the IETF logo with white background:
-       <IMG
-SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
-        ALT="IETF logo with white background">
-       And here is the IETF logo with transparent background:
-       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
-        ietflogo2e.gif"
-       <ALT="IETF logo with transparent background">
-
-Saving the same text as aggregate might give the following
-file
-
-    From: Alice <alice@bar.net>
-    To: Bob <bob2@foo.net>
-    Date: 23 Jan 1998 10:51
-    Subject: A simple example
-    Mime-Version: 1.0
-    Content-Type: multipart/related; boundary="boundary-example-1";
-                  type="text/html"; start=<foo3@foo1@bar.net>
-
-    --boundary-example-1
-       Content-Type: text/html;charset=US-ASCII
-       Content-ID: <foo3@foo1@bar.net>
-
-       Here is the IETF logo with white background:
-       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
-        ietflogo.gif"
-        ALT="IETF logo with white background">
-       And here is the IETF logo with transparent background:
-       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
-        ietflogo2e.gif"
-       <ALT="IETF logo with transparent background">
-
-    --boundary-example-1
-        Content-Location: ietflogo.gif
-        Content-Base: http://www.ietf.cnri.reston.va.us/images/
-       Content-Type: IMAGE/GIF
-       Content-Transfer-Encoding: BASE64
-
-
-       R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
-       NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
-       etc...
-
-    --boundary-example-1--
-
-
-
-Saving the same text as archiving aggregate might give the
-following file (where the missing body part is fetched
-through http and added to the saved file):
-
-    From: Alice <alice@bar.net>
-    To: Bob <bob2@foo.net>
-    Date: 23 Jan 1998 10:51
-    Subject: A simple example
-    Mime-Version: 1.0
-    Content-Type: multipart/related; boundary="boundary-example-1";
-                  type="text/html"; start=<foo3@foo1@bar.net>
-
-    --boundary-example-1
-       Content-Type: text/html;charset=US-ASCII
-       Content-ID: <foo3@foo1@bar.net>
-
-       Here is the IETF logo with white background:
-       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
-        ietflogo.gif"
-        ALT="IETF logo with white background">
-       And here is the IETF logo with transparent background:
-       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
-        ietflogo2e.gif"
-       <ALT="IETF logo with transparent background">
-
-    --boundary-example-1
-        Content-Location: ietflogo.gif
-        Content-Base: http://www.ietf.cnri.reston.va.us/images/
-       Content-Type: IMAGE/GIF
-       Content-Transfer-Encoding: BASE64
-
-
-       R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
-       NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
-       etc...
-
-    --boundary-example-1
-      Content-Location: ietflogo2e.gif
-      Content-Base: http://www.ietf.cnri.reston.va.us/images/
-      Content-Type: IMAGE/GIF
-      Content-Transfer-Encoding: BASE64
-
-
-      R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4
-      SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa
-      etc...
-
-    --boundary-example-1--
-
-
-
-Saving the same message as message might give the following
-file:
-
-    from:<alice@bar.net>
-    To:<bob@foo.net>
-    Mime-Version: 1.0
-    Content-Type: Message/rfc822;
-          boundary="boundary-example-2"
-
-    --boundary-example-2
-    From: Alice <alice@bar.net>
-    To: Bob <bob2@foo.net>
-    Date: 23 Jan 1998 10:51
-    Subject: A simple example
-    Mime-Version: 1.0
-    Content-Type: multipart/related;
-boundary="boundary-example-1";
-                  type="text/html"; start=<foo3@foo1@bar.net>
-
-    --boundary-example-1
-       Content-Type: text/html;charset=US-ASCII
-       Content-ID: <foo3@foo1@bar.net>
-
-       Here is the IETF logo with white background:
-       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
-        ietflogo.gif"
-        ALT="IETF logo with white background">
-       And here is the IETF logo with transparent background:
-       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
-        ietflogo2e.gif"
-       <ALT="IETF logo with transparent background">
-    --boundary-example-1
-        Content-Location: ietflogo.gif
-        Content-Base: http://www.ietf.cnri.reston.va.us/images/
-       Content-Type: IMAGE/GIF
-       Content-Transfer-Encoding: BASE64
-
-       R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
-       NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
-       etc...
-
-    --boundary-example-1--
-    --boundary-example-2--
-
-
-
-8.   Recipients which cannot Handle the Multipart/related
-Content-Type
-
-A message sent according to the specifications in [MHTML]
-may have recipients, whose mailers cannot handle the
-Multipart/related Content-Type in the way specified in
-[MHTML].
-
-According to [MIME1] a mailer which encounters an unknown
-subtype to Multipart, should handle this as
-Multipart/mixed.
-
-To improve this, Multipart/alternative can be used as
-discussed in section 9 of this memo.
-
-Content-Disposition, as specified in [CONDISP] and in
-[MHTML], section 10, can also be used as an aid to mailers
-which do not understand Multipart/related.
-
-Captions on images, which are included in the HTML text,
-might for non-HTML-capable recipients be found in the
-Content-Description header [CONDISP]. Do not assume,
-however, that HTML-capable user agents will display the
-Content-Description header, they may assume that this
-information is included in the HTML text instead.
-
-
-9.   Use of the Content-Type: Multipart/alternative
-
-If the message is sent to recipients, all of which may not
-have mailers capable of handling the Text/HTML
-content-type, then the "Content-Type:
-Multipart/Alternative" [MIME1] can be used in two ways:
-
-9.1  Multipart/alternative inside Multipart/related
-
-The Multipart/alternative is put inside the "Content-Type
-Multipart/related", body parts can be specified with
-"Content-Type: Text/plain" as the first choice, and
-"Content-Type: Text/HTML" as the second choice.
-
-Example:
-
-    Content-Type: Multipart/related;
-boundary="boundary-example-1";
-                  type=MULTIPART/ALTERNATIVE
-
-       --boundary-example 1
-       Content-Type: MULTIPART/ALTERNATIVE
-       Boundary: boundary-example-2
-
-          --boundary-example-2
-          Content-Type: Text/plain
-
-          ... plain text version of the document for recipients
-          whose mailers cannot handle Text/HTML ...
-
-          --boundary-example-2
-          Content-Type: Text/HTML; charset=US-ASCII
-          Content-ID: content-id-example@example.host
-
-          ... text of the HTML document ...
-
-          --boundary-example-2--
-       --boundary-example-1
-       Content-Type: Image/GIF
-
-       ... a body part, to which the HTML document has a link  ...
-       --boundary-example-1--
-
-
-
-Note that the type parameter of Multipart/related in this
-case should be Multipart/alternative and not Text/HTML.
-
-
-9.2  Multipart/alternative outside Multipart/related
-
-The multipart/alternative is put outside the
-Multipart/Related, with Multipart/Related as one
-alternative and Multipart/Mixed as the other alternative.
-Note however that the [MHTML] does not recommend links from
-inside Multipart/Related to objects outside of the
-Multipart/Related, so putting inline images outside the
-Multipart/Related is not suitable. Instead, such inline
-images may have to repeated in both branches of the
-multipart/alternative with this method.
-
-Example:
-
-    Content-Type: MULTIPART/ALTERNATIVE
-    Boundary: boundary-example-1
-
-    --boundary-example-1
-       Content-Type: Multipart/mixed; boundary="boundary-example-3"
-
-       --boundary-example-3
-          Content-Type: Text/plain; charset=US-ASCII
-
-          ... plain text version of the message for recipients
-          whose mailers cannot handle Text/HTML ...
-
-       --boundary-example-3
-       Content-Type: Image/GIF
-
-          ... A picture associated with the plain text message  ...
-       --boundary-example-3--
-
-    --boundary-example-1
-       Content-Type: Multipart/related; boundary="boundary-example-1";
-                     type=Text/HTML
-
-       --boundary-example 2
-          Content-Type: Text/HTML; charset=US-ASCII
-          Content-ID: content-id-example@example.host
-
-          ... text of the HTML document ...
-
-       --boundary-example-2
-       Content-Type: Image/GIF
-
-          ... a body part, to which the HTML document has a link  ...
-       --boundary-example-2--
-    --boundary-example-1--
-
-
-9.3  Comparing the Two Methods
-
-When choosing between these two methods of employing
-multipart/alternative, note the following:
-
-  (1)  Clients which do not support Multipart/related,
-       and which thus will interpret it as
-       Multipart/mixed, will with choice 9.1 display the
-       inline objects. Thus, a recipient whose mailer
-       can handle image/gif but not multipart/related
-       will still be shown the images, they will not be
-       suppressed by being inside a suppressed branch of
-       the Multipart/alternative.
-
-(2)   Choice 9.2 will not show inline images in the
-       Multipart/Related, unless this information is
-       repeated in both branches of the
-       Multipart/Alternative.
-
-A general warning: Some mailers do not support
-"Content-Type: Multipart/alternative", and may then
-interpret it as Multipart/mixed, even though support of
-multipart/alternative is required for MIME conformance.
-
-
-9.4  Reducing the Download Time
-
-If a message is sent as multipart/alternative, this would
-normally mean that the mail client downloads both variants,
-and then shows only one of the to the user. This will thus
-increase the download time. A way of avoiding this problem
-is to use the FETCH command of IMAP, which allows a client
-to download only certain body parts from a multipart
-message.
-
-
-10.  Writing Readable HTML
-
-An alternative to use of multipart/alternative is to
-produce HTML code which is is easy to read as it is. This
-alternative only works if you restrict the use of HTML
-features, for example if you have a special program to
-generate the HTML text.
-
-Below is an example of such a readable HTML text:
-
-<p>   This is an example of HTML code, which is written
-       so as to be readable for people who read it as
-       plain text.
-
-<p>   Here is the second paragraph, which contains a
-          <a href="cid:456*foo@bar.net"> link
-</a>  to a separate body part.
-<p>   Here is an embedded picture:
-
-<p>      <img src="cid:123*foo@bar.net" width="13" height="13">
-
-<p>   End of this HTML-formatted message.
-
-
-
-11.  Textual Alternatives to HTML Forms
-
-One important usage of HTML in e-mail is to send forms,
-which the recipients fill in and return. It is then
-problematic how to handle recipients whose mailers do not
-support HTML. One way is to use textual encoding of the
-forms. This encoding is done so that the user action needed
-to send in the form is made simple also for those who have
-only textual e-mail systems. Important is that the textual
-users are not forced to write complex commands in special
-command languages. Instead, the form should be written so
-that the user need only make simple changes to the form
-before sending it back, like deleting or adding single
-characters.
-
-Below is an example which shows how this can be done. The
-main principle is that every line beginning with ";" is an
-explanation for the reader, and every line beginning with
-"!" is a text, which the user can convert into a command by
-just deleting the "!" in front of the line.
-
-The users will thus have to learn a very simple rule of
-filling in forms: Just delete the "!" in front of your
-selections.
-
-Technically, the recipient of a filled-in textual form
-should regard all lines beginning with ";" or "!" as
-comment, and interpret all other lines as commands.
-
-11.1 Form in HTML Format
-
-<FORM action="mailto:meeting-scheduling@ietf.org"
-method="POST">
-
-<P>Which meeting date do you prefer?
-
-<P>1 December 1997 <SELECT NAME="19971201">
-    <OPTION>Very good
-    <OPTION>Good
-    <OPTION>Acceptable
-    <OPTION>Bad
-    <OPTION>Very bad
-</SELECT>
-
-<P>7 December 1997 <SELECT NAME="19971207">
-    <OPTION>Very good
-    <OPTION>Good
-    <OPTION>Acceptable
-    <OPTION>Bad
-    <OPTION>Very bad
-</SELECT>
-
-<P>14 December 1997 <SELECT NAME="19971214">
-    <OPTION>Very good
-    <OPTION>Good
-    <OPTION>Acceptable
-    <OPTION>Bad
-    <OPTION>Very bad
-</SELECT>
-
-<P>21 December 1997 <SELECT NAME="19971221">
-    <OPTION>Very good
-    <OPTION>Good
-    <OPTION>Acceptable
-    <OPTION>Bad
-    <OPTION>Very bad
-</SELECT>
-
-<P>Who should be the chairman?
-
-<P><INPUT TYPE="radio" NAME="chairman" VALUE="Mary">Mary
-
-<P><INPUT TYPE="radio" NAME="chairman" VALUE="John">John
-
-<P>Do you want simultaneous translation during the meeting?
-
-<P><INPUT TYPE="checkbox" NAME="translation"
-VALUE="English">To and
-from English
-
-<P><INPUT TYPE="checkbox" NAME="translation"
-VALUE="French">To and
-from French
-
-<P><INPUT TYPE="checkbox" NAME="translation"
-VALUE="Japanese">To and
-from Japanese
-
-<P>Please propose issues to discuss during the meeting:
-
-<P><TEXTAREA NAME="issues" ROWS=7 COLS=66></TEXTAREA>
-
-<P><INPUT TYPE="submit" NAME="Submit"
-VALUE="Submit"><INPUT TYPE="reset" VALUE="Reset">
-
-
-11.2 The same Form In Textual Format
-
-; This is a computer-generated form. Please fill it in and return it
-; to meeting-scheduler@ietf.org. To fill in the form, just copy its
-; text into your reply and remove the exclamation mark (!) in front
-; of your choices.
-
-; If your mailer adds ">" or "> " in front of lines, you can keep
-; these or remove them as you prefer.
-
-Question 1: Which meeting date do you prefer?
-
-Option 1.1: 1 December 1997
-! Very good
-! Good
-! Acceptable
-! Bad
-! Very bad
-
-Option 1.2: 7 December 1997
-! Very good
-! Good
-! Acceptable
-! Bad
-! Very bad
-
-Option 1.3: 14 December 1997
-! Very good
-! Good
-! Acceptable
-! Bad
-! Very bad
-
-Option 1.4: 21 December 1997
-! Very good
-! Good
-! Acceptable
-! Bad
-! Very bad
-
-Question 2: Who should be the chairman?
-! Mary
-! John
-
-Question 3: Do you want simultaneous translation during the
-meeting?
-
-Option 3.1: To and from English
-! Yes
-! No
-
-Option 3.2: To and from French
-! Yes
-! No
-
-Option 3.3: To and from Japanese
-! Yes
-! No
-
-Question 4: Please propose issues to discuss during the
-meeting.
-Write your proposal on the empty lines below.
-
-
-
-
-
-
--- End of Question 4
-
-
-
-12.  Recipient may not have Full Internet Connectivity
-
-The recipient of a message sent by email may not always
-have full Internet connectivity. The recipient may be
-behind a gateway or firewall which prohibits or restricts
-Internet connectivity.
-
-This means that the recipient may not be able to resolve
-URI-s in an email message, unless the referred-to documents
-are included in the email message itself. Thus, it is often
-suitable to include in an email message all documents which
-are referred to (directly or indirectly) by URI-s in the
-message. This may of course not always be possible, in some
-cases the set of referred-to documents (directly or
-indirectly) may be the whole WWW document space, i.e.
-millions of documents. A choice must then be made how much
-to include. Of course, it is most important to include all
-inline objects, i.e. objects linked by such hyperlinks as
-IMG, etc., which specify that the linked objects are to be
-shown to the user immediately.
-
-In the case of ACTION elements in HTML forms, by making
-these ACTION elements of the "mailto:" URL type, rather
-than the "http:" URL type, you will enable also recipients
-without full Internet connectivity to fill in and send in
-your forms. The HTML specification [HTML2] allows default
-action when no ACTION element is included, but this default
-action may not be suitable when sending the HTML document
-via email. Thus, it is better to always put an explicit
-ACTION element into HTML forms sent by email.
-
-A disadvantage with the "mailto:" URL as ACTION, however,
-is that this may not work if the user has not specified his
-e-mail address in the preferences of this HTML viewer. This
-is common for multi-user workstations.
-
-Including URLs, which have to resolved over the Internet,
-typically referring to 1x1 pixel transparent images, is a
-known method for spammers to get information about the
-recipient of e-mail. It is possible that some mailers will
-restrict or disallow this in order to stop this method of
-information-gathering by spammers.
-
-
-Encoding of Non-Ascii Characters
-
-          Displayed text                        Displayed text
-                |                                     ^
-                V                                     |
-          +-------------+                       +----------------+
-          | HTML editor |                       | HTML viewer    |
-          |             |                       | or Web browser |
-          +-------------+                       +----------------+
-              |                                       ^
-              V                                       |
-          HTML markup                             HTML markup
-              |                                       ^
-              V                                       |
-   +---------+ +---------------+       +-------------+ +---------------+
-   | MIME    | | MIME content- |       | MIME        | | MIME content- |
-   | encap-  | | transfer-     |       | heading     | | transfer-     |
-   | sulator | | encoder       |       | interpreter | | decoder       |
-   +---------+ +---------------+       +-------------+ +---------------+
-     |              |                            ^              ^
-     V              V         +-----------+      |              |
-MIME heading + MIME content->| Transport |->MIME heading + MIME content
-                              +-----------+
-
-                                Figure 5
-
-Definitions (see Figure 5):
-
-Displayed     A visual representation of the intended
-text          text.
-
-HTML markup   A sequence of characters formatted
-               according to the HTML specification
-               [HTML2].
-
-MIME content  A sequence of octets physically forwarded
-               via email, may use MIME content-transfer-
-               encoding as specified in [MIME1].
-
-HTML editor   Software used to produce HTML markup.
-
-MIME content- Software used to encode non-US-ASCII
-transfer-     charactersr as specified in [MIME1].
-encoder
-
-MIME content- Software used to decode non-US-ASCII
-transfer-     characters as specified in [MIME1].
-decoder
-
-MIME heading  Software used to interpret the information
-interpreter   in MIME  headings.
-
-HTML viewer   Software used to display HTML documents to
-               recipients.
-
-Some implementations may have a choice of whether to
-represent non-ascii characters at the HTML layer (using "&"
-entity references or numeric character references as
-defined in [HTML2] section 3.2.1) or at the MIME layer
-(using Content-Transfer-Encoding as defined in [MIME1]
-section 5).
-
-In choosing between these two representation methods, note
-the following effects:
-
-(1)   Modifying HTML markup may disrupt security content
-       integrity  checksums. If the checksums are computed
-       between the HTML editor  and the MIME encapsulator,
-       then making the encoding in the MIME  encapsulator
-       will not break the checksums.
-
-(2)   The choice of modifying HTML markup may be more
-       suitable for  recipients whose mailers do not
-       support MIME.
-
-(3)   Using MIME Content-Transfer-Encoding may be more
-       suitable for  recipients who have MIME-compliant
-       mailers but do pass the text over  to a document
-       viewer (web browser).
-
-
-14.  Conversion from HTTP to MIME
-
-Information received or retrieved using HTTP cannot always
-be sent unchanged as email using the "Content-Type:
-Text/HTML", because of the restrictions which MIME places
-on the format of "Content-Type: Text/HTML". The same
-problem may occur for documents retrieved via HTTP, which
-are in other textual formats than HTML. In particular, note
-the following:
-
-(a)  Content-encodings allowed in HTTP, but not allowed in
-      MIME, must  be removed.
-
-(b)  HTTP allows line breaks as bare CRs or bare LFs or
-      something  else, while MIME only allows line breaks as
-      CRLF in subtypes  of the Text content-type.
-
-(c)  HTTP allows character sets like Unicode-1-1, which do
-      not  represent line breaks as CRLFs, such text may have
-      to be  rewritten to character sets like
-      Unicode-1-1-UTF-7 in which  line breaks are represented
-      as CRLFs.
-
-A good overview of the differences, with regard to the use
-of "Content-Type: Text", between MIME and HTTP, can be
-found in [HTTP] appendix C.
-
-If you want to provide web documents, which can be sent
-through e-mail without modification (which might break
-integrity checksums), then you SHOULD provide them up in
-the canonical form, with line breaks as CRLF, and avoid
-lines longer than 76 characters/line.
-
-If you want to send HTTP unchanged via email, you might
-consider using the "Content-Type: Message/HTTP" instead of
-the "Content-Type: Text/HTML". Note that with this Content-
-Type, the whole object, as sent through HTTP, can be
-encoded as a single object with, for example, BASE64
-encoding. After decoding of the BASE64, the resulting
-object can have HTTP peculiar formats, like single LF or
-single CR between lines. However, some mailers may not be
-capable of handling the Message/HTTP Content-Type.
-
-Example, the binary part of the following message
-
-    Content-Type: message/http
-    Content-Transfer-Encoding: base64
-
-
-SFRUUC8xLjEgMjAwIE9LDURhdGU6IFNhdCwgMTQgRmViIDE5OTggMTM6MDM
-6MzggR01U
-
-DVNlcnZlcjogQXBhY2hlLzEuMi40DUxhc3QtTW9kaWZpZWQ6IFdlZCwgMjM
-gSnVsIDE5
-    ... ... ...
-
-
-might, when the base64 encoding above is decoded, yield:
-
-    HTTP/1.1 200 OK
-    Date: Sat, 14 Feb 1998 13:03:38 GMT
-    ETag: "43788-124-33d658c5"
-    Content-Length: 292
-    Accept-Ranges: bytes
-    Content-Type: text/html
-
-    ... <HTML data with only LF between lines> ...
-
-
-
-15.  Default Font Size
-
-Many HTML editors and viewers allow the user to specify the
-size of the default font (<FONT SIZE=3> or <FONT SIZE="+0">
-according to personal wishes, for example 10 pt or 12 pt or
-14 pt depending on eye sight and screen distance. This
-setting should *not* cause a change in the FONT SIZE= value
-in the generated HTML which is produced and sent. The
-reason for this is that otherwise users may inadvertently
-send whole letters with the text in <FONT SIZE=1> or <FONT
-SIZE=2>, which may be easy to read for the sender but
-difficult to read for some recipients.
-
-Similarly, a user choice of default FONT, to for example
-GENEVA or ARIAL, should not cause <FONT FACE=GENEVA> or
-<FONT FACE=ARIAL> to be sent. User who wish to send e-mail
-with <FONT SIZE=2> or <FONT FACE=GENEVA> must explicitly
-specify this, for example using a FONT command in their
-HTML editor or e-mail text editor.
-
-
-16.  Copyright and Disclaimer
-
-The IETF takes no position regarding the validity
-or scope of any intellectual property 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;
-neither does it represent that it has made any
-effort to identify any such rights. Information on
-the IETF's procedures with respect to rights in
-standards-track and standards-related documentation
-can be found in BCP-11. Copies of claims of rights
-made available for publication 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 implementors or users of this specification can
-be obtained from the IETF Secretariat."
-
-The IETF invites any interested party to bring to
-its attention any copyrights, patents or patent
-applications, or other proprietary rights which may
-cover technology that may be required to practice
-this standard. Please address the information to
-the IETF Executive Director.
-
-Copyright (C) The Internet Society (date). 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
-implmentation 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.
-
-
-17.  Acknowledgments
-
-Harald Tveit Alvestrand, Richard Baker, Dave Crocker,
-Martin J. Duerst, Roy Fielding, Lewis Geer, Al Gilman, Paul
-Hoffman, Alexander Hopmann, Mark K. Joseph, Greg Herlihy,
-Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay
-Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin
-Nicol, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie
-Zawinski and several other people have helped us with
-preparing this memo. I alone take responsibility for any
-errors which may still be in the memo.
-
-
-18.  References
-
-Temporary note: This list contains some references to
-Internet drafts. It is anticipated that these Internet
-drafts will become RFC-s before this memo. The references
-will then in this memo be changed to refer to the
-corresponding RFC instead. This list also includes some
-RFC-s which are not up to date, and which will be replaced
-by new memos presently in ietf draft status.
-
-Ref.       Author, title
----        -------------
-
-[CONDISP]  R. Troost, S. Dorner: "Communicating
-            Presentation Information in Internet Messages:
-            The Content- Disposition Header", RFC 1806, June
-            1995.
-
-[HOSTS]    R. Braden (editor): "Requirements for Internet
-            Hosts -- Application and Support", STD-3, RFC
-            1123, October 1989.
-
-[HTML2]    T. Berners-Lee, D. Connolly: "Hypertext Markup
-            Language - 2.0", RFC 1866, November 1995.
-
-[HTTP]     J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
-            Berners-Lee: 2616 Hypertext Transfer Protocol --
-            HTTP/1.1. R. Fielding, J. Gettys, RFC 2616, June
-            1999.
-
-[MHTML]    J. Palme, A. Hopmann, N. Shelness: MIME
-            Encapsulation of Aggregate Documents, such as
-            HTML (MHTML). RFC 2557, March 1999.
-
-[MIDCID]   E. Levinson.: Content-ID and Message-ID Uniform
-            Resource Locators. RFC 2392, August 1998.
-
-[MIME1]    N. Freed & N. Borenstein: "MIME (Multipurpose
-            Internet Mail Extensions) Part One: Mechanisms
-            for Specifying and Describing the Format of
-            Internet Message Bodies", RFC 2045, November
-            1996.
-
-[MIME2]    N. Freed & N. Borenstein: "Multipurpose Internet
-            Mail Extensions (MIME) Part Two: Media Types".
-            RFC 2046, November 1996.
-
-[NEWS]     M.R. Horton, R. Adams: "Standard for interchange
-            of USENET messages", RFC 1036, December 1987.
-
-[REL]      E. Levinson.: The MIME Multipart/Related Content-
-            type. RFC 2387, August 1998.
-
-[RELURL]   R. Fielding: "Relative Uniform Resource
-            Locators", RFC 1808, June 1995.
-
-[MSGFMT]   P. Resnick: "Internet Message Format" STD 11,
-            RFC 2822, April 2001.
-
-[SMTP]     J. Klensin: "Simple Mail Transfer Protocol", RFC
-            2821, April 2001.
-
-[URL]      T. Berners-Lee, L. Masinter, M. McCahill:
-            "Uniform Resource Locators (URL)", RFC 1738,
-            December 1994.
-
-[URLBODY]  N. Freed and Keith Moore: "Definition of the URL
-            MIME External-Body Access-Type", RFC 2017,
-            October 1996.
-
-19.  Author's Address
-
-Jacob Palme                          Phone: +46-8-16 16 67
-Stockholm University and KTH         Fax: +46-8-783 08 29
-Electrum 230                         Email: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
-Working group chairman:
-
-Einar Stefferud <stef@nma.com>
diff --git a/Documentation/en/I-D/draft-palme-newfields-info-02.txt b/Documentation/en/I-D/draft-palme-newfields-info-02.txt
deleted file mode 100644
index 649f86ba..00000000
--- a/Documentation/en/I-D/draft-palme-newfields-info-02.txt
+++ /dev/null
@@ -1,255 +0,0 @@
-Network Working Group                                       Jacob Palme
-Internet Draft                                 Stockholm University/KTH
-draft-palme-newfields-info-02.doc
-IETF status: To become an informational RFC
-Expires: May 1998                                         November 1998
-
-
-
-
-Advice on the implementation of In-Reply-To, References and Supersedes
-e-mail and netnews headers
-
-
-
-Status of this Document
-
-
-This document is an Internet-Draft. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as ``work in progress.''
-
-To learn the current status of any Internet-Draft, please check the
-``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
-Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
-ftp.isi.edu (US West Coast).
-
-Copyright (C) The Internet Society 1998. All Rights Reserved.
-
-
-
-Abstract
-
-Separate Internets standards documents define the e-mail headers
-In-Reply-To, References, Supersedes and Expires. This document, which
-is an informational RFC, gives some advice on the implementation of
-these features.
-
-
-Table of Contents
-
-1. User interface
-2. Hard and soft Supersedes
-3. Data base
-4. Copyright
-5. References
-6. Author's Address
-
-1.    User interface
-
-The fields "In-Reply-To", "References" and "Supersedes" are all used to
-convey information about references between different e-mail messages
-or netnews articles.
-
-A good way to implement these fields is to tell the recipient that two
-messages reference each other, and to make it easy for readers to
-traverse threads (series of linked messages) up and down.
-
-It is also possible to have special features to see a whole thread (set
-of related messages) graphically, or as an indented list, and to allow
-users to traverse, print, save or do other actions on a thread.
-
-Example of showing a thread as an indented list:
-
-   This is entry no. 1, the start entry of the thread
-     This is entry no. 2, a reply to entry no. 1
-       This is entry no. 3, a reply to entry no. 2
-     This is entry no. 4, a reply to entry no. 1
-
-In the particular case of "Supersedes", a user who has not yet read
-either the old or the new version, may be shown only the new version as
-a new message, but with methods to easily find the old version.
-
-A way to show this information to users is to show the "In-Reply-To",
-"Supersedes" and "References" fields, possibly as buttons, and allow
-the user to click on them to get to the referred-to messages.
-Additionally, it is useful to add buttons to follow threads forward,
-with texts like "Next in thread" or "Replies" or "This document is
-referenced by" or "Superseding documents". This allows a user, when
-reading a message, to see if someone else has already replied, and it
-allows users to traverse threads downwards and not only upwards. Such
-reverse buttons should not be sent in e-mail, they are just for local
-handling in user mailbox databases. Note that their values may change
-after a message has been submitted, when more new messages arrive which
-reference it.
-
-Example of showing a message with thread information:
-
-   To: IETF-Announce: ;
-   From: The IESG <iesg-secretary@ns.ietf.org>
-   Subject: Last Call: The Auto-Submitted, Supersedes and Expires
-      Headers in E-mail and Netnews to Proposed Standard
-   In-Reply-To: <v04003a00b12335fb8686@ns.ietf.org>
-   Replied-By: <v04003a00b12335fb8687@ns.ietf.org>
-   Date: Thu, 05 Mar 1998 07:02:47 -0500
-   Sender: scoya@cnri.reston.va.us
-
-
-2.    Hard and soft Supersedes
-
-By a hard supersedes is meant a Supersedes which causes deletion of the
-superseded message. By a soft supersedes is meant a Supersedes which
-still keeps both messages, and allows a user to see and use the
-reference between them, somewhat similar to In-Reply-To and References.
-
-Supersedes is best implemented as soft supersedes. Users of the
-supersedes field should however be aware that some implementations,
-especially in Usenet News, do implement it as hard supersedes.
-
-Hard supersedes has the same security problem as the Cancel command of
-Usenet News. They can be used to maliciously delete other people's
-messages. Use of strong authentication of the author can reduce this
-risk.
-
-
-3.    Data base
-
-In order to implement threads, a data base is needed which, given a
-Message-ID, can find the message which this Message-ID refers to. This
-data base has a very simple structure, just a single value mapped to
-one or more messages. Note, however, that the same message can be
-copied to more than one mailbox, so the data base should not be
-restricted to only one location for each Message-ID.
-
-Every time a message is added, moved, copied, deleted or purged, this
-data base need to be updated.
-
-When a new message arrives, the mailer can find the messages, to which
-this message has references. Note that there is a risk that replies
-arrive before the replied-to message, so a good implementation should
-work even in this case.
-
-A problem with these kinds of Message-ID data bases is that they tend
-to become very large with time, and they easily collect garbage
-(Message-ID-s of messages not any more available in the mailbox data
-base).
-
-The two most common methods to implement such data bases are:
-
-(a) Implement a large data base, but with some method of purging to
-    avoid unlimited growth of the data base.
-
-(b) Implement a smaller data base, where all objects are deleted
-    after a certain time. A couple of months is enough if the
-    techniques described in the next paragraph are used.
-
-With implementation method (b), information about the references in the
-form of "In-Reply-To", "References", "Supersedes", "Replied-By",
-"Referenced-By" and "Superseded-By" should also be stored in the
-message headers themselves. The reason method (b) works is that it is
-very uncommon that a message has a reference to other than very recent
-messages. Thus, the lack of "Replied-By", "Referenced-By" and
-"Superseded-By" headers in these very uncommon cases is acceptable.
-
-The advantage with method (b) is that a complex garbage collection
-method, as for method (a), is not needed. A much simpler garbage
-collection method can be used instead, just removing records after a
-certain expiration time.
-
-4.    More implementation hints
-
-More implementation hints can be found at URL
-http://www.dsv.su.se/~jpalme/ietf/thread-support-proposal.html
-
-See also URL
-http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#newfields
-
-
-5.    Acknowledgements
-
-Peter Kaminski has given me valuable ideas for this document.
-
-6.    Copyright
-
-Copyright (C) The Internet Society (date). 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.
-
-
-
-7.    References
-
-Ref.            Author, title
----------       --------------------------------------------------------
-
-[AUTOLOOP]      J. Palme: "Loop control for the Auto-Submitted e-mail
-                header", draft-palme-autosub-03.txt, July 1997.
-
-[MIME1]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
-                Extensions (MIME) Part One: Format of Internet Message
-                Bodies", RFC 2045, December 1996.
-                .
-[MIME2]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
-                Extensions (MIME) Part Two:  Media Types", RFC 2046,
-                December 1996.
-
-[MIME3]         K. Moore, "MIME (Multipurpose Internet Mail Extensions)
-                Part Three:  Message Header Extensions for Non-ASCII
-                Text", RFC 2047, December 1996.
-
-[MIME4]          N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
-                Mail Extensions (MIME) Part Four:  Registration
-                Procedures", RFC 2048, January 1997.
-
-[MIME5]         "Multipurpose Internet Mail Extensions (MIME) Part Five:
-                Conformance Criteria and Examples", RFC 2049, December
-                1996.
-
-[NEWFIELDS]     J. Palme: "The Auto-Submitted, Supersedes and Expires
-                E-mail Headers", draft-ietf-mailext-new-fields-12.txt,
-                March 1998.
-
-[NEWS]          M.R. Horton, R. Adams: "Standard for interchange of
-                USENET messages", RFC 1036, December 1987.
-
-[RFC822]        D. Crocker: "Standard for the format of ARPA Internet
-                text messages." STD 11, RFC 822, August 1982.
-
-[SMTP]          J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
-                821, August 1982.
-
-8.    Author's Address
-
-Jacob Palme                          Phone: +46-8-16 16 67
-Stockholm University and KTH         Fax: +46-8-783 08 29
-Electrum 230                         E-mail: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
diff --git a/Documentation/en/I-D/draft-palme-newsmail-01.txt b/Documentation/en/I-D/draft-palme-newsmail-01.txt
deleted file mode 100644
index 2cc38fc0..00000000
--- a/Documentation/en/I-D/draft-palme-newsmail-01.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-J. Palme: jpalme@dsv.su.se                                                        

-

-

diff --git a/Documentation/en/I-D/draft-palme-select-01.txt b/Documentation/en/I-D/draft-palme-select-01.txt
deleted file mode 100644
index 1795600b..00000000
--- a/Documentation/en/I-D/draft-palme-select-01.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-J. Palme: jpalme@dsv.su.se                                                        

-J. Kaers: johan@starlab.net                                                       

-

-

diff --git a/Documentation/en/I-D/draft-palme-supersedes-01.txt b/Documentation/en/I-D/draft-palme-supersedes-01.txt
deleted file mode 100644
index d09a2ded..00000000
--- a/Documentation/en/I-D/draft-palme-supersedes-01.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-This Internet-Draft has expired and is no longer available.
-
-Unrevised documents placed in the Internet-Drafts directories have a
-maximum life of six months. After that time, they must be updated, or
-they will be deleted. This document was deleted on March 20, 2000.
diff --git a/Documentation/en/I-D/draft-varshavchik-data-smtpext-02.txt b/Documentation/en/I-D/draft-varshavchik-data-smtpext-02.txt
deleted file mode 100644
index d09a2ded..00000000
--- a/Documentation/en/I-D/draft-varshavchik-data-smtpext-02.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-This Internet-Draft has expired and is no longer available.
-
-Unrevised documents placed in the Internet-Drafts directories have a
-maximum life of six months. After that time, they must be updated, or
-they will be deleted. This document was deleted on March 20, 2000.
diff --git a/Documentation/en/I-D/draft-varshavchik-verp-smtpext-02.txt b/Documentation/en/I-D/draft-varshavchik-verp-smtpext-02.txt
deleted file mode 100644
index d09a2ded..00000000
--- a/Documentation/en/I-D/draft-varshavchik-verp-smtpext-02.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-This Internet-Draft has expired and is no longer available.
-
-Unrevised documents placed in the Internet-Drafts directories have a
-maximum life of six months. After that time, they must be updated, or
-they will be deleted. This document was deleted on March 20, 2000.
diff --git a/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-03.txt b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-03.txt
deleted file mode 100644
index 624a8aac..00000000
--- a/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-03.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-A new Request for Comments is now available in online RFC libraries.

-

-

-        RFC 3030

-

-        Title:      SMTP Service Extensions for Transmission of Large

-                    and Binary MIME Messages

-        Author(s):  G. Vaudreuil

-        Status:     Standards Track

-        Date:       December 2000

-        Mailbox:    GregV@ieee.org

-        Pages:      12

-        Characters: 23405

-        Obsoletes:  1830

-

-        I-D Tag:    draft-vaudreuil-esmtp-binary2-03.txt

-

-        URL:        ftp://ftp.isi.edu/in-notes/rfc3030.txt

-

-

-This memo defines two extensions to the SMTP (Simple Mail Transfer

-Protocol) service.  The first extension enables a SMTP client and

-server to negotiate the use of an alternative to the DATA command,

-called "BDAT", for efficiently sending large MIME (Multipurpose

-Internet Mail Extensions) messages.  The second extension takes

-advantage of the BDAT command to permit the negotiated sending of MIME

-messages that employ the binary transfer encoding.  This document is

-intended to update and obsolete RFC 1830.

-

-This is now a Proposed Standard Protocol.

-

-This document specifies an Internet standards track protocol for

-the Internet community, and requests discussion and suggestions

-for improvements.  Please refer to the current edition of the

-"Internet Official Protocol Standards" (STD 1) for the

-standardization state and status of this protocol.  Distribution

-of this memo is unlimited.

-

-This announcement is sent to the IETF list and the RFC-DIST list.

-Requests to be added to or deleted from the IETF distribution list

-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be

-added to or deleted from the RFC-DIST distribution list should

-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

-

-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

-help: ways_to_get_rfcs.  For example:

-

-        To: rfc-info@RFC-EDITOR.ORG

-        Subject: getting rfcs

-

-        help: ways_to_get_rfcs

-

-Requests for special distribution should be addressed to either the

-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless

-specifically noted otherwise on the RFC itself, all RFCs are for

-unlimited distribution.echo 

-Submissions for Requests for Comments should be sent to

-RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC

-Authors, for further information.

-

-

diff --git a/Documentation/en/I-D/draft-ward-esmtp-slide-04.txt b/Documentation/en/I-D/draft-ward-esmtp-slide-04.txt
deleted file mode 100644
index 4bdea7e5..00000000
--- a/Documentation/en/I-D/draft-ward-esmtp-slide-04.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-A. Ward: neoplasm@aol.com                                                        

-

-

diff --git a/Documentation/en/I-D/draft-wing-smtp-capabilities-00.txt b/Documentation/en/I-D/draft-wing-smtp-capabilities-00.txt
deleted file mode 100644
index 5b82588a..00000000
--- a/Documentation/en/I-D/draft-wing-smtp-capabilities-00.txt
+++ /dev/null
@@ -1,4 +0,0 @@
-
-This Internet-Draft <draft-wing-smtp-capabilities-00.txt> 
-has been replaced by
-another Internet-Draft <draft-ietf-fax-smtp-capabilities-00.txt>
diff --git a/Documentation/en/I-D/index.html b/Documentation/en/I-D/index.html
deleted file mode 100644
index d31fdac6..00000000
--- a/Documentation/en/I-D/index.html
+++ /dev/null
@@ -1,739 +0,0 @@
-<UL>
-<LI> A (autosub)
-<UL>   <LI>
-   <A HREF="draft-palme-autosub-03.txt">
-   draft-palme-autosub-03.txt
-   </A>
-	Internet Draft                     Stockholm University/KTH
-	<draft-palme-autosub-03.txt>                         Sweden
-	Category-to-be: Experimental standard             July 1997
-	    Loop control for the Auto-Submitted e-mail header
-
-
-   <LI>
-   <A HREF="draft-palme-autosub-07.txt">
-   draft-palme-autosub-07.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-</UL><LI> B (bsmtp)
-<UL>   <LI>
-   <A HREF="draft-freed-bsmtp-02.txt">
-   draft-freed-bsmtp-02.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2442.txt">RFC2442</A>
-
-
-</UL><LI> D (data datetime dm drums)
-<UL>   <LI>
-   <A HREF="draft-varshavchik-data-smtpext-02.txt">
-   draft-varshavchik-data-smtpext-02.txt
-   </A>
-	This Internet-Draft has expired and is no longer available.
-	Unrevised documents placed in the Internet-Drafts directories have a
-	maximum life of six months. After that time, they must be updated, or
-	they will be deleted. This document was deleted on March 20, 2000.
-
-
-   <LI>
-   <A HREF="draft-newman-datetime-02.txt">
-   draft-newman-datetime-02.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-hall-dm-idns-00.txt">
-   draft-hall-dm-idns-00.txt
-   </A>
-	  INTERNET-DRAFT                                      Eric A. Hall, Editor 
-	  Document: draft-hall-dm-idns-00.txt                           Consultant 
-	  Expires: May 2002                                          November 2001 
-	                  The Internationalized Domain Name System 
-
-
-   <LI>
-   <A HREF="draft-ietf-drums-smtpupd-13.txt">
-   draft-ietf-drums-smtpupd-13.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2821.txt">RFC2821</A>
-
-
-   <LI>
-   <A HREF="draft-ietf-drums-mail-followup-to-01.txt">
-   draft-ietf-drums-mail-followup-to-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-ietf-drums-smtpupd-09.txt">
-   draft-ietf-drums-smtpupd-09.txt
-   </A>
-	December 29, 1998
-	                  Simple Mail Transfer Protocol 
-	                 draft-ietf-drums-smtpupd-09.txt
-
-
-</UL><LI> E (e eplf esmtp)
-<UL>   <LI>
-   <A HREF="draft-palme-e-mail-translation-03.txt">
-   draft-palme-e-mail-translation-03.txt
-   </A>
-	Internet Draft                                   Stockholm
-	draft-palme-e-mail-translation-03.txt       University/KTH
-	                                                     Sweden
-	Category-to-be: Proposed standard      Date: December 2001
-	                                         Expires: June 2001
-	                   Support for Language Translation
-	                        in E-Mail and Netnews
-
-
-   <LI>
-   <A HREF="draft-bernstein-eplf-06.txt">
-   draft-bernstein-eplf-06.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-bernstein-eplf-02.txt">
-   draft-bernstein-eplf-02.txt
-   </A>
-	Easily Parsed LIST Format (EPLF)
-
-
-   <LI>
-   <A HREF="draft-melnikov-esmtp-lang-00.txt">
-   draft-melnikov-esmtp-lang-00.txt
-   </A>
-	Internet Draft

-	                          SMTP Language Extension

-
-
-   <LI>
-   <A HREF="draft-vaudreuil-esmtp-binary2-03.txt">
-   draft-vaudreuil-esmtp-binary2-03.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.

-   <A HREF="../rfc/rfc3030.txt">RFC3030</A>
-
-
-   <LI>
-   <A HREF="draft-ward-esmtp-slide-04.txt">
-   draft-ward-esmtp-slide-04.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-</UL><LI> F (fax)
-<UL>   <LI>
-   <A HREF="draft-ietf-fax-smtp-session-04.txt">
-   draft-ietf-fax-smtp-session-04.txt
-   </A>
-	Applications Area                                             Neil Joffe
-	Internet Draft                                                  Dan Wing
-	August 7, 1998                                             Cisco Systems
-	                                                       Xerox Corporation
-	                       SMTP Service Extension for
-	                           Immediate Delivery
-	                   draft-ietf-fax-smtp-session-04.txt
-
-
-   <LI>
-   <A HREF="draft-ietf-fax-smtp-capabilities-01.txt">
-   draft-ietf-fax-smtp-capabilities-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-ietf-fax-esmtp-conneg-01.txt">
-   draft-ietf-fax-esmtp-conneg-01.txt
-   </A>
-	Internet Draft                       D. Crocker, Brandenburg
-	  draft-ietf-fax-esmtp-conneg-01.txt           November 2001
-	Expires: May 2002
-	                   SMTP Service Extension
-	           for Content Negotiation of Internet Fax
-
-
-</UL><LI> H (hcmssc)
-<UL>   <LI>
-   <A HREF="draft-bernstein-hcmssc-02.txt">
-   draft-bernstein-hcmssc-02.txt
-   </A>
-	The Hash Convention For Mail System Status Codes (HCMSSC)
-
-
-   <LI>
-   <A HREF="draft-bernstein-hcmssc-06.txt">
-   draft-bernstein-hcmssc-06.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-</UL><LI> I (impp int ipngwg ipv6)
-<UL>   <LI>
-   <A HREF="draft-ietf-impp-datetime-05.txt">
-   draft-ietf-impp-datetime-05.txt
-   </A>
-	Internet Draft                               C. Newman, Sun Microsystems
-	                                                         2 November 2001
-	                                                       Expires: May 2002
-	               Date and Time on the Internet: Timestamps
-	                   <draft-ietf-impp-datetime-05.txt>
-
-
-   <LI>
-   <A HREF="draft-palme-int-print-04.txt">
-   draft-palme-int-print-04.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2346.txt">RFC2346</A>
-
-
-   <LI>
-   <A HREF="draft-ietf-ipngwg-dns-discovery-analysis-00.txt">
-   draft-ietf-ipngwg-dns-discovery-analysis-00.txt
-   </A>
-	IPNG Working Group                       DNS Discovery Design Team
-	       Analysis of DNS Server Discovery Mechanisms for IPv6
-	        <draft-ietf-ipngwg-dns-discovery-analysis-00.txt>
-
-
-   <LI>
-   <A HREF="draft-motonori-ipv6-smtp-requirement-01.txt">
-   draft-motonori-ipv6-smtp-requirement-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-</UL><LI> L (ldapbis legis)
-<UL>   <LI>
-   <A HREF="draft-ietf-ldapbis-url-01.txt">
-   draft-ietf-ldapbis-url-01.txt
-   </A>
-	Request for Comments: DRAFT               Netscape Communications Corp.
-	Obsoletes: RFC 2255                                           Tim Howes
-	                                                        Loudcloud, Inc.
-	                                                            10 May 2001
-	                          The LDAP URL Format
-	                    <draft-ietf-ldapbis-url-01.txt>
-	1.  Status of this Memo
-
-
-   <LI>
-   <A HREF="draft-hoffman-legis-smtp-banner-03.txt">
-   draft-hoffman-legis-smtp-banner-03.txt
-   </A>
-	Internet Draft                              Paul Hoffman
-	draft-hoffman-legis-smtp-banner-03.txt      Internet Mail Consortium
-	November 12, 1998                           John Levine
-	                Anti-UBE and Anti-UCE Keywords in SMTP Banners
-
-
-</UL><LI> M (mail mailext maillist mhregistry mhtml mpls msghdr msgtrk)
-<UL>   <LI>
-   <A HREF="draft-bernstein-mail-loops-war-02.txt">
-   draft-bernstein-mail-loops-war-02.txt
-   </A>
-	Tools in the War on Mail Loops
-
-
-   <LI>
-   <A HREF="draft-bernstein-mail-loops-war-06.txt">
-   draft-bernstein-mail-loops-war-06.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-ietf-mailext-mail-attributes-07.txt">
-   draft-ietf-mailext-mail-attributes-07.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2076.txt">RFC2076</A>
-
-
-   <LI>
-   <A HREF="draft-palme-mailext-headers-06.txt">
-   draft-palme-mailext-headers-06.txt
-   </A>
-	Internet Draft                                   Stockholm
-	draft-palme-mailext-headers-06.txt          University/KTH
-	Category: Informational                             Sweden
-	Revision of: RFC 2076                  Date: November 2001
-	                                        Expires: April 2002
-	                   Common Internet Message Header Fields
-
-
-   <LI>
-   <A HREF="draft-palme-maillist-01.txt">
-   draft-palme-maillist-01.txt
-   </A>
-	draft-palme-maillist-01.txt                              Sweden
-	Appropriate Mailing List Behaviour
-
-
-   <LI>
-   <A HREF="draft-palme-MHRegistry-00.txt">
-   draft-palme-MHRegistry-00.txt
-   </A>
-	This Internet-Draft <draft-palme-MHRegistry-00.txt>
-	has been replaced by another Internet-Draft 
-	<draft-ietf-drums-MHRegistry-00.txt>
-
-
-   <LI>
-   <A HREF="draft-palme-mhtml-info-01.txt">
-   draft-palme-mhtml-info-01.txt
-   </A>
-	Internet Draft                                 Stockholm
-	draft-palme-mhtml-info-01.txt             University/KTH
-	                                            December 2001
-	Category-to-be:
-	Informational
-	Expires: June 2001
-	              Sending HTML in MIME,
-	     an informational supplement to the RFC:
-	     MIME Encapsulation of Aggregate Documents,
-	              such as HTML (MHTML)
-
-
-   <LI>
-   <A HREF="draft-bernstein-mpls-sonet-01.txt">
-   draft-bernstein-mpls-sonet-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-klyne-msghdr-registry-01.txt">
-   draft-klyne-msghdr-registry-01.txt
-   </A>
-	Internet-Draft                                         MIMEsweeper Group
-	Expires: July 5, 2002                                        Jan 4, 2002
-	              Registration procedures for message headers
-	                     draft-klyne-msghdr-registry-01
-
-
-   <LI>
-   <A HREF="draft-ietf-msgtrk-model-04.txt">
-   draft-ietf-msgtrk-model-04.txt
-   </A>
-	Internet Draft                                                 T. Hansen
-	draft-ietf-msgtrk-model-04.txt                         AT&T Laboratories
-	Valid for six months                                    November 6, 2001
-	                Message Tracking Model and Requirements
-	                    <draft-ietf-msgtrk-model-04.txt>
-	                         Authors' version: 1.14
-
-
-   <LI>
-   <A HREF="draft-ietf-msgtrk-mtqp-04.txt">
-   draft-ietf-msgtrk-mtqp-04.txt
-   </A>
-	Internet Draft                                                 T. Hansen
-	draft-ietf-msgtrk-mtqp-04.txt                          AT&T Laboratories
-	Valid for six months                                   November 20, 2001
-	                    Message Tracking Query Protocol
-	                    <draft-ietf-msgtrk-mtqp-04.txt>
-	                         Authors' version: 1.10
-
-
-   <LI>
-   <A HREF="draft-ietf-msgtrk-trkstat-03.txt">
-   draft-ietf-msgtrk-trkstat-03.txt
-   </A>
-	Internet Draft                                               E. Allman
-	draft-ietf-msgtrk-trkstat-03.txt                        Sendmail, Inc.
-	Valid for six months                                  November 2, 2001
-	Updates: RFC 1893
-	              The Message/Tracking-Status MIME Extension
-	                  <draft-ietf-msgtrk-trkstat-03.txt>
-
-
-   <LI>
-   <A HREF="draft-ietf-msgtrk-smtpext-03.txt">
-   draft-ietf-msgtrk-smtpext-03.txt
-   </A>
-	Internet Draft                                               E. Allman
-	draft-ietf-msgtrk-smtpext-03.txt                        Sendmail, Inc.
-	Valid for six months                                         T. Hansen
-	Updates: RFC 1891                                    AT&T Laboratories
-	                                                      November 2, 2001
-	                        SMTP Service Extension
-	                         for Message Tracking
-	                  <draft-ietf-msgtrk-smtpext-03.txt>
-
-
-   <LI>
-   <A HREF="draft-ietf-msgtrk-protocol-05.txt">
-   draft-ietf-msgtrk-protocol-05.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-jones-msgtrk-def-02.txt">
-   draft-jones-msgtrk-def-02.txt
-   </A>
-	This Internet-Draft has expired and is no longer available.
-	Unrevised documents placed in the Internet-Drafts directories have a
-	maximum life of six months. After that time, they must be updated, or
-	they will be deleted. This document was deleted on March 20, 2000.
-
-
-   <LI>
-   <A HREF="draft-ietf-msgtrk-protocol-00.txt">
-   draft-ietf-msgtrk-protocol-00.txt
-   </A>
-	Internet Draft						       E. Allman
-	draft-ietf-msgtrk-protocol-00.txt			  Sendmail, Inc.
-	Valid for six months					       T. Hansen
-							       AT&T Laboratories
-								  March	10, 2000
-				 SMTP Service Extension
-				  for Message Tracking
-			  <draft-ietf-msgtrk-protocol-00.txt>
-				 Authors' version: 1.1
-
-
-</UL><LI> N (netstrings newfields newsmail ngtrans nrudt)
-<UL>   <LI>
-   <A HREF="draft-bernstein-netstrings-06.txt">
-   draft-bernstein-netstrings-06.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-bernstein-netstrings-02.txt">
-   draft-bernstein-netstrings-02.txt
-   </A>
-	Netstrings
-
-
-   <LI>
-   <A HREF="draft-palme-newfields-info-02.txt">
-   draft-palme-newfields-info-02.txt
-   </A>
-	Internet Draft                                 Stockholm University/KTH
-	draft-palme-newfields-info-02.doc
-	IETF status: To become an informational RFC
-	Expires: May 1998                                         November 1998
-	Advice on the implementation of In-Reply-To, References and Supersedes
-	e-mail and netnews headers
-
-
-   <LI>
-   <A HREF="draft-palme-newsmail-01.txt">
-   draft-palme-newsmail-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt">
-   draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
-   </A>
-	Internet Engineering Task Force                        Motonori Nakamura
-	Expires: May 8, 2002                            Jun-ichiro itojun Hagino
-	                                                 IIJ Research Laboratory
-	                                                        November 8, 2001
-	                   IPv6 SMTP operational requirements
-	            draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
-
-
-   <LI>
-   <A HREF="draft-bernstein-nrudt-02.txt">
-   draft-bernstein-nrudt-02.txt
-   </A>
-	Notice-Requested-Upon-Delivery-To (NRUDT)
-
-
-   <LI>
-   <A HREF="draft-bernstein-nrudt-06.txt">
-   draft-bernstein-nrudt-06.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-</UL><LI> O (owner)
-<UL>   <LI>
-   <A HREF="draft-bernstein-owner-hack-01.txt">
-   draft-bernstein-owner-hack-01.txt
-   </A>
-	The Owner Hack
-
-
-   <LI>
-   <A HREF="draft-bernstein-owner-hack-05.txt">
-   draft-bernstein-owner-hack-05.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-</UL><LI> P (palme pirp)
-<UL>   <LI>
-   <A HREF="draft-ietf-palme-select-00.txt">
-   draft-ietf-palme-select-00.txt
-   </A>
-	Internet Draft                                Stockholm University/KTH
-	draft-ietf-palme-select-00.txt                             Johan Kaers
-	Intended-for: Proposed standard                                Starlab
-	Expires: December 2000                                       June 2000
-	The SELECT Protocol for Rating and Filtering
-
-
-   <LI>
-   <A HREF="draft-bernstein-pirp-02.txt">
-   draft-bernstein-pirp-02.txt
-   </A>
-	Public Information Retrieval Protocol (PIRP)
-
-
-   <LI>
-   <A HREF="draft-bernstein-pirp-06.txt">
-   draft-bernstein-pirp-06.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-</UL><LI> Q (qmtp qsbmf)
-<UL>   <LI>
-   <A HREF="draft-bernstein-qmtp-01.txt">
-   draft-bernstein-qmtp-01.txt
-   </A>
-	Quick Mail Transfer Protocol (QMTP)
-
-
-   <LI>
-   <A HREF="draft-bernstein-qmtp-05.txt">
-   draft-bernstein-qmtp-05.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-bernstein-qsbmf-02.txt">
-   draft-bernstein-qsbmf-02.txt
-   </A>
-	The qmail-send Bounce Message Format (QSBMF)
-
-
-   <LI>
-   <A HREF="draft-bernstein-qsbmf-06.txt">
-   draft-bernstein-qsbmf-06.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-</UL><LI> R (reqbehaviors rfc2487bis)
-<UL>   <LI>
-   <A HREF="draft-meyer-reqbehaviors-manager-00.txt">
-   draft-meyer-reqbehaviors-manager-00.txt
-   </A>
-	draft-meyer-reqbehaviors-manager-00.txt                     Mike Meyer
-	Category: Informational                               Meyer Consulting
-	Expires: September, 2002                                   March, 2002
-	           Required behaviors for mail list managers
-
-
-   <LI>
-   <A HREF="draft-hoffman-rfc2487bis-06.txt">
-   draft-hoffman-rfc2487bis-06.txt
-   </A>
-	Internet Draft                                          Paul Hoffman
-	draft-hoffman-rfc2487bis-06.txt             Internet Mail Consortium
-	November 4, 2001
-	            SMTP Service Extension for Secure SMTP over TLS
-
-
-   <LI>
-   <A HREF="draft-hoffman-rfc2487bis-00.txt">
-   draft-hoffman-rfc2487bis-00.txt
-   </A>
-	Internet Draft                                          Paul Hoffman
-	<draft-hoffman-rfc2487bis-00.txt>           Internet Mail Consortium
-	April 15, 1999
-	            SMTP Service Extension for Secure SMTP over TLS
-
-
-</UL><LI> S (select shipworm smtp stringprep supersedes)
-<UL>   <LI>
-   <A HREF="draft-palme-select-01.txt">
-   draft-palme-select-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-huitema-shipworm-01.txt">
-   draft-huitema-shipworm-01.txt
-   </A>
-	This  document has been replaced by draft-ietf-ngtrans-shipworm-00.txt.
-
-
-   <LI>
-   <A HREF="draft-hoffman-smtp-ssl-09.txt">
-   draft-hoffman-smtp-ssl-09.txt
-   </A>
-	Internet Draft                              Paul Hoffman
-	draft-hoffman-smtp-ssl-09.txt               Internet Mail Consortium
-	October 25, 1998
-	         SMTP Service Extension for Secure SMTP over TLS
-
-
-   <LI>
-   <A HREF="draft-khanna-smtp-mail-transfer-reliability-01.txt">
-   draft-khanna-smtp-mail-transfer-reliability-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-freed-smtp-pipe-01.txt">
-   draft-freed-smtp-pipe-01.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.

-	        STD 60 

-   <A HREF="../rfc/rfc2920.txt">RFC2920</A>
-
-
-   <LI>
-   <A HREF="draft-bose-smtp-integrity-00.txt">
-   draft-bose-smtp-integrity-00.txt
-   </A>
-	        CHECKING OF MESSAGE INTEGRITY DURING SMTP TRANSACTIONS
-
-
-   <LI>
-   <A HREF="draft-melnikov-smtp-lang-04.txt">
-   draft-melnikov-smtp-lang-04.txt
-   </A>
-	Internet Draft           Alexey Melnikov, ACI WorldWide/MessagingDirect
-	                          SMTP Language Extension
-
-
-   <LI>
-   <A HREF="draft-hoffman-smtp-ssl-10.txt">
-   draft-hoffman-smtp-ssl-10.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2487.txt">RFC2487</A>
-
-
-   <LI>
-   <A HREF="draft-myers-smtp-auth-12.txt">
-   draft-myers-smtp-auth-12.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2554.txt">RFC2554</A>
-
-
-   <LI>
-   <A HREF="draft-freed-smtp-pipeline-02.txt">
-   draft-freed-smtp-pipeline-02.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2197.txt">RFC2197</A>
-
-
-   <LI>
-   <A HREF="draft-wing-smtp-capabilities-00.txt">
-   draft-wing-smtp-capabilities-00.txt
-   </A>
-	This Internet-Draft <draft-wing-smtp-capabilities-00.txt> 
-	has been replaced by
-	another Internet-Draft <draft-ietf-fax-smtp-capabilities-00.txt>
-
-
-   <LI>
-   <A HREF="draft-hoffman-stringprep-03.txt">
-   draft-hoffman-stringprep-03.txt
-   </A>
-	Internet Draft                                          Paul Hoffman
-	draft-hoffman-stringprep-03.txt                           IMC & VPNC
-	May 17, 2002                                           Marc Blanchet
-	        Preparation of Internationalized Strings ("stringprep")
-
-
-   <LI>
-   <A HREF="draft-palme-supersedes-01.txt">
-   draft-palme-supersedes-01.txt
-   </A>
-	This Internet-Draft has expired and is no longer available.
-	Unrevised documents placed in the Internet-Drafts directories have a
-	maximum life of six months. After that time, they must be updated, or
-	they will be deleted. This document was deleted on March 20, 2000.
-
-
-</UL><LI> U (url)
-<UL>   <LI>
-   <A HREF="draft-earhart-url-smtp-00.txt">
-   draft-earhart-url-smtp-00.txt
-   </A>
-	                         An SMTP URL Interface
-
-
-</UL><LI> V (verp vpim)
-<UL>   <LI>
-   <A HREF="draft-varshavchik-verp-smtpext-02.txt">
-   draft-varshavchik-verp-smtpext-02.txt
-   </A>
-	This Internet-Draft has expired and is no longer available.
-	Unrevised documents placed in the Internet-Drafts directories have a
-	maximum life of six months. After that time, they must be updated, or
-	they will be deleted. This document was deleted on March 20, 2000.
-
-
-   <LI>
-   <A HREF="draft-ietf-vpim-pndn-01.txt">
-   draft-ietf-vpim-pndn-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-ietf-vpim-cc-04.txt">
-   draft-ietf-vpim-cc-04.txt
-   </A>
-	Internet Draft                                         SnowShore Networks 
-	Category: Standards Track                                                 
-	                   Critical Content of Internet Mail 
-
-
-   <LI>
-   <A HREF="draft-burger-vpim-pc-01.txt">
-   draft-burger-vpim-pc-01.txt
-   </A>
-	This document has been replaced by draft-ietf-vpim-hint-00.txt.

-	For more information or a copy of the document, contact the author directly.

-
-
-   <LI>
-   <A HREF="draft-ietf-vpim-hint-07.txt">
-   draft-ietf-vpim-hint-07.txt
-   </A>
-	Internet Draft                                         SnowShore Networks 
-	Category: Standards Track                                        Comverse 
-	                                                    Microsoft Corporation 
-	                                                                 G. Klyne 
-	                                                   Baltimore Technologies 
-	                                                             June 5, 2001 
-	                   Message Context for Internet Mail 
-
-
-   <LI>
-   <A HREF="draft-ema-vpim-pndn-04.txt">
-   draft-ema-vpim-pndn-04.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-</UL></UL>