nuke obsolete I-D

3 files changed, 28 insertions, 1790 deletions

diff --git a/Documentation/en/I-D/.remove_obsolete.pl b/Documentation/en/I-D/.remove_obsolete.pl
new file mode 100755
index 00000000..965f6349
--- /dev/null
+++ b/Documentation/en/I-D/.remove_obsolete.pl
@@ -0,0 +1,28 @@
+#!/usr/bin/env perl
+#
+# $FML$
+#
+
+use strict;
+use Carp;
+
+my $prev = '';
+for my $cur (sort <draft*txt>) {
+    if (compare($prev, $cur)) {
+	print "cvs remove $prev\n";
+    }
+
+    $prev = $cur;
+}
+
+
+sub compare
+{
+    my ($a, $b) = @_;
+    my ($ta, $tb, $xa, $xb);
+
+    if ($a =~ /(.*)\-\d+(\d)\.txt/) { $ta = $1; $xa = $2;}
+    if ($b =~ /(.*)\-\d+(\d)\.txt/) { $tb = $1; $xb = $2;}
+
+    return (($ta eq $tb) && ($xb - $xa) == 1) ? 1 : 0;
+}
diff --git a/Documentation/en/I-D/draft-ietf-fax-smtp-session-02.txt b/Documentation/en/I-D/draft-ietf-fax-smtp-session-02.txt
deleted file mode 100644
index 24152a6b..00000000
--- a/Documentation/en/I-D/draft-ietf-fax-smtp-session-02.txt
+++ /dev/null
@@ -1,950 +0,0 @@
-
-Applications Area                                             Neil Joffe
-Internet Draft                                                  Dan Wing
-February 23, 1997                                          Cisco Systems
-Expires August 1998                                       Larry Masinter
-                                                       Xerox Corporation
-
-                       SMTP Service Extension for
-                           Immediate Delivery
-
-                   draft-ietf-fax-smtp-session-02.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 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.
-
-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 store-
-   and-forward.  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 August 1998                  [Page 1]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-Table of Contents
-
-   0.  Administrivia
-   0.1.  Changes Since Previous Versions
-   1.  Introduction
-   1.2.  Discussion of This Draft
-   1.3.  Requirements Notation
-   2.  Framework for Immediate Delivery Support
-   3.  Esmtp-keyword SESSION
-   3.1.  Delivery Responsibility
-   3.2.  Fallback to Store and Forward
-   3.2.1.  Non-Session Aware Mailers
-   3.2.1.  Excessive Delays with Multiple MTAs
-   3.3.  Sequence of Events and State Diagrams
-   3.3.1.  Events - Single Remote MTA
-   3.3.2.  Events - Multiple Remote MTAs
-   3.3.3.  State Diagram - SMTP client
-   3.3.4.  State Diagram - SMTP Server
-   3.3.5.  State diagram - MTA relay
-   4.  New SMTP Verb STAT
-   4.1.  Format of STAT Response
-   4.2.  Sequence of Events
-   4.3.  Timing Considerations
-   5.  Security Considerations
-   5.1.  Denial of Service
-   5.2.  Abuse of Immediate Delivery
-   6.  Examples
-   6.1.  Successful Session Delivery to Two Recipients
-   6.2.  Unsuccessful Session Delivery
-   6.3.  SMTP Client Disconnects Before Sending STAT
-   7.  Acknowledgments
-   8.  References
-   9.  Copyright
-   10.  Authors' Addresses
-
-0.  Administrivia
-
-0.1.  Changes Since Previous Versions
-
-   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 simple codes instead
-        of a multipart/report.
-
-      * STAT command polls for all recipients that had SESSION
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                  [Page 2]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-        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 [SMTP] 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.
-
-   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 [LMTP] provides immediate delivery, but as
-   discussed in [LMTP] can aggrevate the duplicate message delivery
-   problem [DUPLICATE], especially over a WAN.  The Session extension
-   described in this memo is intended to provide immediate delivery
-   of SMTP messages while avoiding aggrevating 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
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                  [Page 3]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   3.2.
-
-   Unlike the deprecated SAML, SOML and SEND commands (documented in
-   [SMTP] 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 [SMTP-EXT] 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 RFC 2119 [REQ].
-
-2.  Framework for Immediate Delivery Support
-
-   The immediate message delivery is defined as follows:
-
-       (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
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                  [Page 4]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   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
-   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.  Non-Session Aware Mailers
-
-   If an MTA is encountered which does not support the Session
-   extension, the MTA which detected this SHOULD respond with a 252
-   response code, and this MTA is responsible for performing normal
-   store-and-forward mail delivery to the non-Session aware mailer.
-
-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.
-
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                  [Page 5]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   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)
-
-   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 [CHUNKING]) command, then
-
-      7.  (B) would send the DATA (or BDAT) command to (C),
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                  [Page 6]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-          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
-          [CHUNKING]), 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.
-
-          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
-          [DUPLICATE].  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
-
-   In 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)
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                  [Page 7]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   (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.
-
-   XXX - is all this obvious, or should we describe it?
-
-3.3.3.  State Diagram - SMTP client
-
-   XXX
-
-3.3.4.  State Diagram - SMTP Server
-
-   XXX
-
-3.3.5.  State diagram - MTA relay
-
-   The following state diagram describes the behavior of an MTA relaying
-   Session connection.
-
-        |
-        V (1)
-      +---------+  (2)  +---------+
-      | Setup   |------>| Connect |
-      | message |<------| forward |
-      +---------+  (3)  +---------+
-        |
-        V (4)
-      +---------+ (5) +---------+ (6) +---------+ (7) +--------+
-      | Sending |---->| Waiting |---->| Gather  |---->| Query  |
-      |  data   |     |         |<----| status  |<----| status |
-      +---------+     +---------+ (9) +---------+ (8) +--------+
-                          |
-                          V (10)
-                        +----------+
-                        | Complete |
-                        +----------+
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                  [Page 8]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   (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.
-
-   (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
-
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                  [Page 9]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   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 (".").  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 [ABNF],
-   is:
-
-      stat-cmd = "STAT" CR LF
-
-4.1.  Format of STAT Response
-
-   The SMTP server's is making a 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 5xx responses.
-
-   The syntax of the positive response must be parsable by an SMTP
-   client.  Using the notation described in [ABNF], the syntax is:
-
-      stat-response  = *( "250-" [status-code SP] resp-line CR LF )
-                          "250 " [status-code SP] resp-line CR LF
-
-      resp-line      = forward-path SP session-status
-                       [SP "by" SP mta-hostname]
-
-      session-status = "delivered" /
-                       "in-progress" SP prog-value /
-                       "queued"
-
-      prog-value     = sent-count "/" total-count
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                 [Page 10]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-      sent-count     = 1*DIGIT
-
-      total-count    = 1*DIGIT
-
-      mta-hostname   = *( ALPHA / DIGIT / "." / "-" / "_" )
-
-      trans-id       = *( ALPHA / DIGIT / "." / "-" / "_" )
-
-      status-code    = <as defined in [SMTP-ENH-ERR]>
-
-      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.
-
-   "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.
-
-   "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.
-
-   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.
-
-   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 a 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 August 1998                 [Page 11]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-
-   XXX - we should probably describe behavior of STAT in more
-   detail
-
-   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 with establishing connections with each
-   MTA in the SMTP "path", SMTP servers that implement the Session
-   extension SHOULD also implement [SMTP-PIPE], 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
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                 [Page 12]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   the number of Session connections to/from certain hosts or
-   domains.
-
-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, masinter@parc.xerox.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 by fwall.cisco.com 5/184
-      S: 250 <njoffe@cisco.com> delivered by popstore.cisco.com 184/184
-      C: STAT
-      S: 250-<bill@fuggles.com> delivered by popmusic.xerox.com 184/184
-      S: 250 <njoffe@cisco.com> delivered by popstore.cisco.com 184/184
-      C: QUIT
-      S: 221 Goodbye
-
-6.2.  Unsuccessful Session Delivery
-
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                 [Page 13]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   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 pea.com 158/158
-      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
-      C: DATA
-      S: 354 Enter your data
-      C: From: Dan Wing <dwing@cisco.com>
-      C: To: masinter@parc.xerox.com
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                 [Page 14]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-      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), and Greg
-   Vaudreuil (Lucent) for their contributions to this work.
-
-8.  References
-
-   [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
-      Specifications:  ABNF", RFC 2234, November 1997.
-
-   [CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission of
-      Large and Binary MIME Messages", RFC 1830 (Experimental), August
-      1995.
-
-   [DSN] K. Moore, G. Vaudreuil, "An Extensible Message Format for
-      Delivery Status Notifications", RFC 1894, January 1996.
-
-   [DRUMS] J. Klensin, D. Mann, "Simple Mail Transfer Protocol",
-      Internet Draft, Work in Progress, draft-ietf-drums-smtpupd-??.txt.
-
-   [DUPLICATE] C. Partridge, "DUPLICATE MESSAGES AND SMTP", RFC 1047,
-      February 1988.
-
-   [HEADERS] J. Palme, "Common Internet Message Headers", RFC 2076,
-      February 1997.
-
-   [LMTP] J. Myers, "Local Mail Transfer Protocol", RFC 2033, October
-      1996.
-
-   [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement
-      Levels", BCP-14, RFC 2119, March 1997.
-
-   [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
-      and Support", RFC 1123, October 1989.
-
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                 [Page 15]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   [SMTP] J. Postel, "Simple Mail Transfer Protocol", STD-10, RFC 821,
-      August 1982.
-
-   [SMTP-ENH-ERR] N. Freed, "SMTP Service Extension for Returning
-      Enhanced Error Codes", RFC 2034, October 1996.
-
-   [SMTP-EXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker,
-      "SMTP Service Extensions", STD-10, RFC 1869, November 1995.
-
-   [SMTP-PIPE] N. Freed, "SMTP Service Extension for Command
-      Pipelining", RFC 2197, September 1997.  .in -5
-
-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.
-
-10.  Authors' Addresses
-
-   Dan Wing
-   Cisco Systems, Inc.
-   101 Cooper Street
-   Santa Cruz, CA 95060  USA
-
-
-
-
-Joffe, Wing, Masinter     Expires August 1998                 [Page 16]
-
-Internet Draft          SMTP Immediate Delivery            February 1998
-
-
-   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
-
-
-   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 August 1998                 [Page 17]
-
diff --git a/Documentation/en/I-D/draft-ietf-fax-smtp-session-03.txt b/Documentation/en/I-D/draft-ietf-fax-smtp-session-03.txt
deleted file mode 100644
index 4ca7a549..00000000
--- a/Documentation/en/I-D/draft-ietf-fax-smtp-session-03.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-Applications Area                                             Neil Joffe
-Internet Draft                                                  Dan Wing
-July 15, 1998                                              Cisco Systems
-Expires December 1998                                     Larry Masinter
-                                                       Xerox Corporation
-
-                       SMTP Service Extension for
-                           Immediate Delivery
-
-                   draft-ietf-fax-smtp-session-03.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 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), 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 store-
-   and-forward.  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 December 1998                 [Page 1]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-0.  Administrivia
-
-0.1.  Changes Since Previous Versions
-
-   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 [SMTP] 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.
-
-   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
-
-Joffe, Wing, Masinter    Expires December 1998                 [Page 2]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-   other messaging applications where immediate delivery and
-   confirmation of immediate delivery are requested.
-
-   The LMTP protocol [LMTP] provides immediate delivery, but as
-   discussed in [LMTP] can aggravate the duplicate message delivery
-   problem [DUPLICATE], 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
-   [SMTP] 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 [SMTP-EXT] 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 RFC 2119 [REQ].
-
-2.  Framework for Immediate Delivery Support
-
-   The immediate message delivery is defined as follows:
-
-       (1)  The name of the immediate extension is Session;
-
-       (2)  the EHLO keyword value associated with the immediate
-            extension is SESSION;
-
-Joffe, Wing, Masinter    Expires December 1998                 [Page 3]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-       (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
-   accepted responsibility for message delivery at this point.  See
-   the section "Sequence of Events" for details.
-
-3.2.  Fallback to Store and Forward
-
-Joffe, Wing, Masinter    Expires December 1998                 [Page 4]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-   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)
-
-   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
-
-Joffe, Wing, Masinter    Expires December 1998                 [Page 5]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-          (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 [CHUNKING]) 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
-          [CHUNKING]), 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.
-
-          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
-          [DUPLICATE].  It MUST generate a bounce message for the failed
-          local recipient(s), and the bounce SHOULD be in the format
-
-Joffe, Wing, Masinter    Expires December 1998                 [Page 6]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-          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)  +---------+
-      | Setup   |------>| Connect |
-      | message |<------| forward |
-      +---------+  (3)  +---------+
-        |
-        V (4)
-
-Joffe, Wing, Masinter    Expires December 1998                 [Page 7]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-      +---------+ (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.
-
-   (8)  Event:  Response to STAT command.
-        Test:   -
-        Action: Pass back as response to incoming STAT.  If status
-                indicates completion then close the downstream
-                connection.
-
-Joffe, Wing, Masinter    Expires December 1998                 [Page 8]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-   (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 [ABNF],
-   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
-   5xx responses.
-
-   The syntax of the positive response must be parsable by an SMTP
-   client.  Using the notation described in [ABNF], the syntax is:
-
-Joffe, Wing, Masinter    Expires December 1998                 [Page 9]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-      stat-response  = *( "250-" [status-code SP] resp-line CR LF )
-                          "250 " [status-code SP] resp-line CR LF
-
-      resp-line      = forward-path SP session-status
-                       [SP "by=" mta-hostname]
-
-      session-status = "delivered" [SP trans-id] /
-                       "in-progress" SP prog-value /
-                       "queued" [SP trans-id]
-
-      trans-id       = "trans=" transaction
-
-      prog-value     = sent-count "/" total-count
-
-      sent-count     = 1*DIGIT
-
-      total-count    = 1*DIGIT
-
-      mta-hostname   = *( ALPHA / DIGIT / "." / "-" / "_" )
-
-      transaction    = *( ALPHA / DIGIT / "." / "-" / "_" )
-
-      status-code    = <as defined in [SMTP-ENH-ERR]>
-
-      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
-                  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>.
-
-Joffe, Wing, Masinter    Expires December 1998                [Page 10]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-   <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.
-
-   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 [SMTP-PIPE], and SMTP clients SHOULD use
-
-Joffe, Wing, Masinter    Expires December 1998                [Page 11]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-   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.
-
-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>
-
-Joffe, Wing, Masinter    Expires December 1998                [Page 12]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-      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
-
-   (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
-
-Joffe, Wing, Masinter    Expires December 1998                [Page 13]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-      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
-      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.
-
-Joffe, Wing, Masinter    Expires December 1998                [Page 14]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-   The authors would like to thank Ned Freed (Innosoft), Graham Klyne
-   (Integralis), Keith Moore (University of Tennessee), and Greg
-   Vaudreuil (Lucent) for their contributions to this work.
-
-8.  References
-
-   [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
-      Specifications: ABNF", RFC 2234, November 1997.
-
-   [CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission of
-      Large and Binary MIME Messages", RFC 1830 (Experimental), August
-      1995.
-
-   [DRUMS] J. Klensin, D. Mann, "Simple Mail Transfer Protocol",
-      Internet Draft, Work in Progress, draft-ietf-drums-smtpupd-??.txt.
-
-   [DUPLICATE] C. Partridge, "DUPLICATE MESSAGES AND SMTP", RFC 1047,
-      February 1988.
-
-   [LMTP] J. Myers, "Local Mail Transfer Protocol", RFC 2033, October
-      1996.
-
-   [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement
-      Levels", BCP-14, RFC 2119, March 1997.
-
-   [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
-      and Support", RFC 1123, October 1989.
-
-   [SMTP] J. Postel, "Simple Mail Transfer Protocol", STD-10, RFC 821,
-      August 1982.
-
-   [SMTP-ENH-ERR] N. Freed, "SMTP Service Extension for Returning
-      Enhanced Error Codes", RFC 2034, October 1996.
-
-   [SMTP-EXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker,
-      "SMTP Service Extensions", STD-10, RFC 1869, November 1995.
-
-   [SMTP-PIPE] N. Freed, "SMTP Service Extension for Command
-      Pipelining", RFC 2197, September 1997.  .in -5
-
-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
-
-Joffe, Wing, Masinter    Expires December 1998                [Page 15]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-   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.  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
-
-Joffe, Wing, Masinter    Expires December 1998                [Page 16]
-
-Internet Draft          SMTP Immediate Delivery                July 1998
-
-   Fax:    +1 415 812 4333
-   Email:  masinter@parc.xerox.com
-
-Joffe, Wing, Masinter    Expires December 1998                [Page 17]