import pointer book cvs repository

43 files changed, 25539 insertions, 0 deletions

diff --git a/Documentation/en/I-D/draft-bernstein-eplf-02.txt b/Documentation/en/I-D/draft-bernstein-eplf-02.txt
new file mode 100644
index 00000000..59f9621d
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-eplf-02.txt
@@ -0,0 +1,258 @@
+
+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-hcmssc-02.txt b/Documentation/en/I-D/draft-bernstein-hcmssc-02.txt
new file mode 100644
index 00000000..2c598afb
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-hcmssc-02.txt
@@ -0,0 +1,74 @@
+
+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-mail-loops-war-02.txt b/Documentation/en/I-D/draft-bernstein-mail-loops-war-02.txt
new file mode 100644
index 00000000..4a7035a2
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-mail-loops-war-02.txt
@@ -0,0 +1,385 @@
+
+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-mpls-sonet-00.txt b/Documentation/en/I-D/draft-bernstein-mpls-sonet-00.txt
new file mode 100644
index 00000000..5693fcb5
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-mpls-sonet-00.txt
@@ -0,0 +1,395 @@
+Network Working Group                               Greg Bernstein
+Internet Draft                                      Ciena Networks
+Expiration Date:  August 2000
+
+
+    Some Comments on the Use of MPLS Traffic Engineering for 
+                    SONET/SDH Path Establishment
+
+                   draft-bernstein-mpls-sonet-00.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.
+
+
+2. Abstract
+
+   In [Awduche] the MPLS Traffic Engineering control plane was applied
+   to the creation of light paths (optical circuits). Due to the general
+   hierarchical capabilities of MPLS, and the flexibility of the label 
+   switching paradigm the same techniques used to apply the MPLS control 
+   plane to the optical layer can be used to apply it to the SONET/SDH 
+   path layer and in fact any form of circuit switching. This note 
+   discusses advantages of such an approach and some of the issues 
+   involved in its application. 
+
+
+3. Introduction
+
+   In [Awduche] the MPLS Traffic Engineering control plane was applied 
+   to the creation of light paths (optical circuits). This initial work 
+   along with the formation of a new optical signaling working group at 
+   the Optical Internetworking Forum (OIF), and a new industry 
+   coalition, the Optical Domain Service Interconnect(ODSI)has very much 
+   underscored the desire to automate the control of optical networks.
+   Due to the hierarchical capabilities of MPLS and the flexibility of 
+   the MPLS paradigm, MPLS techniques can be applied to the general 
+   problem of control of hierarchical circuit switched networks. Given 
+   the number of recent internet drafts concerning the optical domain
+   [Kompella, Wang, Fan, Krishna]  the comments here will be 
+   concentrated on time division multiplexed hierarchies. Before 
+   focusing on some SONET specific issues (note that [Mannie] gives a 
+   good overview of the SDH specific issues) we review some of the
+   problems to be solved.
+
+3.1 Transport Network Issues
+ 
+3.1.1 Multi Vendor Topology/Resource Discovery 
+
+   Although modern transport networks based on SONET/SDH excel at 
+   interoperability in the performance monitoring (PM) and fault 
+   management (FM) areas, they do not inter-operate in the areas of 
+   topology discovery or resource status.  Although link state route 
+   protocols, such as IS-IS and OSPF, have been used for some time in 
+   the IP world to compute destination based next hops for routes 
+   (without routing loops). Their value in providing timely topology and 
+   network status information in a distributed manner, i.e., at any 
+   network node, is immense. If resource utilization information is 
+   disseminated along with the link status (as was done in ATM's PNNI 
+   routing protocol) then a very complete picture of network status is 
+   available to a network operator for use in planning, provisioning and 
+   operations. Note that in the circuit switch domain bandwidth 
+   utilization and connection admission control is much simplified over 
+   similar concepts in the packet switching world.
+   Other items of interest for circuit based network control include 
+   switching capabilities of the nodes (granularity, signal types, 
+   etc.), protection properties of the links (linear 1+1, linear 1:N, 
+   ring), failure risk of the links (which links have a tendency to fail 
+   at the same time - ).  At this point the main difference in this 
+   application of link state routing versus that for IP is that no 
+   routes have actually be calculated.
+
+3.1.2 Multi Vendor Connection Control
+
+   Traditionally end-to-end circuit connections have been set up via an 
+   equipment vendor's element management system (EMS). Only limited 
+   interoperability has been achieved via management systems. Hence, 
+   end-to-end circuits in a multi-vendor environment typically require 
+   the use of multiple management systems and the infamous configuration 
+   via "yellow sticky notes". A common signaling protocol such as RSVP 
+   with TE extensions or CR-LDP appropriately extended for circuit 
+   switching applications can solve this interoperability problem.
+
+3.1.3 Customer/Edge Connection Control
+
+   This is the case where the edge device, by desire, does not fully 
+   participate in the routing protocol, i.e., does not receive or share 
+   topology information with the rest of the network. Such a device 
+   would typically be discovered/register through a separate protocol 
+   from the routing protocol.  The edge device would then typically use 
+   a signaling protocol similar to that used in the network to request 
+   services associated with circuits (setup, clear, query). Note that 
+   the multiplex hierarchy used in TDM networks generally alleviates the 
+   scaling issues that could otherwise be troublesome, i.e., a core 
+   SONET switch with OC-192 trunks will not be dealing with signals of 
+   DS0 or DS1 granularity. Defining some these protocols is the type of 
+   work of initial interest at both ODSI and the OIF's signaling working 
+   group.
+
+3.1.4 Path Computation
+
+   Although a link state route protocol can be used to obtain network 
+   topology and resource information, this does not imply the use of an 
+   "open shortest path first" route. The path must be open in the sense 
+   that the bandwidth must be available, however the switches along the 
+   path must also be capable, in some way, of transporting the desired 
+   signal type, i.e., we've got an additional constraint.  Other 
+   constraints may include hop count, total delay (mostly propagation), 
+   and hop count. In addition, in addition it may be desirable to route 
+   traffic in order to optimize overall network capacity, reliability or 
+   some combination of the two. Dikstra's algorithm computes the 
+   shortest path with respect to link weights for a single connection at 
+   a time. This can be much different than the paths that would be 
+   selected in response to a request to set up a batch of connections 
+   between a set of endpoints in order to optimize network link 
+   utilization. One can think along the line of global or local 
+   optimization of the network. Due to the complexity of some of the 
+   route algorithms (high dimensionality non-linear integer programming 
+   problems) and various criteria by which one may optimize their 
+   network it may not be possible or desirable to run these algorithms 
+   on network nodes. However, it may still be desirable to have some 
+   basic path computation ability running on the network nodes, 
+   particularly in restoration situations. Such an approach is in line 
+   with the use of MPLS for traffic engineering but is much different 
+   than typical OSPF or IS-IS usage where all nodes must run the same 
+   route algorithm.
+
+3.2 Decomposition of the MPLS/Circuit Switching Problem Space
+
+   Although those familiar with MPLS may be familiar with its 
+   application in a variety of application areas, e.g., ATM, Frame 
+   Relay, etc.  We quickly review its decomposition when applied to the 
+   circuit switching problem space.
+   
+   (i) Information needed to compute paths must be made globally 
+   available throughout the network.  Since this is done via the 
+   link state route protocol any information of this nature must 
+   either be in the existing link state advertisements (LSAs) or 
+   the LSAs must be supplemented to convey this information.  For 
+   example, if its desirable to offer different levels of service 
+   in a network based on whether a circuit is routed over SONET 
+   lines are Ring protected vs. not being protected 
+   (differentiation based on reliability). Then the type of 
+   protection on a SONET line would be an important topological 
+   parameter that should be distributed via the link state route 
+   protocol. Other important parameters are described in 
+   [Kompella].
+
+   (ii) Information that is only needed between two "adjacent" switches 
+   for the purposes of connection establishment is appropriate for 
+   distribution via one of the label distribution protocols. In 
+   fact this information may form the "virtual" label. For example 
+   in SONET if we are distributing information to switches 
+   concerning an end-to-end STS-1 path traversing a network. It is 
+   critical that adjacent switches agree on the "time slot" used 
+   by this STS-1 (but this information is only of local 
+   significance between the two switches). Hence the time slot 
+   number in this case can be used as a virtual label. Note that 
+   it is virtual in that it is not appended to the payload in 
+   anyway, but it is still a label in the sense that it uniquely 
+   identifies the signal local to the link between the two 
+   switches.
+
+   (iii) Information that all switches in the path will need to know 
+   about a connection will also be distributed via the label 
+   distribution protocol. Example of such information can include 
+   bandwidth, priority, and preemption information.
+
+   (iv) Information intended only for end systems of the connection. 
+   Some of the payload type information in [Mannie] may fall into 
+   this category.
+
+
+4. SONET Considerations
+
+   SONET/SDH is a a TDM based multiplexing technology that has a number
+   of standard options that a network user may choose to use. In
+   addition a number of extensions have been proposed [Jones] or are
+   beneficial for network operations, e.g., eliminate the need for link
+   grooming.  This draft reviews the SONET multiplex structure, options
+   and possible extensions with respect to the information that is
+   required to be shared between MPLS LSRs working at the SONET layer
+   for the establishment of SONET layer LSPs.
+
+
+4.1 SONET Structure and Extensions
+
+   The fundamental signal in SONET is the STS-1 (about 51 Mbps). This 
+   signal consists of a transport overhead and a Synchronous Payload 
+   Envelope (SPE). The SPE floats within its alloted space within the 
+   SONET frame structure with the pointer bytes (H1, H2 and H3) in the 
+   Line Overhead of the SONET transport overhead pointing to the 
+   begining of the SPE.  An STS-N signal is formed from a SONET STS-(N- 
+   1) signal and an STS-1 signal via byte interleaving.  The transport 
+   overhead structures are frame aligned prior to interleaving but this 
+   is not required of the SPEs, i.e., there is no special relationship 
+   between the payload envelopes.  To transport signals in excess of 
+   about 50Mbps the SPEs can be concatenated, i.e., glued together. In 
+   this case their relationship with respect to each other is fixed in 
+   time and hence this relieves, when possible, and end system of any 
+   inverse multiplexing bonding processes.
+   
+   Due to the previously describe structure the end points of SONET 
+   connections can be identified by the "time slots" (position) that 
+   they occupy within the interleaved frame structure. In the standard 
+   SONET case we are concerned with which of the M STS-1 paths within an 
+   STS-N signal will be used to transport our data (M <= N, and N = 3, 
+   12, 48, 192,...). The SPEs of these M STS-1s can be concatenated to 
+   form an STS-Mc. The STS-Mc notation is really a short hand way of 
+   describing an STS-M signal whose SPEs have been concatenated.
+   
+   In BellCore GR-253 [GR-253] section 6.1.2 (requirement R6-3) two 
+   conventions are given for identifying an STS-1 within an STS-N:
+
+         - A two-level "STS-3 #, STS-1 #"
+
+         - A single-level "1 to N in order of appearance at the input to
+         the byte-interleaver"
+
+   For example STS-1 number 23 within an OC-48 can also be represented
+   by the tuple (8, 2).  We will be using the single-level numbering
+   scheme in our discussion, but this is not imply an encoding format.
+
+   A second complication is in dealing with concatenated signals. In
+   Bellcore GR-253 section 5.1 the multiplexing procedures for SONET are
+   given. Constraints are imposed on the size of STS-Mc signals, i.e.,
+   they must be a multiple of 3, and on their starting location and
+   interleaving.  This has the following advantages: (a) restriction to
+   multiples of 3 helps with SDH compatibility (there is no STS-1
+   equivalent signal in STS-1 an STM-1 is equivalent (essentially) to an
+   STS-3c); (b) the restriction to multiples of 3 reduces the number of
+   connection types; (c) the restriction on the placement and
+   interleaving could allow more compact representation of the "label";
+   The major disadvantage of these restrictions are: (a) Limited
+   flexibility in bandwidth assignment (somewhat inhibits finer grained
+   traffic engineering). (b) The lack of flexibility in starting time
+   slots for STS-Mc signals and in their interleaving (where the rest of
+   the signal gets put in terms of STS-1 slot numbers) leads to the
+   requirement for re-grooming (due to bandwidth fragmentation).
+
+4.2 SONET Concatenation Extensions
+
+   Due to these disadvantages some SONET framer manufacturers now 
+   support "arbitrary" concatenation, i.e., no restrictions on the size 
+   of an STS-Mc (as long as M <= N) and no constraints on the STS-1 
+   timeslots used to convey it. It is recommended that arbitrary 
+   concatenation be supported in the format for SONET labels. It is also 
+   recommended that the use of arbitrary concatenation or "standard" 
+   concatenation be negotiated as part of the label assignment process 
+   between two SONET LSRs.
+   
+   Note that arbitrary concatenation as used here is a network service 
+   that is similar in nature to the SONET end system service of higher 
+   order virtual concatenation [Jones],[Mannie]. In one example of 
+   virtual concatenation two end systems supporting this feature could 
+   essentially "inverse multiplex" two STS-1s into a virtual STS-2c for 
+   the efficient transport of 100Mbps Ethernet traffic.  The burden in 
+   virtual concatenation is on the end systems while in arbitrary 
+   concatenation it is on the network.  In addition arbitrary 
+   concatenation includes arbitrary interleaving which avoids the need 
+   for link regrooming between any pair of nodes supporting this 
+   feature.
+
+4.3 SONET Connection Bundling
+
+   Connection Bundling is the process of routing a set of non-
+   concatenated STS-1s together as a group, i.e., they are all contained 
+   within the same SONET line (or WDM signal) and receive essentially 
+   the same delay and propagation. This simplifies connection 
+   establishment (especially for batches of DS-3s that are being 
+   wholesaled) and speeds re-routes. Such bundling may be important when 
+   establishing STS-1s that will be used between end systems 
+   implementing virtual concatenation. It is recommended that the labels 
+   chosen for SONET paths can incorporate the concept of STS-1 bundling. 
+   Whether it is desirable to bundle larger signals, i.e., groups of 
+   STS-Mc, is for further study.
+
+4.4 SONET Transparency
+
+   One last transport technique that bears mentioning since it can be 
+   viewed as a service is that of transparent multiplexing or switching. 
+   The SONET over head is broken into three layers: Section, Line and 
+   Path. All these layers are concerned with fault and performance 
+   monitoring. Section overhead is primarily concerned with framing and 
+   Line overhead is primarily concerned with multiplexing and 
+   protection. To perform multiplexing a SONET network element should be 
+   line terminating. However not all SONET multiplexers/switches perform 
+   SONET pointer adjustments on all the STS-1s contained within them or 
+   if they perform the pointer adjustments they do not terminate the 
+   line overhead. For example a multiplexer may take four SONET STS-48 
+   signals and multiplex them onto an STS-192 without performing 
+   standard line pointer adjustments on the individual STS-1s.  This can 
+   be looked at as a service since it may be desirable to pass SONET 
+   signals, like an STS-12 or STS-48, with some level of transparency 
+   through a network and still take advantage of TDM.  Transparent 
+   multiplexing and switching can also be viewed as a constraint since 
+   some multiplexers and switches may not switch at as fine a 
+   granularity as others.  The levels of transparency and their 
+   representation is for further study.
+
+4.5 SONET Protection
+
+   SONET and SDH networks offer a variety of protection options at both 
+   the SONET line and SONET path level.  Standardized SONET line level 
+   protection techniques include Linear 1+1 and Linear 1:N automatic 
+   protection switching (APS)[GR-253] and both two fiber and four fiber 
+   bi-directional line switched rings (BLSRs) [GR-1230]. At the path 
+   layer SONET offers uni-directional path switched ring protection. 
+   Both ring and 1:N line protection also allow for "extra traffic" to 
+   be carried over the protection line when it is not being used, i.e., 
+   not carrying traffic for a failed working line. It may be desirable 
+   to route some connections over lines with protection of a given type, 
+   unprotected lines, or primarily over protection lines as "extra 
+   data". In order to do this the method of protecting a line (if any) 
+   or whether a line is a protection line is useful topology information 
+   that can be disseminated via the link state route protocol. In 
+   addition, a signaling protocol should allow the optional 
+   specification of link protection types as one of the connection 
+   attributes.
+
+5. Summary
+
+   This note has discussed some of the advantages of a circuit switching 
+   control plane based on MPLS in terms of the current interoperability 
+   problems that MPLS can help solve. An overview of the application of 
+   MPLS to circuit switching and its decomposition into routing and 
+   label distribution components was presented. And, finally a few of 
+   the subtleties particular to SONET that need to be taken into account 
+   when an MPLS control plane is applied to this application were 
+   detailed.
+
+6. Acknowledgements
+   The author would like to thank Yakov Rekhter and Jeff Weiss for a 
+   number of enlightening and stimulating discussions that prompted 
+   these notes.
+
+7. References
+
+   [Awduche] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi-
+   Protocol Lambda Switching: Combining MPLS Traffic Engineering Control
+   With Optical Crossconnects", draft-awduche-mpls-te-optical-01.txt
+
+   [Jones] Jones, N., Murton, C., "Extending PPP over SONET/SDH, with
+   virtual concatenation, high order and low order payloads", draft-
+   ietf-pppext-posvcholo-01.txt
+
+   [GR-253] Bellcore Generic Requirements, GR-253-CORE, Synchronous
+   Optical Network (SONET) Transport Systems: Common Generic Criteria,
+   Issue 2, December 1995.
+
+   [Mannie] Mannie, E., "MPLS for SDH control", draft-mannie-mpls-sdh-
+   control-00.txt.
+   
+   [Kompella] Kireeti Kompella, et. al., "Extensions to IS-IS/OSPF and 
+   RSVP in support of MPL(ambda)S", draft-kompella-mpls-optical-00.txt.
+   
+   [Wang] Gouqiand Wang, et. al., "Extensions to OSPF/IS-IS for Optical 
+   Routing", March 2000, Internet Draft, draft-wang-ospf-isis-lambda-te-
+   routing-00.txt. 
+   
+   [Fan] Yanhe Fan, et. al., "Extensions to CR-LDP and RSVP-TE for 
+   Optical Path Set-up", March 2000, draft-fan-mpls-lambda-signaling-
+   00.txt.
+   
+   [Krishna] Murali Krishnaswamy, et. al., "MPLS control plane for 
+   Switched Optical Networks",2/25/00,draft-krishnaswamy-mpls-son-
+   00.txt.
+
+8. Author Information
+
+   Greg Bernstein
+   Ciena Core Switching Division
+   10201 Bubb Road
+   Cupertino, CA 95014
+   e-mail: Greg@ciena.com
+   Phone: (408) 865-6213
+
diff --git a/Documentation/en/I-D/draft-bernstein-netstrings-02.txt b/Documentation/en/I-D/draft-bernstein-netstrings-02.txt
new file mode 100644
index 00000000..402c91d9
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-netstrings-02.txt
@@ -0,0 +1,131 @@
+
+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-nrudt-02.txt b/Documentation/en/I-D/draft-bernstein-nrudt-02.txt
new file mode 100644
index 00000000..949d3fb5
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-nrudt-02.txt
@@ -0,0 +1,139 @@
+
+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-owner-hack-01.txt b/Documentation/en/I-D/draft-bernstein-owner-hack-01.txt
new file mode 100644
index 00000000..558638a5
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-owner-hack-01.txt
@@ -0,0 +1,133 @@
+
+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-pirp-02.txt b/Documentation/en/I-D/draft-bernstein-pirp-02.txt
new file mode 100644
index 00000000..122822ba
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-pirp-02.txt
@@ -0,0 +1,174 @@
+
+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-qmtp-01.txt b/Documentation/en/I-D/draft-bernstein-qmtp-01.txt
new file mode 100644
index 00000000..9f3ce00c
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-qmtp-01.txt
@@ -0,0 +1,266 @@
+
+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-qsbmf-02.txt b/Documentation/en/I-D/draft-bernstein-qsbmf-02.txt
new file mode 100644
index 00000000..108fde82
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-qsbmf-02.txt
@@ -0,0 +1,193 @@
+
+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-earhart-url-smtp-00.txt b/Documentation/en/I-D/draft-earhart-url-smtp-00.txt
new file mode 100644
index 00000000..1b98cb68
--- /dev/null
+++ b/Documentation/en/I-D/draft-earhart-url-smtp-00.txt
@@ -0,0 +1,281 @@
+
+
+
+
+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-freed-bsmtp-00.txt b/Documentation/en/I-D/draft-freed-bsmtp-00.txt
new file mode 100644
index 00000000..208728a6
--- /dev/null
+++ b/Documentation/en/I-D/draft-freed-bsmtp-00.txt
@@ -0,0 +1,648 @@
+
+
+
+
+
+Network Working Group                      Ned Freed, Innosoft
+Internet Draft                            Dan Newman, Innosoft
+<draft-freed-bsmtp-00.txt>                   Mark Hoy, SunSoft
+                                    Jacques Belissent, SunSoft
+
+                             The
+                          Batch SMTP
+                          Media Type
+
+                        December 1997
+
+
+
+                     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. Internet-Drafts 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 a "working draft" or "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 ds.internic.net (US East
+Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),
+or munnari.oz.au (Pacific Rim).
+
+Copyright (C) The Internet Society (1997).  All Rights
+Reserved.
+
+
+1.  Abstract
+
+This document defines a MIME content type suitable for
+tunneling a an ESMTP [RFC-821, RFC-1869] transaction through
+any MIME-capable transport.  This type can be used for a
+variety of purposes, including:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+ (1)   Extending end-to-end MIME-based security services (e.g.
+       [RFC-1847]) to cover message envelope information as
+       well as message content.
+
+ (2)   Making it possible to use specific SMTP extensions such
+       as NOTARY [RFC-1891] over unextended SMTP transport
+       infrastructure.
+
+ (3)   Enabling the transfer of multiple separate messages in
+       a single transactional unit.
+
+
+1.1.  Requirements Notation
+
+This document occasionally uses terms that appear in capital
+letters. When the terms "MUST", "SHOULD", "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 [RFC-
+2119].
+
+
+2.  The Application/batch-SMTP Content Type
+
+The "application/batch-SMTP" MIME content type is a container
+for the client side of an SMTP or ESMTP transaction. In
+keeping with traditional SMTP, the contents are line oriented
+and CRLF line terminators MUST be used.
+
+The "application/batch-SMTP" type is defined as follows:
+
+   Media type name: application
+   Media subtype name: batch-SMTP
+   Required parameters: none
+   Optional parameters: required-extensions
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                      Expires June 1998               [Page 2]
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+   Encoding considerations:
+     8bit material may appear, so quoted-printable or base64
+     encoding may be necessary on transports that do not
+     support 8bit. While the content of this type is
+     line-oriented and uses conventional CR/LF terminators,
+     lines longer than 7bit and 8bit encodings allow (998
+     octets) may appear, hence quoted-printable or
+     base64 encoding may be necessary even in conjunction
+     with 8bit transports.
+   Security considerations:
+     Discussed in the Security Considerations Section.
+
+
+3.  How application/batch-SMTP is used
+
+The following diagram illustrates how the application/batch-
+SMTP type is intended to be used:
+
+                 application/batch-SMTP object
+                      +----------------+
+                      |                |
+        +-----------+ v  +----------+  v +-----------+
+        | batch     |    | MIME-    |    | batch     |
+     => | SMTP      | => | capable  | => | SMTP      | =>
+        | generator |    |transport |    | processor |
+     ^  +-----------+    +----------+    +-----------+  ^
+     |                                                  |
+     +-- conventional SMTP/RFC822 message transaction --+
+
+A conventional SMTP message transaction is converted into an
+application/batch-SMTP object by the batch SMTP generator.
+This object is then carried over some type of MIME-capable
+transport. Once the destination is reached the object is
+presented to a batch SMTP processor, which converts the
+application/batch-SMTP object back into a conventional SMTP
+message transaction.
+
+
+4.  Generation of application/batch-SMTP material
+
+Application/batch-SMTP material is generated by a specially
+modified SMTP client operating without a corresponding SMTP
+server. The client simply assumes a successful response to all
+commands it issues. The resulting content then consists of the
+collected output from the SMTP client.
+
+
+
+
+
+                      Expires June 1998               [Page 3]
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+4.1.  Honoring SMTP restrictions
+
+Most batch SMTP processors will be constructed by modifying
+and extending existing SMTP servers. As such, all of the
+restrictions on SMTP constructs imposed by RFC 821, RFC 1123,
+and RFC 1869 MUST be observed. In particular, restrictions on
+command and data line lengths, number of recipients, and so on
+still exist and apply to batch SMTP.
+
+
+4.2.  Use of SMTP Extensions
+
+Since no SMTP server is present the client must be prepared to
+make certain assumptions about which SMTP extensions can be
+used. The generator
+
+ (1)   MAY assume that ESMTP [RFC-1869] facilities are
+       available, that is, it is acceptable to use the EHLO
+       command and additional parameters on MAIL FROM and RCPT
+       TO.
+
+ (2)   If EHLO is used MAY assume that the 8bitMIME [RFC-
+       1652], SIZE [RFC-1653], and NOTARY [RFC-1891]
+       extensions are available. In particular, NOTARY SHOULD
+       be used.
+
+ (3)   MAY create private bilateral agreements which specify
+       the availability of additional SMTP extensions.
+       Additional SMTP extensions MUST NOT be used in the
+       absence of such an agreement, and, perhaps more
+       importantly, a conformant generation of
+       application/batch-SMTP objects MUST be able to produce
+       objects restricted to use of the extensions listed
+       above.
+
+The "required-extensions" content type parameter MAY be used
+to communicate a list of the extensions actually used,
+specified as a comma-separated list of EHLO responses. If
+absent it defaults to the list "8bitMIME,SIZE,NOTARY".  Any
+use by private bilateral agreement of additional or different
+extensions MUST be noted in the "required-extensions"
+parameter.
+
+Note that many SMTP extensions simply do not make sense in the
+context of batch SMTP. For example, the pipelining extension
+
+
+
+
+
+                      Expires June 1998               [Page 4]
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+[RFC-1854] makes no sense in the absence of a network
+connection.
+
+
+4.3.  Handling Multiple Messages
+
+Generators SHOULD attempt to minimize the number of messages
+placed in a single application/batch-SMTP object. Ideally a
+single application/batch-SMTP object will be created for each
+message. Note, however, that some uses of application/batch-
+SMTP (e.g. mail bagging) may exist solely to take advantage of
+the multiple messages in a single container capability of
+batch SMTP, so requiring a one message per container is not
+possible.
+
+DISCUSSION: The SMTP protocols provides for the transfer of a
+series of messages over a single connection. This extends in a
+natural way to batch SMTP.  However, the issues in batch SMTP
+are somewhat different. Suppose, for example, that a batch
+SMTP processor receives an application/batch-SMTP object
+containing two messages but is unable to process the second
+message because of a storage allocation failure. But not only
+does this failure preclude processing of the second message,
+it also precludes requeuing or otherwise noting that the first
+message has already been processed. Subsequent reprocessing of
+the application/batch-SMTP then leads to duplication of the
+first message.
+
+This issue is not materially different from the well-known
+problems with SMTP synchronization that in practice often lead
+to duplicated messages. Since this behavior is inherent in
+SMTP to begin with it is not incumbent on application/batch-
+SMTP to completely address the issue. Nevertheless, it seems
+prudent for application/batch-SMTP to try and not make matters
+even worse.
+
+
+5.  Tranport of application/batch-SMTP objects
+
+Application/batch-SMTP objects may be transported by any
+transport capable of preserving their MIME labelling, e.g.
+HTTP or SMTP.
+
+Transports MUST remain cognizant of the special nature of
+application/batch-SMTP. An application/batch-SMTP object
+
+
+
+
+
+                      Expires June 1998               [Page 5]
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+contains one or more "frozen" SMTP message transactions. SMTP
+message transactions typically carry with them various
+assumptions about quality of service, e.g. that messages will
+either be delivered successfully or a nondelivery notification
+will be returned, that a nondelivery notification will be
+returned if delivery cannot be accomplished in a timely
+fashion, and so on. It is vital that the encapsulation of
+these objects for carriage over other forms of transport not
+interfere with these capabilities.
+
+
+6.  Processing of application/batch-SMTP material
+
+Processing of application/batch-SMTP material is considerably
+more complex than generating it. As might be expected, a
+modified SMTP/ESMTP processor is used.  However, since it
+cannot return information to the client, it must handle all
+error conditions that arise itself. In other words, a batch
+SMTP processor assumes both the responsibilities of a
+traditional SMTP server as well as part of the
+responsibilities of a traditional SMTP client.
+
+As such, a conforming processor:
+
+ (1)   MUST check MIME content type information to insure that
+       the material it has been presented with is labelled as
+       application/batch-SMTP and doesn't specify any
+       extensions the processor doesn't support in the
+       "required-extensions" parameter. Application/batch-SMTP
+       objects that employ an unsupported extension SHOULD be
+       forwarded to the local postmaster for manual inspection
+       and handling.
+
+ (2)   MUST accept any syntactically valid EHLO or HELO
+       command.
+
+ (3)   MUST accept any syntactically valid MAIL FROM command.
+       A conforming processor, MAY, if it so desires, note the
+       unacceptability of some part of a given MAIL FROM
+       command and use this information to subsequently
+       generate non-delivery notifications for any or all
+       recipients.
+
+ (4)   MUST accept any syntactically valid RCPT TO command. A
+       conforming processor SHOULD note the unacceptability of
+
+
+
+
+
+                      Expires June 1998               [Page 6]
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+       some part of a given RCPT TO command and subsequently
+       use this information to generate a non-delivery
+       notification for this recipient in lieu of actually
+       delivering the message.
+
+ (5)   MUST accept any of the additional parameters defined by
+       the 8bitMIME, SIZE, and NOTARY SMTP extensions on the
+       MAIL FROM and RCPT TO commands.
+
+ (6)   MUST accept the DATA command even when no valid
+       recipients are present. 8bit MIME messages MUST be
+       accepted.
+
+ (7)   MUST accept the RSET command and handle multple
+       messages in a single application/batch-SMTP object.
+       Processors MUST process each message in an
+       application/batch-SMTP object once and SHOULD take
+       whatever steps are necessary to avoid processing a
+       message more than once. For example, if processing of
+       an application/batch-SMTP object containing multiple
+       messages is interrupted at an intermediate point it
+       should subsequently be restarted at the end of the last
+       message that was completely processed.
+
+ (8)   SHOULD forward any syntactically invalid
+       application/batch-SMTP message to the local postmaster
+       for manual inspection and handling.
+
+
+7.  Security Considerations
+
+Application/batch-SMTP implements a tunneling mechanism. In
+general tunneling mechanisms are prone to abuse because they
+may provide a means of bypassing existing security
+restrictions. For example, an application/batch-SMTP tunnel
+implemented over an existing SMTP transport may allow someone
+to bypass relay restrictions imposed to block redistribution
+of spam.
+
+Application/batch-SMTP processors SHOULD implement access
+restrictions designed to limit access to the processor to
+authorized generators only. (Note that this facility may be
+provided automatically if application/batch-SMTP is being used
+to secure message envelope information.)
+
+
+
+
+
+
+                      Expires June 1998               [Page 7]
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+8.  Acknowledgements
+
+The general concept of batch SMTP has been around for a long
+time. One particular type of batch SMTP was defined by Alan
+Crosswell and used on BITNET to overcome BITNET's native 8
+character limit on user and host names. However, this form of
+batch SMTP differed from the current proposal in that it
+envisioned having the server return the status code responses
+to the client. In this case the client bore the burden of
+correlating responses with the original SMTP dialogue after
+the fact.
+
+Unfortunately this approach proved not to work well in
+practice. BITNET eventually switched to the same basic form of
+batch SMTP that has been defined here. Unfortunately that
+definition was, to the best of the present authors' knowledge,
+never captured in a formal specification. It should also be
+noted that the definition given here also differs in that it
+takes SMTP extensions into account.
+
+Einar Stefferud had previously considered the problem of
+carrying extended SMTP messages over unextended SMTP
+transports. He proposed that some form of "double enveloping"
+technology be developed to address this problem. The mechanism
+presented here effectively implements the type of solution he
+proposed.
+
+
+9.  References
+
+[RFC-821]
+     Postel, J.,  "Simple Mail Transfer Protocol",  RFC 821,
+     August, 1982.
+
+[RFC-822]
+     Crocker, D., "Standard for the Format of ARPA Internet
+     Text Messages", RFC 822 August, 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                      Expires June 1998               [Page 8]
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+[RFC-1123]
+     Braden, B., "Requirements for Internet Hosts --
+     Application and Support", RFC 1123, STD 3, October 1989.
+
+[RFC-1652]
+     Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker,
+     D., "SMTP Service Extension for 8bit-MIMEtransport", RFC
+     1652, July, 1994.
+
+[RFC-1653]
+     Klensin, J., Freed, N., Moore, K., "SMTP Service
+     Extension for Message Size Declaration", RFC 1653, July,
+     1994.
+
+[RFC-1847]
+     Galvin, J., Murphy, S., Crocker, S., Freed, N., "
+     Security Multiparts for MIME: Multipart/Signed and
+     Multipart/Encrypted", RFC 1847, October, 1995.
+
+[RFC-1854]
+     Freed, N., Cargille, A., "SMTP Service Extension for
+     Command Pipelining", RFC 1854, October, 1995.
+
+[RFC-1869]
+     Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker,
+     D., "SMTP Service Extensions", RFC 1869, STD 10,
+     November, 1995.
+
+[RFC-2045]
+     Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+     Extensions (MIME) Part One: Format of Internet Message
+     Bodies", RFC 2045, Innosoft, First Virtual Holdings,
+     December, 1996.
+
+[RFC-2046]
+     Freed, N. and Borenstein, N., "Multipurpose Internet Mail
+     Extensions (MIME) Part Two: Media Types", RFC 2046,
+     Innosoft, First Virtual Holdings, December, 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+                      Expires June 1998               [Page 9]
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+[RFC-2119]
+     Bradner, S., "Key words for use in RFCs to Indicate
+     Requirement Levels", RFC 2119, March, 1997.
+
+
+10.  Authors' Addresses
+
+Ned Freed
+Innosoft International, Inc.
+1050 Lakes Drive
+West Covina, CA 91790
+USA
+ tel: +1 626 919 3600           fax: +1 626 919 3614
+ email: ned.freed@innosoft.com
+
+Dan Newman
+Innosoft International, Inc.
+1050 Lakes Drive
+West Covina, CA 91790
+USA
+ tel: +1 626 919 3600           fax: +1 626 919 3614
+ email: ned.freed@innosoft.com
+
+Mark Hoy
+SunSoft
+
+Jacques Bellisent
+SunSoft
+
+
+11.  Full Copyright Statement
+
+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
+
+
+
+
+
+                      Expires June 1998              [Page 10]
+
+
+
+
+
+Internet Draft            Batch SMTP             December 1997
+
+
+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 1998              [Page 11]
+
+
diff --git a/Documentation/en/I-D/draft-freed-bsmtp-01.txt b/Documentation/en/I-D/draft-freed-bsmtp-01.txt
new file mode 100644
index 00000000..c99ef789
--- /dev/null
+++ b/Documentation/en/I-D/draft-freed-bsmtp-01.txt
@@ -0,0 +1,65 @@
+
+
+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-bsmtp-02.txt b/Documentation/en/I-D/draft-freed-bsmtp-02.txt
new file mode 100644
index 00000000..c99ef789
--- /dev/null
+++ b/Documentation/en/I-D/draft-freed-bsmtp-02.txt
@@ -0,0 +1,65 @@
+
+
+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-00.txt b/Documentation/en/I-D/draft-freed-smtp-pipe-00.txt
new file mode 100644
index 00000000..1abca5d9
--- /dev/null
+++ b/Documentation/en/I-D/draft-freed-smtp-pipe-00.txt
@@ -0,0 +1,587 @@
+
+
+
+Network Working Group                                Ned Freed
+Internet Draft                                        Innosoft
+                                <draft-freed-smtp-pipe-00.txt>
+
+                    SMTP Service Extension
+                    for Command Pipelining
+
+                        November 1998
+
+
+                     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. Internet-Drafts 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 a "working draft" or "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).
+
+
+1.  Abstract
+
+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.
+
+The present document is an updated version of RFC 2197 [5],
+which in turn was a revision of RFC 1854 [2]. Only textual and
+editorial changes have been made; the protocol has not changed
+in any way.
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Draft         SMTP Pipelining           November 1998
+
+
+2.  Introduction
+
+Although SMTP is widely and robustly deployed, certain
+extensions may nevertheless prove useful. In particular, many
+parts of the Internet make use of high latency network links.
+SMTP's intrinsic one command-one response structure is
+significantly penalized by high latency links, often to the
+point where the factors contributing to overall connection
+time are dominated by the time spent waiting for responses to
+individual commands (turnaround time).
+
+In the best of all worlds it would be possible to simply
+deploy SMTP client software that makes use of command
+pipelining: batching up multiple commands into single TCP send
+operations. Unfortunately, the original SMTP specification [1]
+did not explicitly state that SMTP servers must support this.
+As a result a non-trivial number of Internet SMTP servers
+cannot adequately handle command pipelining. Flaws known to
+exist in deployed servers include:
+
+ (1)   Connection handoff and buffer flushes in the middle of
+       the SMTP dialogue.  Creation of server processes for
+       incoming SMTP connections is a useful, obvious, and
+       harmless implementation technique. However, some SMTP
+       servers defer process forking and connection handoff
+       until some intermediate point in the SMTP dialogue.
+       When this is done material read from the TCP connection
+       and kept in process buffers can be lost.
+
+ (2)   Flushing the TCP input buffer when an SMTP command
+       fails. SMTP commands often fail but there is no reason
+       to flush the TCP input buffer when this happens.
+       Nevertheless, some SMTP servers do this.
+
+ (3)   Improper processing and promulgation of SMTP command
+       failures. For example, some SMTP servers will refuse to
+       accept a DATA command if the last RCPT TO command
+       fails, paying no attention to the success or failure of
+       prior RCPT TO command results. Other servers will
+       accept a DATA command even when all previous RCPT TO
+       commands have failed. Although it is possible to
+       accommodate this sort of behavior in a client that
+       employs command pipelining, it does complicate the
+       construction of the client unnecessarily.
+
+
+
+
+
+
+                       Expires May 1999               [Page 2]
+
+
+
+
+
+Internet Draft         SMTP Pipelining           November 1998
+
+
+This memo uses the mechanism described in RFC 1869 [3] to
+define an extension to the SMTP service whereby an SMTP server
+can declare that it is capable of handling pipelined commands.
+The SMTP client can then check for this declaration and use
+pipelining only when the server declares itself capable of
+handling it.
+
+
+2.1.  Requirements notation
+
+This document occasionally uses terms that appear in capital
+letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD
+NOT", and "MAY" appear capitalized, they are being used to
+indicate particular requirements of this specification. A
+discussion of the meanings of the terms "MUST", "SHOULD", and
+"MAY" appears in  RFC 1123 [2]; the terms "MUST NOT" and
+"SHOULD NOT" are logical extensions of this usage.
+
+
+3.  Framework for the Command Pipelining Extension
+
+The Command Pipelining extension is defined as follows:
+
+ (1)   the name of the SMTP service extension is Pipelining;
+
+ (2)   the EHLO keyword value associated with the extension is
+       PIPELINING;
+
+ (3)   no parameter is used with the PIPELINING EHLO keyword;
+
+ (4)   no additional parameters are added to either the MAIL
+       FROM or RCPT TO commands.
+
+ (5)   no additional SMTP verbs are defined by this extension;
+       and,
+
+ (6)   the next section specifies how support for the
+       extension affects the behavior of a server and client
+       SMTP.
+
+
+4.  The Pipelining Service Extension
+
+When a client SMTP wishes to employ command pipelining, it
+first issues the EHLO command to the server SMTP. If the
+
+
+
+
+
+                       Expires May 1999               [Page 3]
+
+
+
+
+
+Internet Draft         SMTP Pipelining           November 1998
+
+
+server SMTP responds with code 250 to the EHLO command, and
+the response includes the EHLO keyword value PIPELINING, then
+the server SMTP has indicated that it can accommodate SMTP
+command pipelining.
+
+
+4.1.  Client use of pipelining
+
+Once the client SMTP has confirmed that support exists for the
+pipelining extension, the client SMTP may then elect to
+transmit groups of SMTP commands in batches without waiting
+for a response to each individual command. In particular, the
+commands RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, and
+RCPT TO can all appear anywhere in a pipelined command group.
+The EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP commands can
+only appear as the last command in a group since their success
+or failure produces a change of state which the client SMTP
+must accommodate. (NOOP is included in this group so it can be
+used as a synchronization point.)
+
+Additional commands added by other SMTP extensions may only
+appear as the last command in a group unless otherwise
+specified by the extensions that define the commands.
+
+The actual transfer of message content is explicitly allowed
+to be the first "command" in a group. That is, a RSET/MAIL
+FROM sequence used to initiate a new message transaction can
+be placed in the same group as the final transfer of the
+headers and body of the previous message.
+
+Client SMTP implementations that employ pipelining MUST check
+ALL statuses associated with each command in a group. For
+example, if none of the RCPT TO recipient addresses were
+accepted the client must then check the response to the DATA
+command -- the client cannot assume that the DATA command will
+be rejected just because none of the RCPT TO commands worked.
+If the DATA command was properly rejected the client SMTP can
+just issue RSET, but if the DATA command was accepted the
+client SMTP should send a single dot.
+
+Command statuses MUST be coordinated with responses by
+counting each separate response and correlating that count
+with the number of commands known to have been issued.
+Multiline responses MUST be supported. Matching on the basis
+of either the error code value or associated text is expressly
+
+
+
+
+
+                       Expires May 1999               [Page 4]
+
+
+
+
+
+Internet Draft         SMTP Pipelining           November 1998
+
+
+forbidden.
+
+Client SMTP implementations MAY elect to operate in a
+nonblocking fashion, processing server responses immediately
+upon receipt, even if there is still data pending transmission
+from the client's previous TCP send operation. If nonblocking
+operation is not supported, however, client SMTP
+implementations MUST also check the TCP window size and make
+sure that each group of commands fits entirely within the
+window. The window size is usually, but not always, 4K octets.
+Failure to perform this check can lead to deadlock conditions.
+
+Clients MUST NOT confuse responses to multiple commands with
+multiline responses. Each command requires one or more lines
+of response, the last line not containing a dash between the
+response code and the response string.
+
+
+4.2.  Server support of pipelining
+
+A server SMTP implementation that offers the pipelining
+extension:
+
+ (1)   MUST respond to commands in the order they are received
+       from the client.
+
+ (2)   SHOULD elect to store responses to grouped RSET, MAIL
+       FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO
+       commands in an internal buffer so they can sent as a
+       unit.
+
+ (3)   SHOULD issue a positive response to the DATA command if
+       and only if one or more valid RCPT TO addresses have
+       been previously received.
+
+ (4)   MUST NOT, after issuing a positive response to a DATA
+       command with no valid recipients and subsequently
+       receiving an empty message, send any message whatsoever
+       to anybody.
+
+ (5)   MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN,
+       TURN, QUIT, and NOOP.
+
+ (6)   MUST NOT buffer responses to unrecognized commands.
+
+
+
+
+
+
+                       Expires May 1999               [Page 5]
+
+
+
+
+
+Internet Draft         SMTP Pipelining           November 1998
+
+
+ (7)   MUST send all pending responses immediately whenever
+       the local TCP input buffer is emptied.
+
+ (8)   MUST NOT make assumptions about commands that are yet
+       to be received.
+
+ (9)   MUST NOT flush or otherwise lose the contents of the
+       TCP input buffer under any circumstances whatsoever.
+
+ (10)  SHOULD issue response text that indicates, either
+       implicitly or explicitly, what command the response
+       matches.
+
+The overriding intent of these server requirements is to make
+it as easy as possible for servers to conform to these
+pipelining extensions.
+
+
+5.  Examples
+
+Consider the following SMTP dialogue that does not use
+pipelining:
+
+S: <wait for open connection>
+C: <open connection to server>
+S: 220 innosoft.com SMTP service ready
+C: HELO dbc.mtview.ca.us
+S: 250 innosoft.com
+C: MAIL FROM:<mrose@dbc.mtview.ca.us>
+S: 250 sender <mrose@dbc.mtview.ca.us> OK
+C: RCPT TO:<ned@innosoft.com>
+S: 250 recipient <ned@innosoft.com> OK
+C: RCPT TO:<dan@innosoft.com>
+S: 250 recipient <dan@innosoft.com> OK
+C: RCPT TO:<kvc@innosoft.com>
+S: 250 recipient <kvc@innosoft.com> OK
+C: DATA
+S: 354 enter mail, end with line containing only "."
+ ...
+C: .
+S: 250 message sent
+C: QUIT
+S: 221 goodbye
+
+The client waits for a server response a total of 9 times in
+
+
+
+
+
+                       Expires May 1999               [Page 6]
+
+
+
+
+
+Internet Draft         SMTP Pipelining           November 1998
+
+
+this simple example. But if pipelining is employed the
+following dialogue is possible:
+
+S: <wait for open connection>
+C: <open connection to server>
+S: 220 innosoft.com SMTP service ready
+C: EHLO dbc.mtview.ca.us
+S: 250-innosoft.com
+S: 250 PIPELINING
+C: MAIL FROM:<mrose@dbc.mtview.ca.us>
+C: RCPT TO:<ned@innosoft.com>
+C: RCPT TO:<dan@innosoft.com>
+C: RCPT TO:<kvc@innosoft.com>
+C: DATA
+S: 250 sender <mrose@dbc.mtview.ca.us> OK
+S: 250 recipient <ned@innosoft.com> OK
+S: 250 recipient <dan@innosoft.com> OK
+S: 250 recipient <kvc@innosoft.com> OK
+S: 354 enter mail, end with line containing only "."
+ ...
+C: .
+C: QUIT
+S: 250 message sent
+S: 221 goodbye
+
+The total number of turnarounds has been reduced from 9 to 4.
+
+The next example illustrates one possible form of behavior
+when pipelining is used and all recipients are rejected:
+
+S: <wait for open connection>
+C: <open connection to server>
+S: 220 innosoft.com SMTP service ready
+C: EHLO dbc.mtview.ca.us
+S: 250-innosoft.com
+S: 250 PIPELINING
+C: MAIL FROM:<mrose@dbc.mtview.ca.us>
+C: RCPT TO:<nsb@thumper.bellcore.com>
+C: RCPT TO:<galvin@tis.com>
+C: DATA
+S: 250 sender <mrose@dbc.mtview.ca.us> OK
+S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
+S: 550 remote mail to <galvin@tis.com> not allowed
+S: 554 no valid recipients given
+C: QUIT
+
+
+
+
+
+                       Expires May 1999               [Page 7]
+
+
+
+
+
+Internet Draft         SMTP Pipelining           November 1998
+
+
+S: 221 goodbye
+
+The client SMTP waits for the server 4 times here as well. If
+the server SMTP does not check for at least one valid
+recipient prior to accepting the DATA command, the following
+dialogue would result:
+
+S: <wait for open connection>
+C: <open connection to server>
+S: 220 innosoft.com SMTP service ready
+C: EHLO dbc.mtview.ca.us
+S: 250-innosoft.com
+S: 250 PIPELINING
+C: MAIL FROM:<mrose@dbc.mtview.ca.us>
+C: RCPT TO:<nsb@thumper.bellcore.com>
+C: RCPT TO:<galvin@tis.com>
+C: DATA
+S: 250 sender <mrose@dbc.mtview.ca.us> OK
+S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
+S: 550 remote mail to <galvin@tis.com> not allowed
+S: 354 enter mail, end with line containing only "."
+C: .
+C: QUIT
+S: 554 no valid recipients
+S: 221 goodbye
+
+
+6.  Security Considerations
+
+This RFC does not discuss security issues and is not believed
+to raise any security issues not endemic in electronic mail
+and present in fully conforming implementations of [1].
+
+
+7.  Acknowledgements
+
+This document is based on the SMTP service extension model
+presented in RFC 1425. Marshall Rose's description of SMTP
+command pipelining in his book "The Internet Message" also
+served as a source of inspiration for this extension.
+
+
+
+
+
+
+
+
+
+
+                       Expires May 1999               [Page 8]
+
+
+
+
+
+Internet Draft         SMTP Pipelining           November 1998
+
+
+8.  References
+
+[1]  J.B. Postel. Simple Mail Transfer Protocol. STD 10, RFC
+     821, (August, 1982).
+
+[4]  R. Braden, Editor, Requirements for Internet Hosts --
+     Application and Support.  STD 3, RFC 1123, (October
+     1989).
+
+[3]  J.C. Klensin, N. Freed, M.T. Rose, E.A. Stefferud,
+     D.H. Crocker. SMTP Service Extensions. STD 10, RFC 1869,
+     (November, 1995).
+
+[4]  N. Freed. SMTP Service Extension for Command Pipelining.
+     RFC 1854, (October, 1995).
+
+[5]  N. Freed. SMTP Service Extension for Command Pipelining.
+     RFC 2197, (September, 1997).
+
+
+9.  Author's Address
+
+Ned Freed
+Innosoft International, Inc.
+1050 Lakes Drive
+West Covina, CA 91790
+USA
+ tel: +1 626 919 3600           fax: +1 626 919 3614
+ email: ned.freed@innosoft.com
+
+This document is a product of work done by the Internet
+Engineering Task Force Working Group on Messaging Extensions,
+Alan Cargille, chair.
+
+
+10.  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
+
+
+
+
+
+                       Expires May 1999               [Page 9]
+
+
+
+
+
+Internet Draft         SMTP Pipelining           November 1998
+
+
+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 May 1999              [Page 10]
+
+
diff --git a/Documentation/en/I-D/draft-freed-smtp-pipe-01.txt b/Documentation/en/I-D/draft-freed-smtp-pipe-01.txt
new file mode 100644
index 00000000..5ab22e56
--- /dev/null
+++ b/Documentation/en/I-D/draft-freed-smtp-pipe-01.txt
@@ -0,0 +1,584 @@
+
+Network Working Group                                Ned Freed
+Internet Draft                                        Innosoft
+Obsoletes: 2197, 1854           <draft-freed-smtp-pipe-01.txt>
+
+                    SMTP Service Extension
+                    for Command Pipelining
+
+                          March 2000
+
+
+                     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.
+
+                       Copyright Notice
+
+Copyright (C) The Internet Society (2000).  All Rights
+Reserved.
+
+
+1.  Abstract
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Internet Draft         SMTP Pipelining              March 2000
+
+
+The present document is an updated version of [RFC-2197],
+which in turn was a revision of [RFC-1854]. Only textual and
+editorial changes have been made; the protocol has not changed
+in any way.
+
+
+2.  Introduction
+
+Although SMTP is widely and robustly deployed, certain
+extensions may nevertheless prove useful. In particular, many
+parts of the Internet make use of high latency network links.
+SMTP's intrinsic one command-one response structure is
+significantly penalized by high latency links, often to the
+point where the factors contributing to overall connection
+time are dominated by the time spent waiting for responses to
+individual commands (turnaround time).
+
+In the best of all worlds it would be possible to simply
+deploy SMTP client software that makes use of command
+pipelining: batching up multiple commands into single TCP send
+operations. Unfortunately, the original SMTP specification
+[RFC-821] did not explicitly state that SMTP servers must
+support this. As a result a non-trivial number of Internet
+SMTP servers cannot adequately handle command pipelining.
+Flaws known to exist in deployed servers include:
+
+ (1)   Connection handoff and buffer flushes in the middle of
+       the SMTP dialogue.  Creation of server processes for
+       incoming SMTP connections is a useful, obvious, and
+       harmless implementation technique. However, some SMTP
+       servers defer process forking and connection handoff
+       until some intermediate point in the SMTP dialogue.
+       When this is done material read from the TCP connection
+       and kept in process buffers can be lost.
+
+ (2)   Flushing the TCP input buffer when an SMTP command
+       fails. SMTP commands often fail but there is no reason
+       to flush the TCP input buffer when this happens.
+       Nevertheless, some SMTP servers do this.
+
+ (3)   Improper processing and promulgation of SMTP command
+       failures. For example, some SMTP servers will refuse to
+       accept a DATA command if the last RCPT TO command
+       fails, paying no attention to the success or failure of
+       prior RCPT TO command results. Other servers will
+
+
+
+
+
+                    Expires September 2000            [Page 2]
+
+
+
+
+
+Internet Draft         SMTP Pipelining              March 2000
+
+
+accept a DATA command even when all previous RCPT TO commands
+       have failed. Although it is possible to accommodate
+       this sort of behavior in a client that employs command
+       pipelining, it does complicate the construction of the
+       client unnecessarily.
+
+This memo uses the mechanism described in [RFC-1869] to define
+an extension to the SMTP service whereby an SMTP server can
+declare that it is capable of handling pipelined commands. The
+SMTP client can then check for this declaration and use
+pipelining only when the server declares itself capable of
+handling it.
+
+
+2.1.  Requirements Notation
+
+This document occasionally uses terms that appear in capital
+letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD
+NOT", and "MAY" appear capitalized, they are being used to
+indicate particular requirements of this specification. A
+discussion of the meanings of the terms "MUST", "SHOULD", and
+"MAY" appears in  [RFC-1123]; the terms "MUST NOT" and "SHOULD
+NOT" are logical extensions of this usage.
+
+
+3.  Framework for the Command Pipelining Extension
+
+The Command Pipelining extension is defined as follows:
+
+ (1)   the name of the SMTP service extension is Pipelining;
+
+ (2)   the EHLO keyword value associated with the extension is
+       PIPELINING;
+
+ (3)   no parameter is used with the PIPELINING EHLO keyword;
+
+ (4)   no additional parameters are added to either the MAIL
+       FROM or RCPT TO commands.
+
+ (5)   no additional SMTP verbs are defined by this extension;
+       and,
+
+ (6)   the next section specifies how support for the
+       extension affects the behavior of a server and client
+       SMTP.
+
+
+
+
+
+                    Expires September 2000            [Page 3]
+
+
+
+
+
+Internet Draft         SMTP Pipelining              March 2000
+
+
+4.  The Pipelining Service Extension
+
+When a client SMTP wishes to employ command pipelining, it
+first issues the EHLO command to the server SMTP. If the
+server SMTP responds with code 250 to the EHLO command, and
+the response includes the EHLO keyword value PIPELINING, then
+the server SMTP has indicated that it can accommodate SMTP
+command pipelining.
+
+
+4.1.  Client use of pipelining
+
+Once the client SMTP has confirmed that support exists for the
+pipelining extension, the client SMTP may then elect to
+transmit groups of SMTP commands in batches without waiting
+for a response to each individual command. In particular, the
+commands RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, and
+RCPT TO can all appear anywhere in a pipelined command group.
+The EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP commands can
+only appear as the last command in a group since their success
+or failure produces a change of state which the client SMTP
+must accommodate. (NOOP is included in this group so it can be
+used as a synchronization point.)
+
+Additional commands added by other SMTP extensions may only
+appear as the last command in a group unless otherwise
+specified by the extensions that define the commands.
+
+The actual transfer of message content is explicitly allowed
+to be the first "command" in a group. That is, a RSET/MAIL
+FROM sequence used to initiate a new message transaction can
+be placed in the same group as the final transfer of the
+headers and body of the previous message.
+
+Client SMTP implementations that employ pipelining MUST check
+ALL statuses associated with each command in a group. For
+example, if none of the RCPT TO recipient addresses were
+accepted the client must then check the response to the DATA
+command -- the client cannot assume that the DATA command will
+be rejected just because none of the RCPT TO commands worked.
+If the DATA command was properly rejected the client SMTP can
+just issue RSET, but if the DATA command was accepted the
+client SMTP should send a single dot.
+
+
+
+
+
+
+
+                    Expires September 2000            [Page 4]
+
+
+
+
+
+Internet Draft         SMTP Pipelining              March 2000
+
+
+Command statuses MUST be coordinated with responses by
+counting each separate response and correlating that count
+with the number of commands known to have been issued.
+Multiline responses MUST be supported. Matching on the basis
+of either the error code value or associated text is expressly
+forbidden.
+
+Client SMTP implementations MAY elect to operate in a
+nonblocking fashion, processing server responses immediately
+upon receipt, even if there is still data pending transmission
+from the client's previous TCP send operation. If nonblocking
+operation is not supported, however, client SMTP
+implementations MUST also check the TCP window size and make
+sure that each group of commands fits entirely within the
+window. The window size is usually, but not always, 4K octets.
+Failure to perform this check can lead to deadlock conditions.
+
+Clients MUST NOT confuse responses to multiple commands with
+multiline responses. Each command requires one or more lines
+of response, the last line not containing a dash between the
+response code and the response string.
+
+
+4.2.  Server support of pipelining
+
+A server SMTP implementation that offers the pipelining
+extension:
+
+ (1)   MUST respond to commands in the order they are received
+       from the client.
+
+ (2)   SHOULD elect to store responses to grouped RSET, MAIL
+       FROM, SEND FROM, SOML FROM, SAML FROM, and RCPT TO
+       commands in an internal buffer so they can sent as a
+       unit.
+
+ (3)   SHOULD issue a positive response to the DATA command if
+       and only if one or more valid RCPT TO addresses have
+       been previously received.
+
+ (4)   MUST NOT, after issuing a positive response to a DATA
+       command with no valid recipients and subsequently
+       receiving an empty message, send any message whatsoever
+       to anybody.
+
+
+
+
+
+
+                    Expires September 2000            [Page 5]
+
+
+
+
+
+Internet Draft         SMTP Pipelining              March 2000
+
+
+ (5)   MUST NOT buffer responses to EHLO, DATA, VRFY, EXPN,
+       TURN, QUIT, and NOOP.
+
+ (6)   MUST NOT buffer responses to unrecognized commands.
+
+ (7)   MUST send all pending responses immediately whenever
+       the local TCP input buffer is emptied.
+
+ (8)   MUST NOT make assumptions about commands that are yet
+       to be received.
+
+ (9)   MUST NOT flush or otherwise lose the contents of the
+       TCP input buffer under any circumstances whatsoever.
+
+ (10)  SHOULD issue response text that indicates, either
+       implicitly or explicitly, what command the response
+       matches.
+
+The overriding intent of these server requirements is to make
+it as easy as possible for servers to conform to these
+pipelining extensions.
+
+
+5.  Examples
+
+Consider the following SMTP dialogue that does not use
+pipelining:
+
+S: <wait for open connection>
+C: <open connection to server>
+S: 220 innosoft.com SMTP service ready
+C: HELO dbc.mtview.ca.us
+S: 250 innosoft.com
+C: MAIL FROM:<mrose@dbc.mtview.ca.us>
+S: 250 sender <mrose@dbc.mtview.ca.us> OK
+C: RCPT TO:<ned@innosoft.com>
+S: 250 recipient <ned@innosoft.com> OK
+C: RCPT TO:<dan@innosoft.com>
+S: 250 recipient <dan@innosoft.com> OK
+C: RCPT TO:<kvc@innosoft.com>
+S: 250 recipient <kvc@innosoft.com> OK
+C: DATA
+S: 354 enter mail, end with line containing only "."
+ ...
+C: .
+
+
+
+
+
+                    Expires September 2000            [Page 6]
+
+
+
+
+
+Internet Draft         SMTP Pipelining              March 2000
+
+
+S: 250 message sent
+C: QUIT
+S: 221 goodbye
+
+The client waits for a server response a total of 9 times in
+this simple example. But if pipelining is employed the
+following dialogue is possible:
+
+S: <wait for open connection>
+C: <open connection to server>
+S: 220 innosoft.com SMTP service ready
+C: EHLO dbc.mtview.ca.us
+S: 250-innosoft.com
+S: 250 PIPELINING
+C: MAIL FROM:<mrose@dbc.mtview.ca.us>
+C: RCPT TO:<ned@innosoft.com>
+C: RCPT TO:<dan@innosoft.com>
+C: RCPT TO:<kvc@innosoft.com>
+C: DATA
+S: 250 sender <mrose@dbc.mtview.ca.us> OK
+S: 250 recipient <ned@innosoft.com> OK
+S: 250 recipient <dan@innosoft.com> OK
+S: 250 recipient <kvc@innosoft.com> OK
+S: 354 enter mail, end with line containing only "."
+ ...
+C: .
+C: QUIT
+S: 250 message sent
+S: 221 goodbye
+
+The total number of turnarounds has been reduced from 9 to 4.
+
+The next example illustrates one possible form of behavior
+when pipelining is used and all recipients are rejected:
+
+S: <wait for open connection>
+C: <open connection to server>
+S: 220 innosoft.com SMTP service ready
+C: EHLO dbc.mtview.ca.us
+S: 250-innosoft.com
+S: 250 PIPELINING
+C: MAIL FROM:<mrose@dbc.mtview.ca.us>
+C: RCPT TO:<nsb@thumper.bellcore.com>
+C: RCPT TO:<galvin@tis.com>
+C: DATA
+
+
+
+
+
+                    Expires September 2000            [Page 7]
+
+
+
+
+
+Internet Draft         SMTP Pipelining              March 2000
+
+
+S: 250 sender <mrose@dbc.mtview.ca.us> OK
+S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
+S: 550 remote mail to <galvin@tis.com> not allowed
+S: 554 no valid recipients given
+C: QUIT
+S: 221 goodbye
+
+The client SMTP waits for the server 4 times here as well. If
+the server SMTP does not check for at least one valid
+recipient prior to accepting the DATA command, the following
+dialogue would result:
+
+S: <wait for open connection>
+C: <open connection to server>
+S: 220 innosoft.com SMTP service ready
+C: EHLO dbc.mtview.ca.us
+S: 250-innosoft.com
+S: 250 PIPELINING
+C: MAIL FROM:<mrose@dbc.mtview.ca.us>
+C: RCPT TO:<nsb@thumper.bellcore.com>
+C: RCPT TO:<galvin@tis.com>
+C: DATA
+S: 250 sender <mrose@dbc.mtview.ca.us> OK
+S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
+S: 550 remote mail to <galvin@tis.com> not allowed
+S: 354 enter mail, end with line containing only "."
+C: .
+C: QUIT
+S: 554 no valid recipients
+S: 221 goodbye
+
+
+6.  Security Considerations
+
+This RFC does not discuss security issues and is not believed
+to raise any security issues not endemic in electronic mail
+and present in fully conforming implementations of [RFC-821].
+
+
+7.  Acknowledgements
+
+This document is based on the SMTP service extension model
+presented in RFC 1425. Marshall Rose's description of SMTP
+command pipelining in his book "The Internet Message" also
+served as a source of inspiration for this extension.
+
+
+
+
+
+                    Expires September 2000            [Page 8]
+
+
+
+
+
+Internet Draft         SMTP Pipelining              March 2000
+
+
+8.  References
+
+[RFC-821]
+     Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+     821, August, 1982.
+
+[RFC-1123]
+     Braden, R., "Requirements for Internet Hosts --
+     Application and Support", STD 3, RFC 1123, October, 1989.
+
+[RFC-1854]
+     Freed, N., "SMTP Service Extension for Command
+     Pipelining", RFC 1854, October, 1995.
+
+[RFC-1869]
+     "Klensin, J., Freed, N., Rose, M., Stefferud, E.,
+     Crocker, D., "SMTP Service Extensions", STD 10, RFC 1869,
+     November, 1995.
+
+[RFC-2197]
+     Freed, N., "SMTP Service Extension for Command
+     Pipelining", RFC 2197, September, 1997.
+
+
+9.  Author's Address
+
+Ned Freed
+Innosoft International, Inc.
+1050 Lakes Drive
+West Covina, CA 91790
+USA
+ tel: +1 626 919 3600           fax: +1 626 919 3614
+ email: ned.freed@innosoft.com
+
+This document is a product of work done by the Internet
+Engineering Task Force Working Group on Messaging Extensions,
+Alan Cargille, chair.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                    Expires September 2000            [Page 9]
+
+
+
+
+
+Internet Draft         SMTP Pipelining              March 2000
+
+
+10.  Full Copyright Statement
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                    Expires September 2000           [Page 10]
+
diff --git a/Documentation/en/I-D/draft-freed-smtp-pipeline-02.txt b/Documentation/en/I-D/draft-freed-smtp-pipeline-02.txt
new file mode 100644
index 00000000..db08d2b1
--- /dev/null
+++ b/Documentation/en/I-D/draft-freed-smtp-pipeline-02.txt
@@ -0,0 +1,67 @@
+
+
+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-hoffman-legis-smtp-banner-03.txt b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-03.txt
new file mode 100644
index 00000000..c4948ace
--- /dev/null
+++ b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-03.txt
@@ -0,0 +1,169 @@
+
+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-smtp-ssl-10.txt b/Documentation/en/I-D/draft-hoffman-smtp-ssl-10.txt
new file mode 100644
index 00000000..9442e135
--- /dev/null
+++ b/Documentation/en/I-D/draft-hoffman-smtp-ssl-10.txt
@@ -0,0 +1,62 @@
+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-ietf-drums-smtpupd-11.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-11.txt
new file mode 100644
index 00000000..ec272339
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-11.txt
@@ -0,0 +1,4018 @@
+INTERNET-DRAFT                                John C. Klensin, Editor
+Expires September 9, 2000
+March 9, 2000
+
+
+                  Simple Mail Transfer Protocol
+
+                 draft-ietf-drums-smtpupd-11.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.
+
+[[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 and Message Stores
+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 General Syntax Principles and Transaction Model
+
+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.3.1 Size limits and minimums
+4.5.3.2 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
+
+Appendices
+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 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 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 [MSGFMT] discusses message headers, message bodies
+and formats and structures for them, and their relationship.
+
+Comments on this draft should be addressed to the IETF DRUMS Working
+Group:
+	 General Discussion:drums@cs.utk.edu
+	 To Subscribe: drums-request@cs.utk.edu
+	 Archive: ftp://cs.utk.edu/pub/drums/mail-archive/
+
+
+
+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
+networks, usually referred to as "SMTP mail relaying" (see section 3.8).
+A network consists of the mutually-TCP-accessible hosts on the public
+Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP
+Intranet, or hosts in some other LAN or WAN environment utilizing a
+non-TCP transport-level protocol.  Using SMTP, a process can transfer
+mail to another process on the same network or to some other network via
+a relay or gateway process accessible to both networks.
+
+Inthis way, a mail message may pass through a number of intermediate
+relay or gateway hosts on its path from sender to ultimate recipient.
+The Mail eXchanger mechanisms of the domain name system [RFC-DNS, and
+section 5 of this document] are used to identify the appropriate next-hop
+destination for a message being transported.
+
+
+2. The SMTP Model
+
+2.1 Basic Structure
+
+The SMTP design can be pictured as:
+
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Client- |Commands/Replies| Server-  |
+   +------+    |   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 responsibility 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 presented 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.
+
+In other words, message transfer can occur in a single connection between
+the original SMTP-sender and the final SMTP-recipient, or can occur in a
+series of hops through intermediary systems.  In either case, a formal
+handoff of responsibility for the message occurs: the protocol requires
+that a server accept responsibility for either delivering a message or
+properly reporting the failure to do so.
+
+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 section 5 and 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 and RCPT 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 or RCPT
+   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 and/or RCPT, 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 violate "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 other
+contemporary 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 and Message Stores
+
+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, e.g., by depositing the message in a "message
+store").  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.  These components ("labels" in DNS terminology [RFC-DNS]
+are restricted for SMTP purposes to consist of a sequence of letters,
+digits, and hyphens drawn from the ASCII character set [US-ASCII}.
+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.  Limits MAY be imposed on line
+lengths by servers (see section 4.5.3).
+
+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 passes 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.  For the purposes of this specification, firewalls
+that rewrite addresses should be considered as gateways, even if SMTP
+is used on both sides of them.  (See [IAB-Firewalls].)
+
+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".  Consequently, and due to a long history of problems when
+intermediate hosts have attempted to optimize transport by modifying
+them, the local-part MUST be 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.  Recent work [RFC-Reply] has specified further structuring
+of the reply strings, including the use of supplemental and more
+specific completion codes.
+
+2.4 General Syntax Principles 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 space character. Complete definitions of
+commands and replies appear in section 4.
+
+Verbs and argument values (e.g., "TO:" or "to:" in the MAIL command and
+extension name keywords) 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.  In particular, for some hosts the user "smith" is
+different from the user "Smith".  However, exploiting the case
+sensitivity of mailbox local-parts impedes interoperability and is
+discouraged.
+
+A few SMTP servers, in violation of this specification (and RFC 821)
+require that command verbs 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 end of the line, i.e., 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.
+
+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.
+
+
+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.  For a particular connection attempt, if
+the server returns a "command not recognized" response to EHLO, the
+client SHOULD be able to fall back and send HELO.
+
+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> [<SP> <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> portion of the first or
+only argument 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>
+
+The first or only argument to this command includes 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 a RCPT command appears without a previous MAIL
+command, 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, or no RCPT, command, or all such commands
+   were rejected, the server MAY return a "command out of sequence"
+   (503) reply in response to the DATA command.  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
+   (including, of course, the server unexpectedly becoming
+   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 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 (in the sense of actually validating
+addresses and returning information) 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 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, RFC-974] 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, SMTP servers 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.
+
+Many mail-sending clients exist, especially in conjunction with
+facilities that receive mail via POP3 or IMAP, that have limited
+capability to support some of the requirements of this specification,
+such as the ability to queue messages for subsequent delivery attempts.
+For these clients, it is common practice to make private arrangements
+to send all messages to a single server for processing and subsequent
+distribution.  SMTP, as specified here, is not ideally suited for this
+role, and work is underway on standardized mail submission protocols
+that might eventually supercede the current practices.  In any event,
+because these arrangements are private and fall outside the scope of
+this specification, they are not described here.
+
+It is important to note that MX records can point to SMTP servers which
+act as gateways into other environments, not just SMTP relays and final
+delivery systems; see sections 3.8 and 5.
+
+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, optionally,
+to attempt to detect looping in the mail system (see 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.  Addresses and headers generated by gateways MUST conform to
+applicable Internet standards (including this one and RFC-822).
+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.  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.
+
+Syntax:
+  ehlo            = "EHLO" SP Domain CRLF
+  helo            = "HELO" SP Domain CRLF
+
+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 ehlo-greet ] CRLF )
+                / (    "250-"   domain [ SP ehlo-greet ] CRLF
+                    *( "250-"   ehlo-line                CRLF )
+                       "250"    SP ehlo-line             CRLF  )
+
+   ehlo-greet   = 1*(%d0-9 / %d11-12 / %d14-127)
+                ; string of any characters other than CR or LF
+
+   ehlo-line    = ehlo-keyword *( SP ehlo-param )
+
+   ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+                ; additional syntax of ehlo-params depends on
+				; ehlo-keyword
+
+   ehlo-param   = 1*(%d33-127)
+                ; any CHAR excluding <SP> and all
+                ; control characters (US-ASCII 0-31 inclusive)
+
+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 an SMTP server which may, in turn, deliver it to
+one or more mailboxes or pass it on to another system (possibly using
+SMTP).  The argument field contains a reverse-path and may contain
+optional parameters.  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.  Historically, that
+mailbox might optionally have been preceeded by a list of hosts, but
+that behavior.  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] CRLF
+
+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 argument field contains a forward-path and may contain
+optional parameters.
+
+The forward-path normally consists of the required destination mailbox.
+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 hosta.int, using the envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+or 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 command is received,
+using a 550 code (since this is a "policy reason").
+
+If service extensions were negotiated, the RCPT 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:" ("<Postmaster@" domain ">" / Forward-Path)
+                    [SP Rcpt-parameters] CRLF
+
+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.
+
+Syntax:
+   "DATA" CRLF
+
+
+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" CRLF
+
+
+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 CRLF
+
+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 CRLF
+
+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 ] CRLF
+
+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 ] CRLF
+
+
+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 SHOULD wait until it 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" CRLF
+
+
+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 = esmtp-param *(SP esmtp-param)
+   Rcpt-parameters = esmtp-param *(SP esmtp-param)
+   esmtp-param     = esmtp-keyword ["=" esmtp-value]
+   esmtp-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+   esmtp-value     = 1*(%d33-60 / %d62-127)
+                     ; any CHAR excluding "=", SP, and control
+					 ; characters
+   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 "]"
+                 ; See section 4.1.3
+
+   Mailbox = Local-part "@" Domain
+
+   Local-part = Dot-string / Quoted-string
+              ; MAY be case-sensitive
+
+   Dot-string = Atom [ "." Atom ]
+
+   Atom = 1*atext
+
+   Quoted-string = DQUOTE *qcontent DQUOTE
+
+   String = Atom / Quoted-string
+
+
+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
+in SMTP 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 or RCPT commands or other commands
+that require mailbox names.
+
+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 invalid 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 [IPv6AddrSpec].
+
+Specifically:
+
+   IPv4-address-literal = Snum 3("." Snum)
+   IPv6-address-literal = "IPv6:" IPv6-addr
+   General-address-literal = Standardized-tag ":" 1*dcontent
+   Standardized-tag = Ldh-str
+                    ; MUST be 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
+
+   IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
+   IPv6-hex  = 1*4HEXDIG
+   IPv6-full = IPv6-hex 7(":" IPv6-hex)
+   IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
+              IPv6-hex)]
+            ; The "::" represents at least 2 16-bit groups of zeros
+            ; No more than 6 groups in addition to the "::" may be
+			; present
+   IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
+   IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
+                [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
+            ; The "::" represents at least 2 16-bit groups of zeros
+            ; No more than 4 groups in addition to the "::" and
+            ; IPv4-address-literal may be present
+
+
+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, if possible, 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 for this reason 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 do not 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 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.
+
+When an SMTP server returns a permanent error status (5yz) code after
+the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make any
+further attempt to deliver the message.  As with temporary error status
+codes, the SMTP client retains responsibility for the message, but
+SHOULD not again attempt delivery to the same server without user
+review and intervention of the message.
+
+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 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 reverse path address from the
+MAIL command) as the destination for error messages is not applicable
+on the Internet. The reverse path 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 reverse path argument to
+   the MAIL command in 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 60 (to allow
+							  for leap seconds), 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
+
+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 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, that
+store data in records rather than strings, or which use special
+character sequences as delimiters inside mailboxes.  If such
+transformations are necessary, they MUST be reversible, especially if
+they are applied to mail being relayed.
+
+4.5.3 Sizes and Timeouts
+
+4.5.3.1 Size limits and minimums
+
+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 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 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 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
+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 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.
+
+4.5.3.2 Timeouts
+
+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 the
+MAIL command 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 but servers that
+cannot handle more than one SMTP transaction at a time are not in
+conformance with the intent of this specification.
+
+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 MUST be 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.  Of course, neither of the latter require that the list of
+MX records be examined further.
+
+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 MUST 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 return path
+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 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 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 command.
+
+There is no inherent relationship between either "reverse" (from MAIL,
+SAML, etc., commands) or "forward" (RCPT) 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 as well as a
+common source of unintended information disclosure 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, or RCPT 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.
+
+[IPv6AddrSpec] 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] Partridge, C., "Mail routing and the domain system", RFC 974,
+01/01/1986
+
+[RFC-1047] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
+02/01/1988.
+
+[RFC-1123] Braden, R., "Requirements for Internet hosts - application and
+support", 10/01/1989
+
+[RFC-BDAT] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large
+and Binary MIME Messages", RFC 1830, 08/16/1995.
+
+[RFC-DNS] Mockapetris, P., "Domain names - implementation and
+specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and
+facilities", RFC 1034. (STD 13)
+
+[RFC-ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue
+Starting", RFC 1985, 08/14/1996.
+
+[RFC-IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
+1176, 08/20/1990.
+
+[RFC-IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
+2060, 12/04/1996.
+
+[RFC-INTLHDR] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996.
+
+[IAB-Firewalls] Freed, N, ed., "Behavior of and Requirements for
+Internet Firewalls", Work in progress, draft-iab-firewall-req-01.txt,
+Feb 2000.
+
+[RFC-MIME] Freed, N., N. Borenstein, "Multipurpose Internet Mail Extensions
+(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996.
+
+[RFC-MOSS] Crocker, S., 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.
+
+[SMTPEXT] 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
+AT&T Laboratories
+Tel: 617-674-3076
+email: klensin@research.att.com
+
+
+
+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.
+
+
+
+
+							   APPENDICES
+
+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 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
+   C:     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.
+
+(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).
+
+(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy
+matters.
+
+
+X.1.10. Substantive changes between draft-ietf-drums-smtpupd-09.txt and
+draft-ietf-drums-smtpupd-10.txt.
+
+(i) A large series of typos, most of them caught by Philip Hazel,
+corrected.
+
+(ii) Residual problems with references to mailboxes, forward, and
+reverse paths in 4.1.1.2 and 4.1.1.3 corrected and some text, I hope,
+clarified.
+
+(iii) Text added to 4.2.5 to talk about 5yz errors after DATA.  This
+text should be checked carefully -- it is a proposal and may or may not
+reflect WG consensus.
+
+(iv) Upper bound on "seconds" has been changed to 60 (not 61), per list
+discussion.  Years are still four-digits and will stay that way unless
+the list discussion converges on something else.  The increase to 60
+seconds includes an explicit note about leap seconds.
+
+(v) Text has been inserted to reflect the Orlando consensus about
+"QUIT", i.e., the client MUST send a QUIT command and SHOULD wait for
+the results before closing the connection.  Servers are still not
+permitted to close without receiving a QUIT and sending a 221 response
+(except, of course, under the usual "unavoidable circumstances", in
+which case they should get off a 451 if that is feasible).
+
+(vi) The EHLO response specification has been changed back to reflect
+non-advertisement of VRFY and some text implying that VRFY was optional
+to support has been removed (WG consensus seemed to be moving in that
+direction at one point, and the editor reacted prematurely).  This
+makes the text compatible with RFC1869 and restores VRFY to its RFC1123
+status.
+
+(vii) The text in section 5 has been clarified with regard to what a
+relay that receives a message because of its designation as an MX can
+do and 3.7 has been slightly modified to point to it.
+
+(viii) New text has been added to 3.7 to clarify the use of "SMTP
+server" relays in "dumb" originating clients.
+
+(viii) Small wording changes inserted into 4.1.4 (e.g., insertion of ",
+if possible," into the first sentence of the fifth paragraph to
+eliminate the apparent conflict with the second sentence).
+
+
+X.1.11. Substantive changes between draft-ietf-drums-smtpupd-10.txt and
+draft-ietf-drums-smtpupd-11.txt.  Note that the most significant change
+is the insertion of RFC 2234-conforming ABNF throughout.  That material
+should be checked carefully.
+
+(i) Dumb client text revised again, as discussed on the list and using
+the text agreed to there.  New text simply notes that the submission
+issues are outside the scope of the spec/standard.
+
+(ii) ABNF updated and replaced (thanks, Chris).  Some possible issues/
+questions:
+
+  (ii.1) RFC 1869 permits a NUL octet in the greeting (ehlo-greet in
+       the syntax).  Chris proposes to remove that capability on the
+	   grounds that it has no obvious value and will probably not
+	   work with many servers anyway.
+
+  (ii.2) Previous drafts have assumed that the tag to indicate what
+       is coming in a non-IPv4 address literal will be separated by
+	   the address itself by a space.  Chris proposes to change it to
+	   a colon, on the theory that this will cause fewer parsing
+	   problems with existing MTAs and MUAs.
+
+  (ii.3) The full IPv6 address syntax has been transposed from
+       the prose of RFC2373 into ABNF.  It can be left out and 2373
+	   cited if the WG prefers.
+
+(iii) Added firewall clarification to section 2.3.8.
+
+(iv) Small clarifications and tightenings in several sections, notably
+the end of 3.7, 3.8.3, 4.5.4.2, 7.2, clarifying editorial changes
+elsewhere, slightly improved crossreferences, and some redundant
+sections stripped out.  Many thanks to Graham Klyne for extensive
+and specific comments in these areas.
+
+(v) The "TO:" in "RCPT TO:" is part of an argument, not part of the
+command.  Similarly for "FROM:" in "MAIL FROM:".  All of these are
+believed to be fixed.
+
+(vi)Section 2.3.5 has been changed to make it clear that restrictions
+on the syntax and character set of domain names are part of the mail
+system, not an intrinsic limit of the DNS itself.   This, and some
+other text, are not going to be popular with those working to
+internationalize the DNS, but I believe it is important to lay down a
+clear baseline and then start making modifications or extensions,
+rather than trying to delude ourselves with a DNS equivalent of "just
+send 8".
+
+(vii) Clarified the EHLO-> HELO fallback requirement in 3.2.  I think
+this is consistent with what the WG wanted; if not, I'm sure I'll hear
+about it.
+
+
+
+
+
+Z.  Full Copyright Statement
+
+Copyright (C) The Internet Society (1998-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.
+
+Expires September 9, 2000.
diff --git a/Documentation/en/I-D/draft-ietf-fax-smtp-capabilities-00.txt b/Documentation/en/I-D/draft-ietf-fax-smtp-capabilities-00.txt
new file mode 100644
index 00000000..5fc86e9d
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-fax-smtp-capabilities-00.txt
@@ -0,0 +1,503 @@
+
+Network Working Group                                           Dan Wing
+Internet Draft                                                Neil Joffe
+November 3, 1997                                     Cisco Systems, Inc.
+Expires May 1998
+
+
+            SMTP Service Extension for Capabilities Exchange
+                draft-ietf-fax-smtp-capabilities-00.txt
+
+
+Status of this memo
+
+This document is an Internet-Draft. Internet-Drafts are working
+documents .br 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), ftp.nordu.net (Europe),
+munnari.oz.au (Pacific Rim), ds.internic.net (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.
+
+
+0.  Administrivia
+
+0.1.  Changes since previous versions
+
+Changes from draft-wing-smtp-capabilities-00.txt to
+draft-ietf-fax-smtp-capabilities-00.txt:
+
+  * Filename changed from -wing- to -ietf-fax-.
+  * More example methods to get recipient capabilities in section
+    2.1.
+  * Reference fax requirements document and fax profile for internet
+    mail document.
+
+
+1.  Abstract
+
+
+
+Wing, Joffe                 Expires May 1998                    [Page 1]
+
+Internet Draft        SMTP Capabilities Exchange           November 1997
+
+
+This document describes an extension to SMTP [SMTP] which provides a
+mechanism for capabilities exchange so the sender of a message can know
+selected capabilities of its ultimate recipient, or of the message
+transmission path to that recipient.
+
+
+2.  Introduction
+
+This memo defines a mechanism to allow an SMTP client to determine the
+capabilities (such as viewers, word processors, and color support) and
+preferences (such as language) of a recipient, which allows the SMTP
+client to send a message in a format that is usable by the recipient.
+
+This memo was motivated by an analysis of the requirements for using the
+Internet to deliver fax messages, described in [FAX-REQ] and
+[FAX-PROFILE].  While capabilities exchange is necessary for fax, it can
+be useful in other messaging scenerios such as delivery to cellular
+telephones via SMS, security [SMIME-40BIT], and to send normal messages
+that will be usable by the recipient.
+
+
+2.1.  CAPABILITIES Extension
+
+The CAPABILITIES extension permits an SMTP client to easily obtain a
+list of a recipient's capabilities.  These capabilities can be used by
+the client to send a message that is known to be readable, processable,
+or understood by the recipient, or to inform the mail user agent that
+the recipient will be unable to read the message.
+
+The CAPS esmtp-keyword for the RCPT command causes the server to
+advertise recipient capabilities.  These capabilities can be:
+
+  (a)  those of the actual recipient (if known through a mechanism
+       such as [ACAP], [DIR-EMAIL], [DS-EMAIL], [SALUTATION], querying
+       the next MTA in the SMTP path, or some other
+       implementation-specific mechanism), or
+
+  (b)  the recipient's capabilities (from (a)), plus those capabilities
+       the SMTP server is willing to accept and translate to the
+       recipient's capabilities (text/8bit to text/quoted-printable, for
+       example).
+
+This memo uses the mechanism described in [SMTP-EXT] to define an
+extension to the SMTP protocol for indicating recipient's capabilities
+to the SMTP client.
+
+
+2.2.  Discussion of this draft
+
+
+
+Wing, Joffe                 Expires May 1998                    [Page 2]
+
+Internet Draft        SMTP Capabilities Exchange           November 1997
+
+
+
+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.
+
+
+2.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 RFC 2119 [REQ].
+
+
+3.  Framework for capabilities extension
+
+The following service extension is defined for capabilities exchange.
+
+  (1)  The name of the capabilities extension is Capabilities;
+
+  (2)  the EHLO keyword value associated with the capabilities extension
+       is CAPABILITIES;
+
+  (3)  no parameters are allowed with this extension;
+
+  (4)  no new SMTP verbs are associated with this extension;
+
+  (5)  one optional parameter for the RCPT command, using the
+       esmtp-keyword "CAPS", (used to request the capabilities of the
+       recipient), is defined in section 4,
+
+       no parameters are added to the MAIL command;
+
+  (6)  the maximum length of RCPT TO is increased by 5 characters.
+
+
+4.  Behavior of RCPT TO:<forward-path> CAPS
+
+A RCPT command issued by a client may contain the optional esmtp-keyword
+"CAPS" to indicate that the SMTP client wishes to receive recipient
+capabilities information in the RCPT response from the SMTP server.
+
+The server should be aware of the nature of the recipient via some
+implementation-specific method (LDAP or other directory query,
+contacting the destination system directly, [DIR-EMAIL], or some other
+
+
+
+Wing, Joffe                 Expires May 1998                    [Page 3]
+
+Internet Draft        SMTP Capabilities Exchange           November 1997
+
+
+implementation-specific method).
+
+
+4.1.  Responses to RCPT TO esmtp-keyword CAPS
+
+The response to the esmtp-keyword CAPS on a RCPT TO command is a
+multiline reply, consisting of the standard SMTP reply, followed by
+recipient capabilities in the format specified in section 6 and 8.2 of
+[HTTP-NEG] and section 14 of [HTTP-1.1].  The response should be split
+on multiple lines to not exceed the 512 character limit for a reply line
+as specified in [RFC821, SMTP-UPD].
+
+The SMTP server only needs to indicate capabilities if the SMTP server
+is responding with a positive (2xx) reply.  Non-positive replies don't
+need to include capabilities and such capabilities are to be ignored by
+the SMTP client if they are present.
+
+The positive response, in [ABNF] form is:
+
+  caps-response = rsp-code SP rcpt-response CR LF /
+                  ( rsp-code "-" rcpt-response CR LF
+                    1*( rsp-code "-" caps-line CR LF )
+                    rsp-code SP caps-line CR LF )
+
+  rsp-code = "2" 2DIGIT
+
+  rcpt-response = <normal response to RCPT command by this SMTP server
+                   in the absence of the esmtp-keyword CAPABILITIES>
+
+  caps-line = [status-code SP] features-line CR LF
+
+  features-line = http-line / ( ttl-caps ttl-seconds )
+
+  status-code   = <This is <status-code> of section 4 of [SMTP-ENH-ERR]
+                   if SMTP server implements [SMTP-ENH-ERR]>
+
+  http-line     = <Accept-Features, as described in [HTTP-NEG]>
+
+  ttl-caps    = "ttl=" ttl-seconds
+  ttl-seconds = 1*DIGIT
+
+
+(XXX - ttl-caps and ttl-seconds aren't defined in [HTTP-NEG], but
+ they should probably be moved there, as they're more appropriate
+ there
+
+ The purpose of <ttl> is to indicate how long the list of capabilties
+ should be considered an authoritative list of capabilities.  The ttl is
+
+
+
+Wing, Joffe                 Expires May 1998                    [Page 4]
+
+Internet Draft        SMTP Capabilities Exchange           November 1997
+
+
+ decremented by the SMTP server for the length of time since the data
+ was last refreshed.  A ttl of 0 indicates the capabilities list is
+ out-of-date but newer authoritative capabilities are not obtainable at
+ this time.  )
+
+
+
+
+4.2.  SMTP server unable to obtain capabilities
+
+If the SMTP server receives a request for recipient capabilities but
+cannot determine the capabilities of the recipient for some reason, the
+SMTP server may reply with:
+
+  (1) ttl=0, or
+  (2) an expired capabilities list and ttl=0
+
+This allows the SMTP client to:
+
+  (a) abort the transaction, or
+  (b) send whatever data it wishes (case 1, above), or
+  (c) send data meeting the capabilities listed in (case 2, above).
+
+
+4.3.  Behavior when client exceeds recipient's capabilities
+
+The SMTP server MAY verify that the SMTP client did not exceed the
+recipient capabilities advertised by the server.  If the SMTP server
+determines that the SMTP client exceeded the advertised capabilities,
+the SMTP server can reject the message after the end-of-mail-data
+indicator.  See the discussion in section 2.4.1 in [SMTP-UPD] for more
+information.
+
+
+5.  Examples
+
+5.1.  Simple capabilities exchange
+
+  S: 220 gw.cisco.com ESMTP service ready
+  C: EHLO joffe-pc.cisco.com
+  S: 250-gw.cisco.com says hello
+  S: 250 CAPABILITIES
+  C: MAIL FROM:<njoffe@cisco.com>
+  S: 250 <njoffe@cisco.com> sender okay
+  C: RCPT TO:<masinter@parc.xerox.com> CAPS
+  S: 250-<masinter@parc.xerox.com> recipient ok
+  S: 250-Accept: audio/basic
+  S: 250-Accept: text/*
+
+
+
+Wing, Joffe                 Expires May 1998                    [Page 5]
+
+Internet Draft        SMTP Capabilities Exchange           November 1997
+
+
+  S: 250-Accept: image/tiff;application=f, image/tiff;application=fx,
+       application/octet-stream; q=0.2
+  S: 250-Accept-Features: papersize=na-letter, papersize=iso-a4
+  S: 250-Accept-Features: pix-x=1728, res=204x196
+  S: 250 ttl=500
+  C: DATA
+  S: 354 Send your data
+  ...
+
+5.2.  SMTP server isn't able to obtain capabilities for recipient
+
+  S: 220 gw.cisco.com SMTP service ready
+  C: EHLO wing-pc.cisco.com
+  S: 250-gw.cisco.com says hello
+  S: 250 CAPABILITIES
+  C: MAIL FROM:<dwing@cisco.com>
+  S: 250 <dwing@cisco.com> sender okay
+  C: RCPT TO:<adelman@adelman.com> CAPS
+  S: 250 <adelman@adelman.com> recipient ok
+  C: DATA
+  S: 354 Send your data
+  ...
+
+5.3.  SMTP server can only obtain expired capabilities information
+
+  S: 220 gw.cisco.com SMTP service ready
+  C: EHLO wing-pc.cisco.com
+  S: 250-gw.cisco.com says hello
+  S: 250 CAPABILITIES
+  C: MAIL FROM:<dwing@cisco.com>
+  S: 250 <dwing@cisco.com> sender okay
+  C: RCPT TO:<benefits@cisco.com>
+  S: 250-<benefits@cisco.com> recipient ok
+  S: 250-Accept: text/*
+  S: 250-Accept: application/ms-word, application/powerpoint
+  S: 250 ttl=0
+  C: DATA
+  S: 354 Send your data
+  ...
+
+
+6.  Security Considerations
+
+As detailed in section 14 of [HTTP-NEG], Accept- headers, in particular
+Accept-Language headers, may reveal information which the user would
+rather keep private.  For this reason it may be desirable to restrict
+externally-accessible information on user preferences and capabilities.
+
+
+
+
+Wing, Joffe                 Expires May 1998                    [Page 6]
+
+Internet Draft        SMTP Capabilities Exchange           November 1997
+
+
+7.  Acknowledgments
+
+This document was produced by work initially started in the Internet Fax
+Working Group.
+
+The authors would like to thank Graham Klyne (Integralis Ltd.) and
+Larry Masinter (Xerox PARC) for their contributions to this work.
+
+
+8.  References
+
+  [ACAP]
+       J. Myers, C. Newman, "ACAP -- Application Configuration Access
+       Protocol", Internet Draft, Work in Progress,
+       draft-ietf-acap-spec-??.txt.
+
+  [ABNF]
+       D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications:
+       ABNF", Internet Draft, Work in Progress,
+       draft-ietf-drums-abnf-??.txt.
+
+  [DIR-EMAIL]
+       B. Greenblatt, "Directory Entries From Email Address", Internet
+       Draft, Work in Progress, draft-greenblatt-defema-??.txt.
+
+  [DS-EMAIL]
+       P. Leach, "Locating DS Entries by E-mail Address", Internet
+       Draft, Work in Progress, draft-leach-asid-ds-email-??.txt.
+
+  [FAX-PROFILE]
+       ?, "FAX Profile for Internet Mail", Internet Draft, Work in
+       Progress, draft-ietf-fax-profile-??.txt
+
+  [FAX-REQ]
+       L. Masinter, "Requirements for Internet FAX", Internet Draft,
+       Work in Progress, draft-ietf-fax-requirements-??.txt.
+
+  [HTTP-1.1]
+       R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
+       "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January
+       1997.
+
+  [HTTP-NEG]
+       K. Holtman, A. Mutz, "Transparent Content Negotiation in HTTP",
+       Internet Draft, Work In Progress,
+       draft-ietf-http-negotiation-??.txt.
+
+  [REQ]
+
+
+
+Wing, Joffe                 Expires May 1998                    [Page 7]
+
+Internet Draft        SMTP Capabilities Exchange           November 1997
+
+
+       S. Bradner, "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP-14, RFC 2119, March 1997.
+
+  [SALUTATION]
+       The Salutation Consortium, "Salutation Architecture
+       Specification", December 1996.
+
+  [SMIME-40BIT]
+       Bruce Schneier, "Counterpane Systems Releases Windows
+       95-compatible S/MIME 40-bit RC2 Cracking ScreenSaver",
+       http://www.counterpane.com/smime.html.
+
+  [SMTP]
+       D. Crocker, "Standard for the Format of ARPA Internet Text
+       Messages", STD-10, RFC 822, August 1982.
+
+  [SMTP-EXT]
+       J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+       Service Extensions", STD-10, RFC 1869, November 1995.
+
+  [SMTP-UPD]
+       J. Klensin, D. Mann, "Simple Mail Transfer Protocol", Internet
+       Draft, Work in Progress, draft-ietf-drums-smtpupd-??.txt.
+
+  [SMTP-ENH-ERR]
+       N. Freed, "SMTP Service Extension for Returning Enhanced Error
+       Codes", RFC 2034, October 1996.
+
+
+9.  Author's Addresses
+
+   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
+
+
+   Neil Joffe
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706  USA
+
+   Phone: +1 408 526 4000
+   Email: njoffe@cisco.com
+
+
+
+Wing, Joffe                 Expires May 1998                    [Page 8]
+
+Internet Draft        SMTP Capabilities Exchange           November 1997
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wing, Joffe                 Expires May 1998                    [Page 9]
+
+
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
new file mode 100644
index 00000000..d55e5a1e
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-fax-smtp-session-04.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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-mailext-mail-attributes-07.txt b/Documentation/en/I-D/draft-ietf-mailext-mail-attributes-07.txt
new file mode 100644
index 00000000..d04db73c
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-mailext-mail-attributes-07.txt
@@ -0,0 +1,54 @@
+
+
+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-palme-select-00.txt b/Documentation/en/I-D/draft-ietf-palme-select-00.txt
new file mode 100644
index 00000000..f304bff0
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-palme-select-00.txt
@@ -0,0 +1,3880 @@
+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-melnikov-esmtp-lang-00.txt b/Documentation/en/I-D/draft-melnikov-esmtp-lang-00.txt
new file mode 100644
index 00000000..607b2bb3
--- /dev/null
+++ b/Documentation/en/I-D/draft-melnikov-esmtp-lang-00.txt
@@ -0,0 +1,275 @@
+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-01.txt b/Documentation/en/I-D/draft-melnikov-smtp-lang-01.txt
new file mode 100644
index 00000000..fd0bacef
--- /dev/null
+++ b/Documentation/en/I-D/draft-melnikov-smtp-lang-01.txt
@@ -0,0 +1,439 @@
+Network Working Group                            Mike Gahrns, Microsoft 
+Internet Draft                        Alexey Melnikov, Messaging Direct
+Document: draft-melnikov-smtp-lang-01.txt                  October 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.
+
+
+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)
+
+7) LANG command must always have language-tag as a parameter. Only EHLO response could
+   be used to examine list of supported languages.
+
+
+   Open issues
+
+1) Should language information be added to MAIL FROM so that it could be used
+   in DSN/MDN notification messages?
+
+
+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 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) No additional SMTP parameters to either MAIL FROM or RCPT TO commands 
+      are defined by this extension.
+
+  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
+
+   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 [*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 BAD 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 LANG extension.
+
+         LANG 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.
+
+
+5. Extended LANG 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 Enchanced 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
+
+
+6. 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 [*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 5 for definition 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]  
+
+
+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>
+
+   [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., "IMAP4 Language Extension", 
+   draft-gahrns-imap-language-01.txt (work in progress), Microsoft, 
+   October 1999
+
+   [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
+
+8.  Acknowledgments
+
+   This document is derived from [IMAP-LANGUAGE]. Thus the work of
+   Mike Gahrns and Andrew McCown is appreciated.
+
+
+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
+
+    Mike Gahrns
+    Microsoft
+    One Microsoft Way
+    Redmond, WA, 98072
+
+    Phone: (425) 936-9833
+    Email: mikega@microsoft.com 
+
+    Alexey Melnikov
+    Messaging Direct, Inc.
+    #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-myers-smtp-auth-11.txt b/Documentation/en/I-D/draft-myers-smtp-auth-11.txt
new file mode 100644
index 00000000..ceba7e05
--- /dev/null
+++ b/Documentation/en/I-D/draft-myers-smtp-auth-11.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Internet Draft: SMTP Authentication                        February 1998
+Document: draft-myers-smtp-auth-11.txt
+
+
+                         SMTP Service Extension
+                           for Authentication
+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.  Internet Drafts 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 a
+   ``working draft'' or ``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 ds.internic.net, nic.nordu.net, ftp.isi.edu, or
+   munnari.oz.au.
+
+   A revised version of this draft document will be submitted to the RFC
+   editor as a Proposed Standard for the Internet Community.  Discussion
+   and suggestions for improvement are requested.  This document will
+   expire before July 1996.  Distribution of this draft is unlimited.
+
+
+1. Introduction
+
+   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].
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                                                           [Page 1]
+
+Internet Draft            SMTP Authentication          February 26, 1998
+
+
+2. Conventions Used in this Document
+
+   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].
+
+
+3. The Authentication service extension
+
+
+   (1) the name of the SMTP service extension is "Authentication"
+
+   (2) the EHLO keyword value associated with this extension is "AUTH"
+
+   (3) The AUTH EHLO keyword contains as a parameter a space separated
+       list of the names of supported SASL mechanisms.
+
+   (4) a new SMTP verb "AUTH" is defined
+
+   (5) an optional parameter using the keyword "AUTH" is added to the
+       MAIL FROM command.
+
+
+4. The AUTH command
+
+   AUTH mechanism [initial-response]
+
+     Arguments:
+         a string identifying a SASL authentication mechanism.
+         an optional base64-encoded response
+
+     Restrictions:
+         after an AUTH command has successfully completed, no more AUTH
+         commands may be issued in the same session.  After a successful
+         AUTH command completes, a server MUST reject any further AUTH
+         commands with a 503 reply.
+
+     Discussion:
+         The AUTH command indicates an authentication mechanism to the
+         server.  If the server supports the requested authentication
+         mechanism, it performs an authentication protocol exchange to
+         authenticate and identify the user.  Optionally, it also
+         negotiates a security layer for subsequent protocol
+         interactions.  If the requested authentication mechanism is not
+         supported, the server rejects the AUTH command with a 504
+
+
+
+Myers                                                           [Page 2]
+
+Internet Draft            SMTP Authentication          February 26, 1998
+
+
+         reply.
+
+         The authentication protocol exchange consists of a series of
+         server challenges and client answers that are specific to the
+         authentication mechanism.  A server challenge, otherwise known
+         as a ready response, is a 334 reply with the text part
+         containing a BASE64 encoded string.  The client answer consists
+         of a line containing a BASE64 encoded string.  If the client
+         wishes to cancel an authentication exchange, it issues a line
+         with a single "*".  If the server receives such an answer, it
+         MUST reject the AUTH command by sending a 501 reply.
+
+         The optional initial-response argument to the AUTH command is
+         used to save a round trip when using authentication mechanisms
+         that are defined to send no data in the initial challenge.
+         When the initial-response argument is used with such a
+         mechanism, the initial empty challenge is not sent to the
+         client and the server uses the data in the initial-response
+         argument as if it were sent in response to the empty challenge.
+         If the initial-response argument to the AUTH command is used
+         with a mechanism that sends data in the initial challenge, the
+         server rejects the AUTH command with a 535 reply.
+
+         If the server cannot BASE64 decode the argument, it rejects the
+         AUTH command with a 501 reply.  If the server rejects the
+         authentication data, it SHOULD reject the AUTH command with a
+         535 reply unless a more specific error code, such as one listed
+         in section 6, is appropriate.  Should the client successfully
+         complete the authentication exchange, the SMTP server issues a
+         235 reply.
+
+         The service name specified by this protocol's profile of SASL
+         is "smtp".
+
+         If a security layer is negotiated through the SASL
+         authentication exchange, it takes effect immediately following
+         the CRLF that concludes the authentication exchange for the
+         client, and the CRLF of the success reply for the server.
+
+         The server is not required to support any particular
+         authentication mechanism, nor are authentication mechanisms
+         required to support any security layers.  If an AUTH command
+         fails, the client may try another authentication mechanism by
+         issuing another AUTH command.  In other words, the client may
+         request authentication types in decreasing order of preference.
+
+         If an AUTH command fails, the server MUST behave the same as if
+         the client had not issued the AUTH command.
+
+
+
+Myers                                                           [Page 3]
+
+Internet Draft            SMTP Authentication          February 26, 1998
+
+
+         The BASE64 string may in general be arbitrarily long.  Clients
+         and servers MUST be able to support challenges and responses
+         that are as long as are generated by the authentication
+         mechanisms they support, independent of any line length
+         limitations the client or server may have in other parts of its
+         protocol implementation.
+
+     Examples:
+         S: 220 smtp.andrew.cmu.edu ESMTP server ready
+         C: EHLO jgm.pc.cc.cmu.edu
+         S: 250-smtp.andrew.cmu.edu
+         S: 250 AUTH SKEY PLAIN
+         C: AUTH FOOBAR
+         S: 504 Unrecognized authentication type
+         C: AUTH SKEY c21pdGg=
+         S: 334 OTUgUWE1ODMwOA==
+         C: BsAY3g4gBNo=
+         S: 235 S/Key authentication successful
+
+
+
+5. The AUTH parameter to the MAIL FROM command
+
+   AUTH=addr-spec
+
+   Arguments:
+       An addr-spec containing the identity which submitted the message
+       to the delivery system.  To comply with the restrictions imposed
+       on ESMTP parameters, the addr-spec is encoded inside an xtext.
+       The syntax of an xtext is described in section 5 of [ESMTP-DSN].
+
+   Discussion:
+       The optional AUTH parameter to the MAIL FROM command allows
+       cooperating agents in a trusted environment to communicate the
+       authentication of individual messages.
+
+       If the server trusts the authenticated identity of the client to
+       assert that the message was originally submitted by the supplied
+       addr-spec, then the server SHOULD supply the same addr-spec in an
+       AUTH parameter when relaying the message to any server which
+       supports the AUTH extension.
+
+       If the server does not sufficiently trust the authenticated
+       identity of the client, or if the client is not authenticated,
+       then the server MUST behave as if no AUTH parameter was supplied.
+       The server MAY, however, place the value of the AUTH parameter in
+       a comment in the inserted Received: header and/or write it to a
+       log file.
+
+
+
+Myers                                                           [Page 4]
+
+Internet Draft            SMTP Authentication          February 26, 1998
+
+
+       A server MAY treat expansion of a mailing list as a new
+       submission, setting the AUTH parameter to the mailing list
+       address or mailing list administration address when relaying the
+       message to list subscribers.
+
+       It is conforming for an implementation to be hard-coded to treat
+       all clients as being insufficiently trusted.  In that case, the
+       implementation does nothing more than parse and discard
+       syntactically valid AUTH parameters to the MAIL FROM command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                                                           [Page 5]
+
+Internet Draft            SMTP Authentication          February 26, 1998
+
+
+6. Error Codes
+
+   The following error codes may be used to indicate various conditions
+   as described.
+
+   422 A password transition is needed
+
+   This response to the AUTH command indicates that the user needs to
+   transition to the selected authentication mechanism.  This typically
+   done by authenticating once using the PLAIN authentication mechanism.
+
+   522 Authentication mechanism is too weak
+
+   This response to the AUTH command indicates that the selected
+   authentication mechanism is weaker than server policy permits for
+   that user.
+
+   523 Encryption required for requested authentication mechanism
+
+   This response to the AUTH command indicates that the selected
+   authentication mechanism may only be used when the underlying SMTP
+   connection is encrypted.
+
+   454 Temporary authentication failure
+
+   This response to the AUTH command indicates that the authentication
+   failed due to a temporary server failure.
+
+   505 Authentication required
+
+   This response may be returned by any command other than AUTH, EHLO,
+   NOOP, or QUIT.  It indicates that server policy requires
+   authentication in order to perform the requested action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                                                           [Page 6]
+
+Internet Draft            SMTP Authentication          February 26, 1998
+
+
+7. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [RFC822].
+
+   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.
+
+   ATOM_CHAR       = <any CHAR except atom_specials>
+
+   atom_specials   = "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
+                       <"> / "\"
+
+   auth_command    = "AUTH" SPACE auth_type [SPACE base64]
+       *(CRLF base64) CRLF
+
+   auth_param      = "AUTH=" xtext
+                       ;; xtext is defined in section 5 of RFC 1891
+                       ;; The decoded form of the xtext MUST be an addr-spec
+
+   auth_type       = 1*ATOM_CHAR
+
+   base64          = *(4base64_CHAR) [base64_terminal]
+
+   base64_char     = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
+                     "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
+                     "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
+                     "Y" / "Z" /
+                     "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
+                     "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
+                     "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
+                     "y" / "z" /
+                     "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
+                     "8" / "9" / "+" / "/"
+                       ;; Case-sensitive
+
+   base64_terminal = (2base64_char "==") / (3base64_char "=")
+
+   CHAR            = <any 7-bit US-ASCII character except NUL,
+                        0x01 - 0x7f>
+
+   continue_req    = "334" SPACE base64 CRLF
+
+   CR              = <ASCII CR, carriage return, 0x0C>
+
+   CRLF            = CR LF
+
+
+
+Myers                                                           [Page 7]
+
+Internet Draft            SMTP Authentication          February 26, 1998
+
+
+   CTL             = <any ASCII control character and DEL,
+                      0x00 - 0x1f, 0x7f>
+
+   LF              = <ASCII LF, line feed, 0x0A>
+
+   SPACE           = <ASCII SP, space, 0x20>
+
+
+
+8. References
+
+   [ESMTP] Klensin et al, "SMTP Service Extensions", RFC 1869, November
+   1995.
+
+   [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
+   Notifications", RFC 1890.
+
+   [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, March 1997.
+
+   [SASL]  Myers, J., "Simple Authentication and Security Layer",
+   draft-myers-auth-sasl-13.txt, November 1997.
+
+   [RFC821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
+   1982.
+
+   [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", RFC 822, August 1982.
+
+
+
+9. Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+   If a client uses this extension to get an encrypted tunnel through an
+   insecure network to a cooperating server, it needs to be configured
+   to never send mail to that server when the connection is not mutually
+   authenticated and encrypted.  Otherwise, an attacker could steal the
+   client's mail by hijacking the SMTP connection and either pretending
+   the server does not support the Authentication extension or causing
+   all AUTH commands to fail.
+
+   This extension does not provide a defined mechanism for
+   authentication using a plaintext password.  This omission is
+   intentional.
+
+   This extension is not intended to replace or be used instead of end-
+
+
+
+Myers                                                           [Page 8]
+
+Internet Draft            SMTP Authentication          February 26, 1998
+
+
+   to-end message signature and encryption systems such as PEM or PGP.
+   This extension addresses a different problem than end-to-end systems;
+   it has the following key differences:
+
+   (1) it is generally useful only within a trusted enclave
+
+   (2) it protects the entire envelope of a message, not just the
+       message's body.
+
+   (3) it authenticates the message submission, not authorship of the
+       message content
+
+   (4) it can give the sender some assurance the message was delivered
+       to the next hop in the case where the sender mutually
+       authenticates with the next hop and negotiates an appropriate
+       security layer.
+
+       Additional security considerations are mentioned in the SASL
+       specification [SASL].
+
+
+
+10. Author's Address:
+
+John Gardiner Myers
+Netscape Communications
+501 East Middlefield Road
+Mail Stop MV-029
+Mountain View, CA 94043
+
+Email: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                                                           [Page 9]
+
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-myers-smtp-auth-12.txt b/Documentation/en/I-D/draft-myers-smtp-auth-12.txt
new file mode 100644
index 00000000..044891e7
--- /dev/null
+++ b/Documentation/en/I-D/draft-myers-smtp-auth-12.txt
@@ -0,0 +1,62 @@
+
+
+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-palme-MHRegistry-00.txt b/Documentation/en/I-D/draft-palme-MHRegistry-00.txt
new file mode 100644
index 00000000..2bffb377
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-MHRegistry-00.txt
@@ -0,0 +1,5 @@
+
+
+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
new file mode 100644
index 00000000..4a49e80d
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-autosub-03.txt
@@ -0,0 +1,151 @@
+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-e-mail-translation-00.txt b/Documentation/en/I-D/draft-palme-e-mail-translation-00.txt
new file mode 100644
index 00000000..4523815d
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-e-mail-translation-00.txt
@@ -0,0 +1,350 @@
+Network Working Group                                     Jacob Palme
+Internet Draft                               Stockholm University/KTH
+draft-palme-e-mail-translation-00.txt                          Sweden
+Category-to-be: Proposed standard                    Date: April 1999
+                                                Expires: October 1999
+
+
+                  Support for Language Translation of E-Mail
+
+                        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 1998. All Rights Reserved.
+
+
+1.1.1.                            Abstract
+
+This memo proposes extensions to e-mail and netnews standards, to allow
+for the submission of translation 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. Two new e-mail/netnews header
+fields are proposed, "Translation-Of" and "Translator".
+
+This proposal does not propose any change to the already existing
+proposed standard for the Content-Language header (RFC 1766).
+
+Further discussion of this memo can take place in the mailing list WG-
+I18N@TERENA.NL.
+
+Mailing List Information
+
+To write contributions
+
+ Further discussion on this document should be done through the
+ mailing list WG-I18N@TERENA.NL.
+
+ 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@TERENA.NL
+ which contains the text
+ SUB[SCRIBE] WG-I18N <your name (not your email address)>
+
+To unsubscribe
+
+ To unsubscribe from this list, send a message to
+ LISTSERV@TERENA.NL
+ which contains the text
+ UNS[UBSCRIBE] WG-I18N
+
+To access mailing list archives
+
+ The archives are available for browsing from
+ http://www.terena.nl/working-groups/wg-i18n/hypermail/
+
+The archives are also available by email. Send a message to
+ LISTSERV@TERENA.NL with the text "INDEX WG-I18N" to get a list
+ of the archive files, and then a new message "GET <file name>" to
+ retrieve archive files.
+
+                         Table of contents
+
+1.   Introduction
+2.   Multi-Language Scenario
+3.   The Translation-Of Header Field
+4.   The Translator Header Field
+5.   Examples
+6.   Security considerations
+7.   Copyright and disclaimer
+8.   Acknowledgments
+9.   References
+10.  Author's address
+
+
+1.    Introduction
+
+The "Language:" e-mail content header specified in RFC 1766 [5] 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] can be
+used to send the same text in more than one language. Each part is
+marked with the "Language:" header to indicate its language, and the
+recipient can choose the body part according to his or her language
+preferences.
+
+In HTTP [6], a GET operation can indicate a list of preferred
+languages, and the server can then deliver the resource in the
+preferred language. 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.
+
+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.
+
+
+2.    Multi-Language Scenario
+
+John Smith writes a message in English and submits it to a mailing list
+or to a Usenet newsgroup. An automatic translation agent gets this
+message and translates it into German. The German translation is
+submitted to the same mailing list or newsgroup. Ernst Dürrenmatt 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.
+
+
+3.    The Translation-Of Header Field
+
+The "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 before translation. If a message is
+available in more than one language, "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 "Translation-Of" should reference the
+version which was the basis of this translation.
+
+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" is only to be used when the original
+message is revised. Example:
+
+
+4.    The Translator Header Field
+
+The "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 "Translator" header field can
+indicate who made the translation.
+
+The syntax of the "Translator" header field is:
+
+translator           = "Translator:" CFWS mailbox-list
+                       *(";" translator-parameter) CFWS CRLF
+
+translator-parameter = art / fluency / future-extension
+
+art                  = "Human" / "Machine"
+
+fluency              = "Expert" / "Native"
+
+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" [7]
+          header should also be added to the message heading.
+
+Expert  = Translation was made by an expert translator.
+
+Native  = Translation was made by a native speaker of the target
+          language.
+
+
+5.    Examples
+
+Message-ID: A
+From: John Smith <jsmit@foo.bar.net>
+To: Tropical Flowers Mailing list
+Language: en
+
+Message-ID: B
+From: John Smith <jsmit@foo.bar.net>
+To: Tropical Flowers Mailing list
+Translation-Of: A
+Translator: Erika Ernst <eernst@foo.bar.de>; human; native
+Language: de
+
+Message-ID: C
+From: John Smith <jsmit@foo.bar.net>
+To: Tropical Flowers Mailing list
+Translation-Of: A
+Translator: Tomas Dürrenmatt <tdurrenmatt@foo.bar.de>; expert
+Language: de
+
+Message-ID: D
+From: John Smith <jsmit@foo.bar.net>
+To: Tropical Flowers Mailing list
+Language: en
+Supersedes: A
+
+Message-ID: E
+From: John Smith <jsmit@foo.bar.net>
+To: Tropical Flowers Mailing list
+Translation-Of: D
+Translator: Supertrans Super Translation Engine <supertrans@foo.bar>
+Auto-Submitted: Auto-generated
+Language: de
+Supersedes: A
+
+
+6.    Security considerations
+
+Translations made by other people than the original author of
+a message will of ourse 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, if the
+recipient has a choice of either not understanding a message
+at all, or getting a bad 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.
+
+
+7.    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.
+
+
+8.    Acknowledgments
+
+Suggestions during the development of this memo has been given by Henry
+Spencer and Larry Masinter.
+
+
+9.    References
+
+Ref.    Author, title                                    IETF status
+                                                         (July 1996)
+-----   ---------------------------------------------    -----------
+[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
+        STD 10, RFC 821, August 1982.                    Recommended
+
+[2]     D. Crocker: "Standard for the format of ARPA     Standard,
+        Internet text messages." STD 11, RFC 822,        Recommended
+        August 1982.
+
+[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
+        interchange of USENET messages", RFC 1036,       cial IETF
+        December 1987.                                   standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[4]     N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
+        Internet Mail Extensions) Part One: Format of    Standard,
+        Internet Message Bodies. RFC 2945. November      elective
+        1996.
+
+[5]     H. Alvestrand: "Tags for the Identification      Proposed
+        of Languages", RFC 1766, February 1995.          standard,
+                                                         elective
+
+[6]     R. Fielding, J. Gettys, J. Mogul, H. Frystyk,    Proposed
+        T. Berners-Lee: Hypertext Transfer Protocol -    standard
+        - HTTP/1.1, RFC 2068, January 1997.
+
+[7]     J. Palme: The Auto-Submitted, Supersedes and     Work in
+        Expires Headers in E-mail and Netnews, draft-    progress
+        ietf-mailext-new-fields-14.txt, November
+        1998.
+
+
+10.   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-int-print-04.txt b/Documentation/en/I-D/draft-palme-int-print-04.txt
new file mode 100644
index 00000000..6b65e556
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-int-print-04.txt
@@ -0,0 +1,64 @@
+
+
+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-03.txt b/Documentation/en/I-D/draft-palme-mailext-headers-03.txt
new file mode 100644
index 00000000..289699e1
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-mailext-headers-03.txt
@@ -0,0 +1,1737 @@
+Network Working Group                                     Jacob Palme
+Internet Draft                               Stockholm University/KTH
+draft-palme-mailext-headers-03.txt                             Sweden
+Category: Informational                               Date: June 2000
+Revision of: RFC 2076                          Expires: December 2000
+
+
+
+                  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 1998. 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.
+
+                  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:
+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, Original-Recipient,
+Originator, Originator-Info, Path, PICS-Label, Read-Receipt-To,
+Received, Registered-Mail-Reply-Requested-By, Replaces, Return-
+Receipt-Requested, Speech-Act, Translated-By. Translation-Of, X-
+Confirm-Reading-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-Sender, X-X-Sender, X-UIDL, X-URL,
+X-URI.
+
+The latest, revised version of this document is available from URL
+http://www.dsv.su.se/jpalme/ietf/mail-headers
+
+
+                         Table of contents
+
+Abstract
+Changes since previous version
+1. Introduction
+2. Use of gatewaying header fields
+3. Table of header fields
+     3.1 Phrases used in the tables
+     3.2 Trace information
+     3.3 Format and control information
+     3.4 Sender and recipient indication
+     3.5 Response control
+     3.6 Message identification and referral header fields
+     3.7 Other textual header fields
+     3.8 Header fields containing dates and times
+     3.9 Quality information
+     3.10 Language information
+     3.11 Size information
+     3.12 Conversion control
+     3.13 Encoding information
+     3.14 Resent-header fields
+     3.15 Security and reliability
+     3.16 Mailing list control
+     3.17 Miscellaneous
+4. Acknowledgments
+Copyright and disclaimer
+5. References
+6. Author's address
+Appendix A:
+Header fields sorted by Internet RFC document in which they
+appear.
+     RFC 822
+     RFC 976
+     RFC 1049
+     RFC 1036
+     RFC 1123
+     RFC 2156
+     RFC 1505
+     RFC 1766
+     RFC 2183
+     RFC 1864
+     RFC 2421
+     RFC 2045
+     RFC 2110
+     RFC 2369
+     son-of-RFC1036 [21]
+     draft-ietf-receipt
+     World Wide Web Consortium (W3C) Recommendations
+     Not Internet standard (as of June 2000)
+Appendix B: Alphabetical index
+
+
+                         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 (2000) 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 defined
+usage"                  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 only in RFC
+for use in e-mail"      1036 for use in Usenet 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-Expansion-   RFC 2156, not for
+passed.                              History:        general usage.
+
+List of MTAs passed.                 Path:           RFC 1036: 2.1.6,
+                                                     only in Usenet
+                                                     News, not in e-
+                                                     mail.
+
+Trace of MTAs which a message has    Received:       RFC 822: 4.3.2,
+passed.                                              RFC 1123: 5.2.8.
+
+Used to convey the information       Return-Path:    RFC 821,
+from the MAIL FROM envelope                          RFC 1123: 5.2.13.
+attribute in final delivery, when
+the message leaves the SMTP
+environment in which "MAIL FROM"
+is used.
+
+3.3 Format and control information
+
+Special Usenet News commands and     Also-Control:   son-of-RFC1036
+a normal article at the same                         [21], non-
+time.                                                standard, only in
+                                                     Usenet News, not
+                                                     in e-mail
+
+Controls whether this message may    Alternate-      RFC 2156, not for
+be forwarded to alternate            Recipient:      general usage.
+recipients such as a postmaster
+if delivery is not possible to
+the intended recipient. Default:
+Allowed.
+
+Whether a MIME body part is to be    Content-        RFC 2183,
+shown inline or is an attachment;    Disposition:    experimental
+can also indicate a suggested
+filename for use when saving an
+attachment to a file.
+
+Only in Usenet News, contains        Control:        RFC 1036: 2.1.6,
+commands to be performed by News                     only in Usenet
+agents.                                              News, not in e-
+                                                     mail.
+
+Whether recipients are to be told    Disclose-       RFC 2156, not for
+the names of other recipients of     Recipients:     general usage.
+the same 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 message is    MIME-Version:   RFC 2045: 4.
+formatted according to the MIME
+standard, and an indication of
+which version of MIME is
+utilized.
+
+Which body part types occur in       Original-       RFC 2156, not for
+this message.                        Encoded-        general usage.
+                                     Information-
+                                     Types:
+
+3.4 Sender and recipient indication
+
+Inserted by Sendmail when there      Apparently-     Non-standard,
+is no "To:" recipient in the         To:             discouraged,
+original message, listing                            mentioned in
+recipients derived from the                          RFC 1211.
+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: 2.2.11,
+newsgroup to which this article                      not standardized
+is sent; necessary on an article                     for use in e-mail.
+sent to a moderated newsgroup to
+allow 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-By:    Non-standard, used
+mailing list, and who has                            by some mailing
+approved this message for                            list expansion
+distribution to the members of                       systems.
+the list.
+Recipients not to be disclosed to    bcc:            RFC 822: 4.5.3,
+other recipients. (bcc = Blind                       RFC 1123: 5.2.15-
+Carbon Copy).                                        16, 5.3.7.
+
+Secondary, informational             cc:             RFC 822: 4.5.2,
+recipients. (cc = Carbon Copy)                       RFC 1123. 5.2.15-
+                                                     16, 5.3.7.
+
+Geographical or organizational       Distribution:   RFC 1036: 2.2.7,
+limitation on where this article                     not standardized
+can be distributed. Value can be                     for use in e-mail.
+a compete or incomplete domain
+names, also various special
+values are accepted like "world",
+"usenet", "USA", etc.
+
+Fax number of the originator.        Fax:,           Non-standard.
+                                     Telefax:
+
+Primary recipients, who are          For-Approval:   Non-standard
+requested to approve the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Comment:    Non-standard
+requested to comment on the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Handling:   Non-standard
+requested to handle the
+information in this message or
+its attachments.
+
+(2) Used in Usenet News mail         From            RFC 976: 2.4 for
+transport, to indicate the path      or              use in Usenet News
+through which an article has gone    >From
+when transferred to a new host.      (not followed
+                                     by a colon)
+Sometimes called "From_" header
+field.
+
+(1) This header field should         From (not       not standardized
+never appear in e-mail being         followed by a   for use in e-mail
+sent, and should thus not appear     colon)
+in this memo. It is 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 message.                      RFC 1123: 5.2.15-
+                                                     16, 5.3.7,
+Note difference from the "From "                     RFC 1036 2.1.1
+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:
+
+In Usenet News: group(s) to which    Newsgroups:     RFC 1036: 2.1.3,
+this article was posted.                             not standardized
+Some systems provide this header                     and controversial
+field also in e-mail although it                     for use in e-mail.
+is not standardized there.
+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.
+
+Sometimes used in Usenet News in     Originator:     Non-standard in
+similar ways to "Sender:"                            Usenet News,
+                                                     Experimental in
+Also used in printing protocols.                     RFC 1528.
+
+Contains information about the       Originator-     Non-standard [25]
+authentication of the originator     Info:
+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 originator.      Phone:          Non-standard.
+
+The person or agent submitting       Sender:         RFC 822: 4.4.2,
+the message to the network, if                       RFC 1123: 5.2.15-
+other than shown by the From:                        16, 5.3.7, RFC
+header 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 envelope        X-Envelope-     Non-standard.
+(SMTP "RCTP TO") is not the same     From
+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 envelope     X-Envelope-To   Non-standard.
+(SMTP "MAIL FROM") is not
+included in the CC list, some
+mail servers add 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 the     X-Face          Non-Standard
+sender of this message.
+
+Indication in the mail header of     X-RCPT-TO:      Non-standard
+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 the     X-X-Sender:     Non-standard
+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:"
+
+3.5 Response control
+
+Indicates whether the content of     Content-        RFC 2156, not for
+a message is to be returned with     Return:         general usage.
+non-delivery notifications.
+For future options on disposition    Disposition-    RFC 2298
+notifications.                       Notification-
+                                     Options:
+
+
+Indicate that the sender wants a     Disposition-    RFC 2298
+dispoisition notification when       Notification-
+this message is received (read,      To:
+processed, etc.) by its
+receipents.
+
+Address to which notifications       Errors-To:,     Non-standard,
+are to be sent and a request to      Return-         discouraged.
+get delivery notifications.          Receipt-To:,
+Internet standards recommend,        Read-Receipt-
+however, the use of MAIL FROM and    To:, X-
+Return-Path, not Errors-To, for      Confirm-
+where delivery notifications are     reading-to:,
+to be sent.                          Return-
+                                     Receipt-
+                                     Requested,
+                                     Register-Mail-
+                                     Reply-
+                                     Requested-By:
+
+Used in Usenet News to indicate      Followup-To:    RFC 1036: 2.2.3,
+that future discussions (=follow-                    not standardized
+up) on an article should go to a                     for use in e-mail.
+different set of newsgroups 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 for
+wanted at successful delivery.       Delivery-       general usage.
+Default is not to generate such a    Report:
+report.
+Original Recipient information       Original-       RFC 2298
+for inclusion in disposition         Recipient
+notifications.
+
+Whether non-delivery report is       Prevent-        RFC 2156, not for
+wanted at delivery error. Default    NonDelivery-    general usage.
+is to want such a report.            Report:
+
+This header field is meant to        Reply-To:       RFC 822: 4.4.3,
+indicate where the sender wants                      RFC 1036: 2.2.1
+replies to go. Unfortunately,                        controversial.
+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 header    Reply-To2
+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.
+
+Possible future change of name       X400-Content-   non-standard
+for "Content-Return:"                Return:
+
+3.6 Message identification and referral header fields
+
+Reference to specially important     Article-        son-of-RFC1036
+articles for a particular Usenet     Names:          [21], non-standard
+Newsgroup.
+Only in Usenet News, similar to      Article-        son-of-RFC1036
+"Supersedes:" but does not cause     Updates:        [21], non-standard
+the referenced article to be
+physically deleted.
+
+Used in addition to Content-         Content-        Work in progress
+Location if this content part can    Alias:
+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 resolving        Content-Base:   RFC 2110
+relative URIs within this content
+part.
+
+Unique ID of one body part of the    Content-ID:     RFC 2045: 7.
+content of a message.
+URI with which the content of        Content-        RFC 2110
+this content part might be           Location:
+retrievable.
+Used by some automatic services      Delivered-To:   non-standard
+(mainly MLMs and autoresponders)     or
+for the purpose of loop              X-Loop:
+detection. 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 this      In-Reply-To:    RFC 822: 4.6.2.
+message is a reply to.
+Unique ID of this message.           Message-ID:     RFC 822: 4.6.1
+                                                     RFC 1036: 2.1.5.
+
+Reference to previous message        Obsoletes:      RFC 2156, not for
+being corrected and replaced.                        general usage.
+Compare to "Supersedes:" below.
+This field may in the future be
+replaced with "Supersedes:".
+
+In e-mail: reference to other        References:     RFC 822: 4.6.3
+related messages, in Usenet News:                    RFC 1036: 2.1.5.
+reference to replied-to-articles.
+Still another name for similar       Replaces:       non-standard,
+functionality as for "Obsoletes:"                    proposed in IETF
+and "Supersedes:". This may                          USEFOR working
+become the most recommended                          group
+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 in      Supersedes:     son-of-RFC1036
+similar ways to the "Obsoletes"                      [21], non-standard
+header field 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 made       Translated-     non-standard
+the translation.                     By:
+
+Reference to the Message-ID of a     Translation-    non-standard
+message, which the current           Of:
+message is a translation of.
+
+Unique identifier for a message,     X-UIDL:         non-standard
+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". The URI    X-URI:          Non-standard
+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 IMAP      X-IMAP:         Non-standard
+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 body     Content-        RFC 2045: 8.
+part of a message, for example a     Description:
+caption for an image body part.
+A text string which identifies       Content-        RFC 2156, not for
+the content of a message.            Identifier:     general usage.
+
+Search keys for data base            Keywords:       RFC 822: 4.7.1
+retrieval.                                           RFC 1036: 2.2.9.
+
+See Organization above.              Organisation:   Non-standard.
+
+Organization to which the sender     Organization:   RFC 1036: 2.2.8,
+of this article belongs.                             not standardized
+                                                     for use in e-mail.
+
+Title, heading, subject. Often       Subject:        RFC 822: 4.7.1
+used as thread indicator for                         RFC 1036: 2.1.4.
+messages replying to or
+commenting on other messages.
+
+Short text describing a longer       Summary:        RFC 1036: 2.2.10,
+article. Warning: Some mail                          not standardized
+systems will not display this                        for use in e-mail,
+text to the recipient. Because of                    discouraged.
+this, do not use this header
+field 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 X.400,                       RFC 1123: 5.2.14
+the time a message was submitted.                    RFC 1036: 2.1.2.
+Some Internet mail systems also
+use the date when the message was
+submitted.
+
+The time when a message was          Delivery-       RFC 2156, not for
+delivered to its recipient.          Date:           general usage.
+
+A suggested expiration date. Can     Expires:        RFC 1036: 2.2.4,
+be used both to limit the time of                    not standardized
+an article which is not                              for use in e-mail.
+meaningful after a certain date,
+and to extend the storage of
+important articles.
+
+Time at which a message loses its    Expiry-Date:    RFC 2156, not for
+validity. This field may in the                      general usage.
+future be replaced by "Expires:".
+Latest time at which a reply is      Reply-By:       RFC 2156, not for
+requested (not demanded).                            general usage.
+
+Time when this message was           X-OriginalArr   Non-standard
+delivered into the message           ivalTime:
+transport system (usually the
+same time as in the last
+"Received:" header)
+
+3.9 Quality information
+
+A hint from the originator to the    Importance:     RFC 2156 and
+recipients about how important a                     RFC 2421, proposed
+message is. Values: High, normal
+or low. Not used to control
+transmission speed.
+
+Body parts are missing.              Incomplete-     RFC 2156, not for
+                                     Copy:           general usage.
+
+Ratings label to control             PICS-Label:     REC-PICS-labels,
+selection (filtering) of messages                    W3C document [23].
+according to the PICS protocol.
+Sometimes used as a priority         Precedence:     Non-standard,
+value which can influence                            controversial.
+transmission speed and 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 "non-   Priority:       RFC 2156, not for
+urgent" and can influence                            general usage.
+transmission speed and delivery.
+How sensitive it is to disclose      Sensitivity:    RFC 2156 and
+this message to other people than                    RFC 2421, proposed
+the 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 indication.     X-MSMail-       Non-standard
+                                     Priority:
+
+Values: 1 (Highest), 2 (High), 3     X-Priority:     Non-standard [24]
+(Normal), 4 (Low), 5 (Lowest). 3
+(Normal) is default if the field
+is omitted.
+
+3.10 Language information
+
+Can include a code for the           Content-        RFC 1766, proposed
+natural language used in a           Language:       standard.
+message, e.g. "en" for English.
+Can include a code for the           Language:       RFC 2156, not for
+natural language used in a                           general usage.
+message, e.g. "en" for English.
+3.11 Size information
+
+Inserted by certain mailers to       Content-        Non-standard,
+indicate the size in bytes of the    Length:         discouraged.
+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 [27].
+alternative variant of this          Alternative:
+document might be found.
+Non-standard variant of              Content-        Non-standard.
+Conversion: with the same values.    Conversion:
+
+The body of this message may not     Conversion:     RFC 2156, not for
+be converted from one character                      general usage.
+set to another. Values:
+Prohibited and allowed.
+
+The body of this message may not     Conversion-     RFC 2156, not for
+be converted from one character      With-Loss:      general usage.
+set to another if information
+will be lost. Values: Prohibited
+and allowed.
+
+3.13 Encoding information
+
+Type information of the content      Content-        non-standard
+in some class hierarchy. Class       Class:
+hierarchies are commonly used to
+classify data structures in
+software development.
+
+Can give more detailed               Content-        non-standard
+information about the Content-       Features:
+Type. Example:
+
+(&  (color=binary)
+    (image-file-structure=TIFF-S)
+    (dpi=200)
+    (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 entity     Content-SGML-   non-standard
+declaration 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 set     Content-Type:   RFC 1049,
+etc.) Note that the values for                       RFC 1123: 5.2.13,
+this header field are defined in                     RFC 1766: 4.1
+different ways in RFC 1049 and in                    RFC 2045: 5.
+MIME (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 ways by    Encoding:       RFC 1154,
+different mail systems. Some use                     RFC 1505,
+it for a kind of content-type                        experimental.
+information, some for encoding
+and length information, some for
+a kind of boundary information,
+some in other ways.
+
+Only used with the value             Message-Type:   RFC 2156, not for
+"Delivery Report" to indicates                       general usage.
+that this is a delivery report
+gatewayed from X.400.
+
+Information about conversion of      X-MIME-         non-standard
+this message on the path from        Autoconverted:
+sender to recipient, 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-Reply-   RFC 822: C.3.3.
+message, header fields referring     To:,
+to the forwarding, not to the        Resent-From:,
+original message.  Note: MIME        Resent-
+specifies another way of             Sender:,
+resending messages, using the        Resent-From:,
+"Message" Content-Type.              Resent-Date:,
+                                     Resent-To:,
+                                     Resent-cc:,
+                                     Resent-bcc:,
+                                     Resent-
+                                     Message-ID:
+
+3.15 Security and reliability
+
+Checksum of content to ensure        Content-MD5:    RFC 1864, proposed
+that it has not been modified.                       standard.
+
+Used in Usenet News to store         Xref:           RFC 1036: 2.2.13,
+information to avoid showing a                       only in Usenet
+reader the same article twice if                     News, not in e-
+it was sent to more than one                         mail.
+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 browse the    List-Archive    RFC 2369 [26]
+archives of the mailing list from
+which this message was relayed.
+
+URL to use to get a subscription     List-Digest     Non-standard
+to the 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 the      List-ID         Approved by the
+mailing list, through which this                     IESG for
+message was distributed.                             standardization.
+
+Contains URL to send e-mail to       List-Owner      RFC 2369 [26]
+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 software       List-Software   Non-standard, has
+used in a mailing list expander                      been considered
+through which this message has                       for inclusion in
+passed.                                              [26].
+
+Contains URL to use to get a         List-           RFC 2369 [26]
+subscription to the mailing list     Subscribe
+from which this message was
+relayed.
+
+Contains URL to use to               List-           RFC 2369 [26]
+unsubscribe the mailing list from    Unsubscribe
+which this message was relayed.
+
+Contains URL where information of    List-URL        Non-standard
+various kinds about the mailing
+list from which this message was
+relayed.
+
+Information about the server and     X-Listserver,   Non-standard.
+software used in a mailing list      X-List-Host     Recommended to use
+expander through which this                          "List-Software"
+message 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 forwarded.    Autoforwarded   RFC 2156, not for
+                                     :               general usage.
+
+Can be used in Internet mail to      Discarded-      RFC 2156, not for
+indicate X.400 IPM extensions        X400-IPMS-      general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+Can be used in Internet mail to      Discarded-      RFC 2156, not for
+indicate X.400 MTS extensions        X400-MTS-       general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+Name of file in which a copy of      Fcc:            Non-standard.
+this message is stored.
+Speech act categoriztion of a        Speech-Act:     Non-standard
+message, examples of speeach acts
+are Question, Idea, More,
+Promise, Sad, Happy, Angry,
+summary, Decision
+This field is used by some mail      Status:         Non-standard,
+delivery systems to indicate the                     should never
+status of delivery for this                          appear in mail in
+message when stored. Common                          transit.
+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 in       X-No-Archive:   Non-standard
+publicly available archives.         Yes
+
+
+
+                          4. Acknowledgments
+
+Harald Tveit Alvestrand, Neil Carpenter, William C. Carpenter, Rob
+Chandhok, Ned Freed, Olle J„rnefors, 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
+                                                         (July 1999)
+-----   ---------------------------------------------    -----------
+[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
+        STD 10, RFC 821, August 1982.                    Recommended
+
+[2]     D. Crocker: "Standard for the format of ARPA     Standard,
+        Internet text messages." STD 11, RFC 822,        Recommended
+        August 1982.
+
+[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
+        interchange of USENET messages", RFC 1036,       cial IETF
+        December 1987.                                   standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[4]     M. Sirbu: "A Content-Type header field header    Historic
+        field for internet messages", RFC 1049, March
+        1988.
+
+[5]     R. Braden (editor): "Requirements for            Standard,
+        Internet Hosts -- Application and Support",      Required
+        STD-3, RFC 1123, October 1989.
+
+[6]     D. Robinson, R. Ullman: "Encoding Header         Non-standard
+        field for Internet Messages", RFC 1505,
+        August 1993.
+
+[7]     S. Hardcastle-Kille: "Mapping between            Proposed
+        X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
+        2156 January 1998.                               elective
+
+[8]     H. Alvestrand & J. Romaguera: "Rules for         Proposed
+        Downgrading Messages from X.400/88 to            standard,
+        X.400/84 When MIME Content-Types are Present     elective
+        in the Messages", RFC 1496, August 1993.
+
+[9]     A. Costanzo: "Encoding Header field Header       Non-standard
+        field for Internet Messages", RFC 1154, April
+        1990.
+
+[10]    A. Costanzo, D. Robinson: "Encoding Header       Experimental
+        field Header field for Internet Messages",
+        RFC 1505, August 1993.
+
+[11]    N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
+        Internet Mail Extensions) Part One: Format of    Standard,
+        Internet Message Bodies. RFC 2045. November      elective
+        1996.
+
+[12]    H. Alvestrand: "Tags for the Identification      Proposed
+        of Languages", RFC 1766, February 1995.          standard,
+                                                         elective
+
+[13]    J. Palme: "Electronic Mail", Artech House        Non-standard
+        publishers, London-Boston 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 Transfer    Proposed
+        Protocol: "A Proposed Standard for the Stream-   standard
+        Based Transmission of News", RFC 977, January
+        1986.
+[16]    1848  PS   S. Crocker, N. Freed, J. Galvin,      Proposed
+        S. Murphy, "MIME Object Security Services",      standard
+        RFC 1848, March 1995.
+
+[17]    J. Myers, M. Rose: The Content-MD5 Header        Draft
+        field Header field, RFC 1864, October 1995.      standard
+
+[18]    M. Horton, UUCP mail interchange format          Not an offi-
+        standard, RFC 976, Januari 1986.                 cial IETF
+                                                         standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[19]    T. Berners-Lee, R. Header fielding, H.           Informatio
+        Frystyk: Hypertext Transfer Protocol --          nal
+        HTTP/1.0, RFC 1945.
+
+[20]    G. Vaudreuil: Voice Profile for Internet         Proposed
+        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 widely
+        FTP://zoo.toronto.edu/pub/news.txt.Z             used and
+                                                         partly almost
+        This document is often referenced under the      a de-facto
+        name "son-of-RFC1036".                           standard for
+                                                         Usenet News
+
+[23]    PICS Label Distribution Label Syntax and         Other
+        Communication Protocols, World Wide Web          standard
+        Consortium, October 1996.
+
+[24]    Eudora Pro Macintosh User Manual, Qualcomm       Non-standard
+        Inc., 1988-1995.
+
+[25]    C. Newman: Originator-Info Message Header        Non-standard
+        field. work in progress, July 1997.
+
+[26]    Grant Neufeld and Joshua D. Baer: The Use of     Proposed
+        URLs as Meta-Syntax for Core Mail List           standard
+        Commands and their Transport through Message
+        Header fields, RFC 2369, July 1998.
+
+[27]    G. Klyne (ed.): Content Negotiation for          Non-standard
+        Facsimile Using Internet Mail, Work in
+        progress, March 2000.
+
+                          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 2421
+--------
+
+Importance
+Sensitivity
+
+RFC 2045
+--------
+
+Content-Description
+Content-ID
+Content-Transfer-Encoding
+Content-Type
+MIME-Version
+
+RFC 2110
+--------
+
+Content-Base
+Content-Location
+
+RFC 2369
+--------
+
+List-Archive
+List-Help
+List-Owner
+List-Post
+List-Software
+List-Subscribe
+List-Unsubscribe
+
+son-of-RFC1036 [21]
+-------------------
+
+Also-Control
+Article-Names
+Article-Updates
+See-Also
+Supersedes
+
+draft-ietf-receipt
+------------------
+
+Disposition-Notification-To
+Disposition-Notification-Options
+Original-Recipient
+
+World Wide Web Consortium (W3C) Recommendations
+-----------------------------------------------
+
+Pics-Label
+
+Not Internet standard (as of June 2000)
+---------------------------------------
+
+"From " (not followed by ":")
+Apparently-To
+Approved-By
+Content-Alias
+Content-Alternative
+Content-Class
+Content-Conversion
+Content-Features
+Content-Length
+Content-SGML-Entity
+Delivered-To
+Encoding
+Errors-To
+Fax
+Fcc
+For-Approval
+For-Comment
+For-Handling
+List-Digest
+List-ID
+List-URL
+Mail-System-Version
+Mailer
+Organisation
+Originating-Client
+Originator
+Originator-Info
+Phone
+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
+X-Confirm-Reading-To
+X-Envelope-From
+X-Envelope-To
+X-Face
+X-IMAP
+X-Loop
+X-List-Host
+X-Listserver
+X-Mailer
+X-MIME-Autoconverted
+X-MIMEOLE
+X-MSMail-Priority
+X-Newsreader
+X-No-Archive
+X-OriginalArrivalTime
+X-Priority
+X-RCPT-TO
+X-Sender
+X-UIDL
+X-URI
+X-URL
+X-X-Sender
+X400-Content-Return
+
+                   Appendix B: Alphabetical index
+
+Section Header field
+------- ------------
+
+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.4     Mail-System-Version see also X-mailer
+3.4     Mailer
+        MD5 see Content-MD5
+3.6     Message-ID
+3.13    Message-Type
+3.3     MIME-Version
+3.4     Newsgroups
+        Newsreader, see X-Newsreader
+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.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-
+        Recipient
+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
+        Version, see MIME-Version, X-Mailer
+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.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-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-00.txt b/Documentation/en/I-D/draft-palme-maillist-00.txt
new file mode 100644
index 00000000..59118de2
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-maillist-00.txt
@@ -0,0 +1,460 @@
+INTERNET-DRAFT                                      Jacob Palme
+Network Working Group                  Stockholm University/KTH
+draft-palme-maillist-00.txt                              Sweden
+Expires August 1999                               February 1999
+
+
+
+
+
+Good 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 1998. 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.
+
+
+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.  Groupware
+13.  Security Considerations
+14.  Copyright and Disclaimer
+15.  Acknowledgments
+16.  References
+17.  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 [RFC821], 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
+
+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.
+
+
+3.    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.
+
+Common such commands are:
+
+3.1   Subscription Control
+
+The subscription control commands handle the subscription of the SMTP
+sender of the request (not the 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.
+
+3.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".
+
+3.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.
+
+3.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.
+
+
+4.    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 11. Spam Control below).
+- Members only:     Only members 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.
+
+The checking on who may submit to a list is done on the SMTP sender of
+the message, not on the names in From: or Sender: fields in the
+heading.
+
+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.
+
+(b) Send a non-delivery notification to the SMTP sender of the
+    rejected message, in accordance with [RFC1891] and [RFC1894].
+
+
+5.    SMTP Envelope
+
+The SMTP sender [RFC821] of a message after expansion should be the
+list owner or maintainer [RFC1123], not the original sender. For
+small, closed lists, the option of retaining the SMTP sender of the
+original sender can also occur.
+
+
+6.    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.
+
+
+7.    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-<-+
+                        |                   |         |    |
+            +-----<-----+----->-----+     List B--->--+--<-+
+            |           |           |       |              |
+         Sublist A  Sublist B  Sublist C    +---->------List C
+            |
+     +--<---+---->---+
+     |               |
+  SubList A1  Sublist A2
+
+
+With a hierarchical structure, contributions intended for all members
+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. Groupware). Looped
+nesting will also avoid the problem with contributions submitted to
+the wrong branch of a hierarchical structure.
+
+
+8.    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) Store a data base 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 is enough.
+
+(3) Store a data base 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.
+
+
+9.    List Headers
+
+A mailing list expander should add headers to the mailing list
+according to [RFC2369]. 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)
+
+
+10.   Header Munging
+
+Apart from what is specifed in sections 8. Loop Control and 9. 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:". 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].
+
+
+11.   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.
+
+
+12.   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.
+
+
+13.   Security Considerations
+
+Allowing people to retrieve lists of members 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 11. 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.
+
+
+14.   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.
+
+
+15.   Acknowledgments
+
+Many people have helped with the production of this document. Of
+special value have been .....
+
+
+16.   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)
+            
+
+17.   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-newfields-info-02.txt b/Documentation/en/I-D/draft-palme-newfields-info-02.txt
new file mode 100644
index 00000000..649f86ba
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-newfields-info-02.txt
@@ -0,0 +1,255 @@
+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-00.txt b/Documentation/en/I-D/draft-palme-newsmail-00.txt
new file mode 100644
index 00000000..0259eefd
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-newsmail-00.txt
@@ -0,0 +1,719 @@
+Network Working Group                                       Jacob Palme
+Internet Draft                             Stockholm University and KTH
+draft-palme-newsmail-00.txt                                 August 1997
+Category-to-be: Proposed standard                Expires: February 1998
+
+
+
+                  Messages between Email and Netnews
+
+                         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
+
+Messages can be transported through gateways between email and netnews.
+Combined clients for mail and netnews can submit the same message at the
+same time to email and netnews. Many netnews clients can produce email
+replies to the author of netnews articles. This standard specifies how
+to handle these kinds of messages. This standard specifies three new
+email headers: 'Posted-To', 'Group-Reply-To' and 'Personal-Reply-To'.
+Further discussions on this memo should take place in the mailing-list
+MAILNEWS-L@SEGATE.SUNET.SE. More info in the full text of this memo or
+at URL http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#newsharmony.
+
+
+Table of contents
+
+1. Mailing List
+2. Status
+3. Introduction
+4. Definitions
+5. Headers in Combined and Converted Messages
+    5.1 References and In-Reply-To
+    5.2 Message-ID Header
+    5.3 "Followup-To" and "Group-Reply-To" Headers
+    5.4 "Posted-To" header
+    5.5 "Newsgroups" Header
+    5.6 "Approved" Header
+    5.7 "Subject" Header
+    5.8 "Received" and "Path" headers
+    5.9 "Control" messages
+    5.10 Other Headers
+    5.11 Headers Mandatory in Netnews but not in Email
+    5.12 Headers Optional in Netnews and not Defined in Email
+6. Preparation of Replies to Combined Messages
+7. Cooperating Clients and Gateways
+8. Security considerations
+9. Acknowledgments
+10. References
+11. Author's Addresses
+Appendix A: Examples
+Appendix B: Algorithm for Assigning Message-IDs to Messages in Gateways
+from Email to Netnews
+Appendix C: Example of two partially overlapping threads
+
+1.    Mailing List
+
+Further discussion on this memo should be done through the mailing list
+MAILNEWS-L@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 in the
+directory /lists/mailnews-l. The archives are also available by email.
+Send a message to
+LISTSERV@SEGATE.SUNET.SE with the text INDEX MAILNEWS-L to get a list of
+the archive files,
+and then a new message GET <file name> to retrieve the archive files.
+
+You can also browse the archives by http from
+HTTP://segate.sunet.se/archives/mailnews-l.html. The FTP archives are
+better if you want to
+download all messages, the HTTP archives are better if you want to
+browse and find a
+particular message only.
+
+Finally, the archives from December 3, 1996 are also available in
+searchable format from URL
+http://www.reference.com/cgi-bin/pn/listarch?list=MAILNEWS-L@segate.sune
+t.se
+
+
+2.    Status
+
+This standard updates current email and netnews standards [RFC822],
+[RFC1036], [RFC1123] and [MIME].
+
+
+3.    Introduction
+
+Clients which can handle both email and netnews are becoming more
+common. Also those clients which are mainly intended for netnews often
+provide facilities for replying by email to the author of netnews
+articles. Messages are often gatewayed between netnews and email, for
+example by having a mailing list paralleling a newsgroup. Thus the same
+message is often sent to both email and netnews, or an email message is
+a reply to a netnews article. This standard specifies the use and
+interpretation of certain header information in such messages. This
+standard specifies three not-previously standardized email headers:
+"Posted-To", "Group-Reply-To" and "Personal-Reply-To" and gives
+additional advice on the use of other email and netnews headers. This
+standard also registers a global domain name, "md5.net" which should not
+be used except as specified in this standard.
+
+One goal of this standard is that the recipient should be able to
+unambiguously identify the recipients (newsgroups and/or email) of a
+message and get information as a basis for decisions on where to send
+replies and followups to such messages.
+
+In particular, some existing practice can cause the undesired public
+posting of private email messages to news. It is for this reason that a
+solution is necessary.  Because of the installed base of software which
+is based on two irreconcilable meanings of the "Newsgroups" header, when
+it occurs in email, it is not feasible to simply change the definition
+of these headers. New agents which use one of the two uses of this
+header might increase the likelihood of very undesirable results, in
+particular the undesired and unintended automatic conversion of private
+messages to public newsgroup postings.
+
+This standard does not repeat information which is in the email and
+netnews standards [SMTP], [RFC822], [RFC1036], [RFC1123] and [MIME],
+except where this is needed for clarity.
+
+
+4.    Definitions
+
+The following terms are used in this standard. These terms may have a
+broader meaning in other standards, but are limited to the specific
+definitions within this document.
+
+News Client        A program used by a user to read and post news.
+
+Mail Client        A program used by a user to read and send mail.
+
+Combined Client    A program which combines the some or all of the functions
+                   of a mail client and a news client.
+
+Message            A message sent to either netnews, email or both.
+
+Mail Message       Any message prepared by a client for transmission by mail
+                   only.
+
+News Message       Any message prepared by a client for transmission by news
+                   only.
+
+Combined Message   Any message which a combined agent distributes via both
+                   news and mail.
+
+Group              A group of people receiving a message. A group can be a
+                   newsgroup (representing its subscribers), a mailing list
+                   (representing its subscribers), a set of nested mailing
+                   lists, or a number of recipient names in To, Cc or Bcc
+                   headers, or any combinations of these kinds of groups.
+
+Original Message   The message to which the current message is a reply.
+
+Root Message       A message which does not have any References, In-Reply-To
+                   or Supersedes headers.
+
+Thread             The set of messages which can be found by finding all
+                   messages which have "References", "In-Reply-To" or
+                   "Supersedes" references to a certain root message, and
+                   continuing this operation recursively. Note that a message
+                   which has "In-Reply-To", "References" or "Supersedes"
+                   headers referring to messages in more than one thread, will
+                   not cause these two threads to merge into one thread.
+                   Successive messages, however, will in this case belong to
+                   more than one thread. See appendix C for an example.
+
+Netnews Standards  See [RFC 1036]
+
+Email Standards    See [RFC822], [RFC1123], [SMTP], [MIME]
+
+
+5.    Headers in Combined and Converted Messages
+
+5.1   References and In-Reply-To
+
+Messages which are sent at the same time to both mail and news MUST use
+the References field according to the definitions in netnews standards
+[RFC 1036], both for the copy of the message sent via email and the copy
+sent via netnews.
+
+Gateways from news to mail SHOULD not modify the "References" field.
+
+Gateways from mail to news MUST, if needed, modify the syntax of
+References and In-Reply-To to agree with netnews standards (where the
+"phrase" variant is not allowed).
+
+Gateways from mail to news MAY transport the "References" and
+"In-Reply-To" header unchanged except for necessary syntax changes
+("phrase" is not allowed in netnews). If they are able to do it
+correctly, they MAY convert the "References" and "In-Reply-To" field
+contents from the usage specified for email to the usage specified for
+netnews. Note that such a conversion requires a check on the messages
+whose Message-ID are given in the "References" and "In-Reply-To" field,
+and this check may have to be performed recursively all the way back to
+the root message of a thread (since the netnews usage of the
+"References" field requires the "References" field to contain the first,
+the last and as many as possible of the intermediate earlier messages in
+the thread, see [RFC 1036] clause 2.2.5). Thus, such a conversion is not
+easy to perform. Conversion should not be done unless the gateway is
+capable of doing it correctly.
+
+Netnews messages can get replies, which are sent only as personal mail
+and are not to be gatewayed to netnews. Such replies SHOULD use the
+netnews (? or email?) conventions for "References" and "In-Reply-To".
+
+Email replies to news messages MAY indicate the newsgroup of the
+original message as a comment in the "In-Reply-To" header. Example:
+
+In-Reply-To: <message.id@some.host> (article in newsgroup foo.bar)
+
+
+5.2   Message-ID Header
+
+The "Message-ID" header MUST [RFC1036] be used (with its netnews syntax
+[RFC1036]) in messages sent to netnews and in combined messages and
+SHOULD be used with this syntax in messages sent via email to gateways
+from mail to news.
+
+A message to be gatewayed from email to netnews may lack a "Message-ID"
+header. For creation of the Message-ID, the algorithm described in
+appendix B is recommended. Mail and news software should however not
+assume, without further checking, that a Message-ID which looks like it
+had been generated according to this algorithm is the same for copies of
+the same message which have been gatewayed at different places.
+
+
+5.3   "Followup-To" and "Group-Reply-To" Headers
+
+If the sender wishes to specify that further discussion on a message
+sent to more than one newsgroup and/or mailing list is to be sent to
+only one newsgroup, the "Followup-To" header MUST be used according to
+netnews conventions in both the email and netnews version of combined
+messages. It MUST only contain newsgroup names or the string "poster",
+never email addresses, not even email addresses which are gatewayed to
+newsgroups.
+
+If the sender of a message wants followups, intended for the group of
+people who saw the replied-to article, to be sent to a mailing-list,
+this SHOULD be indicated using the "Group-Reply-To" header. The
+"Group-Reply-To" header has the same syntax as the "Reply-To" header in
+email standards, thus, multiple values are allowed. The "Group-Reply-To"
+can be used to indicate a recommended reply-address for replies intended
+for the same group of people who read the original message. Like
+"Followup-To" in netnews, this header can suggest followups to only some
+of the groups who got the original message. Readers of messages that
+contain "Followup-To" or "Group-Reply-To" headers, who want to read
+followups, should ensure that they are subscribed to one of the
+newsgroups in "Followup-To" or one of the mailing lists in
+"Group-Reply-To".
+
+If the sender wants group followups to be sent to both a newsgroup and a
+mailing-list, both a Followup-To and a Group-Reply-To header can be
+used. This SHOULD however not be done if there is a gateway between the
+mailing-list and the newsgroup.
+
+A person who sends a message to a mailing list, and does not want to get
+group replies except via this list, can include the list name in a
+"Group-Reply-To" header. If this person wants group replies both
+directly to his e- mail address and through the list, or if the person
+does not subscribe to the list, s/he can put both his/her personal
+e-mail address and the mailing list name in a "Group-Reply-To" header.
+
+If "Group-Reply-To" refers to a mailing list which is run in parallel
+with a newsgroup, gateways from mail to news may translate the
+"Group-Reply-To" mailing list to its newsgroup equivalent in a
+"Followup-To" clause, and gateways from news to mail may translate the
+"Followup-To" clause to the equivalent "Group-Reply-To" header referring
+to its parallel mailing list.
+
+The "Reply-To" header in e-mail is unfortunately used in two conflicting
+ways: (A) to indicate a replacement for the author as recipient of
+personal replies, (B) as specified above for "Group-Reply-To". Because
+of this, it SHOULD be phased-out, and replaced by the more explicit
+headers "Personal-Reply-To" and "Group-Reply-To". However, because of
+the wide usage of "Reply-To" (in both meanings) its phasing-out may take
+some years. "Personal-Reply-To" can be used both in e-mail and netnews
+to indicate where personal replies should be sent.
+
+
+5.4   "Posted-To" header
+
+This standard defines the new header "Posted-To".  The "Posted-To"
+header shall have the same syntax as the "Newsgroups" header defined in
+netnews standards.
+
+The email version of a combined message MUST use the "Posted-To" header
+to indicate the newsgroups which this message is sent to. "Posted-To"
+MUST NOT be used in the netnews version of the message (there, the
+"Newsgroups" header is used instead). "Posted-To" must not be used for
+any other purpose than described here.
+
+Gateways between netnews and email SHOULD convert the "Newsgroups"
+header in netnews to the "Posted-To" header in email and the reverse.
+Gateways which do not perform this conversion MUST remove the
+"Newsgroups" header from outgoing email messages and remove "Posted-To"
+from outgoing news articles.
+
+
+5.5   "Newsgroups" Header
+
+The "Newsgroups" header SHOULD not be used in email messages, even if
+these messages are also sent to newsgroups or are replies to news
+messages. If a message arriving via email has a "Newsgroups" header, the
+value of this header should be ignored. The value of this header shall
+in particular not be interpreted either to indicate the newsgroup to
+which this message is also posted (use Posted-To see 5.4), or to
+indicate the newsgroup of the original message (use a comment in the
+"In-Reply-To" field instead, see 5.1).
+
+Note: the reason for this rule is that older software uses the
+"Newsgroups" header in either of these two very different ways in email.
+It is not possible to agree on a single meaning of the "Newsgroups"
+header in email, therefore its use is deprecated and replaced by other
+notation instead.
+
+
+5.6   "Approved" Header
+
+The "Approved" header defined in netnews standards may be used in email
+with the same meaning: This message has been approved by the moderator
+for distribution to members of a moderated group.
+
+
+5.7   "Subject" Header
+
+Combined messages SHOULD follow the netnews rules for the "Subject"
+header.
+
+It is the responsibility of the client to create "Subject" headers which
+are correct. It is recommended that the netnews "Re: " convention is
+used also in email.
+
+
+5.8   "Received" and "Path" headers
+
+Email to news gateways MUST remove "Received" headers from incoming
+email messages while converting them to netnews. Attempts at converting
+"Received" headers to "Path" header MUST NOT be done. It is STRONGLY
+RECOMMENDED that the original email message be stored in the gateway
+(including all headers) for a period following processing, to allow
+tracing of forged or otherwise problematical articles. Netnews to email
+gateways MAY copy the "Path" header from the news article into the
+outgoing email.
+
+Note: The "Path" header in netnews has as one of its uses to avoid
+duplicates of the same message. Because of this, trying to convert
+"Received" headers to "Path" headers might cause a message to be skipped
+in netnews, and that is why such conversion MUST NOT be done.
+
+
+5.9   "Control" messages
+
+Mail to netnews gateways should provide the ability for users to cancel
+articles they have used the gateway to post. To prevent the use of such
+gateways for illegitimate cancels, gateways should not post cancels for
+articles which were not posted through that gateway, and should require
+some authentication for cancels it does post.
+
+For example, the gateway may generate a key which is returned to the
+user by email for each article posted. The user would include this key
+in the cancel message he sends to the gateway.
+
+
+5.10  Other Headers
+
+Headers defined for netnews only can occur in email, and headers defined
+for email can occur in netnews. An exception to this is the "Newsgroups"
+header, which must be handled as described in clause 5.4 and 5.5 above.
+Headers defined only for netnews should not be interpreted by email
+clients, nor should email-only headers be interpreted by news clients.
+
+Some headers have a more restricted syntax in netnews than in email, in
+that case, the netnews syntax shall be used in combined messages.
+Gateways must restrict the syntax of such headers if they are conveyed
+from email to netnews.
+
+
+5.11  Headers Mandatory in Netnews but not in Email
+
+The following headers are mandatory in netnews but optional in email:
+"Newsgroups", "Subject", "Message-ID" and "Path". Combined messages
+SHOULD include these fields in both the mail and the netnews copy of the
+message, except that the "Newsgroups" header in netnews is replaced by
+the "Posted-To" header in email.
+
+
+5.12  Headers Optional in Netnews and not Defined in Email
+
+Headers optional in netnews and not defined in email may occur in email
+messages. Combined clients MUST, and email to news gateways SHOULD,
+include these optional headers in the netnews versions of any messages
+they post.
+
+
+6.    Preparation of Replies to Combined Messages
+
+Combined clients generating replies intended only for the author or for
+only a few email recipients shall follow the email conventions for
+replies and MAY indicate the newsgroup of the original message in a
+comment in the "In-Reply-To" clause as specified in section 5.1 of this
+standard.
+
+Combined clients generating replies intended for the group who saw the
+original message should use the information in any "Followup-To" (or
+"Posted-To"/"Newsgroups" header, lacking a "Followup-To") to determine a
+default list of newsgroups to which the reply may be posted, and
+information from "Group-Reply-To" to determine a list of email
+recipients for group replies. The client MUST allow the user to modify
+any default list of email and newsgroup destinations.
+
+"Group-Reply-To" indicates recommendations by the author of where to
+send group replies, when these recommendations are email addresses (or
+email addresses of mail gateways to newsgroups). "Followup-To" also
+indicates such recommendations as specified in RFC 1036. A message may
+include both "Followup-To" indicating a newsgroup, and "Group-Reply-To"
+indicating a mailing list, which for example is run in parallel with the
+same newsgroup or where the message is intended for recipients of both
+the newsgroup and the mailing list.
+
+A client which knows that a followup will reach a mailing list in a
+"Group-Reply-To" header through a gateway from a newsgroup in a
+"Followup-To" header may send a followup only to the newsgroup, relying
+on the gateway to forward it to the mailing list. In this way, the risk
+of recipients getting multiple copies of the message can be reduced. If
+the client is not sure this will work, it should send the followup to
+both "Followup-To" and "Group-Reply-To" recipients.
+
+The choice of the appropriate recipients for a reply to the same group
+as the original message is not always easy, and good user interfaces
+will help users by clarifying to them what they are doing and where
+their reply will be sent, and make the user aware if s/he is moving a
+mail discussion to a news discussion or the reverse.
+
+In particular, any "Newsgroups" header in an email message SHOULD NOT be
+used as an indication that the original message has been sent to this
+newsgroup. Use of the "Newsgroups" header can otherwise easily result in
+a reply to a private message being sent to a newsgroup even though the
+original message was not sent to this newsgroup.
+
+
+7.    Cooperating Clients and Gateways
+
+If an email client is designed to cooperate with a certain gateway from
+email to netnews, then messages sent only between clients of this type
+and gateways of this type may employ additional information, not
+standardized here, to improve the cooperation between them. Such
+additional information MUST not be specified in ways which can cause
+misunderstandings if the message gets to other than the specified
+cooperating recipients.
+
+
+8.    Security considerations
+
+This standard will reduce the risk of various unexpected results for
+combined messages. Some existing risks in email and netnews may stay
+even with this standard, but no new risks are expected as a result of
+this standard. In general, increased transportation of messages between
+news and email may mean that existing risks in news are propagated to
+email or the reverse, but these risks would not be reduced by the lack
+of a standard for such combined messages.
+
+One security problem is that many Usenet News servers will totally
+reject an incoming article, if the server already has an article with
+the same Message-ID. This is of course proper if the new copy is
+destined for the same newsgroup, but if the new copy is destined for
+another newsgroup, the proper handling would be to distribute it to that
+group, but not to the group where it already appears.
+
+Newsgroup servers SHOULD accept articles even if the server already has
+an article with the same Message-ID, but only if the new article has as
+recipient some newsgroup where this message is not already stored, and
+then only distribute the new copy to the new newsgroup. Until all Usenet
+News servers have been modified to work this way, there is a security
+risk with gatewaying mailing lists to news, in that a message sent to
+more than one mailing lists, which are gatewayed to news at different
+hosts, might not get to both newsgroups. The best way to handle this
+problem is to change the behavious of news servers. An alternate
+solution might be to change the Message-ID in gateways, but this
+alternative has obvious drawbacks and is not recommended.
+
+The algorithm for generating Message-IDs for messages lacking them can
+slightly increase this security risk, but since most messages have
+Message-IDs, the problem is there with or without this algorithm.
+
+
+9.    Acknowledgments
+
+This standard is based on an earlier draft written by John Stanley.
+
+
+10.   References
+
+Ref.          Author, title                         IETF status (May 1997)
+                                                    ----------------------
+---           -------------
+
+[SMTP]        J. Postel: "Simple Mail Transfer      Standard, Recommended.
+              Protocol", STD 10, RFC 821, August
+              1982.
+
+[RFC822]      D. Crocker: "Standard for the         Standard, Recommended.
+              format of ARPA Internet text
+              messages." STD 11, RFC 822, August
+              1982.
+
+[RFC1036]     M.R. Horton, R. Adams: "Standard      Non-standard (but still
+              for interchange of USENET             widely used as a de-facto
+              messages", RFC 1036, December         standard).
+              1987.
+
+[RFC1123]     R. Braden (editor): "Requirements     Standard, Required.
+              for Internet Hosts -- Application
+              and Support", STD-3, RFC 1123,
+              October 1989.
+
+[MIME]        N. Freed, N. Borenstein and           Draft Standard, elective.
+              others, "Multipurpose Internet
+              Mail Extensions (MIME) Part One to
+              Five, RFC 2045 to 2049.
+
+[MD5]         Rivest, R., "The MD5                  Non-standard
+              Message-Digest Algorithm", RFC
+              1321, MIT Laboratory for Computer
+              Science and RSA Data Security,
+              Inc., April 1992.
+
+[CMD5]        J. Myers, M. Rose: The Content-MD5    Draft standard, Elective
+              Header. RFC 1864, October 1995.
+
+
+11.   Author's Addresses
+
+Jacob Palme                        Phone: +46-8-16 16 67
+Stockholm University/KTH           Fax: +46-8-783 08 29
+Electrum 230                       Email: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
+
+Appendix A: Examples
+
+A.1 One Combined Message in two Instances.
+
+The following is an example of a combined message, sent both to a
+newsgroup comp.lang.c and via e-mail to a person mary@foo.bar when
+transported via netnews:
+
+   Newsgroups: comp.lang.c
+   To: mary@foo.bar
+   Date: 7 Jan 1997 12:34:21 +0000 (GMT)
+   Subject: A message about inheritance
+   From: fred@somewhere.zz
+   Message-ID: <123zx@somewhere.zz>
+   Path: a.news.system!b.news.system!somewhere.zz!fred
+
+   What is it?
+
+
+The same message when transported via email:
+
+   Posted-To: comp.lang.c
+   To: mary@foo.bar
+   Date: 7 Jan 1997 12:34:21 +0000 (GMT)
+   Subject: A message about inheritance
+   From: fred@somewhere.zz
+   Message-ID: <123zx@somewhere.zz>
+   Path: a.news.system!b.news.system!somewhere.zz!fred
+
+   What is it?
+
+
+A.2 Conversion Performed by Email to News Gateway.
+
+In this case, the mailing list name is not copied to a "To:" header in
+netnews, since it gives the same information which the "Newsgroups:"
+header gives in netnews. The email message before conversion:
+
+   Received: from ietf.org (ietf.org [132.151.1.19])
+             by info.dsv.su.se (8.8.5/8.8.5) with SMTP
+             id QAA00061 for <jpalme@dsv.su.se>;
+             Mon, 2 Jun 1997 16:23:10 +0200 (MET DST)
+   Received: from ietf.org by ietf.org id aa05468; 2 Jun 97 9:50 EDT
+   Received: from ietf.ietf.org by ietf.org id aa04922; 2 Jun 97 9:28
+             EDT
+   Mime-Version: 1.0
+   Content-Type: Multipart/Mixed; Boundary="NextPart"
+   To: IETF-Announce@ietf.org
+   Sender: ietf-announce-request@ietf.org
+   From: Internet-Drafts@ietf.org
+   Reply-to: Internet-Drafts@ietf.org
+   Subject: I-D ACTION:draft-leiba-imap-idle-02.txt
+   Date: Mon, 02 Jun 1997 09:28:44 -0400
+   X-Orig-Sender: cclark@ietf.org
+   Message-ID: <9706020928.aa04922@ietf.org>
+
+   A Revised Internet-Draft is available from the on-line Internet-
+   Drafts directories.
+
+The same message after gatewaying to netnews:
+
+   Mime-Version: 1.0
+   Content-Type: Multipart/Mixed; Boundary="NextPart"
+   Newsgroups: comp.standards.ietf.announcements
+   Sender: ietf-announce-request@ietf.org
+   From: Internet-Drafts@ietf.org
+   Reply-to: Internet-Drafts@ietf.org
+   Subject: I-D ACTION:draft-leiba-imap-idle-02.txt
+   Date: Mon, 02 Jun 1997 09:28:44 -0400
+   X-Orig-Sender: cclark@ietf.org
+   Message-ID: <9706020928.aa04922@ietf.org>
+
+   A Revised Internet-Draft is available from the on-line
+   Internet-Drafts directories.
+
+
+A.3 Conversion Performed by News to Email Gateway.
+
+Original netnews article:
+
+   Newsgroups: comp.sys.mac
+   From: PHLLB@leeds.ac.uk (L. Burkholder)
+   Subject: cocoa (formerly kidsim)
+   Message-ID: <4p1ul5$88k_001@leeds.ac.uk>
+   NNTP-Posting-Host: woolhouse_pc37.leeds.ac.uk
+   Organization: University of Leeds
+   Date: Tue, 4 Jun 1996 19:16:24 +0100 (BST)
+   X-Newsreader: News Xpress Version 1.0 Beta #4
+
+   Does anyone know how to get a copy of the recently announced Apple
+   visual programming language Cocoa (formerly called Kidsim)?
+
+The same message after gatewaying to email:
+
+   Posted-To: comp.sys.mac
+   To: info-mac@sumex-aim.stanford.edu
+   From: PHLLB@leeds.ac.uk (L. Burkholder)
+   Subject: cocoa (formerly kidsim)
+   Message-ID: <4p1ul5$88k_001@leeds.ac.uk>
+   NNTP-Posting-Host: woolhouse_pc37.leeds.ac.uk
+   Organization: University of Leeds
+   Date: Tue, 4 Jun 1996 19:16:24 +0100 (BST)
+   X-Newsreader: News Xpress Version 1.0 Beta #4
+
+   Does anyone know how to get a copy of the recently announced Apple
+   visual programming language Cocoa (formerly called Kidsim)?
+
+
+Appendix B: Algorithm for Assigning Message-IDs to Messages in Gateways
+from Email to Netnews
+
+The intention of the following algorithm is to make it likely that the
+same message will get the same Message-ID even if it is gatewayed in
+more than one place from email to news, and to make it very unlikely
+that two different messages get the same Message-ID. This algorithm is
+only intended for gateways from email to netnews, and only when
+gatewaying messages which do not have a Message-ID.
+
+Step 1: Remove all headers except From, Date, Sender, Subject.
+
+Step 2: Compute an MD5 checksum using the algorithm described in [1].
+
+Step 3: Encode the checksum using BASE64 encoding as specified in [2].
+
+Step 4: Concatenate the string "@MD5.net" to the encoded string.
+
+Note: If the message does not have any Date header, this algorithm
+should not be attempted, instead an algorithm giving a globally unique
+Message-ID based on a domain controlled by the gateway should be used.
+
+
+Appendix C: Example of two partially overlapping threads
+
+THREAD A:                            THREAD B:
+
+Subject: The beatles<-------+        Subject: Abba
+Message-ID: a1@foo.bar       \       Message-ID: b1@foo.bar
+          ^                   \                ^
+          |                    \               |
+References: a1@foo.bar          \    References: b1@foo.bar
+Subject: Re: The beatles         \   Subject: Re: Abba
+Message-ID: a2@foo.bar            \  Message-ID: b2@foo.bar
+          ^                        \           ^
+          |                         \          |   THREADS A+B:
+          |                          \         |
+References: a1@foo.bar, a2@foo.bar   References: a1@foo.bar, b1@foo.bar,
+Subject: Re: The beatles                        b2@foo.bar
+Message-ID: a3@foo.bar               Subject: Re: Abba and the beatles
+          ^                          Message-ID: ab1@foo.bar
+          |                                    ^
+          |                                    |
+References: a1@foo.bar, a2@foo.bar,  References: a1@foo.bar, b1@foo.bar,
+            a3@foo.bar                           b2@foo.bar, ab1@foo.bar
+Subject:    Re: The beatles          Subject: Re: Abba and the beatles
+Message-ID: a4@foo.bar               Message-ID: ab2@foo.bar
+
diff --git a/Documentation/en/I-D/draft-palme-select-00.txt b/Documentation/en/I-D/draft-palme-select-00.txt
new file mode 100644
index 00000000..7e61238b
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-select-00.txt
@@ -0,0 +1,3880 @@
+Network Working Group                                      Jacob Palme
+Internet Draft                                Stockholm University/KTH
+draft-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-palme-supersedes-00.txt b/Documentation/en/I-D/draft-palme-supersedes-00.txt
new file mode 100644
index 00000000..68f9b8a6
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-supersedes-00.txt
@@ -0,0 +1,412 @@
+INTERNET-DRAFT                                    Jacob Palme
+Network Working Group                Stockholm University/KTH
+draft-palme-supersedes-00.txt                          Sweden
+Expires August 1999                             February 1999
+
+
+
+
+The Supersedes or Replaces Header in E-mail
+
+
+
+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 1998. All Rights Reserved.
+
+
+Abstract
+
+This memo introduces one new e-mail header, Supersedes.  This
+document may, if accepted by the IESG, become a proposed
+standard, at some time in the future.
+
+Differences from draft-ietf-mailext-new-fields-14.txt
+
+Most of these changes are to agree with a similar
+specification by Charles Lindsey on the Supersedes and
+Replaces headers in Usenet News, which is being developed as
+part of the IETF USEFOR working group, and by other
+suggestions made in the USEFOR mailing list.
+
+Parameters "noshow", "show" and "repost" have been added to
+the "Supersedes" header, in accordance with discussions in the
+usefor mailing list.
+
+A parameter "version=<decimal-version-number>" might also be
+considered, but has not been added.
+
+The discussion in chapter 1.2.1 Who may supersede a
+message/article? has been extended to more fully explain the
+reasons for the recommended practices for implementing hard
+supersedes.
+
+A discussion note has been added to chapter 1.2.4 When to use
+soft and hard supersedes to explain why the author of a
+message may want hard superseding of a message in certain
+cases.
+
+
+Table of contents
+
+1.   Supersedes
+ 1.1   Syntax
+ 1.2   Semantics
+   1.2.1  Who may supersede a message/article?
+   1.2.2  Semantic variant 1: Soft supersedes
+   1.2.3  Semantic variant 2: Hard supersedes
+   1.2.4  When to use soft and hard supersedes
+   1.2.5  Multiple field values
+2.   Security considerations
+3.   Copyright
+4.   Acknowledgments
+5.   References
+6.   Author's address
+
+
+1.    Supersedes
+
+1.1   Syntax
+
+    Supersedes-field          = "Supersedes:" CFWS identifier
+                                *(identifier)
+                                optional-parameter-list
+                                [CFWS] CRLF
+
+    optional-parameter-list   = *( ";" LWSP parameter )
+
+    parameter                 = parameter-name [ "="
+                                parameter-value ]
+
+    parameter-name            = "noshow" / "show" / "repost"
+                                private-parameter /
+                                future-parameter
+
+Note: There is no comma between multiple values, and that each
+Message-ID value is to be surrounded by angle brackets.
+
+Warning: Some software may not work correctly with comments in
+header fields, especially comments in other places than at the
+beginning and end of the field value.
+
+Warning: This header MUST be spelled "Supersedes" and not
+"Supercedes".
+
+1.2   Semantics
+
+The Supersedes header identifies previous correspondence,
+which this message supersedes. Different messaging agents such
+as user agents, mailing list expanders and mailing list
+archives. A user agent is expected to handle this field in
+much the same way as the In-Reply-To and References header.
+
+Note: The Message-ID of a superseding message MUST be
+different from the Message-ID of the superseded message. The
+Message-ID of the superseded message is used as value in the
+"Supersedes:" header, not in the Message-ID of the superseding
+message.
+
+Parameters:
+
+noshow   In the opinion of the sender, this message makes such
+         a minor change to the superseded version, that a
+         recipient, who has already seen the previous verson,
+         will probably not want to see the new version, unless
+         the user explicitly asks for it.
+
+show     In the opinion of the sender, this message makes such
+         a large change to the superseded version, that a
+         recipient, who has already seen the previous version,
+         will probably want to see the new version, too.
+
+repost   This document is a document which is repeatedly, at
+         regular or irregular intervals, reposted, such as
+         FAQs or mailing list monthly information.
+
+None of these parameters have values. The "noshow" and the
+"show" parameters are mutually exclusive, but both of them can
+occur together with the "repost" parameter.
+
+1.2.1 Who may supersede a message/article?
+
+Agents receiving superseding messages MAY ignore, or issue a
+warning, for the Supersedes header, if the author of the
+message is not approved. Approved authors of superseding
+messages MAY be:
+
+(1) The author of the message being superseded.
+
+(2) For moderated mailing lists, the moderator. Note that a
+    moderator may only supersede messages/articles in groups,
+    for which the moderator is responsible, and such a
+    moderator SHOULD not send superseding messages/articles to
+    other groups.
+
+        Discussion: There are two kinds of moderated lists,
+        pre-moderated and post-moderated. In pre-moderated
+        lists, the moderator approves all contributions
+        before they are sent out to list members.
+        In post-moderated lists, contributions are sent
+        out immediately, but the moderator can supersede
+        inappropriate contributions afterwards. The
+        advantage with pre-moderated lists is that no
+        inappropriate contributions will ever be sent out.
+        The advantage with post-moderated list is faster
+        turnaround time in discussion threads.
+
+(3) Other users given the authority to supersede messages.
+    Such authority is often local to one particular server
+    only.
+
+        Discussion: A server administrator may be legally
+        required to supersede illegal messages, if these
+        are available for download by people who have
+        not yet received them.
+
+An agent MAY ignore or issue a warning for Supersedes headers
+if the Superseding message does not have a verifyable digital
+signature of its author or another agent who the agent owner
+thinks should be allowed to supersede this message. Digital
+signatures are separately standardized (like SMIME [9] and PGP
+[10] or other standards for digital signatures) and their
+format and semantics are not specified in this standard.
+
+1.2.2 Semantic variant 1: Soft supersedes
+
+(a) With soft supersedes this header does not imply any
+    mandatory deletion of the previous correspondence in
+    mailboxes and user agent databases. The user is still able
+    to view old versions of superseded messages.
+
+(b) Agents which provide user commands for getting from a
+    reply to the replied-to message (or for getting from a
+    replied-to message to its replies), MAY provide similar
+    commands for getting from a superseding message to the
+    superseded message (or for getting from a superseded
+    message to its superseding version).
+
+(c) Agents MAY normally show the recipient both the previous
+    and the superseding message. If, however, both the
+    previous and the superseding message have arrived, both
+    having the same author, but the user has not yet seen
+    either of them, a user agent MAY show only the superseding
+    message, but also show a mark to inform the recipient that
+    this message supersedes a previous message.
+
+1.2.3 Semantic variant 2: Hard supersedes
+
+With hard supersedes, the arrival of a superseding message or
+article will cause the deletion of the superseded message. The
+new message will however still have a new Message-ID and will
+not take over the Message-ID of the superseded
+message/article.
+
+1.2.4 When to use soft and hard supersedes
+
+Hard and soft supersedes are differentiated by the receiving
+client, not the sender. There is no format difference in the
+header between hard and soft supersedes.
+
+Mail stores under the control of an individual user (for
+example, POP or IMAP mail boxes) SHOULD implement soft
+supersedes but MAY implement hard supersedes, possibly only as
+an (off by default) option.  (Please read the security
+considerations if you plan to implement this). Multi-user
+message archives and servers MAY implement HARD supersedes.
+
+    Discussion: A person, who has by mistake written an
+    illegal message, may be legally required to hard supersede
+    the illegal message, in places where it is available for
+    download by people who have not yet received it.
+
+Note: In Usenet News, servers commonly implement hard
+supersedes.
+
+If the handler of a message/article storage has a mechanism
+for automatic purging of old messages, the fact that there is
+a superseding message may be a component in the decision of
+when to purge the previous version.
+
+1.2.5 Multiple field values
+
+When this is written (1999) some Usenet News softwares cannot
+handle Supersedes with more than one previous articles listed
+as parameters. This can be expected to change, but until then,
+a gateway from e-mail to news MAY because of this delete all
+but the first parameter of this attribute when conveying
+messages from e-mail to news.
+
+
+2.    Security considerations
+
+
+If a server or receiving user agent suppresses showing of
+superseded messages, the "Supersedes:" feature might be used
+maliciously to suppress messages written by other people. To
+reduce the risk for this, it is RECOMMENDED that user agents
+give a warning to the recipient when a superseding message has
+a different "From:" name than the superseded message.
+
+A moderately clever forger can of course circumvent this by
+sending messages with falsified "From:" field and even
+falsified SMTP senders. User agents supporting S/MIME [9] or
+PGP [10] or other standards for digital signature can require
+and check digital signatures to reduce also this risk (see
+section 1.2.1 above).
+
+Even more reduction of security problems can be achieved if
+user agents handle "Supersedes:" exactly in the same way as
+"In-Reply-To:" and "References:", i.e. show both versions of
+the message, and only use the "Supersedes:" header as
+information to readers of messages of the relation between
+different messages.
+
+Another possible risk with "Supersedes:" is that it allows
+people to "change their minds", possibly changing the meaning
+of replies to them. Example: A message with the text "Do you
+like your mother" gets the reply "Yes, very much", and then
+the original message might be changed to "Do you like Hitler",
+changing the meaning of the reply. Note, however, that the
+"In-Reply-To" or "References" headers in the reply refers to
+the Message-ID of the original message, not of the superseding
+message. Thus, a user agent can avoid this problem by
+designing the user interface so that replies are not shown as
+referring to the superseding message, when they use the
+Message-ID of the superseded message.
+
+Also, since "Supersedes:" in e-mail is meant to not actually
+cause deletion of the superseded message, recipients can look
+up the superseded message to see if the author has changed his
+mind. In general, it is not illegal or unethical to change
+your mind, rather, it shows your openness to new ideas and
+willingness to listen to the arguments of other people.
+
+The fact that some implementations of Supersedes cause
+deletion of the Superseded message (hard supersedes, section
+1.2.3 above), but others do not (soft supersedes, section
+1.2.2 above), may cause security problems. To reduce this
+problem, a server should clarify its policy on this to its
+users and follow the recommendations in section 1.2.4 above.
+
+
+3.    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.
+
+
+4.    Acknowledgments
+
+Many people have helped with the production of this document.
+Of special value have been R. Allbery, H. T. Alvestrand, A.
+Bowesman, B. Franz, P. Hoffman, S. Kille, S. Lyall, K. Moore,
+P. Overell, U. Paz, E. Sommarskog, H. Spencer, J. Stanley, B.
+Templeton, K. Weide and R. Zellich
+
+
+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. Freed, N. Borenstein, "Multipurpose Internet Mail
+     Extensions (MIME) Part One: Format of Internet Message
+     Bodies", RFC 2045, December 1996
+
+[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]  M.R. Horton, R. Adams: "Standard for interchange of
+     USENET messages", RFC 1036, December 1987.
+
+[9]  B. Ramsdell: S/MIME Version 3 Message Specification. Work
+     in progress.
+
+[10] J. Callas, L. Donnerhacke, H. Finney, R. Thayer: OpenPGP
+     Message Format. Work in progress.
+
+[11] J. Palme: "Advise on the implementation of In-Reply-To,
+     References and Supersedes e-mail and netnews headers",
+     draft-palme-newfields-info-02.doc, March 1998.
+
+[12] D. Crocker: Augmented BNF for Syntax Specifications:
+     ABNF, RFC 2234, November 1997.
+
+
+6.    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-varshavchik-data-smtpext-01.txt b/Documentation/en/I-D/draft-varshavchik-data-smtpext-01.txt
new file mode 100644
index 00000000..eaab3128
--- /dev/null
+++ b/Documentation/en/I-D/draft-varshavchik-data-smtpext-01.txt
@@ -0,0 +1,353 @@
+INTERNET-DRAFT                                            S. Varshavchik
+Expires Jan 26, 2000                              Double Precision, Inc.
+                                                           July 26, 1999
+
+                        Extended SMTP DATA Reply
+                 draft-varshavchik-data-smtpext-01.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.
+
+0. Revision history
+
+   01 - fixed a footnote typo.  Added references to related documents:
+   RFC2033, RFC1047, draft-ietf-fax-smtp-session.
+
+1. Abstract
+
+   This document describes an extension to the SMTP service [RFC1425],
+   called Extended DATA Reply.  This is an extended format of the SMTP
+   response to the DATA verb which provides recipient-specific status
+   information.  This allows mail recipients to use individual mail
+   filters as part of the Simple Mail Transfer Protocol.  This is a very
+   desirable feature because of escalating amounts of unwanted junk E-
+   mail sent over the Internet.
+
+2. Introduction
+
+   The reply to the SMTP [RFC821] DATA verb is a status code indicating
+   if the message was accepted or rejected.  The status code also
+
+Expires Jan 26, 2000                                            [Page 1]
+
+EXDATA SMTP Extension        S. Varshavchik                July 26, 1999
+
+   indicates if the rejection is temporary or permanent.  Additional
+   delivery attempts will be made for messages that are temporarily
+   rejected.
+
+   SMTP allows a message to have multiple recipients, but the reply to
+   the DATA verb cannot indicate if the message was successfully
+   accepted for some recipients only and rejected for the rest of them
+   (permanently or temporarily).  It can only indicate if the message
+   was accepted or rejected for every one of the listed recipients.
+
+   The only way to handle this condition within the current protocol is
+   to send a status code indicating that the message was accepted, then
+   immediately generate a non-delivery report for undeliverable
+   recipients.  This imposes additional resources and overhead, to
+   generate and transmit the non-delivery report.
+
+   The ability to have recipient-specific status in the reply to the
+   DATA verb is desirable for the following reasons:
+
+        A) The receiving SMTP server does not have to generate and send
+           a non-delivery report.
+
+        B) Recipients can install individual mail filters that
+           selectively block unwanted E-mail, and the mail filters will
+           be able to examine the entire contents of the message before
+           deciding to reject the message.  Currently, recipient-
+           specific filtering is only possible in response to the "RCPT
+           TO:" verb.  But the only available information at that point
+           is the network address of the sending mail server and return
+           address of the message.  Filtering unwanted junk mail based
+           only on the network address and the return address is of very
+           limited benefit.
+
+   There are several other mail enhancements that involve recipient-
+   specific processing.  [RFC2033] defines a related, but a completely
+   different, mail delivery protocol which features recipient-specific
+   processing.  There was also another draft memo published, draft-ietf-
+   fax-smtp-session, which defined an extension for recipient-specific
+   mail processing, however its scope is different from the scope of
+   this memo.
+
+3. Framework for the EXDATA SMTP transport extension
+
+   This SMTP transport extension [RFC1425] is laid out as follows.
+
+      (1) The name of the SMTP transport extension defined here is
+          Extended Data Reply (EXDATA).
+
+Expires Jan 26, 2000                                            [Page 2]
+
+EXDATA SMTP Extension        S. Varshavchik                July 26, 1999
+
+      (2) The EHLO keyword associated with this extension is EXDATA.
+
+      (3) The EXDATA EHLO keyword takes no parameters.
+
+      (4) One optional ESMTP keyword EXDATA is associated with the MAIL
+          FROM command. This parameter takes no values.
+
+      (5) No additional ESMTP verbs are defined by this extension.
+
+      (6) The next sections specify how support for this extension
+          affects the behavior of a server and client SMTP server.
+
+4. The EXDATA SMTP extension
+
+   The receiving SMTP server indicates that it is capable of supporting
+   the Extended Data Reply SMTP extension by including the EXDATA
+   keyword in the EHLO list.
+
+   The sending SMTP server indicates that it supports this extension by
+   including the EXDATA keyword in the MAIL FROM command.
+
+   If the sending SMTP server includes the EXDATA keyword in the first
+   MAIL FROM command, it MUST include the keyword in every MAIL FROM
+   command used in the same SMTP session.  If the sending SMTP server
+   does not include the EXDATA keyword in the first MAIL FROM command,
+   it MUST NOT include the keyword in any MAIL FROM command used in the
+   same SMTP session.
+
+   The receiving SMTP server SHOULD NOT send extended replies to the
+   DATA verb if the EXDATA keyword is not included in the MAIL FROM
+   command.
+
+   An extended DATA verb reply MAY be sent instead of the second status
+   code reply to the DATA verb. It MUST NOT be sent as the first reply
+   to the DATA verb (before the message is transmitted).  Using the
+   extended format in the second reply to the DATA verb is optional, and
+   not required.  The receiving SMTP server is always permitted to send
+   regular status replies.
+
+5. Format of an extended SMTP DATA reply
+
+   The extended SMTP DATA reply uses the 558 numeric status code which
+   is explicitly reserved for this purpose.  When a 558 numeric status
+   code is the second reply to the DATA verb, the reply MUST be
+   formatted as follows, where <SP>, <CR> and <LF> represent the ASCII
+   space, carriage return, and line feed characters:
+
+   ex-reply-code: ex-reply-recipient-list
+
+Expires Jan 26, 2000                                            [Page 3]
+
+EXDATA SMTP Extension        S. Varshavchik                July 26, 1999
+
+   ex-reply-recipient-list: non-final-recipient ex-reply-recipient-list
+                       | final-recipient
+
+   non-final-recipient: non-term-line non-final-recipient
+                        | non-final-recipient-term-line
+
+   non-term-line: "558-" result-code "-" result-text
+
+   non-final-recipient-term-line: "558-" result-code <SP> result-text
+
+   final-recipient: non-term-line final-recipient
+                    | final-recipient-term-line
+
+   final-recipient-term-line: "558" <SP> result-code <SP> result-text
+
+   result-code: digit digit digit
+
+   result-text: 0 or more characters, except <CR> and <LF>, terminated
+                by the <CR> <LF> sequence
+
+   digit: Characters "0" through "9"
+
+   The extended DATA reply is formatted like a standard multiline SMTP
+   reply with a 558 numeric status code.  The extended information is
+   contained within the text portion of the 558 multiline reply.  The
+   extended information consists of one or more individual replies,
+   where each reply itself is formatted like an SMTP reply.  There will
+   be exactly one reply for each recipient.  Each individual reply may
+   be a multiline reply itself.
+
+6. Restrictions on the extended SMTP DATA reply
+
+   Extended replies MUST contain exactly one individual reply for each
+   recipient whose RCPT TO command was acknowledged with a 2xx result
+   code.  Extended replies MUST NOT have any replies for recipients
+   whose RCPT TO commands were previously rejected with a 4xx or 5xx
+   result code.
+
+   For example, if a message had three recipients, and the second RCPT
+   TO command was rejected, the extended reply MUST contain two
+   individual replies: the first one is for the first recipient, the
+   second one for the last recipient.
+
+7.  Examples
+
+   In this example the first recipient of a two-recipient message is
+   accepted.  The second recipient is rejected:
+
+Expires Jan 26, 2000                                            [Page 4]
+
+EXDATA SMTP Extension        S. Varshavchik                July 26, 1999
+
+   558-250 Message accepted
+   558-550-Access denied:
+   558 550 Insufficient permission
+
+   In this example the first recipient is rejected. The second recipient
+   is accepted:
+
+   558-550-Access denied
+   558-550 Insufficient permission
+   558-250-Message accepted
+   558 250 Queue ID is 120
+
+7.1 Parsing extended replies
+
+   Extended replies can be parsed rather easily by noting that extended
+   replies are wrapped inside a standard SMTP multiline reply with a 558
+   status code.  If the numeric code of the second status reply to the
+   DATA verb is 558, and if the receiving server listed EXDATA in the
+   EHLO keyword list, the "558-" and "558<SP>" characters are removed
+   from the start of every line in the multiline response. The remaining
+   text is now interpreted as a series of individual SMTP replies, one
+   reply per recipient.  Each individual reply may be a multiline reply
+   itself.
+
+8.  Security Concerns
+
+8.1 Transitional behavior
+
+   The stated benefit of this extension is to allow recipients to use
+   individual mail filters to reject mail during an SMTP transaction.
+   However this extension must be widely implemented for this to happen.
+   Furthermore, the sending mail server can always omit the EXDATA
+   keyword from the MAIL FROM: verb.
+
+   It follows that recipient-specific filtering should still be used
+   even if the sending server does not state its support for the EXDATA
+   extension.  One approach is to reply to the DATA verb with an
+   accepted status, then apply individual filters and generate a non-
+   delivery report for recipients whose filters rejected the message.
+   But this would be exactly how individual mail filtering is currently
+   implemented, and it carries with it the same disadvantages and
+   setbacks.
+
+   Another possible approach is to go ahead and issue an extended reply,
+   which will be interpreted as a permanent failure by the sending mail
+   server.  This approach is unacceptable in most cases because the
+   sending mail server will correctly conclude that every recipient was
+
+Expires Jan 26, 2000                                            [Page 5]
+
+EXDATA SMTP Extension        S. Varshavchik                July 26, 1999
+
+   undeliverable.  If a message comes from a mailing list, the mailing
+   list management software can end up removing all recipients from the
+   mailing list only because of a malfunctioning mail filter used by one
+   recipient only.
+
+   The following approach MUST be used to implement recipient-specific
+   mail filtering during a transition period, using the EXDATA
+   extension, without allowing one recipient's malfunctioning filters to
+   disrupt mail for everyone.
+
+        A) Allow each recipient to specify "white-listed" senders and/or
+           network addresses.
+
+        B) Determine if the message is white-listed in response to the
+           RCPT TO: verb, according to the first recipient's rules.
+
+        C) If the message is white-listed by the first recipient, any
+           additional recipients MUST also have the message white-
+           listed.  If not, reject the corresponding RCPT TO: verb with
+           a temporary 421 status code.  The sending server will
+           retransmit the message for all non white-listed recipients
+           after a small delay.
+
+        D) If the message is not white-listed by the first recipient,
+           any additional recipients MUST NOT have the sender and/or the
+           sending network address white-listed.  If they do, reject the
+           corresponding RCPT TO: verb with a temporary 421 status code.
+           The sending server will retransmit the message for all white-
+           listed recipients after a small delay.
+
+        E) This logic results in separate delivery attempts for white-
+           listed and non white-listed recipients (with a small delay in
+           between).  Individual recipients can white-list specific
+           sources of mail (such as mailing lists).  The mail server
+           will not do any filtering on white-listed mail, and will
+           never send extended replies to those sources.  By white-
+           listing a known mail source recipients can make sure that any
+           other mail filter will not affect their mail delivery.
+
+8.2 Response time to SMTP DATA
+
+   Implementors should try to avoid any lengthy delays, due to mail
+   filters being used, before returning a reply to the SMTP DATA.  Many
+   SMTP clients wait for a response for only a short period of time,
+   before giving up.  This can lead to a message duplication problem,
+   described in [RFC1047].
+
+9. Comments
+
+Expires Jan 26, 2000                                            [Page 6]
+
+EXDATA SMTP Extension        S. Varshavchik                July 26, 1999
+
+   An experimental patch was made available in September 1997 (with
+   various revisions that followed) to a relatively popular mail server.
+   The patch used an XEXDATA EHLO keyword.  The experimental patch was
+   mainly used to implement recipient-specific mail filtering:
+   permitting individual recipients of a message to selectively reject
+   incoming E-mail traffic based on the contents of the message.  The
+   patch implemented the XEXDATA extension only for the receiving side,
+   not for the sending side.
+
+   No issues have been reported concerning the theoretical design of the
+   extended result code.
+
+10. References
+
+       [RFC1425] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
+           Crocker, D.  "SMTP Service Extensions", RFC 1425, United
+           Nations University, Innosoft International, Inc., Dover Beach
+           Consulting, Inc., Network Management Associates, Inc., The
+           Branch Office, February 1993
+
+       [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+           821, USC/Information Sciences Institute, August 1982.
+
+       [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
+           Carnegie Mellon, October 1996.
+
+       [RFC1047] Partridge, C., "DUPLICATE MESSAGES AND SMTP", RFC 1047,
+           CIC at BBN Labs, February 1988.
+
+11. Author's address
+
+   Sam Varshavchik
+   Double Precision, Inc.
+   PO Box 668
+   Greenwood Lake, NY 10925
+   <mrsam@concentric.net>
+
+Expires Jan 26, 2000                                            [Page 7]
diff --git a/Documentation/en/I-D/draft-varshavchik-verp-smtpext-01.txt b/Documentation/en/I-D/draft-varshavchik-verp-smtpext-01.txt
new file mode 100644
index 00000000..4185755d
--- /dev/null
+++ b/Documentation/en/I-D/draft-varshavchik-verp-smtpext-01.txt
@@ -0,0 +1,538 @@
+INTERNET-DRAFT                                            S. Varshavchik
+Expires Jan 26, 2000                              Double Precision, Inc.
+                                                            Jul 26, 1999
+
+              Variable Envelope Return Path SMTP Extension
+                 draft-varshavchik-verp-smtpext-01.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.
+
+0. Revision history
+
+   01 - added additional comments on DSNs not being very successful in
+   automatically handling mailing list functions.  Additional section
+   added with comments regarding vacation autoresponders.
+
+1. Abstract
+
+   This document describes an extension to the SMTP service [1], called
+   Variable Envelope Return Path (VERP).  The VERP extension implements
+   a way of automatically identifying undeliverable mail recipients,
+   even when non-delivery reports originate from mail systems that do
+   not implement delivery status notifications, as specified in [2] and
+   [3].
+
+2. Introduction
+
+   All E-mail software can expect to deal with undeliverable mail.  [2]
+   and [3] specify a machine-readable format for delivery status
+
+S. Varshavchik            Expires Jan 26, 2000                  [Page 1]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+   notifications (DSNs, or non-delivery reports).  DSNs allow
+   undeliverable mail to be handled in a totally automatic fashion,
+   without requiring manual intervention.  For example, mailing list
+   managers can automatically identify addresses that are no longer
+   deliverable, and remove them from the mailing list.
+
+   Although [2] and [3] are now widely implemented, there are still many
+   systems that do not use them.  This makes it impractical to
+   completely rely on DSNs for automatic mailing list management.
+   Undeliverable addresses accumulate quickly even from a very small
+   percentage of non-DSN systems.  This results in a non-trivial amount
+   of manual work to identify undeliverable addresses and purge them
+   from the mailing list.
+
+   Mailing list software began to use VERPs (the acronym stands for
+   Variable Envelope Return Path) after DSNs were found to be
+   impractical for totally automatic mailing list management.  VERPs are
+   an alternative way to handle non-delivery notices.  The advantage of
+   VERPs is that they can be made to work automatically, even when non-
+   delivery notices are not in the format specified by [2].
+
+   Unfortunately, VERPs require much more bandwidth and network
+   resources than DSNs because VERPs cannot be used to send one copy of
+   a mailing list message addressed to all the recipients in the same E-
+   mail domain.
+
+   This SMTP service extension allows E-mail software to send a single
+   VERP message to all addresses in the same mail domain, for as long as
+   mail servers, which relay the message, support the VERP SMTP
+   extension.
+
+   The VERP message may be eventually relayed to a mail server that does
+   not support this extension.  Separate messages - with variable
+   envelope return paths - will be sent when this happens.
+
+   So the worst case scenario results in the same situation where
+   traditional VERPs are used right from the start.  The best case
+   scenario results in significant savings of network resources and
+   bandwidth, from eliminating hundreds (or more) copies of the same
+   message.
+
+   Essentially, the VERP extension postpones the generation of multiple
+   messages with different return paths as much as possible, until it is
+   absolutely required.
+
+2.1 VERP overview
+
+   The traditional VERP message encodes the recipient address as a
+
+S. Varshavchik            Expires Jan 26, 2000                  [Page 2]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+   portion of the return address.  When undeliverable mail comes back,
+   the mail software decodes the return address (now the recipient
+   address) and obtains the address responsible for the non-delivery
+   notice.
+
+   For example: mail sent by a mailing list manager to the address
+   <john@example.org> carries a return address of <mlist-return-
+   john=example.org@domain.com>.  The mailing list software at
+   domain.com handles all mail with the local portion of the address
+   starting with "mlist-return-".  If a non-delivery notice is generated
+   because the address is not deliverable, the mailing list software
+   takes the address where the non-delivery report was sent, retrieves
+   the remaining portion of the local address, "john=example.org", and
+   determines that the undeliverable address was <john@example.org>.
+
+   This does not rely on RFC 1894, and will work for all non-delivery
+   notices.
+
+3. Framework for the VERP SMTP transport extension
+
+   This SMTP transport extension [1] is laid out as follows.
+
+      (1) The name of the SMTP transport extension defined here is
+          Variable Envelope Return Path.
+
+      (2) The EHLO keyword associated with this extension is VERP.
+
+      (3) The VERP EHLO keyword takes no parameters.
+
+      (4) One optional ESMTP keyword VERP is associated with the MAIL
+          FROM command. This parameter takes no values.
+
+      (5) No additional ESMTP verbs are defined by this extension.
+
+      (6) The next section specifies how support for this extension
+          affects the behavior of a server and client SMTP.
+
+4. The VERP SMTP extension
+
+   When a VERP keyword is present in the MAIL FROM command, [4], some
+   additional restrictions are imposed on the RFC 822 address [5],
+   specified by that MAIL FROM command, and on all RFC 822 addresses in
+   the subsequent RCPT TO commands that refer to the same message (that
+   is, until the next DATA, RSET, or QUIT command).  The term "VERP
+   message" refers to any E-mail message whose MAIL FROM command
+   includes the VERP keyword.  The term "VERP-compliant server" refers
+   to any E-mail server that supports the Variable Envelope Return Path
+   SMTP extension.  When a VERP keyword is present in the MAIL FROM
+
+S. Varshavchik            Expires Jan 26, 2000                  [Page 3]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+   command:
+
+       (1) The address specified by the MAIL FROM verb MUST contain at
+           least one @ character.
+
+       (2) The address in every RCPT TO verb referring to the same
+           message MUST contain at least one @ character.
+
+       (3) The domain portion of the address in the MAIL FROM and RCPT
+           TO verbs MUST be compliant with the definition of <domain> in
+           [6].  That is, it MUST contain only letters, digits, hyphens,
+           and periods.  The domain portion of the address is the one
+           that follows the last @ character,
+
+4.1 Delivery failures
+
+   When a VERP-compliant server is unable to deliver a VERP message to
+   one or more recipients, the VERP server MUST do one of the following:
+
+        1) Return an RFC 1891 delivery status notification to the return
+           address, or:
+
+        2) Transmit a separate non-delivery notice for each failed
+           recipient.  The return address for each non-delivery notice
+           MUST be the address that's formed by applying the procedure
+           described in section 7 of this document to the return address
+           of the message and the failed recipient's address.  If more
+           than one recipient was undeliverable a separate notice MUST
+           be sent for each undeliverable address.
+
+5. Final delivery
+
+   Section 4.3.1 of [5] specifies that the mail server performing final
+   delivery of a message will generate a Return-Path: header containing
+   the return address of the message.
+
+   This return address MUST be formed by applying the procedure
+   described in section 7 of this document to the return address and the
+   recipient's address.
+
+   This also applies if the mail server invokes some other external
+   process to handle final delivery, instead of placing the message into
+   the recipient's mailbox. In all cases, the return address specified
+   by the mail server to any external environment or process MUST be
+   derived by applying the procedure in section 7 to the return address
+   and the recipient's address.
+
+6. Relaying
+
+S. Varshavchik            Expires Jan 26, 2000                  [Page 4]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+   When a VERP-compliant server determines that a recipient of a VERP
+   message is not a local mailbox, and the message must be relayed to
+   another server, the VERP-compliant server MUST:
+
+       (1) If the VERP-compliant server's local policies require the
+           return and/or recipient addresses MUST comply with the
+           restrictions specified in section 4 of this document.
+
+       (2) If the VERP-compliant server determines that the remote
+           server is also a VERP compliant server, the VERP keyword MUST
+           be included in the MAIL FROM command used to relay the VERP
+           message to the remote server.
+
+       (3) If the remote server is not a VERP compliant server, The VERP
+           compliant server SHOULD send a separate copy of the message
+           for every recipient.  The return address of each copy of the
+           message MUST be formed by applying the procedure described in
+           section 7 of this document to the original return address,
+           and the address of each individual recipient.  Although the
+           message SHOULD NOT be returned as undeliverable, if it is
+           then the rules defined in section 4.1 MUST be applied.
+
+           These rules also apply if the SMTP-compliant server
+           determines that the VERP message must be forwarded via some
+           other protocol to a non-SMTP gateway, unless the non-SMTP
+           protocol has equivalent features that are completely
+           identical in function to Variable Envelope Return Path SMTP
+           service extension (including any translations of E-mail
+           addresses to and from the non-RFC822 format).
+
+7. Variable envelope return path encoding
+
+   This encoding method starts with a return address and one recipient
+   address.  As mentioned previously, both addresses MUST be valid
+   RFC822 addresses, [5], and MUST contain at least one @ character.
+   The portion of each address following the last @ character MUST be
+   compliant with [6].
+
+   Let "sdomain" represent the portion of the return address that
+   follows the last @ character.
+
+   Let "slocal" represent the portion of the return address that
+   precedes the last @ character.
+
+   Let "rdomain" represent the portion of the recipient address that
+   follows the last @ character.
+
+   Let "rlocal" represent the portion of the recipient address that
+
+S. Varshavchik            Expires Jan 26, 2000                  [Page 5]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+   precedes the last @ character.
+
+   To encode the recipient address within the envelope sender address,
+   create an address of the following form:
+
+          slocal-encodedrlocal=rdomain@sdomain
+
+   Where "encodedrlocal" is formed by taking rlocal and encoding it as
+   follows:
+
+        1) Each @, :, %, !, and + character in rlocal is replaced by a
+           single '+' character followed by two uppercase hexadecimal
+           characters whose value is the ASCII code of the replaced
+           character.
+
+        2) All other characters are unchanged.  Other characters MAY,
+           but SHOULD NOT be also encoded in the same fashion.
+
+   This can be represented using BNF as follows:
+
+     encodedverp: slocal "-" encodedrlocal "=" rdomain "@" sdomain
+
+     encodedrlocal: * (char-literal / char-encoded )
+
+     char-literal: any character valid in an RFC821 address [4],
+                   except @, :, %, !, and +
+
+     char-encoded: "+" hexdigit hexdigit
+
+     hexdigit: ("0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
+                "9" / "A" / "B" / "C" / "D" / "E" / "F" )
+
+8. Variable envelope return path decoding
+
+   Non-delivery notices for VERP messages will be sent to either the
+   original address, <slocal@sdomain>, or to the VERP-encoded address,
+   <slocal-encodedrlocal=rdomain@sdomain>.
+
+   Messages sent to <slocal@sdomain> will be RFC 1891-compliant delivery
+   status notifications.  These messages will be machine-readable, and
+   the mail software will be able to identify failed addresses from the
+   RFC 1891 delivery report.
+
+   Non-delivery notices will also be sent to the VERP-encoded address,
+   and the mail software will be able to reconstruct the failed address
+   from the VERP-encoded address by simply reversing the steps used in
+   encoding:
+
+S. Varshavchik            Expires Jan 26, 2000                  [Page 6]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+        1) Extracting encodedrlocal and rdomain from the recipient
+           address.  There will be at least one = character in the
+           encoded portion of the return address.  encodedrlocal is
+           everything up to the last = character.  Everything following
+           the last = character is rdomain.
+
+        2) Replacing all occurrences of "+" followed by two hexadecimal
+           digits in encodedrlocal with the equivalent ASCII character.
+
+        3) Using the decoded rlocal, @, then rdomain.
+
+9. Examples
+
+   Suppose that a VERP-compliant server named "example.com" receives a
+   message via the following SMTP conversation (for brevity, non-
+   relevant headers have been omitted):
+
+       250 example.com ESMTP
+       EHLO domain.com
+       250-example.com ESMTP
+       250-SIZE
+       250-DSN
+       250-VERP
+       250 HELP
+       MAIL FROM:<itny-out@domain.com> VERP SIZE=100
+       250 Ok
+       RCPT TO:<alex@example.com>
+       250 Ok
+       RCPT TO:<node42!ann@old.example.com>
+       250 Ok
+       RCPT TO:<tom@old.example.com>
+       250 Ok
+       RCPT TO:<lisa@new.example.com>
+       250 Ok
+       RCPT TO:<dave+priority@new.example.com>
+       250 Ok
+       DATA
+       250 Ok
+       From: "John" <john@domain.com>
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
+
+       Today's 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
+       .
+
+   The message is delivered to the local mailbox for <alex@example.com>.
+   The message looks like this:
+
+S. Varshavchik            Expires Jan 26, 2000                  [Page 7]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+       Return-Path: <itny-out-alex=example.com@domain.com>
+       From: "John" <john@domain.com>
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
+
+       Today's 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
+
+   The VERP-compliant server at example.com connects to the mail server
+   for old.example.com.  old.example.com does not support the Variable
+   Envelope Return Path extension.  Therefore, old.example.com receives
+   two messages.  The SMTP conversation for the first message is as
+   follows:
+
+       250 old.example.com ESMTP
+       EHLO example.com
+       250-old.example.com ESMTP
+       250-SIZE
+       250-DSN
+       250 HELP
+       MAIL FROM:<itny-out-node42+21ann=old.example.com@domain.com>
+       250 Ok
+       RCPT TO:<node42!ann@old.example.com>
+       250 Ok
+       DATA
+       250 Ok
+       From: "John" <john@domain.com>
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
+
+       Today's 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
+       .
+
+   The SMTP conversation for the second message is as follows:
+
+       MAIL FROM:<itny-out-tom=old.example.com@domain.com>
+       250 Ok
+       RCPT TO:<tom@old.example.com>
+       250 Ok
+       DATA
+       250 Ok
+       From: "John" <john@domain.com>
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
+
+       Today's 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
+
+S. Varshavchik            Expires Jan 26, 2000                  [Page 8]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+       .
+
+   example.com connects to new.example.com and determines that
+   new.example.com runs a modern ESMTP server that supports the VERP
+   keyword. The SMTP conversation then goes like this:
+
+       250 new.example.com ESMTP
+       EHLO example.com
+       250-new.example.com ESMTP
+       250-SIZE
+       250-DSN
+       250-VERP
+       250 HELP
+       MAIL FROM:<itny-out@domain.com> VERP SIZE=100
+       250 Ok
+       RCPT TO:<lisa@new.example.com>
+       250 Ok
+       RCPT TO:<dave+priority@new.example.com>
+       250 Ok
+       DATA
+       250 Ok
+       From: "John" <john@domain.com>
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
+
+       Today's 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
+       .
+
+10. Security concerns
+
+   All the usual security considerations applicable to SMTP are also
+   applicable to this extension.  Relay of VERP messages to non-VERP
+   servers requires a single message with many recipients to be exploded
+   into many messages with one recipient.  In all cases, however, there
+   will never be any additional overhead beyond the resources that are
+   required when VERPs are manually implemented by the mail sender,
+   instead of the VERP SMTP extension.
+
+   Mail systems which support the VERP extension SHOULD have adequate
+   security measures, including blocks against unauthorized access and
+   relaying.
+
+10.1 Vacation programs, and other autoresponders
+
+   "Vacation" type autoresponders are often used in practice.  A
+   vacation autoresponder is a program that automatically replies to
+   every message, informing the sender that the recipient is on
+
+S. Varshavchik            Expires Jan 26, 2000                  [Page 9]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+   vacation, or is generally unavailable at this time.
+
+   Vacation autoresponders MUST NOT generate autoresponses to mailing
+   list messages, but people often forget to do set them up to do so.
+   Because autoresponses are sent to the same address that's used to
+   receive non-delivery reports, malfunctioning autoresponders result in
+   the recipient being removed from mailing lists.
+
+   Advanced autoresponders send automatic replies in the format
+   specified by [2], as a "delayed" notification.  DSN-aware software
+   will not remove addresses from mailing lists due to delayed
+   notifications.
+
+   Section 5 of this document specifies that the mail server MUST
+   replace the original return address with a VERP-modified address when
+   delivering the message to a mailbox or an external process.
+
+   Therefore it is possible that RFC 1891 reports may also be sent to a
+   VERP-encoded address, as specified by sections 5 and 7 of this
+   document.  Mail software SHOULD ignore any RFC 1891 "delayed" or
+   "success" reports that sent to a VERP-encoded address.  If it is a
+   "failed" report, note that the VERP address will be more reliable
+   than the address specified in the report itself.
+
+S. Varshavchik            Expires Jan 26, 2000                 [Page 10]
+
+VERP SMTP Extension          S. Varshavchik                 Jul 26, 2000
+
+11. References
+
+       [1] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D.
+           "SMTP Service Extensions", RFC 1425, United Nations
+           University, Innosoft International, Inc., Dover Beach
+           Consulting, Inc., Network Management Associates, Inc., The
+           Branch Office, February 1993
+
+       [2] Moore, K., and G. Vaudreuil, "An Extensible Message Format
+           for Delivery Status Notifications", RFC 1894, University of
+           Tennessee, Octel Network Services, January 1996.
+
+       [3] Moore, K. "SMTP Service Extension for Delivery Status
+           Notifications", RFC 1891, University of Tennessee, January
+           1996.
+
+       [4] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+           USC/Information Sciences Institute, August 1982.
+
+       [5] Crocker, D., "Standard for the Format of ARPA Internet Text
+           Messages", STD 11, RFC 822, UDEL, August 1982.
+
+       [6] Mockapetris, P., "Domain Names - Implementation and
+           Specification", RFC 1035, ISI, November 1987
+
+12. Author's address
+
+   Sam Varshavchik
+   Double Precision, Inc.
+   PO Box 668
+   Greenwood Lake, NY 10925
+   <mrsam@concentric.net>
+
+S. Varshavchik            Expires Jan 26, 2000                 [Page 11]
diff --git a/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-00.txt b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-00.txt
new file mode 100644
index 00000000..ca632b75
--- /dev/null
+++ b/Documentation/en/I-D/draft-vaudreuil-esmtp-binary2-00.txt
@@ -0,0 +1,679 @@
+     Internet Draft                                       Greg Vaudreuil
+     Expires in six months                           Lucent Technologies
+                                                        December 1, 1999
+
+
+                            SMTP Service Extensions
+                           for Transmission of Large
+                            and Binary MIME Messages
+
+                     draft-vaudreuil-esmtp-binary2-00.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.
+
+     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 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 a "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.
+
+
+     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).
+
+
+
+  Copyright Notice
+
+     Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+     This Internet-Draft is in conformance with Section 10 of RFC 2026.
+
+  Abstract
+
+     This memo defines two extensions to the SMTP service.  The first
+     service enables a SMTP client and server to negotiate the use of an
+     alternative to the DATA command, called "BDAT" for efficiently sending
+     large MIME messages.  The second extension takes advantage of the BDAT
+     command to permit the negotiated sending of binary contents wrapped in
+     MIME but without a transport encoding.  This document is intended to
+     update and obsolete RFC1830.
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+  Working Group Summary
+
+     This protocol is not the product of an IETF working group, however the
+     specification resulted from discussions within the ESMTP working
+     group.  The resulting protocol documented in RFC1830 was classified as
+     experimental at that time due to questions about the robustness of the
+     Binary Content-Transport-Encoding deployed in then existent MIME
+     implementations.  As MIME has matured and other uses of the Binary
+     Content-Transport-Encoding have been deployed, these concerns have
+     been allayed.  With this document, Binary ESMTP is expected to become
+     standards-track.
+
+  Table of Contents
+
+  1.   OVERVIEW ..........................................................2
+  2.   FRAMEWORK FOR THE LARGE MESSAGE EXTENSIONS ........................3
+  3.   FRAMEWORK FOR THE BINARY SERVICE EXTENSION ........................5
+  4.   EXAMPLES ..........................................................7
+    4.1  Simple Chunking .................................................7
+    4.2  Pipelining Binarymime ...........................................8
+  5.   SECURITY CONSIDERATIONS ...........................................9
+  6.   ACKNOWLEDGMENTS ...................................................9
+  7.   REFERENCES ........................................................9
+  8.   COPYRIGHT NOTICE ..................................................9
+  9.   AUTHOR'S ADDRESS .................................................10
+  10.  APPENDIX A - CHANGES FROM RFC1830 ................................11
+
+
+  1. Overview
+
+     The MIME extensions to the Internet message protocol provides for the
+     transmission of many kinds of data that was previously unsupported in
+     Internet mail.  Anticipating the need to more efficiently transport
+     the new media made possible with MIME, the SMTP protocol has been
+     extended to provide transport for new message types.  RFC 1426 defines
+     one such extension for the transmission of unencoded 8-bit MIME
+     messages [8BIT].  This service extension permits the receiver SMTP to
+     declare support for 8-bit body parts and the sender to request 8-bit
+     transmission of a particular message.
+
+     One expected result of the use of MIME is that the Internet mail
+     system will be expected to carry very large mail messages.  In such
+     transactions, there is a performance-based desire to eliminate the
+     requirement that the message be scanned for "CR LF . CR LF" sequences
+     upon sending and receiving to detect the end of message.
+
+     Independent of the need to send large messages, Internet mail is
+     increasingly multi-media.  There is a need to avoid the overhead of
+     base64 and quoted-printable encoding of binary objects sent using the
+     MIME message format over SMTP between hosts that support binary
+     message processing.
+
+     This memo uses the mechanism defined in [ESMTP] to define two
+     extensions to the SMTP service whereby a client ("sender-SMTP") may
+
+     Vaudreuil                Expires 5/1/00                    [Page 2]
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+     declare support for the message chunking transmission mode and support
+     for the receiption of Binary messages.
+
+  2. Framework for the Large Message Extensions
+
+     The following service extension is hereby defined:
+
+     The name of the data chunking service extension is "CHUNKING".
+
+     The EHLO keyword value associated with this extension is "CHUNKING".
+
+     A new SMTP verb is defined "BDAT" as an alternative to the "DATA"
+     command of [RFC821]. The BDAT verb takes two arguments.  The first
+     argument indicates the length, in octets, of the binary data chunk.
+     The second optional argument indicates that the data packet is the
+     last.
+
+        bdat-cmd   ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
+        chunk-size ::= 1*DIGIT
+        end-marker ::= "LAST"
+
+     The CHUNKING service extension enables the use of the BDAT alternative
+     to the DATA command.  This extension can be used for any message,
+     whether 7 bit, 8BITMIME or BINARYMIME.
+
+     When a client SMTP wishes to submit (using the MAIL command) a large
+     message using the CHUNKING extension, it first issues the EHLO command
+     to the server SMTP.  If the server SMTP responds with code 250 to the
+     EHLO command and the response includes the EHLO keyword value
+     CHUNKING, then the server SMTP is indicating that it supports the BDAT
+     command and will accept the sending of messages in chunks.
+
+     After all MAIL FROM and RCPT TO responses are collected and processed,
+     the message is sent using a series of BDAT commands.  The BDAT command
+     takes one required argument, the exact length of the data segment in
+     octets.  The message data is sent immediately after the trailing <CR>
+     <LF> of the BDAT command line.  Once the receiver-SMTP receives the
+     specified number of octets, it will return a 250 reply code.
+
+     The optional LAST parameter on the BDAT command indicates that this is
+     the last chunk of message data to be sent.  Any BDAT command sent
+     after the BDAT LAST is illegal and must be replied to with a 503 "Bad
+     sequence of commands" reply code. The state resulting from this error
+     is indeterminate.  A RSET command must be sent to clear the
+     transaction before continuing.
+
+     A 250 response should be sent to each BDAT data block.  If a failure
+     ocures after a BDAT command is received, the receiver-SMTP must accept
+     and discard the associated message data before sending the 5XX code.
+     If a 5XX code is received by the sender-SMTP in response to a BDAT
+     chunk, the message should be considered failed and the sender SMTP
+     must not send any additional BDAT segments. If the receiver-SMTP has
+     declared support for streaming, the receiver SMTP must be prepared to
+
+
+     Vaudreuil                Expires 5/1/00                    [Page 3]
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+     accept and discard additional BDAT chunks already in the pipeline
+     after the failed BDAT.
+
+          Note: An error on the receiver-SMTP such as disk full or imminent
+          shutdown can only be reported after the BDAT segment has been
+          received.  It is therefore important to choose a reasonable chunk
+          size given the expected end-to-end bandwidth.
+
+          Note:  Because the receiver-SMTP does not acknowledge the BDAT
+          command before the messafge data is sent, it is important to send
+          the BDAT only to systems that have declared their capability to
+          accept BDAT commands. Illegally sending a BDAT command and
+          associated message data to a non-chunking capable system will
+          result in the receiver-SMTP parsing the associated message data
+          as if it were a potentially very long, binary-data containing
+          E/SMTP command line.
+
+     The resulting state from a failed BDAT command is indeterminate.  A
+     RSET command must be issued to clear the transaction before additional
+     commands may be sent. The RSET command, when issued after the first
+     BDAT and before the BDAT LAST, clears all segments sent during that
+     transaction and resets the session.
+
+     DATA and BDAT commands cannot be used in the same transaction.  If a
+     DATA statement is issued after a BDAT for the current transaction, a
+     503 "Bad sequence of commands" must be issued.  The state resulting
+     from this error is indeterminate.  A RSET command must be sent to
+     clear the transaction before continuing.  There is no prohibition on
+     using DATA and BDAT in the same session, so long as they are not mixed
+     in the same transaction.
+
+     The local storage size of a message may not accurately reflect the
+     actual size of the message sent due to local storage conventions.  In
+     particular, text messages sent with the BDAT command MUST be sent in
+     the canonical MIME format with lines delimited with a <CR><LF>.  It
+     may not be possible to convert the entire message to the canonical
+     format at once. Chunking provides a mechanism to convert the message
+     to canonical form, accurately count the bytes, and send the message a
+     single chunk at a time.
+
+          Note that correct byte counting is essential.  If the sender
+          SMTP indicates a chunk-size larger than the actual chunnk-size,
+          the receiver SMTP will continue to wait for the remainder of the
+          data or when using streaming, will read the subsequent command
+          as additional message data.  In the case where a portion of the
+          previous command was read as data, the parser will return a
+          syntax error when the incomplete command is read.
+
+          If the sender SMTP indicates a chunk-size smaller than the
+          actual chunk-size, the receiver SMTP will interpret the
+          remainder of the message data as invalid commands.  Note that
+          the remainder of the message data may be binary and as such
+          lexicographical parsers must be prepared to receive, process,
+          and reject lines of arbitrary octets.
+
+     Vaudreuil                Expires 5/1/00                    [Page 4]
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+  3. Framework for the Binary Service Extension
+
+     The following service extension is hereby defined:
+
+     1) The name of the binary service extension is "BINARYMIME".
+
+     2) The EHLO keyword value associated with this extension is
+     "BINARYMIME".
+
+     3) The BINARYMIME service extension can only be used with the
+     "CHUNKING" service extension.
+
+     4) No parameter is used with the BINARYMIME keyword.
+
+     5) [8BIT] defines the BODY parameter for the MAIL command.  This
+     extension defines an additional value for the BODY parameter,
+     "BINARYMIME". The value "BINARYMIME" associated with this parameter
+     indicates that this message is a Binary MIME message (in strict
+     compliance with [MIME]) with arbitrary octet content being sent. The
+     revised syntax of the value is as follows, using the ABNF notation of
+     [RFC822]:
+
+                 body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
+
+     6) No new verbs are defined for the BINARYMIME extension.
+
+     A sender SMTP may request that a binary MIME message be sent without
+     transport encoding by sending a BINARYMIME parameter with the MAIL
+     command.  When the receiver SMTP accepts a MAIL FROM command with the
+     BINARYMIME body type requested, it agrees to preserve all bits in each
+     octet passed using the BDAT command.
+
+     BINARYMIME cannot be used with the DATA command.  If a DATA command is
+     issued after a MAIL command containing the body-value of "BINARYMIME",
+     a 501 response should be sent.  The resulting state from this error
+     condition is indeterminate and the transaction should be reset with
+     the RSET command.
+
+     It is important to note that when using BINARYMIME, it is especially
+     important to ensure that the MIME message itself is properly formed.
+     In particular, it is essential that text be canonically encoded with
+     each line properly terminated with <CR> <LF>.  Any transformation of
+     text into non-canonical MIME to observe local storage conventions must
+     be reversed before sending as BINARYMIME.  Some line-oriented
+     shortcuts will break if used with BINARYMIME.
+
+     The syntax of the extended MAIL command is identical to the MAIL
+     command in [RFC821], except that a BODY parameter must appear after
+     the address.  The complete syntax of this extended command is defined
+     in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-value
+     is given by the syntax for body-value in [ESMTP].
+
+
+
+
+     Vaudreuil                Expires 5/1/00                    [Page 5]
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+     If a receiver-SMTP does not indicate support the BINARYMIME message
+     format then the client SMTP must not, under any circumstances, send
+     binary data using the BDAT command.
+
+     If the receiver-SMTP does not support BINARYMIME and the message
+     content is a MIME object with a binary encoding, a client SMTP has two
+     options with which to forward the message.  First, it may implement a
+     gateway transformation to convert the message into valid 7bit-encoded
+     MIME.  Second, it may treat this as a permanent error and handle it in
+     the usual manner for delivery failures.  The specifics of the
+     transformation from Binary MIME to 7bit MIME are not described by this
+     RFC; the conversion is nevertheless constrained in the following ways:
+
+     1.        The conversion must cause no loss of information; MIME transport
+       encodings must be employed as needed to insure this is the case.
+
+     2.        The resulting message must be valid 7bit MIME.  In particular, the
+       transformation may not result in nested Base-64 or Quoted-Printable
+       content-transfer-encodings.
+
+     As of present there are no mechanisms for converting a binary MIME
+     object into an 8-bit MIME object.  Such a transformation will require
+     the specification of a new MIME content-transfer-encoding, the
+     standardization of which is discouraged by [MIME].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                    [Page 6]
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+  4. Examples
+
+  4.1 Simple Chunking
+
+     The following simple dialogue illustrates the use of the large message
+     extension to send a short psudo-RFC822 message to one recipient using
+     the CHUNKING extension:
+
+     R: <wait for connection on TCP port 25>
+     S: <open connection to server>
+     R: 220 cnri.reston.va.us SMTP service ready
+     S: EHLO ymir.claremont.edu
+     R: 250-cnri.reston.va.us says hello
+     R: 250 CHUNKING
+     S: MAIL FROM:<Sam@Random.com>
+     R: 250 <Sam@Random.com> Sender ok
+     S: RCPT TO:<Susan@Random.com>
+     R: 250 <Susan@random.com> Recipient ok
+     S: BDAT 86 LAST
+     S: To: Susan@random.com<CR><LF>
+     S: From: Sam@random.com<CR><LF>
+     S: Subject: This is a bodyless test message<CR><LF>
+     R: 250 Message OK, 86 octets received
+     S: QUIT
+     R: 221 Goodbye
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                    [Page 7]
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+  4.2 Pipelining Binarymime
+
+     The following dialogue illustrates the use of the large message
+     extension to send a BINARYMIME object to two recipients using the
+     CHUNKING and PIPELINING extensions:
+
+     R: <wait for connection on TCP port
+     S: <open connection to server>
+     R: 220 cnri.reston.va.us SMTP service ready
+     S: EHLO ymir.claremont.edu
+     R: 250-cnri.reston.va.us says hello
+     R: 250-PIPELINING
+     R: 250-BINARYMIME
+     R: 250 CHUNKING
+     S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME
+     S: RCPT TO:<gvaudre@cnri.reston.va.us>
+     S: RCPT TO:<jstewart@cnri.reston.va.us>
+     R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
+     R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
+     R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
+     S: BDAT 100000
+     S: (First 10000 octets of canonical MIME message data)
+     S: BDAT 324 LAST
+     S: (Remaining 324 octets of canonical MIME message data)
+     R: 250 100000 bytes received
+     R: 250 Message OK, 100324 octets received
+     S: QUIT
+     R: 221 Goodbye
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                    [Page 8]
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+  5. Security Considerations
+
+     This extension is not known to present any security issues already
+     endemic in electronic mail and present in fully conforming
+     implementations of [RFC821], or otherwise made possible by [MIME].
+
+  6. Acknowledgments
+
+     This protocol is the result of numerous discussions in the IETF SMTP
+     Extensions Working Group and in particular due to the continued
+     advocacy of "chunking" by Neil Katin.
+
+  7. References
+
+     [BINARY] Vaudreuil, G, " SMTP Service Extensions for Transmission of
+     Large and Binary MIME Messages", RFC 1830, August 1995.
+
+     [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+     USC/Information Sciences Institute, August 1982.
+
+     [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
+     Messages", STD 11, RFC 822, UDEL, August 1982.
+
+     [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+     Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
+     2045, Bellcore, Innosoft, November 1996.
+
+     [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+     E., and D. Crocker, "SMTP Service Extensions" RFC 1869, United Nations
+     University, Innosoft International, Inc., Dover Beach Consulting,
+     Inc., Network Management Associates, Inc., The Branch Office, November
+     1995.
+
+     [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+     E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport"
+     RFC 1652, United Nations University, Innosoft International, Inc.,
+     Dover Beach Consulting, Inc., Network Management Associates, Inc., The
+     Branch Office, July 1994.
+
+     [PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining",
+     RFC 1854, Innosoft International, October 1995.
+
+  8. Copyright Notice
+
+     "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
+
+     Vaudreuil                Expires 5/1/00                    [Page 9]
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+     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."
+
+  9. Author's Address
+
+     Gregory M. Vaudreuil
+     Lucent Technologies
+      Communications Application Group
+     17080 Dallas Parkway
+     Dallas, TX 75248-1905
+     Voice/Fax: +1-972-733-2722
+
+     GregV@Lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                   [Page 10]
+
+
+
+     Internet Draft            Binary ESMTP             December 1, 1999
+
+
+  10. Appendix A - Changes from RFC1830
+
+     Numerous editorial changes including required intellectual property
+     boilerplate and revised authors contact information
+
+     Corrected the simple chunking example to use the correct number of
+     bytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     Vaudreuil                Expires 5/1/00                   [Page 11]
+
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ward-esmtp-slide-03.txt b/Documentation/en/I-D/draft-ward-esmtp-slide-03.txt
new file mode 100644
index 00000000..065f9c60
--- /dev/null
+++ b/Documentation/en/I-D/draft-ward-esmtp-slide-03.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+                                                             A. Ward
+INTERNET-DRAFT
+Category:  Experimental                                 15 June 2000
+draft-ward-esmtp-slide-03.txt            Exprires:  15 December 2000
+
+
+
+             SMTP Service Extension for Slightly Differing
+                       Multicast Messages (SLIDE)
+
+
+
+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.
+
+i. Revision History
+
+   The first version (-00) of this document was unleashed on 9 March
+   2000.
+
+   (-01)  Added section (5.1), regarding the impact of the SLIDE
+   extension to signed or encrypted messages.  Modified the first
+   example in section (4.) to make the impact of SLIDE more explicit. (7
+   April 2000)
+
+   (-02)  Added examples to section (5.1.1) and section (5.1.2). (4 May
+   2000)
+
+   (-03)  Minor formatting changes to comply with RFC 2223. (15 June
+   2000)
+
+
+
+Ward                                                            [Page 1]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          15 June 2000
+
+
+Abstract
+
+   This memo defines an extension to the SMTP service [Klensin, et al
+   1995] to realize efficiency improvements in the relaying and delivery
+   of slightly differing messages bound for more than one recipient, as
+   specified by multiple RCPT TO commands [Postel 1982].
+
+0. 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 RFC 2119 [Bradner
+   1997].
+
+1. Introduction
+
+   SMTP is an Internet message protocol that is used to send messages to
+   one or more recipients.  To realize any efficiency when sending a
+   message to multiple recipients, the message body and all headers must
+   be identical.  It is desirable, under some circumstances, to send
+   messages to multiple recipients that differ only slightly in their
+   body and/or headers.
+
+   Under SMTP [Postel 1982] such a scenario would result in a different
+   message being sent from the initial client SMTP through each relay
+   server until the final server SMTP is reached.  In situations where
+   more that one of the multiple recipients have mail handled by the
+   same server SMTP, a significant bandwidth reduction can be realized
+   with the SLIDE service extension.
+
+2. Framework for the Slightly Differing Multicast Message Extension
+
+   The slightly differing multicast message extension is as follows:
+
+   (1) the name of the SMTP service extension defined here is slightly-
+   differing-multicast-message;
+
+   (2) the EHLO keyword value associated with the extension is SLIDE;
+
+   (3) no parameter is used with the SLIDE EHLO keyword;
+
+   (4) no additional SMTP verbs are defined by this extension
+
+   (5) one optional parameter using the keyword SLIDERANGE is added to
+   the RCPT TO command.  The value associated with this parameter is a
+   comma-delimited list of octet ranges indicating which pieces of the
+   overall message SHOULD be delivered to the specified recipient.  The
+   syntax for the value follows, using the ABNF notation of [Crocker
+
+
+
+Ward                                                            [Page 2]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          15 June 2000
+
+
+   1982]:
+
+   sliderange-value ::= octet-range *( "," octet-range )
+
+   octet-range ::= octet-address [ "-" octet-address ]
+
+   octet-address ::= DIGIT *(DIGIT)
+
+   DIGIT ::= <any one of the 10 numeric characters (0 through 9)>
+
+   (6) the next section specifies how support for the extension affects
+   the behaviour of a server and client SMTP; and,
+
+   (7) the maximum length of a RCPT TO command line is increased by 256
+   characters by the possible addition of the SLIDERANGE keyword and
+   value.  Of course, since the value could conceivably be longer than
+   256 characters, implementations are welcome to allot more space for
+   this purpose.
+
+3. The slightly-differing-multicast-message Service Extension
+
+   3.1 Effects on the Client SMTP
+
+      When a client SMTP wishes to submit (using the MAIL command)
+      messages with slightly different content to recipients at the same
+      server SMTP, it first issues the EHLO command to the server SMTP.
+      If the server SMTP responds with code 250 to the EHLO command, and
+      the response includes the EHLO keyword value SLIDE, then the
+      server SMTP is indicating that it supports the extended RCPT
+      command.  Such a server SMTP will accept a message containing the
+      combined contents of the slightly differing messages addressed to
+      all of the recipients for delivery.  The method for combining the
+      various message bodies (and interpreting combined message bodies)
+      is described in the next section.
+
+      The extended RCPT command is issued by a client SMTP when it
+      wishes to transmit part of a combined message body to the
+      specified recipient.  The syntax for this command is identical to
+      the RCPT command in [Postel 1982], except that a SLIDERANGE
+      parameter must appear after the address.  Multiple SLIDERANGE
+      parameters may be used in a single RCPT command; however, in such
+      a case, the values of the several parameters SHOULD be combined
+      into a single, continuous, comma-delimited list of octet ranges.
+
+      The value associated with the SLIDERANGE parameter lists which
+      octets in the impending DATA command are to be sent to the
+      specified recipient.
+
+
+
+
+Ward                                                            [Page 3]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          15 June 2000
+
+
+   3.2 Effects on the Server SMTP
+
+      A server SMTP which supports the slightly differing multicast
+      message service extension SHOULD relay only those octets bound for
+      recipients at a particular domain to the mail exchange for that
+      domain.  If this suggested message trimming occurs, the octets
+      specified in the SLIDERANGE parameter for each recipient MUST be
+      adjusted to correspond with the changes to the message DATA.
+
+      The final 5 octets of the message DATA (<CR><LF>.<CR><LF>) MUST
+      always be relayed, even if not explicitly specified in the
+      SLIDERANGE parameter value.
+
+      Once a server SMTP supporting the slightly differing multicast
+      message service extension accepts a message for which any
+      recipient has a non-trivial SLIDERANGE parameter value, the server
+      SMTP MUST deliver or relay the message in such a way as to ensure
+      that only the octets specified for a particular recipient will be
+      received by that recipient.  As well, when the server SMTP is
+      relaying the message, it SHOULD attempt to minimize the number of
+      octets that are relayed to each downstream server SMTP.
+
+4. Usage Examples
+
+   The following dialogue illustrates the use of the slightly differing
+   multicast message service extension:
+
+   S: <wait for connection>
+   C: <open connection to server>
+   S: 220 anstruther.elsewhere.com SMTP ready
+   C: EHLO burleigh.uwaterloo.ca
+   S: 250-hello burleigh.uwaterloo.ca
+   S: 250 SLIDE
+   C: MAIL FROM:<andrew@burleigh.uwaterloo.ca>
+   S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay
+   C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-322
+   S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay
+   C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-272,320-322
+   S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay
+   C: DATA
+   S: 354 octets beyond 323 will not be relayed, end with CRLF.CRLF
+   C: Message-ID: <1234.abcd@uwaterloo.ca>
+   C: Date: Mon, 03 Apr 2000 12:05:10 -0400
+   C: From: Andrew <andrew@burleigh.uwaterloo.ca>
+   C: To: Ed <ed@elsewhere.com>
+   C: To: Doug <doug@elsewhere.com>
+   C: Subject: special message
+   C:
+
+
+
+Ward                                                            [Page 4]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          15 June 2000
+
+
+   C: this is the message body for a special message
+   C:
+   C: enjoy, andrew
+   C:
+   C: ps. this is a secret that Doug doesn't know
+   C: .
+   S: 250 okay
+   C: QUIT
+   S: 250 bye bye
+
+   This transaction would result in ed@elsewhere.com receiving the
+   message:
+
+   Message-ID: <1234.abcd@uwaterloo.ca>
+   Date: Mon, 03 Apr 2000 12:05:10 -0400
+   From: Andrew <andrew@burleigh.uwaterloo.ca>
+   To: Ed <ed@elsewhere.com>
+   Subject: special message
+
+   this is the message body for a special message
+
+   enjoy, andrew
+
+   ps. this is a secret that Doug doesn't know
+   .
+
+   while doug@elsewhere.com would receive:
+
+   Message-ID: <1234.abcd@uwaterloo.ca>
+   Date: Mon, 03 Apr 2000 12:05:10 -0400
+   From: Andrew <andrew@burleigh.uwaterloo.ca>
+   To: Doug <doug@elsewhere.com>
+   Subject: special message
+
+   this is the message body for a special message
+
+   enjoy, andrew
+   .
+
+   The following dialogue illustrates the efficiencies that can be
+   realized in a relaying scenario:
+
+   S1: 220 one.there.com SMTP ready
+   C0: EHLO zero.here.com
+   S1: 250-hello zero.here.com
+   S1: 250 SLIDE
+   C0: MAIL FROM:<me@here.com>
+   S1: 250 <me@here.com>... sender okay
+
+
+
+Ward                                                            [Page 5]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          15 June 2000
+
+
+   C0: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250
+   S1: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199
+   S1: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<laurene@everywhere.com> SLIDERANGE=0-250
+   S1: 250 <laurene@everywhere.com>... recipient and SLIDERANGE okay
+   C0: RCPT TO:<rachael@elsewhere.com>
+   S1: 250 <rachael@elsewhere.com>... recipient okay
+   C0: DATA
+   S1: 354 okay, send message body, end with CRLF.CRLF
+   C0: ...<1000 octets of message>...
+   C0: .
+   S1: 250 okay
+   C0: QUIT
+   S1: 250 bye bye
+    ...
+   S2: 220 two.everywhere.com SMTP ready
+   C1: EHLO one.there.com
+   S2: 250-hello one.there.com
+   S2: 250 SLIDE
+   C1: MAIL FROM:<me@here.com>
+   S2: 250 <me@here.com>... sender okay
+   C1: RCPT TO:<ed@everywhere.com> SLIDERANGE=0-150,200-250
+   S2: 250 <ed@everywhere.com>... recipient and SLIDERANGE okay
+   C1: RCPT TO:<doug@everywhere.com> SLIDERANGE=0-199
+   S2: 250 <doug@everywhere.com>... recipient and SLIDERANGE okay
+   C1: RCPT TO:<laurene@everywhere.com>
+   S2: 250 <laurene@everywhere.com>... recipient okay
+   C1: DATA
+   S2: 354 okay, send message body, end with CRLF.CRLF
+   C1: ...<octets 0 to 250 of message>...
+   C1: .
+   S2: 250 okay
+   C1: QUIT
+   S2: 250 bye bye
+    ...
+   S3: 220 three.elsewhere.com SMTP ready
+   C1: EHLO one.there.com
+   S3: 250-hello one.there.com
+   S3: 250 SLIDE
+   C1: MAIL FROM:<me@here.com>
+   S3: 250 <me@here.com>... sender okay
+   C1: RCPT TO:<rachael@elsewhere.com>
+   S3: 250 <rachael@elsewhere.com>... recipient okay
+   C1: DATA
+   S3: 354 okay, send message body, end with CRLF.CRLF
+   C1: ...<all octets of message>...
+   C1: .
+
+
+
+Ward                                                            [Page 6]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          15 June 2000
+
+
+   S3: 250 okay
+   C1: QUIT
+   S3: 250 bye bye
+
+5. Security Considerations
+
+   This extension takes some of the "final control" over the message
+   body out of the hands of the client, and places it on the server
+   SMTPs that are charged with relaying and delivering the message.
+   While any server SMTP has access to change the content of a message
+   that it relays or delivers, a server SMTP that supports the slightly
+   differing multicast message service extension is obliged to be able
+   to alter a message that takes advantage of this extension.  As a
+   result of the increased handling by the server SMTP, there is more
+   room for error in the message transmission.
+
+   5.1 Impact on Signed and Encrypted Messages
+
+      Messages that are transferred between a client SMTP and a server
+      SMTP over a secure channel such as SSL or TLS should not be
+      adversely affected by the SLIDE extension.
+
+      Things get messy when it comes to signing or encrypting the
+      message data (all or part of the information sent to the server
+      SMTP following a 354 response to the DATA command).  Two
+      alternatives are suggested in section (5.1.1) and section (5.1.2).
+      A client SMTP may implement either method, as both methods can be
+      used transparently to all other nodes in the chain of relays
+      (including the final server SMTP node).
+
+      5.1.1 Piecewise Signing and Encryption
+
+         With this method, the initial client SMTP may sign or encrypt
+         each separate range of bytes (or part thereof), as defined by
+         the various SLIDERANGE values.
+
+         As an example, consider the piecewise approach as applied to
+         the first usage example presented in section 4.
+
+         S: <wait for connection>
+         C: <open connection to server>
+         S: 220 anstruther.elsewhere.com SMTP ready
+         C: EHLO burleigh.uwaterloo.ca
+         S: 250-hello burleigh.uwaterloo.ca
+         S: 250 SLIDE
+         C: MAIL FROM:<andrew@burleigh.uwaterloo.ca>
+         S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay
+         C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-727
+
+
+
+Ward                                                            [Page 7]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          15 June 2000
+
+
+         S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay
+         C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-483,725-727
+         S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay
+         C: DATA
+         S: 354 octets beyond 728 will not be relayed, end with CRLF.CRLF
+         C: Message-ID: <1234.abcd@uwaterloo.ca>
+         C: Date: Mon, 03 Apr 2000 12:05:10 -0400
+         C: From: Andrew <andrew@burleigh.uwaterloo.ca>
+         C: To: Ed <ed@elsewhere.com>
+         C: To: Doug <doug@elsewhere.com>
+         C: Subject: special message
+         C:
+         C: -----BEGIN PGP SIGNED MESSAGE-----
+         C: Hash: SHA1
+         C:
+         C: this is the message body for a special message
+         C:
+         C: enjoy, andrew
+         C: -----BEGIN PGP SIGNATURE-----
+         C: Version: fakePGP v0.0
+         C:
+         C: aefiuh98ar7ehfpo34h9q83h4fp9q34h9a8efha9348hao
+         C: 98h5nbq3rub9a08ahfoi4no34=
+         C: -----END PGP SIGNATURE-----
+         C:
+         C: -----BEGIN PGP SIGNED MESSAGE-----
+         C: Hash: SHA1
+         C:
+         C: ps. this is a secret that Doug doesn't know
+         C: -----BEGIN PGP SIGNATURE-----
+         C: Version: fakePGP v0.0
+         C:
+         C: 98sdu9bd9fu4eiob3iovb9eb93buiou908fhv9sf
+         C: jlknsdfi0h93un=
+         C: -----END PGP SIGNATURE-----
+         C: .
+         S: 250 okay
+         C: QUIT
+         S: 250 bye bye
+
+
+      5.1.2 Component Message Signing
+
+         This method creates a single signature for each distinct
+         message contained in a set of messages encoded using the SLIDE
+         extension.  During encoding of the SLIDE message, each
+         component message that needs to be signed can have a signature
+         generated for it before the component messages are SLIDE
+
+
+
+Ward                                                            [Page 8]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          15 June 2000
+
+
+         encoded.
+
+         It is important to note that in most (if not all) cases this
+         will not work for encryption, as the same text in the
+         unencrypted component messages will not generate the same
+         encrypted group of octets.
+
+         As an example, consider the component message approach as
+         applied to the first usage example presented in section 4.
+
+         S: <wait for connection>
+         C: <open connection to server>
+         S: 220 anstruther.elsewhere.com SMTP ready
+         C: EHLO burleigh.uwaterloo.ca
+         S: 250-hello burleigh.uwaterloo.ca
+         S: 250 SLIDE
+         C: MAIL FROM:<andrew@burleigh.uwaterloo.ca>
+         S: 250 <andrew@burleigh.uwaterloo.ca>... sender okay
+         C: RCPT TO:<ed@elsewhere.com> SLIDERANGE=0-148,180-322,484-677
+         S: 250 <ed@elsewhere.com>... recipient and SLIDERANGE okay
+         C: RCPT TO:<doug@elsewhere.com> SLIDERANGE=0-121,149-483,675-677
+         S: 250 <doug@elsewhere.com>... recipient and SLIDERANGE okay
+         C: DATA
+         S: 354 octets beyond 678 will not be relayed, end with CRLF.CRLF
+         C: Message-ID: <1234.abcd@uwaterloo.ca>
+         C: Date: Mon, 03 Apr 2000 12:05:10 -0400
+         C: From: Andrew <andrew@burleigh.uwaterloo.ca>
+         C: To: Ed <ed@elsewhere.com>
+         C: To: Doug <doug@elsewhere.com>
+         C: Subject: special message
+         C:
+         C: -----BEGIN PGP SIGNED MESSAGE-----
+         C: Hash: SHA1
+         C:
+         C: this is the message body for a special message
+         C:
+         C: enjoy, andrew
+         C: -----BEGIN PGP SIGNATURE-----
+         C: Version: fakePGP v0.0
+         C:
+         C: nsdf9n934nioq3j4un9ua9fvuerh98h43n9ae8u85
+         C: 34kjfbna9ea9e8rb8d9sd0ge3=
+         C: -----END PGP SIGNATURE-----
+         C:
+         C: ps. this is a secret that Doug doesn't know
+         C: -----BEGIN PGP SIGNATURE-----
+         C: Version: fakePGP v0.0
+         C:
+
+
+
+Ward                                                            [Page 9]
+
+INTERNET-DRAFT        SMTP Service Extension SLIDE          15 June 2000
+
+
+         C: ikbdfv98u4bka8rhi34ubkq3828756bkjai7rf7
+         C: 1kj3k4jnkj3kjk3=
+         C: -----END PGP SIGNATURE-----
+         C: .
+         S: 250 okay
+         C: QUIT
+         S: 250 bye bye
+
+
+6. Acknowledgements
+
+   Thanks to Ed, Doug, Laurene and Rachael for their (unwilling)
+   participation in the usage examples.  Thanks to Dan Wing for his
+   suggested improvements in usage examples and security considerations.
+
+7. References
+
+   [Bradner 1997]  Bradner, S.  "Key words for use in RFCs to Indicate
+   Requirement Levels", BCP 14, RFC 2119.  March 1997.
+
+   [Crocker 1982]  Crocker, D.  "Standard for the Format of ARPA
+   Internet Text Messages", STD 11, RFC 822.  UDEL, August 1982.
+
+   [Klensin, et al 1995]  Klensin, J., N. Freed, M. Rose, E. Stefferud,
+   and D. Crocker.  "SMTP Service Extensions", STD 10, RFC 1869.
+   November 1995.
+
+   [Postel 1982]  Postel, J.  "Simple Mail Transfer Protocol", STD 10,
+   RFC 821.  USC/Information Sciences Institute, August 1982.
+
+8. Author's Address
+
+   Andrew Ward
+   70 Gruhn Street
+   Kitchener, ON  N2G 1S6
+   CANADA
+
+   Phone:  +1 519 581 1201
+   EMail:  amward@uwaterloo.ca
+
+
+
+                        EXPIRES:  15 December 2000
+
+
+
+
+
+
+
+
+Ward                                                           [Page 10]
+
diff --git a/Documentation/en/I-D/draft-wing-smtp-capabilities-00.txt b/Documentation/en/I-D/draft-wing-smtp-capabilities-00.txt
new file mode 100644
index 00000000..5b82588a
--- /dev/null
+++ b/Documentation/en/I-D/draft-wing-smtp-capabilities-00.txt
@@ -0,0 +1,4 @@
+
+This Internet-Draft <draft-wing-smtp-capabilities-00.txt> 
+has been replaced by
+another Internet-Draft <draft-ietf-fax-smtp-capabilities-00.txt>