imported as reference, nuke obsolete ones

9 files changed, 2742 insertions, 969 deletions

diff --git a/Documentation/en/I-D/00_COMMIT_LIST b/Documentation/en/I-D/00_COMMIT_LIST
index 853d1b48..6de5968c 100644
--- a/Documentation/en/I-D/00_COMMIT_LIST
+++ b/Documentation/en/I-D/00_COMMIT_LIST
@@ -8,6 +8,7 @@ draft-bernstein-owner-hack-01.txt
 draft-bernstein-pirp-02.txt
 draft-bernstein-qmtp-01.txt
 draft-bernstein-qsbmf-02.txt
+draft-bose-smtp-integrity-00.txt
 draft-burger-vpim-cc-00.txt
 draft-burger-vpim-cc-01.txt
 draft-burger-vpim-pc-00.txt
@@ -20,6 +21,9 @@ draft-freed-bsmtp-02.txt
 draft-freed-smtp-pipe-00.txt
 draft-freed-smtp-pipe-01.txt
 draft-freed-smtp-pipeline-02.txt
+draft-hoffman-legis-smtp-banner-00.txt
+draft-hoffman-legis-smtp-banner-01.txt
+draft-hoffman-legis-smtp-banner-02.txt
 draft-hoffman-legis-smtp-banner-03.txt
 draft-hoffman-rfc2487bis-00.txt
 draft-hoffman-rfc2487bis-02.txt
@@ -32,6 +36,7 @@ draft-hoffman-smtp-ssl-07.txt
 draft-hoffman-smtp-ssl-08.txt
 draft-hoffman-smtp-ssl-09.txt
 draft-hoffman-smtp-ssl-10.txt
+draft-huitema-shipworm-00.txt
 draft-ietf-drums-smtpupd-06.txt
 draft-ietf-drums-smtpupd-07.txt
 draft-ietf-drums-smtpupd-08.txt
@@ -42,8 +47,12 @@ draft-ietf-drums-smtpupd-12.txt
 draft-ietf-drums-smtpupd-13.txt
 draft-ietf-fax-esmtp-conneg-00.txt
 draft-ietf-fax-smtp-capabilities-00.txt
+draft-ietf-fax-smtp-capabilities-01.txt
+draft-ietf-fax-smtp-session-02.txt
+draft-ietf-fax-smtp-session-03.txt
 draft-ietf-fax-smtp-session-04.txt
 draft-ietf-impp-datetime-00.txt
+draft-ietf-ipngwg-dns-discovery-analysis-00.txt
 draft-ietf-ldapbis-url-00.txt
 draft-ietf-mailext-mail-attributes-07.txt
 draft-ietf-msgtrk-model-00.txt
@@ -82,6 +91,7 @@ draft-ietf-vpim-pndn-01.txt
 draft-jones-msgtrk-def-00.txt
 draft-jones-msgtrk-def-01.txt
 draft-jones-msgtrk-def-02.txt
+draft-khanna-smtp-mail-transfer-reliability-00.txt
 draft-melnikov-esmtp-lang-00.txt
 draft-melnikov-smtp-lang-00.txt
 draft-melnikov-smtp-lang-01.txt
diff --git a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-00.txt b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-00.txt
deleted file mode 100644
index 1bddc91b..00000000
--- a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-00.txt
+++ /dev/null
@@ -1,151 +0,0 @@
-
-Internet Draft                              Paul Hoffman
-draft-hoffman-legis-smtp-banner-00.txt       Internet Mail Consortium
-August 25, 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.
-
-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.
-
-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.
-
-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]. Legislation that requires the server identify states or
-provinces should use "L=" followed by an officially-accepted abbreviation
-(if any) for the state or province name. 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] ISO 3166:1988, Codes for the representation of names of
-countries.
-
-8. Authors' Addresses
-
-Paul Hoffman
-Internet Mail Consortium
-127 Segre Place
-Santa Cruz, CA  95060
-(831) 426-9827
-phoffman@imc.org
-
-John Levine
-IECC
-PO Box 727
-Trumansburg, NY 14886
-johnl@iecc.com
-
-
diff --git a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-01.txt b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-01.txt
deleted file mode 100644
index bd4c59e7..00000000
--- a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-01.txt
+++ /dev/null
@@ -1,153 +0,0 @@
-
-Internet Draft                              Paul Hoffman
-draft-hoffman-legis-smtp-banner-01.txt      Internet Mail Consortium
-September 10, 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.
-
-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.
-
-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]. 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. 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] ISO 3166:1988, Codes for the representation of names of
-countries.
-
-8. Authors' Addresses
-
-Paul Hoffman
-Internet Mail Consortium
-127 Segre Place
-Santa Cruz, CA  95060
-(831) 426-9827
-phoffman@imc.org
-
-John Levine
-IECC
-PO Box 727
-Trumansburg, NY 14886
-johnl@iecc.com
-
diff --git a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-02.txt b/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-02.txt
deleted file mode 100644
index ea97e5fb..00000000
--- a/Documentation/en/I-D/draft-hoffman-legis-smtp-banner-02.txt
+++ /dev/null
@@ -1,162 +0,0 @@
-
-
-Internet Draft                              Paul Hoffman
-draft-hoffman-legis-smtp-banner-02.txt      Internet Mail Consortium
-November 5, 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.
-
-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]. 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. 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] ISO 3166:1988, Codes for the representation of names of
-countries.
-
-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-huitema-shipworm-00.txt b/Documentation/en/I-D/draft-huitema-shipworm-00.txt
new file mode 100644
index 00000000..cc926e39
--- /dev/null
+++ b/Documentation/en/I-D/draft-huitema-shipworm-00.txt
@@ -0,0 +1,922 @@
+INTERNET DRAFT                                              C. Huitema
+<draft-huitema-shipworm-00.txt>                              Microsoft            
+Expires January 12, 2001                                 July 12, 2001
+
+Shipworm: Tunneling IPv6 over UDP through NATs
+
+Status of this memo
+
+This document is an Internet-Draft and is in full conformance with 
+all provisions of Section 10 of RFC2026.
+
+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."
+
+The list of current Internet-Drafts can be accessed at 
+http://www.ietf.org/ietf/1id-abstracts.txt.
+
+The list of Internet-Draft Shadow Directories can be accessed at 
+http://www.ietf.org/shadow.html.
+
+Abstract
+
+We propose here a service that would enable nodes located behind one 
+or several IPv4 NATs to obtain IPv6 connectivity by tunneling 
+packets over UDP; we call this the Shipworm service. The 
+establishment of the tunnel is automatic, and does not require any 
+configuration parameters on the client. Running the service requires 
+the help of "Shipworm servers" and "Shipworm relays"; the Shipworm 
+servers are stateless, and only have to manage a small fraction of 
+the traffic between Shipworm clients; the Shipworm relays act as 
+IPv6 routers between the Shipworm service and the "native" IPv6 
+Internet.
+
+1	Introduction
+
+Classic tunneling methods envisaged for IPv6 transition operate by 
+sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal 
+proposes automatic discovery in this context. A problem with these 
+methods is that they don't work when the IPv6 candidate node is 
+isolated behind a Network Address Translation device: NAT are 
+typically not programmed to allow the transmission of arbitrary 
+payload types; even when they are, the local address cannot be used 
+in a 6to4 scheme. 6to4  will work with NAT if the NAT and 6to4 
+router functions are in the same box; we want to cover the 
+relatively frequent case when the NAT cannot be readily upgraded to 
+provide a 6to4 router function. 
+
+
+Huitema                                                      [Page  1]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+A possible way to solve the problem is to rely on a set of "tunnel 
+brokers." There are however limits to any solution that is based on 
+such brokers: the quality of service is not very good, since the 
+traffic follows a "dog leg" route from the source to the broker and 
+then the destination; the broker has to provide sufficient 
+transmission capacity to relay all packets and thus suffers a high 
+cost. For these two reasons, we tend to prefer solutions that allow 
+for "automatic tunneling", i.e. let the packets follow a direct path 
+to the destination.
+
+The automatic tunneling requirement is indeed at odds with some of 
+the specificities of NATs. Establishing a direct path supposes that 
+the IPv6 Candidate can retrieve a "globally routable" address that 
+results from the translation of its local address by one or several 
+NATs; it also supposes that we can find a way to bypass the various 
+"per destination protections" that many NATs implement. In this 
+memo, we will explain how IPv6 candidates located behind NATs can 
+enlist the help of "v6 UDP routers" to learn their "global address" 
+and to obtain connectivity.
+
+2	Definitions
+
+2.1	Shipworm service
+
+The transmission of IPv6 packets over UDP, as defined in this memo.
+
+2.2	Shipworm Client
+
+A node that has some access to the IPv4 Internet and that wants to 
+gain access to the IPv6 Internet. This node may behave either as an 
+IPv6 host or as an IPv6 router. 
+
+2.3	Shipworm Server
+
+A node that has access to the IPv4 Internet through a globally 
+routable address, and that is used as a helper to provide IPv6 
+connectivity to Shipworm Client. The node is also reachable through 
+the Shipworm IPv4 anycast address.
+
+2.4	Shipworm relay router
+
+An IPv6 router that can receive traffic destined to Shipworm clients 
+and forward it using the Shipworm service.
+
+2.5	Shipworm IPv6 service prefix
+
+A 16 bit IPv6 addressing prefix, whose value is XXXX::/16. (TBD 
+IANA) 
+
+
+
+
+
+Huitema                                                      [Page  2]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+2.6	Shipworm IPv4 anycast prefix
+
+An IPv4 address prefix, whose value is x.x.x.0/24. (TBD IANA)
+This prefix is announced in the IPv4 routing tables.
+
+2.7	Shipworm IPv4 anycast address
+
+An IPv4 address whose value is x.x.x.y, where "x.x.x" is the 24 bit 
+Shipworm IPv4 anycast prefix. (TBD IANA)
+IPv4 Packets sent to this address are directed to the nearest 
+Shipworm server.
+
+2.8	Shipworm UDP port
+
+An UDP port number at which Shipworm Servers are waiting for 
+packets. The value of this port is PPPP. (TBD IANA)
+
+2.9	Shipworm bubble
+
+A packet sent over UDP by a Shipworm agent in order to trigger a 
+side effect in the NAT.
+
+2.10	Shipworm Discard port
+
+An UDP port number that is used as the destination of Shipworm 
+bubbles. The normal value for that port number is 9, i.e. the port 
+number reserved by IANA for the discard service.
+
+2.11	Shipworm service port
+
+The port over which the Shipworm client sends Shipworm packets. This 
+port is attached to one of the client's IPv4 interfaces. The IPv4 
+address may or may not be globally routable, as the client may be 
+located behind one or several NAT.
+
+2.12	Shipworm mapped address and Shipworm mapped port
+
+A global IPv4 address and a UDP port that results from the 
+translation by one or several NAT of the IPv4 address and UDP port 
+of a client's Shipworm service port. The client learns these values 
+through the Shipworm protocol described in this memo.
+
+2.13	Shipworm IPv6 client prefix
+
+A global scope 64 bit IPv6 prefix composed from the Shipworm IPv6 
+service prefix, the Shipworm mapped address and Shipworm mapped 
+port. 
+
+2.14	Shipworm IPv6 address
+
+A Shipworm IPv6 address obtained by combining a Shipworm IPv6 client 
+
+Huitema                                                      [Page  3]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+prefix and a 64 bit node identifier.
+
+2.15	Shipworm IPv6 anycast address
+
+A global scope IPv6 address obtained by combining the Shipworm IPv6 
+service prefix, the Shipworm IPv4 anycast address, the Shipworm port 
+and a null 64 bit node identifier (i.e., all zeroes).
+
+
+3	Model, requirements
+
+The Shipworm service requires the cooperation of three kinds of 
+actors: Shipworm clients, who want to use IPv6 despite being located 
+behind a NAT, Shipworm servers who will facilitate the service, and 
+Shipworm relays that provide for the interconnection between the 
+service and the "native IPv6 Internet."
+
+In order to enable the service, the Shipworm servers must have an 
+unencumbered IPv4 connection, i.e. they must have a global IPv4 
+address. In fact, these servers must be dual homed, capable of 
+receiving packet on a specific, topology dependent, IPv4 address, 
+and also of receiving packets on the generic "Shipworm anycast IPv4 
+address."
+
+The Shipworm routers must be connected to the IPv6 Internet and must 
+participate in IPv6 routing; they must be able to announce 
+reachability over IPv6 of the "Shipworm service IPv6 prefix." They 
+must then be able to relay packets over IPv4 UDP towards Shipworm 
+clients. It is very sensible to combine the functions of Shipworm 
+server and Shipworm relay in a single box.
+
+The Shipworm service is designed primarily for robustness: packets 
+are carried over UDP in order to cross as many NAT implementations 
+as possible. The servers are designed to be stateless, which means 
+that they can easily be replicated. We expect indeed to find many 
+such servers replicated at multiple Internet locations.
+
+The primary role of the servers is to enable the NAT traversal. The 
+service is designed in such a way that, as soon as NAT traversal is 
+guaranteed, packets can flow on a direct path between source and 
+destination, without necessarily involving a relay by a Shipworm 
+server.
+
+4	Description of the solution
+
+The Shipworm service is realized by having clients interact with 
+"Shipworm servers" through the Shipworm service protocol.
+
+The Shipworm server is designed to be stateless. It waits for 
+Shipworm requests or test requests on the Shipworm service and 
+Shipworm test ports, and processes by sending a response to the 
+adequate address and port; it waits for IPv6 packets on the Shipworm 
+
+Huitema                                                      [Page  4]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+relay port, and forwards them to the adequate IPv4 address and UDP 
+port.
+
+4.1	Message formats
+
+4.1.1	Shipworm IPv6 addresses
+
+Shipworm IPv6 addresses comprise four components:
+
+   +------+------------+----+-----------------------------+
+   |Prefix|IPv4 address|Port|       Node identifier       |
+   +------+------------+----+-----------------------------+
+
+The 16 bit prefix is the "Shipworm IPv6 Prefix."
+
+The next 32 bits contain a globally routable IPv4 address.
+
+The next 16 bits contain a port number associated with that address.
+
+The last 64 bits contain a node identifier.
+
+4.1.2	Shipworm IPv6 packets encapsulation
+
+Shipworm IPv6 packets are transmitted as UDP packets [13] within 
+IPv4 [14].  The source and destination IP addresses and UDP port 
+take values that are specified in this section.
+
+4.1.3	Maximum Transmission Unit
+
+Since Shipworm uses UDP as an underlying transport, a Shipworm
+Maximum Transfer Unit (MTU) could potentially be as large as the 
+payload of the largest valid UDP datagram (65527 bytes).  However, 
+since Shipworm packets can travel unto unpredictable path over the 
+Internet, it is best to contain this MTU to a small size, in order 
+to minimize the effect of packet fragmentation and reassembly. The 
+default link MTU assumed by a host, and the link MTU supplied by a 
+Shipworm server during Router Advertisement SHOULD normally be set 
+to the minimum IPv6 MTU size of 1280 bytes [5].
+
+Shipworm implementations SHOULD NOT set the "do not fragment" (DF) 
+bit of the encapsulating IPv4 header.
+
+4.1.4	Shipworm bubble
+
+A Shipworm bubble is a minimal UDP packet sent to a specific 
+destination to "prime" a NAT for later accepting packets from this 
+destination. The bubble has the following parameter:
+
+- IPv4 source address: the Shipworm mapped address of the sender
+
+- IPv4 destination address: the IPv4 address of the target
+
+
+Huitema                                                      [Page  5]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+- UDP source port: the Shipworm mapped port of the sender
+
+- UDP destination port: the Shipworm Discard Port.
+
+- UDP payload: the string "Shipworm." 
+
+4.2	Shipworm Client specification
+
+A Shipworm client expects to exchange IPv6 packets through an UDP 
+port, the Shipworm service port. The client will maintain the 
+following variables that reflect the state of the Shipworm service:
+
+- Shipworm connectivity status,
+- Mapped address and port number of the Shipworm service port,
+- Shipworm IPv6 prefix associated with the Shipworm service port,
+- Shipworm IPv6 address or addresses derived from the prefix,
+- Date and time of the last interaction with the Shipworm server,
+- List of recent Shipworm peers.
+
+Before sending any packets, the client must perform the Shipworm 
+qualification procedure, which determines the Shipworm connectivity 
+status, the mapped address and port number, and the Shipworm IPv6 
+prefix. If the qualification is successful, the client may use the 
+Shipworm service port to transmit and receive IPv6 packets, 
+according to the transmission and reception procedures; these 
+procedures use the "list of recent peers". The client must regularly 
+perform the maintenance procedure in order to guarantee that the 
+Shipworm service port remains usable; the need to use this procedure 
+or not depend on the delay since the last interaction with the 
+Shipworm server. 
+
+4.2.1	Qualification procedure
+
+The purpose of the qualification procedure is to establish the 
+status of the local IPv4 connection, and to determine the Shipworm 
+IPv6 client prefix of the local Shipworm interface. The procedure 
+starts when the service is in the "initial" state, and results in a 
+"qualified" state if successful, in an "off-line" or "bad-NAT" stage 
+if unsuccessful.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huitema                                                      [Page  6]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+          /---------\
+          | Initial |
+          \---------/
+               |
+          +----+----+
+          | Start   |<------+
+          +----+----+       |
+               |            |
+               v            |
+          /---------\ Timer |
+          |Starting |-------+ N attempts   /----------\
+          \---------/--------------------->| Off-line |
+               | Response                  \----------/
+               |
+          +----+----+
+          | Test    |<------+
+          +----+----+       |
+               | OK         |
+               v            |
+          /---------\ Timer |
+          | Testing |-------+ N attempts   /----------\
+          \---------/--------------------->| Bad-NAT  |
+               | Response                  \----------/
+               V
+          /---------\
+          |Qualified|
+          \---------/
+
+Initially, the Shipworm connectivity status is set to "Initial". 
+When the interface is initialized, the system first performs the 
+"start action" by sending a Router Solicit packet. The IPv6 
+destination of the RS is the Shipworm IPv6 anycast address; the IPv6 
+source is the unspecified address; the packet will be sent over UDP 
+to the Shipworm anycast address and Shipworm service port. The 
+connectivity status moves then to "Starting".
+
+In the starting state, the client waits for a router advertisement 
+from the Shipworm server. If no response comes within a time-out, 
+the client should repeat the start action, by resending the Router 
+Solicit packet. If no response has arrived after N=4 repetitions, 
+the client concludes that it cannot use UDP, and that the Shipworm 
+service is not available; the status is set to "Off-line." 
+
+If a response arrives, the client checks that the router 
+advertisement contains exactly one advertised address prefix. This 
+prefix should be a valid Shipworm IPv6 client prefix:
+
+- the first 16 bits contain the Shipworm service TLA,
+
+- the next 32 bits are the client's Shipworm mapped address,
+
+
+Huitema                                                      [Page  7]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+- the next 16 bits are the client's Shipworm mapped port.
+
+The source address of the Router Advertisement is the Shipworm IPv6 
+address of the Shipworm server. This address must be built using an 
+IPv4 unicast address of the server, and a port number at which the 
+server is waiting for packets. 
+
+If the response is a valid router advertisement, from a valid 
+Shipworm source address, and containing a valid Shipworm address 
+prefix, the client should build a Shipworm IPv6 address using the 
+Shipworm IPv6 client prefix learned from the RA and locally selected 
+identifier. The client will then initiate the test of the 
+connection. It does so by sending first a Shipworm bubble whose 
+target is the IPv4 unicast address of the server, as learned from 
+the IPv6 source address of the RA, and then by sending IPv6 ICMP 
+echo request whose IPv6 source address is the client's Shipworm IPv6 
+address, and whose IPv6 destination is the server's Shipworm IPv6 
+address, i.e. the source address of the RA; the echo request is sent 
+over IPv4 UDP to the Shipworm IPv4 anycast address and Shipworm UDP 
+port.
+
+The client is now in the "testing" state, and waits for the ICMP 
+echo response from the Shipworm server. If no response comes within 
+a time-out, the client should repeat the test action, by resending 
+the Shipworm bubble and the Shipworm ICMP echo request. If no 
+response has arrived after N=4 repetitions, the client concludes 
+that the NAT cannot be reliably traversed, and that the Shipworm 
+service is not available; the status is set to "Bad-NAT." 
+
+If the echo response arrives, the address is qualified, and the 
+client can start using the Shipworm service.
+
+4.2.2	Packet reception
+
+The Shipworm client receives packet over the Shipworm interface. The 
+role of the packet reception procedure, besides receiving packets, 
+is to maintain the date and time of the last interaction with the 
+Shipworm server, and the "list of recent peers." Each entry in the 
+list contains an IPv4 address, a UDP port, and a date and time.
+
+When a UDP packet is received, the Shipworm client examines the IPv4 
+source address and port number from which the packet is received. If 
+these values match the Shipworm IPv4 anycast address and Shipworm 
+port, the client updates the "date and time of the last interaction 
+with the Shipworm server" to the current data and time.
+
+The Shipworm client will then examine the IPv6 source address of the 
+encapsulated packet. If the source IPv6 address is a Shipworm IPv6 
+address, the client extracts the "peer IPv4 address" and "peer UDP 
+port" corresponding to that address. If the address and port pair 
+are already represented in the "list of recent peers", the client 
+updates the data and time associated to that list entry. If the pair 
+
+Huitema                                                      [Page  8]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+is not yet represented, the client creates a new list entry for the 
+pair, associated with the current data and time.
+
+The list of peers is used to "optimize" the transmission of IPv6 
+packets by using a "direct path" for the recently active peers. The 
+list of peers could grow over time. Clients should implement a list 
+management strategy, such as for example deleting the least recently 
+used entries. Clients should make sure that the list has a 
+sufficient size, so that most traffic goes over the "direct path."
+
+4.2.3	Packet transmission
+
+When a Shipworm client has to transmit a packet over a Shipworm 
+interface, it examines the destination IPv6 address. If the 
+destination is not a Shipworm IPv6 address, the packet is posted 
+over UDP to the Shipworm IPv4 anycast address and Shipworm UDP port.
+
+If the destination is a Shipworm IPv6 address, the client extracts 
+the "peer IPv4 address" and "peer UDP port" corresponding to that 
+address.
+
+If there is an entry for this address and port pair in the List of 
+recent Shipworm peers for this address and port pair, the packet 
+should be sent over UDP directly to the specified "peer IPv4 
+address" and "peer UDP port".
+
+If there is no entry in the list, the client should first send a 
+Shipworm bubble to the "peer IPv4 address". It should then send the 
+IPv6 packet over IPv4 UDP to the Shipworm IPv4 anycast address and 
+Shipworm UDP port.
+
+4.2.4	Maintenance
+
+The Shipworm client must ensure that the mappings that it uses 
+remain valid. It does so by checking that packets are regularly 
+received from the Shipworm server.
+
+At regular intervals, the client must check the "date and time of 
+the last interaction with the Shipworm server", to ensure that at 
+least one packet has been received in the last 30 seconds. If this 
+is not the case, the client shall send a router solicitation to the 
+Shipworm IPv6 Anycast address. When the router advertisement is 
+received, the client checks that the advertised prefix corresponds 
+to the current Shipworm service prefix. If this is not the case, the 
+mapping has changed; the client must check that the new prefix is 
+valid, as specified in the qualification procedure. It should then 
+invalidate the addresses derived from the old prefixes.
+
+4.3	Shipworm Server specification
+
+The Shipworm server is designed to be stateless. The Shipworm server 
+waits for incoming UDP packets at the Shipworm Relay Port. The 
+
+Huitema                                                      [Page  9]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+incoming packets may be sent to either the Shipworm IPv4 Anycast 
+Address, or to the specific unicast address of the Shipworm Server.
+
+The Shipworm server acts as an IPv6 router. As such, it will receive 
+Router Solicitation packets, to which it will respond with router 
+advertisement packets as explained in the "router solicitation" 
+procedure; it may also receive other packets, for example ICMP 
+packets; ICMP echo request packets must be processed according to 
+the "echo request" procedure.
+
+4.3.1	Processing of Shipworm IPv6 packets
+
+Upon reception of a packet on the Shipworm port, the Shipworm server 
+will first check that the UDP payload contains a valid IPv6 packet; 
+if this is not the case, the packet will be silently discarded. The 
+Shipworm server will then check the IPv6 destination address of the 
+encapsulated IPv6 packet.
+
+If the IPv6 destination address is either the Shipworm IPv6 anycast 
+address or the Shipworm IPv6 address associated to the local 
+interface, the Shipworm server processes the packet; it may in 
+particular have to process "router solicitation" and "echo request" 
+packets according to the corresponding procedures.
+
+If the IPv6 destination address is a valid Shipworm IPv6 address, 
+the Shipworm server encapsulates the IPv6 packet in a new UDP 
+datagram, in which the following parameters are set:
+
+- The destination IPv4 address is derived from the IPv6 destination.
+
+- The source IPv4 address is the Shipworm IPv4 anycast address.
+
+- The destination UDP port is derived from the IPv6 destination.
+
+- The source UDP port is set to the Shipworm Relay Port.
+
+If the destination address is not a Shipworm IPv6 address, the 
+packet should be relayed to the IPv6 Internet using IPv6 routing.
+
+Before relaying packets, the Shipworm server MAY perform the 
+security tests suggested in section 7. 
+
+4.3.2	Processing of router solicitations
+
+When the Shipworm server receives a router solicitation (RS), it 
+retains the IPv4 address and UDP port from which the solicitation 
+was received; these become the Shipworm mapped address and Shipworm 
+mapped port of the client. The router uses these values to compose a 
+Shipworm IPv6 Prefix.
+
+The Shipworm server responds to the router solicitation by sending a 
+Router Advertisement. The router advertisement must advertise the 
+
+Huitema                                                      [Page 10]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+Shipworm IPv6 prefix composed from the mapped address and mapped 
+port. The IPv6 destination address is normally set to the IPv6 
+source address of the RS; if that address was the unspecified 
+address, the IPv6 destination should be set to the Shipworm IPv6 
+anycast address. The Router Advertisement must be sent over UDP to 
+the Shipworm mapped address and Shipworm mapped port of the client; 
+the IPv4 source address and UDP source port should be set to the 
+Shipworm IPv4 anycast address and Shipworm Port.
+
+4.3.3	Processing of echo requests
+
+When the Shipworm server receives an echo request over the Shipworm 
+port, it prepares an ICMP echo reply. If the IPv6 source address of 
+the echo request is a Shipworm address, the IPv6 source address of 
+the response must be set to the Shipworm IPv6 address of the server; 
+the IPv4 destination address and UDP destination port should be set 
+to the value derived from the Shipworm IPv6 address of the client; 
+the IPv4 source address and UDP source address should be set to the 
+values derived from the Shipworm IPv6 address of the server. 
+
+4.3.4	Processing of bubbles
+
+Shipworm servers may receive Shipworm Discard messages on a discard 
+port; these messages are silently discarded.
+
+4.4	Shipworm Relay specification
+
+Shipworm relays are IPv6 routers that advertise reachability of the 
+Shipworm service IPv6 prefix. Shipworm relays will receive IPv6 
+packets bound to Shipworm clients. Shipworm routers can transmit 
+Shipworm packets in one of two ways, depending of whether or not the 
+local configuration allows them to use the Shipworm IPv4 anycast 
+address as the source address of UDP packets.
+
+If the Shipworm Relay can use the Shipworm IPv4 anycast address as a 
+source address, it should transmit the IPv6 packets directly to the 
+target Shipworm client: the IPv4 destination address and UDP 
+destination port are derived from the destination Shipworm IPv6 
+address; the IPv4 source address and UDP source port are set to the 
+Shipworm IPv4 anycast address and Shipworm UDP port.
+
+If the Shipworm Relay cannot use the Shipworm IPv4 anycast address 
+as a source address, it should transmit the IPv6 packets through the 
+nearest Shipworm server: the IPv4 destination address and UDP 
+destination port are set to the Shipworm IPv4 anycast address and 
+Shipworm UDP port; the IPv4 source address and UDP source port are 
+set to a local interface address and local port number on the relay.
+
+It is obviously desirable to combine the functions of Shipworm relay 
+and Shipworm server, but this is not mandatory.
+
+
+
+Huitema                                                      [Page 11]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+5	Discussion of the solution
+
+5.1	Why do we have bubbles and lists of peers?
+
+Experience shows that the implementers of NAT products can adopt 
+widely different treatments of UDP packets:
+
+1. Some implement the simplest solution, which is to map an internal 
+UDP port, defined by an internal address and a port number on the 
+corresponding host, to an external port, defined by a global address 
+managed by the NAT and a port number valid for that address. In this 
+simple case, the mapping is retained as long as the port is active, 
+and is removed after an inactivity timer. As long as the mapping is 
+retained, any packet received by the NAT for the external port is 
+relayed to the internal address and port.
+
+2. Some implement a more complex solution, in which the NAT not only 
+establishes a mapping for the UDP port, but also maintains a list of 
+external hosts to which traffic has been sent from that port. The 
+packets originating from third party hosts to which the local host 
+has not yet sent traffic are rejected.
+
+3. Instead of keeping just a list of authorized hosts, some NAT 
+implementations keep a list of authorized host and port pairs. UDP 
+packets coming from remote addresses are rejected if the internal 
+host has not yet sent traffic to the outside host and port pair.
+
+4. Finally, some NAT map the same internal address and port pair to 
+different external address and port pairs, depending on the address 
+of the remote host.
+
+Measurement campaigns and studies of documentations have shown that 
+most NAT implement either option 1 or option 2. The combination of 
+"bubbles" and "list of peers" allows us to cross these types of NAT; 
+it is not strictly required for the NAT of type 1, but it does not 
+hurt either.
+
+5.2	Why do we test with ICMP?
+
+The purpose of the ICMP test is to check that the client is capable 
+of receiving UDP packets on a mapped port, from a different server 
+than the one which performed the address mapping - i.e. to verify 
+that the NAT is of type 1 or 2, not 3 or 4. The ICMP request will 
+trigger a "triangle":
+
+1) ICMP request sent by the client to the Shipworm IPv4 anycast 
+address,
+
+2) Local transmission on the server between the anycast address and 
+the unicast interface,
+
+
+Huitema                                                      [Page 12]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+3) ICMP response sent from the unicast address of the server.
+
+This test, combined with the transmission of a bubble, is sufficient 
+to check that the same mapping can be used independently of the IPv4 
+address of the peer.
+
+5.3	Why do we need an anycast address?
+
+The use of an IPv4 anycast address to locate the Shipworm server has 
+many advantages. An obvious one is that it solves configuration 
+issues, making it very easy for the Shipworm client to locate the 
+nearest server. A less obvious one is the interaction with the NAT. 
+The type 2 NAT check that the packet comes from a source with which 
+the local client already interacted; by using a single unicast 
+address as the source address of all UDP packets coming from all 
+Shipworm servers, we guarantee that the "pin-hole in the NAT" can be 
+use by all of these servers.
+
+The use of an anycast address is facilitated by the stateless 
+implementation of Shipworm servers: since the service is performed 
+in exactly the same way by any server, it does not matter whether 
+anycast routing carries the packet to a specific server or another.
+
+The only dependency that we have is during the qualification phase: 
+it is important that the echo packet be processed by the same server 
+for which we have sent a bubble. However, since the IPv6 destination 
+address of the echo request specifies a specific server address, we 
+know that even the anycast packet was routed to another server, the 
+normal routing rule will ensure that the packet is relayed from 
+there to the intended server.
+
+The consequences of the use of anycast addresses on access control, 
+scaling, and failover are discussed in [RFC3068] in the context of 
+the "6to4" service.   
+
+5.4	When to use Shipworm?
+
+Shipworm is designed to robustly enable IPv6 traffic through NAT, 
+and the price of robustness is a reasonable amount of overhead, due 
+to UDP encapsulation, transmission of bubbles, and relaying of 
+packets through the Shipworm servers. Nodes that want to connect to 
+the IPv6 Internet should only use the Shipworm service as a "last 
+resort" option: they should prefer using direct IPv6 connectivity if 
+it is locally available, and they should prefer using the less 
+onerous "6to4" encapsulation if they can use a global IPv4 address.
+
+5.5	What about firewalls?
+
+The Shipworm service is not designed to "transparently traverse 
+firewalls." A local administrator can decide to allow or disallow 
+the service, by programming the local firewall to authorize or deny 
+traffic on the Shipworm UDP port. 
+
+Huitema                                                      [Page 13]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+5.6	Why do we use the name Shipworm?
+
+A "Shipworm" is a little saltwater critter that is common in the 
+harbors of warm seas and that digs holes in immersed wood pieces, 
+such as boat hulls or posts. The animal is not an actual worm - it 
+is a mollusk. The Shipworm service also digs holes, albeit in NATs, 
+not in wood. 
+
+On one hand, one may think that the shipworm is a pretty nasty 
+animal. On the other hand, the animal only survives in relatively 
+clean and unpolluted water; its recent comeback in several Northern 
+American harbors is a testimony to their newly retrieved 
+cleanliness. The Shipworm service should, in turn, contribute to a 
+newly retrieved transparency of the Internet. 
+
+6	Future Work
+
+Obviously a lot - this is a first draft.
+
+7	Security Considerations
+
+The security consideration for using a dynamic encapsulation of IPv6 
+over UDP are very similar to the implications of "6to4" [RFC3056], 
+which we partially reproduce here.
+
+Implementors should be aware that, in addition to possible attacks 
+against IPv6, security attacks against IPv4 must also be considered. 
+Use of IP security at both IPv4 and IPv6 levels should nevertheless 
+be avoided, for efficiency reasons.  For example, if IPv6 is running 
+encrypted, encryption of IPv4 would be redundant except if traffic 
+analysis is felt to be a threat.  If IPv6 is running authenticated, 
+then authentication of IPv4 will add little.  Conversely, IPv4 
+security will not protect IPv6 traffic once it leaves the Shipworm 
+service. Therefore, implementing IPv6 security is required even if 
+IPv4 security is available. 
+
+By default, Shipworm traffic will be accepted and decapsulated from 
+any source from which regular IPv4 traffic is accepted.  If this is 
+for any reason felt to be a security risk (for example, if IPv6 
+spoofing is felt to be more likely than IPv4 spoofing), then 
+additional source address based packet filtering could be applied.  
+A possible plausibility check is whether the encapsulating IPv4 
+address is consistent with the encapsulated Shipworm IPv6 address.  
+If this check is applied, exceptions to it must be configured to 
+admit traffic from Shipworm relays and Shipworm servers. 
+
+In any case, any Shipworm traffic whose source or destination 
+address embeds a mapped IPv4 address which is not in the format of a 
+global unicast address MUST be silently discarded by both Shipworm 
+clients and Shipworm servers.  Specifically, this means that IPv4 
+addresses defined in [RFC 1918], broadcast, subnet broadcast, 
+
+Huitema                                                      [Page 14]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+multicast and loopback addresses are unacceptable.
+
+8	IANA Considerations
+
+This memo documents a request to IANA to allocate a Shipworm IPv6 
+service prefix, a Shipworm IPv4 anycast prefix, a Shipworm IPv4 
+anycast address and a Shipworm UDP port.
+
+
+9	Copyright
+
+The following copyright notice is copied from RFC 2026 [Bradner, 
+1996], Section 10.4, and describes the applicable copyright for this 
+document.
+
+Copyright (C) The Internet Society July 12, 2001. All Rights 
+Reserved.
+
+This document and translations of it may be copied and furnished to 
+others, and derivative works that comment on or otherwise explain it 
+or assist in its implementation may be prepared, copied, published 
+and distributed, in whole or in part, without restriction of any 
+kind, provided that the above copyright notice and this paragraph 
+are included on all such copies and derivative works.  However, this 
+document itself may not be modified in any way, such as by removing 
+the copyright notice or references to the Internet Society or other 
+Internet organizations, except as needed for the purpose of 
+developing Internet standards in which case the procedures for 
+copyrights defined in the Internet Standards process must be 
+followed, or as required to translate it into languages other than 
+English.
+
+The limited permissions granted above are perpetual and will not be 
+revoked by the Internet Society or its successors or assignees.
+
+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	Intellectual Property
+
+The following notice is copied from RFC 2026 [Bradner, 1996], 
+Section 10.4, and describes the position of the IETF concerning 
+intellectual property claims made against this document.
+
+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 other technology described in 
+this document or the extent to which any license under such rights 
+
+Huitema                                                      [Page 15]
+
+
+INTERNET DRAFT               Shipworm                    July 12, 2001
+
+might or might not be available; neither does it represent that it 
+has made any effort to identify any such rights.  Information on the 
+IETF's procedures with respect to rights in standards-track and 
+standards-related documentation can be found in BCP-11.  Copies of 
+claims of rights made available for publication and any assurances 
+of licenses to be made available, or the result of an attempt made 
+to obtain a general license or permission for the use of such 
+proprietary rights by implementers or users of this specification 
+can be obtained from the IETF Secretariat.
+
+The IETF invites any interested party to bring to its attention any 
+copyrights, patents or patent applications, or other proprietary 
+rights which may cover technology that may be required to practice 
+this standard.  Please address the information to the IETF Executive 
+Director.
+
+11	Acknowledgements
+
+Many of the ideas in this memo are the result of discussions between 
+the author and Microsoft colleagues, notably Brian Zill and Rick 
+Rashid. Several encapsulation details are inspired from early work 
+by Keith Moore.
+
+12	References
+
+[RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 
+IPv4 Clouds", RFC 3056, February 2001.
+
+[RFC3068] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", 
+RFC 3068, June 2001.
+
+13	Authors' Addresses
+
+Christian Huitema
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052-6399
+
+Email: huitema@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huitema                                                      [Page 16]
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
deleted file mode 100644
index 5fc86e9d..00000000
--- a/Documentation/en/I-D/draft-ietf-fax-smtp-capabilities-00.txt
+++ /dev/null
@@ -1,503 +0,0 @@
-
-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-capabilities-01.txt b/Documentation/en/I-D/draft-ietf-fax-smtp-capabilities-01.txt
new file mode 100644
index 00000000..27e197a9
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-fax-smtp-capabilities-01.txt
@@ -0,0 +1,20 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+N. Joffe: njoffe@cisco.com                                                        

+D. Wing: dwing@cisco.com                                                         

+

+

diff --git a/Documentation/en/I-D/draft-ietf-fax-smtp-session-02.txt b/Documentation/en/I-D/draft-ietf-fax-smtp-session-02.txt
new file mode 100644
index 00000000..24152a6b
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-fax-smtp-session-02.txt
@@ -0,0 +1,950 @@
+
+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
new file mode 100644
index 00000000..4ca7a549
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-fax-smtp-session-03.txt
@@ -0,0 +1,840 @@
+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]