added to collection as reference anyway

55 files changed, 33801 insertions, 0 deletions

diff --git a/Documentation/en/I-D/draft-bernstein-eplf-06.txt b/Documentation/en/I-D/draft-bernstein-eplf-06.txt
new file mode 100644
index 00000000..21103c84
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-eplf-06.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+D. Bernstein: djb@pobox.com                                                           

+

+

diff --git a/Documentation/en/I-D/draft-bernstein-hcmssc-06.txt b/Documentation/en/I-D/draft-bernstein-hcmssc-06.txt
new file mode 100644
index 00000000..21103c84
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-hcmssc-06.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+D. Bernstein: djb@pobox.com                                                           

+

+

diff --git a/Documentation/en/I-D/draft-bernstein-mail-loops-war-06.txt b/Documentation/en/I-D/draft-bernstein-mail-loops-war-06.txt
new file mode 100644
index 00000000..21103c84
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-mail-loops-war-06.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+D. Bernstein: djb@pobox.com                                                           

+

+

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

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+G. Bernstein: creg@ciena.com                                                          

+

+

diff --git a/Documentation/en/I-D/draft-bernstein-netstrings-06.txt b/Documentation/en/I-D/draft-bernstein-netstrings-06.txt
new file mode 100644
index 00000000..21103c84
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-netstrings-06.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+D. Bernstein: djb@pobox.com                                                           

+

+

diff --git a/Documentation/en/I-D/draft-bernstein-nrudt-06.txt b/Documentation/en/I-D/draft-bernstein-nrudt-06.txt
new file mode 100644
index 00000000..21103c84
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-nrudt-06.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+D. Bernstein: djb@pobox.com                                                           

+

+

diff --git a/Documentation/en/I-D/draft-bernstein-owner-hack-05.txt b/Documentation/en/I-D/draft-bernstein-owner-hack-05.txt
new file mode 100644
index 00000000..21103c84
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-owner-hack-05.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+D. Bernstein: djb@pobox.com                                                           

+

+

diff --git a/Documentation/en/I-D/draft-bernstein-pirp-06.txt b/Documentation/en/I-D/draft-bernstein-pirp-06.txt
new file mode 100644
index 00000000..21103c84
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-pirp-06.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+D. Bernstein: djb@pobox.com                                                           

+

+

diff --git a/Documentation/en/I-D/draft-bernstein-qmtp-05.txt b/Documentation/en/I-D/draft-bernstein-qmtp-05.txt
new file mode 100644
index 00000000..21103c84
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-qmtp-05.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+D. Bernstein: djb@pobox.com                                                           

+

+

diff --git a/Documentation/en/I-D/draft-bernstein-qsbmf-06.txt b/Documentation/en/I-D/draft-bernstein-qsbmf-06.txt
new file mode 100644
index 00000000..21103c84
--- /dev/null
+++ b/Documentation/en/I-D/draft-bernstein-qsbmf-06.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+D. Bernstein: djb@pobox.com                                                           

+

+

diff --git a/Documentation/en/I-D/draft-ema-vpim-pndn-00.txt b/Documentation/en/I-D/draft-ema-vpim-pndn-00.txt
new file mode 100644
index 00000000..534794d3
--- /dev/null
+++ b/Documentation/en/I-D/draft-ema-vpim-pndn-00.txt
@@ -0,0 +1,1374 @@
+
+Network Working Group                                   E.Burger
+
+Internet Draft                          Centigram Communications
+Corporation
+Document: draft-ema-vpim-pndn-00.txt           February 15, 2000
+
+Category: Standards Track
+Expires in six months
+
+
+                   Partial Non-Delivery Notification
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [1].  Internet-Drafts are
+   working documents of the Internet Engineering Task Force (IETF), its
+   areas, and its working groups.  Note that other groups may also
+   distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six
+   months.  Other documents may update, replace, or obsolete this
+   document at any time.  It is inappropriate to use Internet-Drafts as
+   reference material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+
+1.
+  Abstract
+   This document describes the interaction between systems sending
+   multi-part Internet mail [2] to systems that cannot render parts of
+   the sent message.  In particular, this document describes an
+   extension to the Delivery Status Notification mechanism described in
+   [3].
+
+   An example of partial message delivery failure is the case when a
+   user sends an audio file and a video file to an Internet Voice Mail
+   [4] system.  The Internet Voice Mail system can render the audio
+   part but not the video part.  In this case, a partial delivery
+   occurs.
+
+   This document reflects work undertaken in support of the Internet
+   Voice Mail and Voice Profile for Internet Mail [5] initiatives.  The
+   VPIM Work Group home page is <http://www.ema.org/vpim>.
+
+
+
+
+
+
+Burger                    Expires 7/11/2000                   [Page 1]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+Table of Contents
+
+   1.   Abstract .....................................................1
+   2.   Conventions used in this document ............................2
+   3.   Introduction .................................................3
+
+   4.   Operation ....................................................5
+   5.   Contents of the PNDN .........................................6
+     5.1.  The message/partial-delivery-status content-type ..........6
+     5.2.  Per-Message PNDN Fields ...................................7
+        5.2.1.  Fields from RFC 1894 .................................7
+        5.2.2.  Original-Message-ID ..................................7
+     5.3.  Per-Part PNDN Fields ......................................8
+        5.3.1.  Fields from RFC 1894 .................................9
+
+        5.3.2.  Action Field .........................................9
+        5.3.3.  Final Recipient Field ...............................10
+        5.3.4.  Original Content ID Field ...........................10
+        5.3.5.  Original Content Description Field ..................10
+        5.3.6.  Original Content Disposition Field ..................10
+        5.3.7.  Original Content Type Field .........................10
+        5.3.8.  Status Field ........................................11
+
+   6.   Appendix - Examples .........................................12
+     6.1.  PNDN With One Failed Body Part ...........................13
+     6.2.  PNDN With Two Failed Body Parts ..........................14
+     6.3.  PNDN With One Body Part Failure and Two Recipients .......15
+     6.4.  PNDN With One Body Part Failure for One Recipient and
+           Another Body Part Failure for Two Recipients .............16
+   7.   Formal Syntax ...............................................18
+   8.   Security Considerations .....................................19
+
+     8.1.  Forgery ..................................................19
+     8.2.  Confidentiality ..........................................20
+   9.   References ..................................................21
+   10.  Acknowledgments .............................................22
+   11.  Author's Address ............................................22
+   12.  Notices and Full Copyright Statement ........................23
+
+
+
+
+2.
+  Conventions used in this document
+
+   This document refers generically to the sender of a message in the
+   masculine (he/him/his) and the recipient of the message in the
+   feminine (she/her/hers).  This convention is purely for convenience
+   and makes no assumption about the gender of a message sender or
+   recipient.
+
+
+
+
+Burger            Internet Draft - Expires 7/11/2000          [Page 2]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   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 [6].
+
+   FORMATTING NOTE: Notes, such at this one, provide additional
+   nonessential information that the reader may skip without missing
+   anything essential.  The primary purpose of these non-essential
+   notes is to convey information about the rationale of this document,
+   or to place this document in the proper historical or evolutionary
+   context.  Readers whose sole purpose is to construct a conformant
+   implementation may skip such information.  However, it may be of use
+   to those who wish to understand why we made certain design choices.
+
+
+
+
+3.
+  Introduction
+
+   This document describes partial non-delivery notifications (PNDN).
+   Partial non-delivery notifications are an extension of the Delivery
+   Status Notification (DSN) described in RFC 1894 [3].
+
+   The need for a partial non-delivery notification comes about because
+   of the internetworking of Internet mail systems with legacy
+   messaging systems that do not fulfil all of the semantics of
+   Internet mail.  Such legacy systems have a limited ability to render
+   all parts of a given message. This document will use the case of an
+   Internet mail system sending electronic messages a legacy voice
+   messaging system for illustrative purposes.
+
+   Electronic mail has historically been text-centric.  Extensions such
+   as MIME enable the desktop to send and receive multi-part,
+   multimedia messages.  Popular multimedia data types include binary
+   word processing documents, binary business presentation graphics,
+   voice, and video.
+
+   Voice mail has historically been audio-centric.  Many voice
+   messaging systems can only render voice.  Extensions such as fax
+   enable the voice mail system to send and receive fax images as well
+   as create multi-part voice and fax messages.  A few voice mail
+   systems can render text using text-to-speech or text-to-fax
+   technology.  Although theoretically possible, none can today render
+   video.
+
+   An important aspect of the interchange between voice messaging
+   services and desktop e-mail client applications is that the
+   rendering capability of the voice messaging platform is often much
+   less than the rendering capability of a desktop e-mail client.  In
+   the e-mail case, the sender has the expectation that the recipient
+   receives all components of a multimedia message.  This is so even if
+   the recipient cannot render all body parts.  For the most part, the
+
+
+Burger            Internet Draft - Expires 7/11/2000          [Page 3]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   recipient can either find the appropriate rendering tool or tell the
+   sender that she cannot read the particular attachment.
+
+   This is an important issue.  By definition, a MIME-enabled user
+   agent, conforming to [7] will present or make available all of the
+   body parts to the recipient.  However, a voice mail system may not
+   be capable of storing non-voice objects.  Moreover, the voice mail
+   system may not be capable of notifying the recipient that there were
+   undeliverable message parts.
+
+   The inability of the receiving system to render a body part is
+   usually a permanent failure.  Retransmission of the message will not
+   improve the likelihood of a future successful delivery.  Contrast
+   this to the case with normal data delivery.  Traditional message
+   failures, such as a garbled message or disabled link will benefit
+   from retransmission.
+
+   Note that the PNDN does not attempt to address User Agent failures,
+   such as a corruption of a body part.  PNDN only addresses the
+   capability of a system to handle the data type by observing the
+   part's metadata.  Other mechanisms, such as Message Disposition
+   Notification [8], can address the situation when the recipient
+   system discovers an error in the payload of a body part.
+
+   This document addresses the need to allow Internet e-mail client
+   applications to send arbitrary multi-part multimedia messages to
+   voice messaging systems, retaining the semantics of delivery
+   notification, while taking into account the limitations of the voice
+   messaging system's rendering capabilities.  The method described by
+   this document is applicable to any interface between a full-featured
+   user agent and a recipient mail transfer agent that has less
+   rendering and media type storage capabilities than the sender has.
+
+   Ideally, the voice mail system would notify the recipient of the
+   undeliverable body parts.  Such behavior would satisfy the essential
+   requirements of [8].  In fact, if the voice mail system can notify
+   the recipient there were undeliverable body parts, then there would
+   be no need for this document.  However, many voice mail systems are
+   not capable of making this notification.
+
+   NOTE: An alternative method of handling partial delivery is to
+   determine what parts of the message the sender considers critical.
+   If the voice mail system could not deliver the critical parts, then
+   the voice mail system would reject the entire message.  If the voice
+   mail system could deliver the critical parts, but there were other
+   undeliverable parts, it would silently delete the parts from the
+   delivered message.  The VPIM work group determined this method, in
+   practice, would be too complex to implement and would have the
+   drawback of the voice mail system silently deleting message
+   components.  In light of the limitations of voice mail systems, we
+   decided to deliver as much of the message as possible, notifying the
+   sender of any parts that the voice mail system fails to deliver.
+
+Burger            Internet Draft - Expires 7/11/2000          [Page 4]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+
+   NOTE: The concept of a critical part indicator is still a useful
+   construction.  The sender may wish to specify a body part as so
+   important that if the system cannot deliver the specified body part,
+   then the system will not deliver any parts of the message.  However,
+   this is beyond the scope of this document.  We should revisit this
+   issue once there is an acceptable mechanism for identifying critical
+   parts.
+
+
+
+
+4.
+  Operation
+
+   The sending system sees the Internet Voice Mail system as a peer e-
+   mail client.  The only special consideration on the part of the
+   sending system is that it may encode the MIME message following the
+   format specified by VPIM [5] or the Internet Voice Mail Profile [4].
+   Properly encoding and profiling the message will enhance the
+   receiving system's ability to process and successfully deliver the
+   message.  Such considerations include the formatting and encoding of
+   the sender's audio name clip, return address information, out-dial
+   destinations, and other elements.  Refer to [5] for more
+   information.
+
+   The recipient system, on receipt of e-mail destined for a voice mail
+   user, makes a best-efforts attempt to deliver what parts it can to
+   the user.
+
+   If the recipient system is capable of delivering the entire message,
+   it follows the notification protocols specified in [4].
+
+   If the recipient system cannot deliver any part of the message, it
+   will return the non-delivery notification specified in [4].
+
+   If the recipient system is capable of delivering only part of the
+   message, it will return a partial non-delivery notification (PNDN)
+   as described below.
+
+   Delivery failure can occur for all recipients of a message because
+   the recipient system cannot handle a given body part.  However,
+   body-part delivery failure can also occur for a subset of recipients
+   of a message.  This happens if the recipient system is capable of
+   handling the media type of the body part, but the recipient user
+   does not subscribe to a service that can present the media type.
+   For example, consider an Internet Voice Mail platform that can
+   handle fax.  Now consider a service provider that has a class of
+   service that is voice only.  If the message recipient user has a
+   voice only class of service, she will not be able to render fax,
+   which is an image.
+
+
+
+Burger            Internet Draft - Expires 7/11/2000          [Page 5]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   NOTE:  We chose Delivery Status Notification (DSN) [3] over Message
+   Disposition Notification (MDN) [8] as a model for PNDN.  There was
+   some discussion on this point because an Internet Voice Mail system
+   acts as both a UA and a MTA.  The Message Disposition Notification
+   deals with things such as return receipt.  The generation of the
+   return receipt can occur long after the receiving system has
+   received the message.  On the other hand, the receiving system can
+   know on receipt whether it has the capabilities to deliver all parts
+   of the message.  In this case, the recipient acts more like an MTA
+   than a UA.  In addition, we decided it was more important for the
+   sender to know the system would never deliver some parts of the
+   message.  It would not be desirable to wait for the recipient to
+   attempt to read the message and only at that point generate a
+   notification that the system could not deliver parts of the message.
+
+   NOTE:  This is why the language uses "is capable of delivering"
+   rather than "delivers" in the description above.
+
+
+
+
+5.
+  Contents of the PNDN
+
+   The PNDN informs a human or machine sender that the recipient system
+   could not deliver one or more parts of a message they have sent.
+
+   The PNDN is a special case of Delivery Status Notification.  In the
+   sections that follow, refer to [3] for a full description of the
+   fields.
+
+   The receiving system transmits a PNDN as a MIME message with a top-
+   level content-type of multipart/report, as defined in [3].
+
+   The mail system can use the multipart/report content-type for any of
+   several kinds of reports.  For a PNDN, the report-type parameter
+   uses the DSN multipart/report content-type of "delivery-status".
+
+   As described in [9], the first part of a multipart/report content-
+   type is a human readable explanation of the report.  For a PNDN, the
+   second component of the multipart/report is of content-type
+   message/delivery-status.  The third component of the
+   multipart/report consists of the original message or some portion
+   thereof.
+
+
+
+5.1. The message/delivery-status content-type
+
+   The message/delivery-status content-type definition is as follows:
+
+     MIME type name:            message
+     MIME subtype name:         delivery-status
+
+Burger            Internet Draft - Expires 7/11/2000          [Page 6]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+     Optional parameters:       none.
+     Encoding considerations:   "7bit" encoding is sufficient and
+                                conforming systems MUST use it to
+                                maintain readability when viewed
+                                by non-MIME mail readers.
+     Security considerations:   discussed in section 7 of this memo.
+
+
+   The message/delivery-status report type for use in the
+   multipart/report is "delivery-status".
+
+   The body of a message/delivery-status consists of one or more
+   "fields" formatted according to the ABNF [10] specified below and in
+   [3].  The per-message fields appear first, followed by a blank line.
+   Following the per-message fields are one or more groups of per-
+   recipient/per-body part fields.  A blank line precedes each group of
+   per-recipient fields.
+
+   The syntax of the message/delivery-status content is in section 7.
+
+   Section 5.2 describes the per-message-fields.  Section 5.3 describes
+   the per-part-fields.
+
+   NOTE:  Readers should focus on Section 5.3 as it describes the
+   essential extensions to DSN.
+
+
+
+5.2. Per-Message PNDN Fields
+
+
+5.2.1. Fields from RFC 1894
+
+   Except as noted below, the PNDN contains all fields as appropriate
+   from DSN [3].  In particular, Reporting-MTA MUST be present.
+
+   NOTE:  The sender's MTA could generate a DSN.  In this case, the
+   Reporting-MTA is optional.  However, only receiving systems will
+   generate Partial Non-Delivery Notifications.  Thus, the sender needs
+   to know who reported the failure.
+
+
+5.2.2. Original-Message-ID
+
+   The recipient system MUST generate an Original-Message-ID field if a
+   Message-ID field was present in the original message.
+
+   NOTE:  This is a change from RFC 1894.  Few User Agents insert an
+   Envelope-ID.  The sender needs to know what message failed.  Sending
+   back the original message in a multimedia environment has security
+   implications.  In particular, requiring the receiving system to send
+   back large multimedia files would make them vulnerable to denial of
+
+Burger            Internet Draft - Expires 7/11/2000          [Page 7]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   service attacks.  Moreover, MIME-encoded body parts are in base64.
+   Since we cannot rely on the user recognizing the original text of
+   their message, we must rely on alternative identifying
+   characteristics.
+
+
+
+5.3. Per-Part PNDN Fields
+
+   A PNDN contains information about attempts to deliver a message's
+   parts to one or more recipients.  A group of contiguous per-message,
+   per-recipient body-part content partial non-delivery notification
+   fields contains delivery information for that body-part.  A blank
+   line precedes each group of per-part fields.
+
+   PNDN expands upon DSN by introducing body part indicators to DSN's
+   per-recipient block.  This extension allows multiple recipients per
+   per-recipient block and multiple body part indicators per per-
+   recipient block.  A conforming implementation may choose to separate
+   each body-part / recipient failure into its own per-recipient block.
+   A conforming PNDN parser MUST be able to digest each of the three
+   reporting types.
+
+   For example, take a message sent to two users, A and B.  In
+   addition, let's say that Part 1 fails for the same reason for both
+   users, and Part 2 fails only for user B for the same reason Part 1
+   failed.  Here are three, equivalent ways of rendering the per-
+   recipient block.
+
+
+     1.   Enumerate all failures individually:
+
+             Recipient A Failure
+             Part 1 Failure
+
+             Recipient B Failure
+             Part 1 Failure
+
+             Recipient B Failure
+             Part 2 Failure
+
+     2.   Group by recipient:
+
+             Recipient A Failure
+             Part 1 Failure
+
+             Recipient B Failure
+             Part 1 Failure
+             Part 2 Failure
+
+     3.   Group by part:
+
+
+Burger            Internet Draft - Expires 7/11/2000          [Page 8]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+
+             Recipient A Failure
+             Recipient B Failure
+             Part 1 Failure
+
+             Recipient B Failure
+             Part 2 Failure
+
+
+   NOTE:  This RFC could have required enumeration as the only way to
+   report failures.  This makes for a cleaner standard.  However,
+   consider the case of a message sent to a large number of recipients.
+   Assuming each recipient / part combination has the same failure
+   mode, expanding all of the redundant information, such as the part
+   identification, for each recipient greatly increases the size of the
+   PNDN.
+
+5.3.1. Fields from RFC 1894
+
+   Except as noted below, the PNDN contains all fields as appropriate
+   from DSN [3].  The Original-Recipient, Final-Recipient, Last-
+   Attempt-Date, and Final-Log-ID fields follow their meaning and
+   requirements set forth in DSN.  The Will-Retry-Until field is not
+   relevant, as the PNDN is not a delayed delivery notification.
+
+
+5.3.2. Action Field
+
+   The action field reflects the disposition of the message.  Since the
+   receiving system can deliver at least part of the message, the
+   action value SHOULD be "delivered".  If the recipient system did not
+   deliver any parts of the message, then it would perform the normal
+   undeliverable message processing described by DSN [3].
+
+   NOTE: Considering partial delivery a failure or a success is a
+   matter of many debates.  There is work ongoing in the IETF to
+   develop an indicator for identifying critical body parts.  With a
+   critical body part indicator, the recipient system can return to the
+   sender a success or failure indication based on whether or not the
+   system succeeded in delivering the critical parts.
+
+   Without critical part indicators, one may chose to err on the side
+   of failing the entire message.  However, from a practical point of
+   view, the sender probably will have some idea of the capabilities of
+   the recipient.  Moreover, experience shows that users do not take
+   well to being bombarded with failure notices they believe should be
+   warnings.
+
+   Therefore, until such a time as we have a critical body part
+   indicator, the best practice is to return a delivered notice to the
+   sender, with the appropriate warning and explanation message for the
+   body part(s) not delivered.
+
+
+Burger            Internet Draft - Expires 7/11/2000          [Page 9]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+
+5.3.3. Final Recipient Field
+
+   The Final-Recipient field indicates the recipient for which this set
+   of per-part fields applies.  The definition of the final recipient
+   field is as described by DSN [3].  However, for security reasons,
+   the PNDN relaxes the imperative for including this field.  That is,
+   the per-part data MAY include the final recipient field
+
+   NOTE:  The change in imperative from [3], from MUST to MAY, comes
+   from the Internet Voice Mail environment.  One can envision Internet
+   Voice Mail implementations where the service provider wishes to keep
+   the actual host name of the voice mail system hidden yet in the
+   Internet name space.  Reporting the final recipient field may
+   include the actual host name of a voice mail node.  Making that
+   information public through a PNDN may enable attacks on that node.
+
+
+5.3.4. Original Content ID Field
+
+   This field, if present in the original message, MUST be present in
+   the PNDN.  It aids the sender in understanding exactly which body
+   part the receiving system is not capable of delivering.
+
+
+5.3.5. Original Content Description Field
+
+   This field, if present in the original message, MUST be present in
+   the PNDN.  It aids the sender in understanding exactly which body
+   part the receiving system is not capable of delivering.  This field
+   will be much more useful than the Original-Content-ID field to a
+   human sender.  However, few User Agents insert the Content-
+   Description field in a message.
+
+
+5.3.6. Original Content Disposition Field
+
+   This field, if present in the original message, MAY be present in
+   the PNDN if there is a Content Type field in the original message.
+   This field MUST be present if there is not a Content Type field in
+   the original message and the content disposition field contains a
+   filename.  This field aids the sender in understanding exactly which
+   body part the receiving system is not capable of delivering.  This
+   field will be more useful than the Original-Content-ID field to a
+   human sender.  It will let the human know the file name of the part
+   the receiving system is not capable of handling.
+
+
+5.3.7. Original Content Type Field
+
+   This field, if present in the original message, MUST be present in
+   the PNDN.  It aids the sender in understanding exactly which body
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 10]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   part the receiving system is not capable of delivering.  This field
+   will be much more useful than the Original-Content-ID field to a
+   human sender.  It will let the human know the MIME types that the
+   receiving system is not capable of handling.  In addition, the
+   sender will get a clue as to what body part the receiving system is
+   not capable of handling from the filename sub-field, if present.
+
+
+5.3.8. Status Field
+
+   Message Transfer Agents (MTAs) are free to generate standard status
+   codes from [11].  This section describes status codes that have
+   special meaning for PNDN.
+
+   All of these status codes are of type "permanent failures of media",
+   type 5.
+
+   Receiving systems that generate Partial Non-Delivery Notifications
+   MUST insert descriptive text in the comment field of the status code
+   so a human sender can understand why his message failed.
+
+   Sending systems that automatically process returned status codes
+   MUST use the numeric status code and MUST NOT use the comment.
+
+
+5.3.8.1.  Media not Supported
+
+   If the recipient system is not capable of delivering a part of a
+   message because it does not support a given media type, it MUST
+   return the Media not Supported status code.  For example, if an
+   Internet Voice Mail system receives an AutoCAD document and it can
+   only render voice, the Internet Voice Mail system will return a
+   Media not Supported status code.
+
+
+5.3.8.2.  Conversion With Loss Performed
+
+   If the recipient system can deliver the part, but only with a lossy
+   conversion, the receiving system SHOULD NOT return Conversion With
+   Loss Performed.
+
+   NOTE:  We considered the optional return code of Conversion With
+   Loss Performed, Status 5.6.4.  However, we realized two things.
+   First, few Internet Voice Mail systems would necessarily have the
+   capability of generating this warning.  Second, there is dubious
+   value to the sender of receiving this warning.  If the receiver has
+   trouble understanding the rendering of the body part, she can always
+   send a message to the sender.  On the other hand, we could foresee
+   confusion on the part of the sender if he constantly received
+   warning messages every time he sends a message to the particular
+   recipient.
+
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 11]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+
+
+
+6.
+  Appendix - Examples
+
+   NOTE:  These examples are for illustrative purposes only and are not
+   a normative part of the PNDN definition.  If an example conflicts
+   with the normative description of sections 3 through 5, the example
+   is wrong.
+
+   The examples in this appendix use the following MIME-Encoded message
+   for the original sent message.
+
+   The message has three parts.  The first part is a text message.  The
+   second part is a voice message.  The third part is a fax message.
+   Here is the sample message.
+
+
+
+   Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   From: "Eric Burger" <ericb@mtc.telecnnct.com>
+   To: "Eric Burger" <eric.burger@centigram.com>
+   Subject: Three-part Message
+   Date: Mon, 22 Nov 1999 12:02:30 -0500
+   MIME-Version: 1.0
+   Content-Type: multipart/mixed;
+        boundary="----=_NextPart_000_0007_01BF34E1.74123720"
+   X-Priority: 3
+   X-Mailer: The One And Only Test Platform V8.1222.974B
+
+   This is a multi-part message in MIME format.
+
+   ------=_NextPart_000_0007_01BF34E1.74123720
+   Content-Type: text/plain;
+        charset="iso-8859-1"
+   Content-Transfer-Encoding: 7bit
+   Content-ID: TextPart0AFF8B
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+
+
+   ------=_NextPart_000_0007_01BF34E1.74123720
+   Content-Type: audio/wav;
+        name="Voice Message.wav"
+   Content-Transfer-Encoding: base64
+   Content-Disposition: attachment;
+        filename="Voice Message.wav"
+
+   UklGRjgRAABXQVZFZm10IBQAAAAxAAEAQB8AAFkGAABBAAAAAgBAAWZhY3QEAAAAwFMA
+   EQAASfYQFoWCEkuSTST3JGyiTbIfDybr9hltilsnh+uBo/OEpE1iTFGWuFEcFJFuVAxk
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 12]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   ...
+   0TIT1twS7JVeyYHHFDaWIEN1mcYMlvLNgGoakdxbL2ErxZprJS+htNhu4ozNYKmwCGvT
+   wErbIgazEvRAGn5hMxhcqGS59UE1cHEjR08A
+
+   ------=_NextPart_000_0007_01BF34E1.74123720
+   Content-Type: image/tiff;
+        name="My House.tif"
+   Content-Transfer-Encoding: base64
+   Content-Disposition: attachment;
+        filename="My House.tif"
+   Content-Description: Picture of My House
+
+   SUkqABhSAAAAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFN
+   AU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAGRqDuH4JefU8/YSwd8/xdn7CKC4PMW
+   ...
+   UAAAGgEFAAEAAAAIUgAAGwEFAAEAAAAQUgAAJAEEAAEAAAAEAAAAKAEDAAEAAAACAAAA
+   AAAAAAEARgEDAAEAAAAAAAAARwEDAAEAAAAAAAAAAAAAAA==
+
+   ------=_NextPart_000_0007_01BF34E1.74123720--
+
+
+
+6.1. PNDN With One Failed Body Part
+
+   This example shows a PNDN for a system that does not handle text,
+   but does handle voice and fax.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+
+   Body part will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 13]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Original-Content-ID: TextPart0AFF8B
+
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+6.2. PNDN With Two Failed Body Parts
+
+   This example shows a PNDN for a system that does not handle text or
+   fax.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+   Could Not Deliver Fax Part to < eric.burger@centigram.com >
+
+   Body parts will be deleted from queue
+
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 14]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Status: 5.6.1     (Media not Supported)
+   Action: delivered
+   Original-Content-ID: TextPart0AFF8B
+
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Status: 5.6.1     (Media not Supported)
+   Action: delivered
+   Original-Content-Description: Picture of My House
+   Original-Content-Type: image/tiff; name="My House.tif"
+   Original-Content-Disposition: attachment; filename="My House.tif"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+6.3. PNDN With One Body Part Failure and Two
+     Recipients
+
+   This example shows a PNDN for a system that does not handle text,
+   but does handle voice and fax.  Assume the original message was sent
+   to <ericb@mtc.telecnnct.com> and <8005551212@vm.sp.net>.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 15]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+   <8005551212@vm.sp.net>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+   Could Not Deliver Text Part to < 8005551212@vm.sp.net >
+
+   Body part will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Original-Recipient: rfc822;8005551212@vm.sp.net
+   Final-Recipient: rfc822;eburger@vmail27.sp.net
+   Original-Content-ID: TextPart0AFF8B
+
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+6.4. PNDN With One Body Part Failure for One Recipient
+     and Another Body Part Failure for Two Recipients
+
+   This example shows a PNDN for a system that does not handle text,
+   but does handle voice and fax.  However, the recipient at
+   ericb@mtc.telecnnct.com does not subscribe to a fax service.  Assume
+   the original message was sent to <ericb@mtc.telecnnct.com> and
+   <8005551212@vm.sp.net>.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 16]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+   <8005551212@vm.sp.net>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+   Could Not Deliver Text Part to < 8005551212@vm.sp.net >
+   Could Not Deliver Fax Part to < eric.burger@centigram.com >
+
+   Body part will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Original-Recipient: rfc822;8005551212@vm.sp.net
+   Final-Recipient: rfc822;eburger@vmail27.sp.net
+   Original-Content-ID: TextPart0AFF8B
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;8005551212@vm.sp.net
+   Final-Recipient: rfc822;eburger@vmail27.sp.net
+   Original-Content-Description: Picture of My House
+   Original-Content-Type: image/tiff; name="My House.tif"
+   Original-Content-Disposition: attachment; filename="My House.tif"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 17]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+7.
+  Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) as described in RFC-2234 [10].
+
+
+   delivery-status-content =
+          per-message-fields 1*( CRLF per-part-fields)
+
+
+7.1. Syntax of Per-Message Fields
+
+   per-message-fields =
+          [ original-message-id-field CRLF ]
+          [ original-envelope-id-field CRLF ]
+          reporting-mta-field CRLF
+          [ dsn-gateway-field CRLF ]
+          [ received-from-mta-field CRLF ]
+          [ arrival-date-field CRLF ]
+          *( extension-field CRLF )
+
+
+   original-message-id-field =
+          "Original-Message-ID" ":" message-id
+
+   message-id = *text
+
+
+   Original-envelope-id-field, reporting-mta-field, dsn-gateway-field,
+   received-from-mta-field, arrival-date-field, and extension-field are
+   all as defined in DSN [3].
+
+
+7.2. Syntax of Per-Part Fields
+
+   per-part-fields =
+       1*( [ original-content-description-field CRLF ]
+           [ original-content-id-field CRLF ]
+           [ original-content-disposition-field CRLF ]
+           [ original-content-type-field CRLF ] )
+       1*( [ original-recipient-field CRLF ]
+           final-recipient-field CRLF )
+       action-field CRLF
+       status-field CRLF
+       [ remote-mta-field CRLF ]
+       [ diagnostic-code-field CRLF ]
+       [ last-attempt-date-field CRLF ]
+       *( extension-field CRLF )
+
+
+   action-field =
+        "Action: delivered"
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 18]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+
+   original-content-id-field =
+             "Original-Content-ID" ":" content-id
+
+   content-id = *text
+
+
+   original-content-description-field =
+             "Original-Content-Description" ":" content-description
+
+   content-description = *text
+
+   original-content-disposition-field =
+             "Original-Content-Disposition" ":" content-disposition
+
+   content-disposition = *text
+
+   original-content-type-field =
+             "Original-Content-Type" ":" content-type
+
+   content-type = *text
+
+   status-field =
+          "Status: 5.6.1" "(" comment ")"
+
+   comment = *text
+
+
+   Original-recipient-field, final-recipient-field, remote-mta-field,
+   diagnostic-code-field, last-attempt-date-field, and extension-field
+   are as defined in DSN [3].
+
+
+8.
+  Security Considerations
+
+   The following security considerations apply when using PNDNs:
+
+
+
+8.1. Forgery
+
+   One can forge a PNDN as easily as ordinary Internet electronic mail.
+   User agents and automatic mail handling facilities (such as
+   automatic voice mail forwarding agents) that wish to make use of
+   PNDNs should take appropriate precautions to minimize the potential
+   damage from denial-of-service attacks.
+
+   Security threats related to forged PNDNs include the sending of:
+
+   (a) A falsified delivery notification when the message is
+       not delivered to the indicated recipient,
+   (b) A falsified Final-Recipient address, or
+   (c) A falsified Remote-MTA identification.
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 19]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+
+
+
+8.2. Confidentiality
+
+   Another dimension of security is confidentiality.  For example, a
+   message recipient can be autoforwarding messages.  However, she does
+   not wish to divulge her autoforward address.  The desire for such
+   confidentiality will probably be heightened as "wireless mailboxes",
+   such as pagers, become more widely used as autoforward addresses.
+
+   Confidentiality also applies to the service provider.  For example,
+   in an Internet Voice Mail scenario, one can envision implementations
+   of protocols such as VPIM [5] where reporting the actual Internet
+   host name can open the system to attack.
+
+   MTA authors are encouraged to provide a mechanism that enables the
+   end user to preserve the confidentiality of a forwarding address.
+   Depending on the degree of confidentiality required, and the nature
+   of the environment to which a message were being forwarded, this
+   might be accomplished by one or more of:
+
+   (a) omitting the "Final-Recipient" field, as it has
+       little use to the sender,
+
+   (b) omitting "Remote-*" or extension fields of a PNDN
+       whenever they would otherwise contain confidential
+       information (such as a confidential forwarding address),
+
+   (c) for messages forwarded to a confidential address,
+       setting the envelope return address (e.g. SMTP MAIL FROM
+       address) to the NULL reverse-path ("<>") (so that no
+       PNDNs would be sent from a downstream MTA to the
+       original sender), or
+
+   (d) when forwarding mail to a confidential address, having
+       the forwarding MTA rewrite the envelope return address
+       for the forwarded message and attempt delivery of that
+       message as if the forwarding MTA were the originator.
+       On its receipt of final delivery status, the forwarding
+       MTA would issue a PNDN to the original sender.
+
+   In general, the Reporting MTA site can omit any optional PNDN field
+   that it determines inclusion of the field would impose too great a
+   compromise of site confidentiality.  The need for such
+   confidentiality must be balanced against the utility of the omitted
+   information in trouble reports.
+
+   Implementers are cautioned that many existing MTAs will send non-
+   delivery notifications to a return address in the message header
+   (rather than to the one in the envelope), in violation of SMTP and
+   other protocols.  If a message is forwarded through such an MTA, no
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 20]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+   reasonable action on the part of the forwarding MTA will prevent the
+   downstream MTA from compromising the forwarding address.  Likewise,
+   if the recipient's MTA automatically responds to messages based on a
+   request in the message header (such as the nonstandard, but widely
+   used, Return-Receipt-To extension header), it will also compromise
+   the forwarding address.
+
+
+
+
+9.
+  References
+
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+      9, RFC 2026, October 1996.
+
+   2  Freed, N. and Borenstein, N, "Multipurpose Internet Mail
+      Extensions (MIME) Part One: Format of Internet Message Bodies",
+      RFC 2045, Innosoft and First Virtual, November 1996.
+
+   3  Moore, K. and Vaudreuil, G., "An Extensible Message Format for
+      Delivery Status Notifications", RFC 1894, U. Tennessee and Octel
+      Network Services, January 1996.
+
+   4  a.k.a. VPIMv3
+
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
+      version 2", Lucent Technologies and Nortel Networks, RFC 2421,
+      September 1998.
+
+   6  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+      Levels", BCP 14, RFC 2119, March 1997.
+
+   7  Freed, N. and Borenstein, N, "Multipurpose Internet Mail
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and
+      First Virtual, November 1996.
+
+   8  Fajman, R., "An Extensible Message Format for Message Disposition
+      Notifications", RFC 2298, National Institutes of Health, March
+      1998.
+
+   9  Vaudreuil, G., "The Multipart/Report Content Type for the
+      Reporting of Mail System Administrative Messages", RFC 1892,
+      Octel Network Services, January 1996.
+
+   10 Crocker, D. and Overell, P., "Augmented BNF for Syntax
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
+      Demon Internet Ltd., November 1997.
+
+   11 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+      Octel Network Systems, January 1996.
+
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 21]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+
+
+
+
+
+10.
+   Acknowledgments
+
+   I'd like to thank Graham Klyne and Keith Moore for valuable insights
+   into the mechanics of DSN.  Graham Klyne also helped me put this
+   document into English.  However, any bizzare language is my own
+   fault.
+
+   Ned Freed and Herman R. Silbiger both had valuable experience
+   corroborating the assertion that users do not like to receive
+   failure notices unless there is a real failure.  Carl-Uno Mauros was
+   able to put into words much better than I did in a prior draft the
+   differences between a system that cannot render a particular part
+   versus a transmission failure.
+
+
+
+11.
+   Author's Address
+
+   Eric W. Burger
+   Centigram Communications Corporation
+   Maryland Technology Center
+   1375 Piccard Dr., MS 150 R
+   Rockville, MD  20850-4311
+   USA
+   Phone: +1 301/212-3320
+   Email: e.burger@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 22]
+
+                  Partial Non-Delivery Notification   January 11, 2000
+
+
+
+12.
+   Notices and Full Copyright Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances
+   of licenses to be made available, or the result of an attempt made
+   to obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification
+   can be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   Copyright (C) 1999, The Internet Society.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its 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.
+
+
+
+
+
+
+Burger            Internet Draft - Expires 7/11/2000         [Page 23]
+
+
+
diff --git a/Documentation/en/I-D/draft-ema-vpim-pndn-01.txt b/Documentation/en/I-D/draft-ema-vpim-pndn-01.txt
new file mode 100644
index 00000000..e301be64
--- /dev/null
+++ b/Documentation/en/I-D/draft-ema-vpim-pndn-01.txt
@@ -0,0 +1,1311 @@
+
+Network Working Group                                              E. Burger
+Internet Draft                          Centigram Communications Corporation
+Document: draft-ema-vpim-pndn-01.txt                           March 1, 2000
+Category: Standards Track
+Expires in six months
+
+
+                   Partial Non-Delivery Notification
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [1].  Internet-Drafts are
+   working documents of the Internet Engineering Task Force (IETF), its
+   areas, and its working groups.  Note that other groups may also
+   distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six
+   months.  Other documents may update, replace, or obsolete this
+   document at any time.  It is inappropriate to use Internet-Drafts as
+   reference material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+
+1.   Abstract
+   This document describes the interaction between systems sending
+   multi-part Internet mail [2] to systems that cannot render parts of
+   the sent message.  In particular, this document describes an
+   extension to the Delivery Status Notification mechanism described in
+   [3].
+
+   An example of partial message delivery failure is the case when a
+   user sends an audio file and a video file to an Internet Voice Mail
+   [4] system.  The Internet Voice Mail system can render the audio
+   part but not the video part.  In this case, a partial delivery
+   occurs.
+
+   This document reflects work undertaken in support of the Internet
+   Voice Mail and Voice Profile for Internet Mail [5] initiatives.  The
+   VPIM Work Group home page is <http://www.ema.org/vpim>.
+
+
+
+
+
+
+Burger                     Expires 9/1/2000                   [Page 1]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+Table of Contents
+
+   1.   Abstract .....................................................1
+   2.   Conventions used in this document ............................2
+   3.   Introduction .................................................3
+
+   4.   Operation ....................................................5
+   5.   Contents of the PNDN .........................................6
+     5.1.  The message/partial-delivery-status content-type ..........6
+     5.2.  Per-Message PNDN Fields ...................................7
+        5.2.1.  Fields from RFC 1894 .................................7
+        5.2.2.  Original-Message-ID ..................................7
+     5.3.  Per-Part PNDN Fields ......................................8
+        5.3.1.  Fields from RFC 1894 .................................9
+
+        5.3.2.  Action Field .........................................9
+        5.3.3.  Final Recipient Field ...............................10
+        5.3.4.  Original Content ID Field ...........................10
+        5.3.5.  Original Content Description Field ..................10
+        5.3.6.  Original Content Disposition Field ..................10
+        5.3.7.  Original Content Type Field .........................11
+        5.3.8.  Status Field ........................................11
+
+   6.   Appendix - Examples .........................................12
+     6.1.  PNDN With One Failed Body Part ...........................13
+     6.2.  PNDN With Two Failed Body Parts ..........................14
+     6.3.  PNDN With One Body Part Failure and Two Recipients .......15
+     6.4.  PNDN With One Body Part Failure for One Recipient and
+           Another Body Part Failure for Two Recipients .............16
+   7.   Formal Syntax ...............................................18
+   8.   Security Considerations .....................................19
+
+     8.1.  Forgery ..................................................20
+     8.2.  Confidentiality ..........................................20
+   9.   References ..................................................21
+   10.  Acknowledgments .............................................22
+   11.  Author's Address ............................................22
+   12.  Notices and Full Copyright Statement ........................23
+
+
+
+
+2.   Conventions used in this document
+
+   This document refers generically to the sender of a message in the
+   masculine (he/him/his) and the recipient of the message in the
+   feminine (she/her/hers).  This convention is purely for convenience
+   and makes no assumption about the gender of a message sender or
+   recipient.
+
+
+
+
+Burger            Internet Draft - Expires 9/1/2000           [Page 2]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   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 [6].
+
+   FORMATTING NOTE: Notes, such at this one, provide additional
+   nonessential information that the reader may skip without missing
+   anything essential.  The primary purpose of these non-essential
+   notes is to convey information about the rationale of this document,
+   or to place this document in the proper historical or evolutionary
+   context.  Readers whose sole purpose is to construct a conformant
+   implementation may skip such information.  However, it may be of use
+   to those who wish to understand why we made certain design choices.
+
+
+
+
+3.   Introduction
+
+   This document describes partial non-delivery notifications (PNDN).
+   Partial non-delivery notifications are an extension of the Delivery
+   Status Notification (DSN) described in RFC 1894 [3].
+
+   The need for a partial non-delivery notification comes about because
+   of the internetworking of Internet mail systems with legacy
+   messaging systems that do not fulfil all of the semantics of
+   Internet mail.  Such legacy systems have a limited ability to render
+   all parts of a given message. This document will use the case of an
+   Internet mail system sending electronic messages a legacy voice
+   messaging system for illustrative purposes.
+
+   Electronic mail has historically been text-centric.  Extensions such
+   as MIME enable the desktop to send and receive multi-part,
+   multimedia messages.  Popular multimedia data types include binary
+   word processing documents, binary business presentation graphics,
+   voice, and video.
+
+   Voice mail has historically been audio-centric.  Many voice
+   messaging systems can only render voice.  Extensions such as fax
+   enable the voice mail system to send and receive fax images as well
+   as create multi-part voice and fax messages.  A few voice mail
+   systems can render text using text-to-speech or text-to-fax
+   technology.  Although theoretically possible, none can today render
+   video.
+
+   An important aspect of the interchange between voice messaging
+   services and desktop e-mail client applications is that the
+   rendering capability of the voice messaging platform is often much
+   less than the rendering capability of a desktop e-mail client.  In
+   the e-mail case, the sender has the expectation that the recipient
+   receives all components of a multimedia message.  This is so even if
+   the recipient cannot render all body parts.  For the most part, the
+
+
+Burger            Internet Draft - Expires 9/1/2000           [Page 3]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   recipient can either find the appropriate rendering tool or tell the
+   sender that she cannot read the particular attachment.
+
+   This is an important issue.  By definition, a MIME-enabled user
+   agent, conforming to [7] will present or make available all of the
+   body parts to the recipient.  However, a voice mail system may not
+   be capable of storing non-voice objects.  Moreover, the voice mail
+   system may not be capable of notifying the recipient that there were
+   undeliverable message parts.
+
+   The inability of the receiving system to render a body part is
+   usually a permanent failure.  Retransmission of the message will not
+   improve the likelihood of a future successful delivery.  Contrast
+   this to the case with normal data delivery.  Traditional message
+   failures, such as a garbled message or disabled link will benefit
+   from retransmission.
+
+   Note that the PNDN does not attempt to address User Agent failures,
+   such as a corruption of a body part.  PNDN only addresses the
+   capability of a system to handle the data type by observing the
+   part's metadata.  Other mechanisms, such as Message Disposition
+   Notification [8], can address the situation when the recipient
+   system discovers an error in the payload of a body part.
+
+   This document addresses the need to allow Internet e-mail client
+   applications to send arbitrary multi-part multimedia messages to
+   voice messaging systems, retaining the semantics of delivery
+   notification, while taking into account the limitations of the voice
+   messaging system's rendering capabilities.  The method described by
+   this document is applicable to any interface between a full-featured
+   user agent and a recipient mail transfer agent that has less
+   rendering and media type storage capabilities than the sender has.
+
+   Ideally, the voice mail system would notify the recipient of the
+   undeliverable body parts.  Such behavior would satisfy the essential
+   requirements of [8].  In fact, if the voice mail system can notify
+   the recipient there were undeliverable body parts, then there would
+   be no need for this document.  However, many voice mail systems are
+   not capable of making this notification.
+
+   NOTE: Another method of handling partial delivery is to determine
+   what parts of the message the sender considers critical.  If the
+   voice mail system could not deliver the critical parts, then the
+   voice mail system would reject the entire message.  If the voice
+   mail system could deliver the critical parts, but there were other
+   undeliverable parts, it would silently delete the parts from the
+   delivered message.  However, currently there is no method to
+   identify critical parts.  In light of the limitations of voice mail
+   systems, we decided to deliver as much of the message as possible,
+   notifying the sender of any parts that the voice mail system fails
+   to deliver.
+
+
+Burger            Internet Draft - Expires 9/1/2000           [Page 4]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   NOTE: The concept of a critical part indicator is still a useful
+   construction.  The sender may wish to specify a body part as so
+   important that if the system cannot deliver the specified body part,
+   then the system will not deliver any parts of the message.  However,
+   this is beyond the scope of this document.  We should revisit this
+   issue once there is an acceptable mechanism for identifying critical
+   parts.
+
+
+
+
+4.   Operation
+
+   The sending system sees the Internet Voice Mail system as a peer e-
+   mail client.  The only special consideration on the part of the
+   sending system is that it may encode the MIME message following the
+   format specified by VPIM [5] or the Internet Voice Mail Profile [4].
+   Properly encoding and profiling the message will enhance the
+   receiving system's ability to process and successfully deliver the
+   message.  Such considerations include the formatting and encoding of
+   the sender's audio name clip, return address information, out-dial
+   destinations, and other elements.  Refer to [5] for more
+   information.
+
+   The recipient system, on receipt of e-mail destined for a voice mail
+   user, makes a best-efforts attempt to deliver what parts it can to
+   the user.
+
+   If the recipient system is capable of delivering the entire message,
+   it follows the notification protocols specified in [4].
+
+   If the recipient system cannot deliver any part of the message, it
+   will return the non-delivery notification specified in [4].
+
+   If the recipient system is capable of delivering only part of the
+   message, it will return a partial non-delivery notification (PNDN)
+   as described below.
+
+   Delivery failure can occur for all recipients of a message because
+   the recipient system cannot handle a given body part.  However,
+   body-part delivery failure can also occur for a subset of recipients
+   of a message.  This happens if the recipient system is capable of
+   handling the media type of the body part, but the recipient user
+   does not subscribe to a service that can present the media type.
+   For example, consider an Internet Voice Mail platform that can
+   handle fax.  Now consider a service provider that has a class of
+   service that is voice only.  If the message recipient user has a
+   voice only class of service, she will not be able to render fax,
+   which is an image.
+
+   NOTE:  We chose Delivery Status Notification (DSN) [3] over Message
+   Disposition Notification (MDN) [8] as a model for PNDN.  There was
+
+Burger            Internet Draft - Expires 9/1/2000           [Page 5]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   some discussion on this point because an Internet Voice Mail system
+   acts as both a UA and a MTA.  The Message Disposition Notification
+   deals with things such as return receipt.  The generation of the
+   return receipt can occur long after the receiving system has
+   received the message.  On the other hand, the receiving system can
+   know on receipt whether it has the capabilities to deliver all parts
+   of the message.  In this case, the recipient acts more like an MTA
+   than a UA.  In addition, we decided it was more important for the
+   sender to know the system would never deliver some parts of the
+   message.  It would not be desirable to wait for the recipient to
+   attempt to read the message and only at that point generate a
+   notification that the system could not deliver parts of the message.
+
+   NOTE:  This is why the language uses "is capable of delivering"
+   rather than "delivers" in the description above.
+
+
+
+
+5.   Contents of the PNDN
+
+   The PNDN informs a human or machine sender that the recipient system
+   could not deliver one or more parts of a message they have sent.
+
+   The PNDN is a special case of Delivery Status Notification.  In the
+   sections that follow, refer to [3] for a full description of the
+   fields.
+
+   The receiving system transmits a PNDN as a MIME message with a top-
+   level content-type of multipart/report, as defined in [3].
+
+   The mail system can use the multipart/report content-type for any of
+   several kinds of reports.  For a PNDN, the report-type parameter
+   uses the DSN multipart/report content-type of "delivery-status".
+
+   As described in [9], the first part of a multipart/report content-
+   type is a human readable explanation of the report.  For a PNDN, the
+   second component of the multipart/report is of content-type
+   message/delivery-status.  The third component of the
+   multipart/report consists of the original message or some portion
+   thereof.
+
+
+
+5.1. The message/delivery-status content-type
+
+   The message/delivery-status content-type definition is as follows:
+
+     MIME type name:            message
+     MIME subtype name:         delivery-status
+     Optional parameters:       none.
+     Encoding considerations:   "7bit" encoding is sufficient and
+
+Burger            Internet Draft - Expires 9/1/2000           [Page 6]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+                                conforming systems MUST use it to
+                                maintain readability when viewed
+                                by non-MIME mail readers.
+     Security considerations:   discussed in section 7 of this memo.
+
+
+   The message/delivery-status report type for use in the
+   multipart/report is "delivery-status".
+
+   The body of a message/delivery-status consists of one or more
+   "fields" formatted according to the ABNF [10] specified below and in
+   [3].  The per-message fields appear first, followed by a blank line.
+   Following the per-message fields are one or more groups of per-
+   recipient/per-body part fields.  A blank line precedes each group of
+   per-recipient fields.
+
+   The syntax of the message/delivery-status content is in section 7.
+
+   Section 5.2 describes the per-message-fields.  Section 5.3 describes
+   the per-part-fields.
+
+   NOTE:  Readers should focus on Section 5.3 as it describes the
+   essential extensions to DSN.
+
+
+
+5.2. Per-Message PNDN Fields
+
+
+5.2.1. Fields from RFC 1894
+
+   Except as noted below, the PNDN contains all fields as appropriate
+   from DSN [3].  In particular, Reporting-MTA MUST be present.
+
+   NOTE:  The sender's MTA could generate a DSN.  In this case, the
+   Reporting-MTA is optional.  However, only receiving systems will
+   generate Partial Non-Delivery Notifications.  Thus, the sender needs
+   to know who reported the failure.
+
+
+5.2.2. Original-Message-ID
+
+   The recipient system MUST generate an Original-Message-ID field if a
+   Message-ID field was present in the original message.
+
+   NOTE:  This is a change from RFC 1894.  Few User Agents insert an
+   Envelope-ID.  The sender needs to know what message failed.  Sending
+   back the original message in a multimedia environment has security
+   implications.  In particular, requiring the receiving system to send
+   back large multimedia files would make them vulnerable to denial of
+   service attacks.  Moreover, MIME-encoded body parts are in base64.
+   Since we cannot rely on the user recognizing the original text of
+
+Burger            Internet Draft - Expires 9/1/2000           [Page 7]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   their message, we must rely on alternative identifying
+   characteristics.
+
+
+
+5.3. Per-Part PNDN Fields
+
+   A PNDN contains information about attempts to deliver a message's
+   parts to one or more recipients.  A group of contiguous per-message,
+   per-recipient body-part content partial non-delivery notification
+   fields contains delivery information for that body-part.  A blank
+   line precedes each group of per-part fields.
+
+   PNDN expands upon DSN by introducing body part indicators to DSN's
+   per-recipient block.  This extension allows multiple recipients per
+   per-recipient block and multiple body part indicators per per-
+   recipient block.  A conforming implementation may choose to separate
+   each body-part / recipient failure into its own per-recipient block.
+   A conforming PNDN parser MUST be able to digest each of the three
+   reporting types.
+
+   For example, take a message sent to two users, A and B.  In
+   addition, let's say that Part 1 fails for the same reason for both
+   users, and Part 2 fails only for user B for the same reason Part 1
+   failed.  Here are three, equivalent ways of rendering the per-
+   recipient block.
+
+
+     1.   Enumerate all failures individually:
+
+             Recipient A Failure
+             Part 1 Failure
+
+             Recipient B Failure
+             Part 1 Failure
+
+             Recipient B Failure
+             Part 2 Failure
+
+     2.   Group by recipient:
+
+             Recipient A Failure
+             Part 1 Failure
+
+             Recipient B Failure
+             Part 1 Failure
+             Part 2 Failure
+
+     3.   Group by part:
+
+             Recipient A Failure
+             Recipient B Failure
+
+Burger            Internet Draft - Expires 9/1/2000           [Page 8]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+             Part 1 Failure
+
+             Recipient B Failure
+             Part 2 Failure
+
+
+   NOTE:  This RFC could have required enumeration as the only way to
+   report failures.  This makes for a cleaner standard.  However,
+   consider the case of a message sent to a large number of recipients.
+   Assuming each recipient / part combination has the same failure
+   mode, expanding all of the redundant information, such as the part
+   identification, for each recipient greatly increases the size of the
+   PNDN.
+
+5.3.1. Fields from RFC 1894
+
+   Except as noted below, the PNDN contains all fields as appropriate
+   from DSN [3].  The Original-Recipient, Final-Recipient, Last-
+   Attempt-Date, and Final-Log-ID fields follow their meaning and
+   requirements set forth in DSN.  The Will-Retry-Until field is not
+   relevant, as the PNDN is not a delayed delivery notification.
+
+
+5.3.2. Action Field
+
+   The action field reflects the disposition of the message.  Since the
+   receiving system can deliver at least part of the message, the
+   action value SHOULD be "delivered".  If the recipient system did not
+   deliver any parts of the message, then it would perform the normal
+   undeliverable message processing described by DSN [3].
+
+   NOTE: Considering partial delivery a failure or a success is a
+   matter of many debates.  There is work ongoing in the IETF to
+   develop an indicator for identifying critical body parts.  With a
+   critical body part indicator, the recipient system can return to the
+   sender a success or failure indication based on whether or not the
+   system succeeded in delivering the critical parts.
+
+   Without critical part indicators, one may chose to err on the side
+   of failing the entire message.  However, from a practical point of
+   view, the sender probably will have some idea of the capabilities of
+   the recipient.  Moreover, experience shows that users do not take
+   well to being bombarded with failure notices they believe should be
+   warnings.
+
+   Therefore, until such a time as we have a critical body part
+   indicator, the best practice is to return a delivered notice to the
+   sender, with the appropriate warning and explanation message for the
+   body part(s) not delivered.
+
+
+
+
+Burger            Internet Draft - Expires 9/1/2000           [Page 9]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+5.3.3. Final Recipient Field
+
+   The Final-Recipient field indicates the recipient for which this set
+   of per-part fields applies.  The definition of the final recipient
+   field is as described by DSN [3].  However, for security reasons,
+   the PNDN relaxes the imperative for including this field.  That is,
+   the per-part data MAY include the final recipient field
+
+   NOTE:  The change in imperative from [3], from MUST to MAY, comes
+   from the Internet Voice Mail environment.  One can envision Internet
+   Voice Mail implementations where the service provider wishes to keep
+   the actual host name of the voice mail system hidden yet in the
+   Internet name space.  Reporting the final recipient field may
+   include the actual host name of a voice mail node.  Making that
+   information public through a PNDN may enable attacks on that node.
+
+
+5.3.4. Original Content ID Field
+
+   The Original-Content-ID field MUST be present in the PNDN if a
+   Content-ID field is present in the original message.  This field
+   aids the sender in understanding exactly which body part the
+   receiving system is not capable of delivering.
+
+
+5.3.5. Original Content Description Field
+
+   The Original-Content-Description field MUST be present in the PNDN
+   if a Content-Description field is present in the original message.
+   This field aids the sender in understanding exactly which body part
+   the receiving system is not capable of delivering.  This field will
+   be much more useful than the Original-Content-ID field to a human
+   sender.  However, few User Agents insert the Content-Description
+   field in a message.
+
+
+5.3.6. Original Content Disposition Field
+
+   The Original-Content-Disposition field MAY be present in the PNDN if
+   a Content-Disposition field is present in the original message.
+
+   If the original message does not have a Content-Type field, the
+   Original-Content-Disposition field MUST be present in the PNDN if a
+   Content-Disposition field is present in the original message.
+
+   The Original-Content-Disposition field aids the sender in
+   understanding exactly which body part the receiving system is not
+   capable of delivering.  This field will be more useful than the
+   Original-Content-ID field to a human sender.  It will let the human
+   know the file name of the part the receiving system is not capable
+   of handling.
+
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 10]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+
+5.3.7. Original Content Type Field
+
+   The Original-Content-Type field MUST be present in the PNDN if a
+   Content-Type field is present in the original message.  This field
+   aids the sender in understanding exactly which body part the
+   receiving system is not capable of delivering.  This field will be
+   much more useful than the Original-Content-ID field to a human
+   sender.  It will let the human know the MIME types that the
+   receiving system is not capable of handling.  In addition, the
+   sender will get a clue as to what body part the receiving system is
+   not capable of handling from the filename sub-field, if present.
+
+
+5.3.8. Status Field
+
+   Message Transfer Agents (MTAs) are free to generate standard status
+   codes from [11].  This section describes status codes that have
+   special meaning for PNDN.
+
+   All of these status codes are of type "permanent failures of media",
+   type 5.
+
+   Receiving systems that generate Partial Non-Delivery Notifications
+   MUST insert descriptive text in the comment field of the status code
+   so a human sender can understand why his message failed.
+
+   Sending systems that automatically process returned status codes
+   MUST use the numeric status code and MUST NOT use the comment.
+
+
+5.3.8.1.  Media not Supported
+
+   If the recipient system is not capable of delivering a part of a
+   message because it does not support a given media type, it MUST
+   return the Media not Supported status code.  For example, if an
+   Internet Voice Mail system receives an AutoCAD document and it can
+   only render voice, the Internet Voice Mail system will return a
+   Media not Supported status code.
+
+   The Media not Supported status code is 5.6.1 [11].
+
+
+5.3.8.2.  Conversion With Loss Performed
+
+   If the recipient system can deliver the part, but only with a lossy
+   conversion, the receiving system SHOULD NOT return Conversion With
+   Loss Performed.
+
+   NOTE:  We considered the optional return code of Conversion With
+   Loss Performed, Status 5.6.4.  However, we realized two things.
+   First, few Internet Voice Mail systems would necessarily have the
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 11]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   capability of generating this warning.  Second, there is dubious
+   value to the sender of receiving this warning.  If the receiver has
+   trouble understanding the rendering of the body part, she can always
+   send a message to the sender.  On the other hand, we could foresee
+   confusion on the part of the sender if he constantly received
+   warning messages every time he sends a message to the particular
+   recipient.
+
+
+
+
+6.   Appendix - Examples
+
+   NOTE:  These examples are for illustrative purposes only and are not
+   a normative part of the PNDN definition.  If an example conflicts
+   with the normative description of sections 3 through 5, the example
+   is wrong.
+
+   The examples in this appendix use the following MIME-Encoded message
+   for the original sent message.
+
+   The message has three parts.  The first part is a text message.  The
+   second part is a voice message.  The third part is a fax message.
+   Here is the sample message.
+
+
+
+   Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   From: "Eric Burger" <ericb@mtc.telecnnct.com>
+   To: "Eric Burger" <eric.burger@centigram.com>
+   Subject: Three-part Message
+   Date: Mon, 22 Nov 1999 12:02:30 -0500
+   MIME-Version: 1.0
+   Content-Type: multipart/mixed;
+        boundary="----=_NextPart_000_0007_01BF34E1.74123720"
+   X-Priority: 3
+   X-Mailer: The One And Only Test Platform V8.1222.974B
+
+   This is a multi-part message in MIME format.
+
+   ------=_NextPart_000_0007_01BF34E1.74123720
+   Content-Type: text/plain;
+        charset="iso-8859-1"
+   Content-Transfer-Encoding: 7bit
+   Content-ID: TextPart0AFF8B
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+
+
+   ------=_NextPart_000_0007_01BF34E1.74123720
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 12]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   Content-Type: audio/wav;
+        name="Voice Message.wav"
+   Content-Transfer-Encoding: base64
+   Content-Disposition: attachment;
+        filename="Voice Message.wav"
+
+   UklGRjgRAABXQVZFZm10IBQAAAAxAAEAQB8AAFkGAABBAAAAAgBAAWZhY3QEAAAAwFMA
+   EQAASfYQFoWCEkuSTST3JGyiTbIfDybr9hltilsnh+uBo/OEpE1iTFGWuFEcFJFuVAxk
+   ...
+   0TIT1twS7JVeyYHHFDaWIEN1mcYMlvLNgGoakdxbL2ErxZprJS+htNhu4ozNYKmwCGvT
+   wErbIgazEvRAGn5hMxhcqGS59UE1cHEjR08A
+
+   ------=_NextPart_000_0007_01BF34E1.74123720
+   Content-Type: image/tiff;
+        name="My House.tif"
+   Content-Transfer-Encoding: base64
+   Content-Disposition: attachment;
+        filename="My House.tif"
+   Content-Description: Picture of My House
+
+   SUkqABhSAAAAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFN
+   AU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAGRqDuH4JefU8/YSwd8/xdn7CKC4PMW
+   ...
+   UAAAGgEFAAEAAAAIUgAAGwEFAAEAAAAQUgAAJAEEAAEAAAAEAAAAKAEDAAEAAAACAAAA
+   AAAAAAEARgEDAAEAAAAAAAAARwEDAAEAAAAAAAAAAAAAAA==
+
+   ------=_NextPart_000_0007_01BF34E1.74123720--
+
+
+
+6.1. PNDN With One Failed Body Part
+
+   This example shows a PNDN for a system that does not handle text,
+   but does handle voice and fax.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 13]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   <eric.burger@centigram.com>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+
+   Body part will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Original-Content-ID: TextPart0AFF8B
+
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+6.2. PNDN With Two Failed Body Parts
+
+   This example shows a PNDN for a system that does not handle text or
+   fax.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 14]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   <eric.burger@centigram.com>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+   Could Not Deliver Fax Part to < eric.burger@centigram.com >
+
+   Body parts will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Status: 5.6.1     (Media not Supported)
+   Action: delivered
+   Original-Content-ID: TextPart0AFF8B
+
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Status: 5.6.1     (Media not Supported)
+   Action: delivered
+   Original-Content-Description: Picture of My House
+   Original-Content-Type: image/tiff; name="My House.tif"
+   Original-Content-Disposition: attachment; filename="My House.tif"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+6.3. PNDN With One Body Part Failure and Two
+     Recipients
+
+   This example shows a PNDN for a system that does not handle text,
+   but does handle voice and fax.  Assume the original message was sent
+   to <ericb@mtc.telecnnct.com> and <8005551212@vm.sp.net>.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 15]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+   <8005551212@vm.sp.net>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+   Could Not Deliver Text Part to < 8005551212@vm.sp.net >
+
+   Body part will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Original-Recipient: rfc822;8005551212@vm.sp.net
+   Final-Recipient: rfc822;eburger@vmail27.sp.net
+   Original-Content-ID: TextPart0AFF8B
+
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+6.4. PNDN With One Body Part Failure for One Recipient
+     and Another Body Part Failure for Two Recipients
+
+   This example shows a PNDN for a system that does not handle text,
+   but does handle voice and fax.  However, the recipient at
+   ericb@mtc.telecnnct.com does not subscribe to a fax service.  Assume
+   the original message was sent to <ericb@mtc.telecnnct.com> and
+   <8005551212@vm.sp.net>.
+
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 16]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+   <8005551212@vm.sp.net>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+   Could Not Deliver Text Part to < 8005551212@vm.sp.net >
+   Could Not Deliver Fax Part to < eric.burger@centigram.com >
+
+   Body part will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Original-Recipient: rfc822;8005551212@vm.sp.net
+   Final-Recipient: rfc822;eburger@vmail27.sp.net
+   Original-Content-ID: TextPart0AFF8B
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;8005551212@vm.sp.net
+   Final-Recipient: rfc822;eburger@vmail27.sp.net
+   Original-Content-Description: Picture of My House
+   Original-Content-Type: image/tiff; name="My House.tif"
+   Original-Content-Disposition: attachment; filename="My House.tif"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 17]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+
+7.   Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) as described in RFC-2234 [10].
+
+
+   delivery-status-content =
+          per-message-fields 1*( CRLF per-part-fields)
+
+
+7.1. Syntax of Per-Message Fields
+
+   per-message-fields =
+          [ original-message-id-field CRLF ]
+          [ original-envelope-id-field CRLF ]
+          reporting-mta-field CRLF
+          [ dsn-gateway-field CRLF ]
+          [ received-from-mta-field CRLF ]
+          [ arrival-date-field CRLF ]
+          *( extension-field CRLF )
+
+
+   original-message-id-field =
+          "Original-Message-ID" ":" message-id
+
+   message-id = *text
+
+
+   Original-envelope-id-field, reporting-mta-field, dsn-gateway-field,
+   received-from-mta-field, arrival-date-field, and extension-field are
+   all as defined in DSN [3].
+
+
+7.2. Syntax of Per-Part Fields
+
+   per-part-fields =
+       1*( [ original-content-description-field CRLF ]
+           [ original-content-id-field CRLF ]
+           [ original-content-disposition-field CRLF ]
+           [ original-content-type-field CRLF ] )
+       1*( [ original-recipient-field CRLF ]
+           final-recipient-field CRLF )
+       action-field CRLF
+       status-field CRLF
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 18]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+       [ remote-mta-field CRLF ]
+       [ diagnostic-code-field CRLF ]
+       [ last-attempt-date-field CRLF ]
+       *( extension-field CRLF )
+
+
+   action-field =
+        "Action: delivered"
+
+   original-content-id-field =
+             "Original-Content-ID" ":" content-id
+
+   content-id = *text
+
+   original-content-description-field =
+             "Original-Content-Description" ":" content-description
+
+   content-description = *text
+
+   original-content-disposition-field =
+             "Original-Content-Disposition" ":" content-disposition
+
+   content-disposition = *text
+
+   original-content-type-field =
+             "Original-Content-Type" ":" content-type
+
+   content-type = *text
+
+   status-field =
+          "Status" ":" status-code "(" comment ")"
+
+   status-code =
+          DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+   comment = *text
+
+
+   Original-recipient-field, final-recipient-field, remote-mta-field,
+   diagnostic-code-field, last-attempt-date-field, and extension-field
+   are as defined in DSN [3].
+
+   Status-code is defined in [11].
+
+
+8.   Security Considerations
+
+   The following security considerations apply when using PNDNs.
+
+
+
+
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 19]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+8.1. Forgery
+
+   One can forge a PNDN as easily as ordinary Internet electronic mail.
+   User agents and automatic mail handling facilities (such as
+   automatic voice mail forwarding agents) that wish to make use of
+   PNDNs should take appropriate precautions to minimize the potential
+   damage from denial-of-service attacks.
+
+   Security threats related to forged PNDNs include the sending of:
+
+   (a) A falsified delivery notification when the message is
+       not delivered to the indicated recipient,
+   (b) A falsified Final-Recipient address, or
+   (c) A falsified Remote-MTA identification.
+
+
+
+8.2. Confidentiality
+
+   Another dimension of security is confidentiality.  For example, a
+   message recipient can be autoforwarding messages.  However, she does
+   not wish to divulge her autoforward address.  The desire for such
+   confidentiality will probably be heightened as "wireless mailboxes",
+   such as pagers, become more widely used as autoforward addresses.
+
+   Confidentiality also applies to the service provider.  For example,
+   in an Internet Voice Mail scenario, one can envision implementations
+   of protocols such as VPIM [5] where reporting the actual Internet
+   host name can open the system to attack.
+
+   MTA authors are encouraged to provide a mechanism that enables the
+   end user to preserve the confidentiality of a forwarding address.
+   Depending on the degree of confidentiality required, and the nature
+   of the environment to which a message were being forwarded, this
+   might be accomplished by one or more of:
+
+   (a) omitting the "Final-Recipient" field, as it has
+       little use to the sender,
+
+   (b) omitting "Remote-*" or extension fields of a PNDN
+       whenever they would otherwise contain confidential
+       information (such as a confidential forwarding address),
+
+   (c) for messages forwarded to a confidential address,
+       setting the envelope return address (e.g. SMTP MAIL FROM
+       address) to the NULL reverse-path ("<>") (so that no
+       PNDNs would be sent from a downstream MTA to the
+       original sender), or
+
+   (d) when forwarding mail to a confidential address, having
+       the forwarding MTA rewrite the envelope return address
+       for the forwarded message and attempt delivery of that
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 20]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+       message as if the forwarding MTA were the originator.
+       On its receipt of final delivery status, the forwarding
+       MTA would issue a PNDN to the original sender.
+
+   In general, the Reporting MTA site can omit any optional PNDN field
+   that it determines inclusion of the field would impose too great a
+   compromise of site confidentiality.  The need for such
+   confidentiality must be balanced against the utility of the omitted
+   information in trouble reports.
+
+   Implementers are cautioned that many existing MTAs will send non-
+   delivery notifications to a return address in the message header
+   (rather than to the one in the envelope), in violation of SMTP and
+   other protocols.  If a message is forwarded through such an MTA, no
+   reasonable action on the part of the forwarding MTA will prevent the
+   downstream MTA from compromising the forwarding address.  Likewise,
+   if the recipient's MTA automatically responds to messages based on a
+   request in the message header (such as the nonstandard, but widely
+   used, Return-Receipt-To extension header), it will also compromise
+   the forwarding address.
+
+
+
+
+9.   References
+
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+      9, RFC 2026, October 1996.
+
+   2  Freed, N. and Borenstein, N, "Multipurpose Internet Mail
+      Extensions (MIME) Part One: Format of Internet Message Bodies",
+      RFC 2045, Innosoft and First Virtual, November 1996.
+
+   3  Moore, K. and Vaudreuil, G., "An Extensible Message Format for
+      Delivery Status Notifications", RFC 1894, U. Tennessee and Octel
+      Network Services, January 1996.
+
+   4  a.k.a. VPIMv3
+
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
+      version 2", Lucent Technologies and Nortel Networks, RFC 2421,
+      September 1998.
+
+   6  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+      Levels", BCP 14, RFC 2119, March 1997.
+
+   7  Freed, N. and Borenstein, N, "Multipurpose Internet Mail
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and
+      First Virtual, November 1996.
+
+
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 21]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+
+   8  Fajman, R., "An Extensible Message Format for Message Disposition
+      Notifications", RFC 2298, National Institutes of Health, March
+      1998.
+
+   9  Vaudreuil, G., "The Multipart/Report Content Type for the
+      Reporting of Mail System Administrative Messages", RFC 1892,
+      Octel Network Services, January 1996.
+
+   10 Crocker, D. and Overell, P., "Augmented BNF for Syntax
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
+      Demon Internet Ltd., November 1997.
+
+   11 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+      Octel Network Systems, January 1996.
+
+
+
+
+10.    Acknowledgments
+
+   I'd like to thank Graham Klyne and Keith Moore for valuable insights
+   into the mechanics of DSN.  Graham Klyne also helped me put this
+   document into English.  However, any bizarre language is my own
+   fault.
+
+   Ned Freed and Herman R. Silbiger both had valuable experience
+   corroborating the assertion that users do not like to receive
+   failure notices unless there is a real failure.  Carl-Uno Mauros was
+   able to put into words much better than I did in a prior draft the
+   differences between a system that cannot render a particular part
+   versus a transmission failure.
+
+
+
+11.    Author's Address
+
+   Eric W. Burger
+   Centigram Communications Corporation
+   Maryland Technology Center
+   1375 Piccard Dr., MS 150 R
+   Rockville, MD  20850-4311
+   USA
+   Phone: +1 301/212-3320
+   Email: e.burger@ieee.org
+
+
+
+
+
+
+
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 22]
+                  Partial Non-Delivery Notification      March 1, 2000
+
+
+12.    Notices and Full Copyright Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances
+   of licenses to be made available, or the result of an attempt made
+   to obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification
+   can be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   Copyright (C) 1999, 2000 The Internet Society.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its 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.
+
+
+
+
+
+
+Burger            Internet Draft - Expires 9/1/2000          [Page 23]
+
diff --git a/Documentation/en/I-D/draft-ema-vpim-pndn-02.txt b/Documentation/en/I-D/draft-ema-vpim-pndn-02.txt
new file mode 100644
index 00000000..43653699
--- /dev/null
+++ b/Documentation/en/I-D/draft-ema-vpim-pndn-02.txt
@@ -0,0 +1,9 @@
+

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

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

+

+Draft Author(s):

+

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

+

+

diff --git a/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt b/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt
new file mode 100644
index 00000000..bdcd591f
--- /dev/null
+++ b/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

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

+

+

diff --git a/Documentation/en/I-D/draft-hall-dm-idns-00.txt b/Documentation/en/I-D/draft-hall-dm-idns-00.txt
new file mode 100644
index 00000000..d3bc4b4e
--- /dev/null
+++ b/Documentation/en/I-D/draft-hall-dm-idns-00.txt
@@ -0,0 +1,2739 @@
+
+
+  INTERNET-DRAFT                                      Eric A. Hall, Editor 
+  Document: draft-hall-dm-idns-00.txt                           Consultant 
+  Expires: May 2002                                          November 2001 
+      
+      
+                  The Internationalized Domain Name System 
+      
+      
+     Status of this Memo 
+      
+     This document is an Internet-Draft and is in full conformance with 
+     all provisions of Section 10 of RFC2026. 
+      
+     Internet-Drafts are working documents of the Internet Engineering 
+     Task Force (IETF), its areas, and its working groups. Note that 
+     other groups may also distribute working documents as Internet-
+     Drafts. 
+      
+     Internet-Drafts are draft documents valid for a maximum of six 
+     months and may be updated, replaced, or obsoleted by other 
+     documents at any time. It is inappropriate to use Internet-Drafts 
+     as reference material or to cite them other than as "work in 
+     progress." 
+      
+     The list of current Internet-Drafts can be accessed at 
+     http://www.ietf.org/ietf/1id-abstracts.txt. 
+      
+     The list of Internet-Draft Shadow Directories can be accessed at 
+     http://www.ietf.org/shadow.html. 
+      
+      
+  1.      Abstract 
+      
+     The principle intention of this specification is to facilitate the 
+     deployment of a completely internationalized domain name syntax 
+     and service which new protocols, applications and host systems can 
+     use, but without disrupting the existing infrastructure. Towards 
+     that end, this document describes a series of elective 
+     encapsulation services and protocol extensions which cumulatively 
+     allow internationalized domain names to be stored and transmitted 
+     in the existing DNS message and within application data streams, 
+     according to the compliance level of the participating systems. 
+      
+   
+   
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+      
+     Table of Contents 
+      
+     1.   Abstract..................................................1 
+     2.   Definitions and Terminology...............................3 
+     3.   Introduction..............................................4 
+       3.1.  Background.............................................4 
+       3.2.  Objectives.............................................5 
+       3.3.  Common Usage Scenarios.................................7 
+       3.4.  User Audiences.........................................9 
+       3.5.  Service Overview......................................11 
+       3.6.  Process Example.......................................13 
+     4.   The Internationalized Namespace..........................19 
+       4.1.  Internationalized Domain Names and Labels.............20 
+       4.2.  Internationalized Host Identifiers....................27 
+       4.3.  STD13 Domain Names....................................28 
+       4.4.  STD13 Host Identifiers................................29 
+     5.   Transfer Encodings and Label Types.......................30 
+       5.1.  The EDNS/UTF-8 Label Type.............................31 
+       5.2.  The STD13 Legacy Label Type...........................33 
+     6.   Application Guidelines...................................36 
+       6.1.  Input and Output Charsets.............................37 
+       6.2.  Protocol and Application Data.........................38 
+       6.3.  DNS Lookups and Resolver Calls........................40 
+     7.   Resolver Guidelines......................................42 
+       7.1.  Resolver APIs.........................................42 
+       7.2.  Query Processing Services.............................44 
+       7.3.  The Hosts Database....................................48 
+     8.   Server Guidelines........................................49 
+       8.1.  Internationalized Zones...............................50 
+       8.2.  Namespace Visibility Restrictions.....................51 
+       8.3.  The Master File Format................................52 
+     9.   Caching Guidelines.......................................53 
+     10.  Security Considerations..................................53 
+     11.  IANA Considerations......................................54 
+     12.  References...............................................54 
+     13.  Acknowledgements.........................................55 
+     14.  Editor's Address.........................................55 
+      
+   
+  Hall                    I-D Expires: May 2002               [page 2] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+      
+  2.      Definitions and Terminology 
+      
+     This document unites, enhances and clarifies several pre-existing 
+     technologies. Readers are expected to be familiar with the 
+     following specifications: 
+      
+          [AMC-ACE-Z] <draft-ietf-idn-amc-ace-z>, "AMC-ACE-Z version 
+            0.3.1" 
+      
+          [NAMEPREP] <draft-ietf-idn-nameprep>, "Preparation of 
+            Internationalized Host Names" 
+      
+          [STD13] (RFC 1034) "Domain names - concepts and facilities", 
+            (RFC 1035) "Domain names - implementation and 
+            specification" 
+      
+          [STD3] (RFC 1122) "Requirements for Internet Hosts -- 
+            Communication Layers", (RFC1123) "Requirements for Internet 
+            Hosts -- Application and Support" 
+      
+          [BCP18] (RFC 2277) "IETF Policy on Character Sets and 
+            Languages" 
+      
+          [RFC2279] "UTF-8, a transformation format of ISO 10646" 
+      
+          [RFC2671] "Extension Mechanisms for DNS (EDNS0)" 
+      
+      
+     The following abbreviations are used throughout this document: 
+      
+          UCS (Universal Character Set) “ The ISO/IEC 10646 character 
+            set repertoire, as represented by the Unicode 3.1 
+            specification. 
+      
+          ACE (ASCII-Compatible Encoding) “ A transfer encoding which 
+            encodes UCS character codes into a seven-bit codespace 
+            which is compatible with US-ASCII. 
+      
+          UTF-8 (UCS Transformation Format, Eight-Bit) “ A transfer 
+            encoding which encodes UCS characters into an eight-bit 
+            codespace which is compatible with DNS message formats. 
+      
+     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
+     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
+     in this document are to be interpreted as described in RFC 2119. 
+   
+  Hall                    I-D Expires: May 2002               [page 3] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+      
+      
+  3.      Introduction 
+      
+     The domain name system (DNS) [STD13] currently defines a message, 
+     namespace and protocol. Although the DNS message is capable of 
+     transferring eight-bit character codes as protocol data, 
+     applications are currently limited to a subset of US-ASCII when 
+     they interact with the DNS namespace, and this restricted syntax 
+     is enforced by almost every TCP/IP application and protocol which 
+     utilizes domain names as embedded data (including, surprisingly, 
+     the DNS protocol). 
+      
+     In order to allow for the use of a larger range of characters in 
+     the namespace, this document extends and clarifies a variety of 
+     Internet specifications so that characters from the Universal 
+     Character Set (UCS) [ISO10646] may be used in domain names. This 
+     document also extends the DNS message structure to allow for the 
+     use of UTF-8 [RFC2279] encoded characters for the purpose of 
+     transferring these domain names, but also provides an ASCII-
+     compatible encoding (ACE) [AMC-ACE-Z] of these character codes 
+     which existing protocols and applications can use to access the 
+     internationalized domain names, and also provides identification 
+     mechanisms which allow the end-point systems to downwardly 
+     negotiate when needed. Finally, this document defines behavior for 
+     DNS systems which implement this architecture, including the end-
+     point applications which generate and store DNS domain names, and 
+     the resolvers, caches and servers which process them. 
+      
+     The mechanisms presented here are elective. Developers, zone 
+     administrators and network operators who wish to make use of the 
+     internationalized domain names may do so according to their own 
+     schedule. Those developers, administrators and operators who 
+     cannot or prefer not to implement the specified extensions can 
+     continue to use their legacy systems, and will still be able to 
+     access resources from the internationalized domain name system. 
+      
+      
+  3.1.    Background 
+      
+     From one perspective, DNS is already an "eight-bit clean" system, 
+     in that the structured DNS message is capable of storing and 
+     transmitting eight-bit data without any additional effort. 
+     However, this perspective only considers one particular facet of 
+     the domain name system, and ignores the more critical aspect of 
+   
+  Hall                    I-D Expires: May 2002               [page 4] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     the DNS namespace, which has rules that are entirely different 
+     from those which govern the message format. 
+      
+     The DNS namespace (or more appropriately, the view of the 
+     namespace which applications use and enforce) is governed by rules 
+     set forth in RFC952 [RFC952], STD3 [STD3], and STD13, which 
+     collectively define the characters that are eligible for use with 
+     host names. These rules are meant to provide a common template 
+     which may be applied to either the DNS namespace or a local hosts 
+     database, such that a query for "host.example.com" can be 
+     processed through either system. The range of valid characters 
+     currently defined are the letters, numbers and hyphen characters 
+     from US-ASCII [ASCII] (additional rules also govern the valid 
+     order and length of a host name). Character code values outside of 
+     this range are valid in domain name messages, but are undefined 
+     when used in the namespace, and are subject to interpretation by 
+     the applications which generate them. 
+      
+     The host name rules are enforced by almost every application and 
+     protocol which uses DNS to identify a host or system. This 
+     includes network utilities such as ping and traceroute which 
+     simply identify systems by name, and complex protocols such as 
+     SMTP which use domain names to determine message-routing paths. 
+     Portions of the DNS protocol itself are also affected by these 
+     restrictions, such as the domain names which may be used for NS 
+     resource records with sub-domain delegation operations (since 
+     these servers are connection targets, they are also required to be 
+     compliant with the host name rules). 
+      
+     Because these domain names are so pervasive throughout the 
+     Internet (and even within proprietary applications that run on 
+     private networks), it is not possible to declare a "flag day" at 
+     which eight-bit domain names will be considered valid encodings of 
+     a particular character set. Instead, an extended namespace with a 
+     larger set of charset rules must be defined, an extended DNS 
+     protocol capable of supporting these domain names must be 
+     deployed, and a transitional mechanism which allows the old and 
+     new systems to interact must be established. This document 
+     attempts to meet these objectives. 
+      
+      
+  3.2.    Objectives 
+      
+     In broad terms, this document has one overall goal, which is to 
+     facilitate the creation and use of an internationalized domain 
+     name system around a UCS namespace, a collection of UTF-8 and 
+   
+  Hall                    I-D Expires: May 2002               [page 5] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     legacy-compatible encodings which are suitable for transferring 
+     internationalized domain names within DNS and the affected 
+     application data streams, and a negotiation mechanism which allows 
+     end-point systems to identify the encoding that they will use for 
+     a particular operation. 
+      
+     One of the objectives stated above is to internationalize the 
+     existing DNS namespace, by allowing UCS characters to be used in 
+     host names and sub-domain delegations in old and new zones 
+     equally. As such, this document does not define a new namespace, 
+     but instead defines mechanisms by which leaf-nodes and sub-domains 
+     may be created within the existing hierarchy. 
+      
+     UTF-8 was chosen as the primary transfer encoding of these domain 
+     names for several reasons. For one, there is a wide availability 
+     of tools and expertise surrounding UTF-8, and it is already widely 
+     deployed within development environments, operating systems and 
+     applications. Furthermore, BCP18 [BCP18] requires that new 
+     application protocols be able to use UTF-8 as application data, 
+     and for many applications, this specifically means domain names 
+     which are passed as data. All signs indicate that UTF-8 is 
+     currently and will continue to be the preferred eight-bit encoding 
+     on the Internet, and this specification embraces this position in 
+     its design. 
+      
+     However, most of the network services currently in use are bound 
+     by the legacy host naming restrictions, and those applications and 
+     protocols will also need to be able to interact with resources 
+     from the internationalized namespace, even though they will not be 
+     compliant with the UTF-8 encoding mechanisms defined in this 
+     document. In order to allow these systems to participate, this 
+     specification also embraces the use of ACE as a seven-bit 
+     backwards-compatible encoding for legacy systems to use. 
+      
+     Note that even though a single encoding could have been specified 
+     by this document, past and present requirements would not have 
+     been satisfied by a single choice. For example, supporting UTF-8 
+     alone would mean isolating legacy systems from resources in the 
+     UCS namespace, while supporting ACE alone would not have provided 
+     a truly internationalized namespace (the ACE encoded domain names 
+     still appear in user data quite frequently). By allowing the UTF-8 
+     and ACE encodings to coexist, the existing and emerging 
+     communities can both be served. 
+      
+     Because both encodings will be active during the same time period, 
+     this document also defines DNS protocol extensions which allow the 
+   
+  Hall                    I-D Expires: May 2002               [page 6] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     end-point systems to detect the encoding that is in use for a 
+     particular query/response pair. Note that these negotiation 
+     mechanisms not only allow new and legacy systems to interoperate, 
+     but they also provide a transition service for developers, zone 
+     administrators and end-users, in that ACE encoded domain names can 
+     be initially deployed within existing applications and DNS 
+     systems, while individual elements of the infrastructure can be 
+     upgraded without disturbing other components. 
+      
+      
+  3.3.    Common Usage Scenarios 
+      
+     Discussion of the mechanism provided by this document depends upon 
+     the usage context of the domain names themselves. Domain names are 
+     extremely pervasive, and are used by almost every TCP/IP protocol 
+     and application in one form or another. However, most usages fall 
+     under one or more of the following scenarios: 
+      
+        *   Connection identifiers “ Domain names are most commonly 
+            used as host-specific identifiers for outbound connection 
+            requests, whether this be for a command-line application 
+            such as ping, or as a host name which is stored in an 
+            application's configuration file. Another common usage 
+            scenario for connection identifiers is with reverse 
+            lookups, where a server is logging incoming connections by 
+            the corresponding domain name, or where a program such as 
+            netstat is displaying all of the application sessions which 
+            are currently active on a host. In both of these cases, 
+            domain names are passed through applications to a resolver, 
+            resulting in DNS queries and responses which eventually 
+            provide the requested DNS data. 
+      
+            A related use (but one which does not generate DNS 
+            messages) is determining the host name of the local system. 
+            This is commonly found with applications and protocols that 
+            need to display the domain name of the local system as part 
+            of a protocol operation (such as an SMTP greeting banner) 
+            or as application data. 
+      
+            Connection identifiers (and lookups in general) are 
+            probably the largest single use of domain names today, and 
+            this is likely to be the case with internationalized domain 
+            names as well. This document fully supports the use of 
+            internationalized domain names for lookup operations, as 
+            long as the calling application, the stub resolver, the 
+            local caching servers, and the authoritative servers for 
+   
+  Hall                    I-D Expires: May 2002               [page 7] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            the specified domain name are compliant with this 
+            specification. If any of these components are not capable 
+            of supporting internationalized domain names in this 
+            manner, the ACE equivalent domain name will be negotiated 
+            for the operation at hand. 
+      
+        *   Protocol data “ Some application protocols exchange domain 
+            names as protocol data, with those domain names either 
+            determining or altering a service-specific operation. 
+            Examples of this usage include SMTP envelopes ("RCPT TO 
+            <user@domain.dom>") where the domain name is used to 
+            determine whether or not a particular email message should 
+            be accepted for delivery, the HTTP HOST header field which 
+            identifies a specific document tree on a shared server, 
+            BOOTP/DHCP options, WHOIS input, and more. 
+      
+            Because these protocols treat domain names as protocol 
+            data, most of these protocols also have specific formatting 
+            requirements which must be addressed before UTF-8 domain 
+            names can be used by these protocols directly. This 
+            document is intended to facilitate the use of UTF-8 encoded 
+            domain names in this manner, although it is expected that 
+            most of the protocol development groups will need to 
+            develop negotiation mechanisms before these protocols can 
+            use internationalized domain names directly. Until such 
+            work is completed, ACE equivalent domain names can be used 
+            to provide these protocols with access to the 
+            internationalized namespace. 
+      
+        *   Structured application data “ Structured application data 
+            is similar to protocol data in that it can trigger or 
+            affect some protocol action, although this will not always 
+            occur. For example, a web browser can process an embedded 
+            IMG link which may be present in a web page, while a user 
+            can manually follow an embedded email link which is also 
+            stored in the same web page; even though both usage models 
+            share the same structured data format (URLs), they are 
+            processed differently by the application. Similarly, email 
+            messages typically contain multiple domain names as 
+            structured data in the message headers, and some of these 
+            domain names will directly affect subsequent protocol 
+            operations, while others will not. 
+      
+            Because of this ambiguity, this document defines no 
+            specific treatment for structured application data. In some 
+            cases, no additional mechanisms will be required, while 
+   
+  Hall                    I-D Expires: May 2002               [page 8] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            other scenarios will require negotiation mechanisms before 
+            an internationalized domain name can be used in the 
+            structured data (with ACE being required as the interim 
+            format). Each protocol development group is encouraged to 
+            analyze each usage independently, to classify the usage as 
+            a connection identifier, protocol data, or unstructured 
+            application data, and to determine the appropriate course 
+            of action for each usage accordingly. 
+      
+        *   Unstructured application data “ Many application protocols 
+            provide free-text data which can contain domain names, but 
+            with those domain names existing as unstructured data. For 
+            example, an email message which is provided as a text/plain 
+            MIME body part may contain a domain name which identifies a 
+            system or service in the context of a specific application, 
+            but in an unstructured form ("your files were moved from 
+            server1 to server2"). Similarly, an email address may be 
+            provided in WHOIS output, but as unstructured data which 
+            does not affect the protocol. 
+      
+            Given the application-specific nature of this data, it 
+            cannot be managed by any global protocol or process. Where 
+            a protocol has rules or restrictions on the data itself, 
+            then those rules are maintained, but some formatting rules 
+            may need to be extended before internationalized domain 
+            names (or their equivalents) can be encoded in the 
+            application data. For example, internationalized domain 
+            names in email messages may need to be converted to a 
+            preferred display charset, while ACE equivalents may be 
+            necessary for protocols which only support US-ASCII. 
+      
+     Each of the above scenarios represent distinct handling cases 
+     where internationalized domain names may or may not be used 
+     directly. In some cases, the internationalized domain names may be 
+     used as soon as the applications and resolvers are configured to 
+     use them, while in other cases, measured and cautious deployment 
+     is required in order to prevent undue breakage. In the latter 
+     cases, however, the backwards-compatible ACE encoding is available 
+     so that the internationalized domain names can be used. 
+      
+      
+  3.4.    User Audiences 
+      
+     Another perspective on the changes which will result from 
+     deploying the mechanisms described in this document can be seen by 
+     analyzing how any such changes will affect the different 
+   
+  Hall                    I-D Expires: May 2002               [page 9] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     "audiences" who work with domain names, and who have their own 
+     unique context-specific usage requirements and objectives. The 
+     three main audiences discussed in this document are: 
+      
+        *   Developers. Protocol and application developers need to be 
+            able to incorporate internationalized domain names into 
+            their systems as easily as possible, although there are 
+            many factors which will affect such usage, including the 
+            input and output charsets and encodings which are available 
+            to the applications and protocols. Where feasible, this 
+            specification allows developers to choose any charset or 
+            encoding which may be required and suitable for use, 
+            although in most cases, a recommendation is also made for 
+            the use of UTF-8 in particular. 
+      
+            Developers may adopt internationalized domain names for 
+            connection identifiers and lookup operations fairly 
+            quickly, such that users can use those system as soon as 
+            they have compliant systems (and they have a target domain 
+            name to communicate with). Implementing support for 
+            internationalized domain names in protocols and application 
+            data will require additional effort by the affected 
+            development groups. 
+      
+            Support for ACE will be harder to implement, since it is a 
+            relatively new and untested encoding syntax, with no 
+            existing developer tools. This will likely be the largest 
+            hurdle to overcome when developing applications for use 
+            with this service. 
+      
+        *   Zone administrators. Organizations that wish to deploy 
+            internationalized domain names should be able to do so 
+            easily, at a reasonable cost, and without suffering 
+            excessive pre-conditions. Towards this objective, the 
+            mechanisms described by this document allow organizations 
+            to deploy and use internationalized domain names within any 
+            zone immediately, without requiring any other zone to have 
+            been updated beforehand (although there are specific and 
+            strong suggestions for upgrading the Internet's high-load 
+            servers as soon as possible). 
+      
+            If an organization wishes to publish internationalized 
+            domain names for users to access and utilize, the 
+            authoritative servers for the affected zone must be 
+            compliant with the naming rules and message formats 
+            described by this document, which will almost certainly 
+   
+  Hall                    I-D Expires: May 2002              [page 10] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            require the administrators of that zone to upgrade their 
+            servers. However, organizations may also choose to only 
+            deploy ACE encoded domain names if an immediate migration 
+            is not feasible, with the caveat that internationalized 
+            domain names in their native form will not be available 
+            from those zones. 
+      
+        *   Network operators. The systems and human users which 
+            generate DNS lookups are another area of concern, as these 
+            protocols, programs and users will expect these lookups to 
+            succeed, and will also expect that the visible namespace 
+            will be compatible with the capabilities of the requesting 
+            system at a minimum investment. This is a broad range of 
+            requirements. 
+      
+            At a minimum, applications must be capable of generating 
+            and accepting the internationalized domain names if they 
+            are to use those domain names (see the "Developers" 
+            discussion above for the application requirements). 
+            Similarly, the local resolvers, caches and forwarders on 
+            the user's network must also support the message formats if 
+            they are to relay internationalized domain names between 
+            their local applications and the remote zones being 
+            queried. If the applications, resolvers and caches do not 
+            support these requirements, intermediary systems will 
+            perform the down-level negotiation automatically on their 
+            behalf such that additional effort is not required on the 
+            user's part. 
+      
+     In summary, the developers, zone administrators and end-users can 
+     immediately participate in the internationalized namespace at no 
+     additional expense if they are content with using ACE encoded 
+     domain names, and can use internationalized domain names in their 
+     native form if they are willing to make the necessary investments. 
+     Furthermore, since the native and backwards-compatible encodings 
+     are not mutually exclusive, implementers of this specification 
+     have the option of adopting ACE for immediate use and then 
+     transitioning to internationalized domain names on a per-system, 
+     per-zone, or per-application basis, according to their schedule. 
+      
+      
+  3.5.    Service Overview 
+      
+     This document specifies a variety of extensions to several 
+     different protocols and services in order to facilitate the use of 
+     internationalized domain names anywhere this support exists or can 
+   
+  Hall                    I-D Expires: May 2002              [page 11] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     be implemented, and to provide a legacy-compatible domain name in 
+     all other situations. 
+      
+     More specifically, this document defines or clarifies behavior for 
+     the following elements: 
+      
+        *   Host name character restrictions. Legacy protocols and 
+            applications are currently restricted to the legacy host 
+            naming rules, which only allow for a subset of US-ASCII 
+            characters (letters, digits and the hyphen character). This 
+            document redefines the characters which are valid within a 
+            host name so that system identifiers, domain name parts of 
+            host names, and new network services can use most of the 
+            characters from the UCS. 
+      
+        *   DNS message format. This document defines an extended label 
+            format based on the extended label services provided by 
+            RFC2671 (Extension Mechanisms for DNS - EDNS0) [RFC2671], 
+            with this label format being used to encapsulate UTF-8 
+            encoded internationalized domain names in DNS messages. Any 
+            DNS message which carries the UTF-8 encoded domain names is 
+            required to use the EDNS/UTF-8 label type defined in this 
+            document. Any DNS message which carries legacy domain names 
+            (including the ACE encoded equivalent domain names) is 
+            required to use the traditional message format. 
+      
+        *   Application handling rules. Applications can use 
+            internationalized domain names immediately for lookup 
+            operations that do not directly affect external services or 
+            protocols, and can use ACE encoding sequences to specify 
+            internationalized domain names in legacy protocol 
+            operations, and can use them both at the same time. 
+      
+        *   Stub resolvers. Stub resolvers will most likely need to 
+            provide a series of internationalized APIs in order to 
+            fully support applications that generate internationalized 
+            domain name lookups. For example, these APIs will almost 
+            certainly be required in order for the resolver to 
+            determine that the calling application is compliant with 
+            the host name requirements defined by this document, and 
+            that the domain names should be encoded in the proper label 
+            format. Although this specification does not dictate these 
+            APIs, it encourages their use, and provides some guidance 
+            on the issues surrounding their use. 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 12] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+        *   Forwarders, resolving servers and caches. The user-side 
+            servers which process internationalized domain names have 
+            several protocol-specific requirements, including the 
+            negotiated fall-back service when UTF-8 queries fail. 
+      
+        *   Authoritative servers. A key part of this specification is 
+            the simultaneous support for internationalized and legacy 
+            compatible domain names in the UCS namespace, thereby 
+            allowing a domain name to be entered into an authoritative 
+            zone database once, and for the appropriate response to be 
+            generated by a server according to the label encoding from 
+            the associated query. In order for this to work, this 
+            specification requires authoritative servers which serve 
+            internationalized domain names to comply with specific 
+            conditions. This specification also allows existing servers 
+            to serve ACE equivalent domain names when the authoritative 
+            servers cannot be upgraded, although this typically results 
+            in lower levels of functionality. 
+      
+     The elements listed above collectively define a completely 
+     internationalized domain name system, which is capable of 
+     servicing internationalized domain names in all compliant systems, 
+     and which is also capable of providing ACE encoded equivalent 
+     domain names when any component from the internationalized service 
+     is not available. 
+      
+      
+  3.6.    Process Example 
+      
+     This section illustrates a series of query/response transactions 
+     under which the processes and protocols defined in this document 
+     function. This example uses a reverse lookup for the PTR resource 
+     record associated with the "14.2.0.192.in-addr.arpa." domain name 
+     (forward lookups work similarly, but the issues are more fully 
+     demonstrated by PTR lookups). Each of the various technologies 
+     shown below are described in later sections of this document. The 
+     sole purpose of this example is to provide an illustration of 
+     these mechanisms in order to facilitate better discussion. 
+      
+     Note that this illustration represents a worst-case scenario 
+     (thereby exercising most of the functionality provided by this 
+     specification), and does not represent a typical scenario. 
+      
+        a.  First, a PTR resource record for 14.2.0.192.in-addr.arpa. 
+            is added to the internationalized zone database on the 
+            replication master server for the 2.0.192.in-addr.arpa. 
+   
+  Hall                    I-D Expires: May 2002              [page 13] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            zone, with the resource record data value of 
+            "host.<idn>.example.com." (where <idn> is an 
+            internationalized domain name compliant with the host 
+            naming rules provided in this document). Both of these 
+            domain names have a primary representation consisting of 
+            UCS characters in some local encoding, but are also 
+            available as UTF-8 and ACE encoded data so they can be 
+            encapsulated within DNS queries and responses. 
+      
+            Once the zone is reloaded and is replicated by the other 
+            authoritative servers for that zone, the domain names can 
+            be processed. 
+      
+        b.  An application on a remote system generates a DNS lookup 
+            for the PTR resource record associated with the 
+            14.2.0.192.in-addr.arpa. domain name. 
+      
+            If this is a legacy application, it issues the lookup using 
+            the only method it knows, which is to pass the domain name 
+            to the legacy resolver API. This would result in the 
+            resolver issuing a legacy DNS query for the PTR resource 
+            record associated with the specified domain name. 
+      
+            If this application is compliant with this specification, 
+            it performs the following steps: 
+      
+            1.   Verify that the resolver is capable of processing 
+                 queries for UTF-8 domain names by probing for an 
+                 internationalized API. If this step failed, then the 
+                 domain name would be converted to the legacy STD13 
+                 octet encoding in step 3.6.b.3 and passed to the 
+                 resolver's legacy API. 
+      
+            2.   Convert the domain name from its generated encoding to 
+                 the canonical UCS characters, and then normalize and 
+                 case-convert the UCS characters. 
+      
+            3.   Convert the normalized and lowercased UCS characters 
+                 to the charset or encoding used by the resolver's 
+                 internationalized API. 
+      
+            4.   Issue a lookup for the PTR resource record associated 
+                 with the internationalized domain name, via the 
+                 resolver's internationalized API. 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 14] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+                 Note that even though the domain name is compatible 
+                 with the legacy host name rules, the domain name is 
+                 passed through the internationalized API so that 
+                 servers can tell whether or not the original 
+                 application is UTF-8 compliant, and can determine the 
+                 format of any internationalized domain names which are 
+                 to be returned in the response messages. This is 
+                 required in case the queried resource record includes 
+                 internationalized domain names as resource record data 
+                 (as would be the case with PTR resource records), and 
+                 is also required for the proper handling of any SOA or 
+                 NS resource records which may be returned as 
+                 additional data in the response. 
+      
+            For the purpose of this example, we will assume that each 
+            of these steps were successfully performed. 
+      
+        c.  The client's stub resolver generates the query, with the 
+            Question Section of the query containing the UTF-8 encoded 
+            domain name encapsulated in an EDNS/UTF-8 extended label. 
+      
+        d.  The stub resolver sends the query to one of its configured 
+            resolving servers. 
+      
+        e.  The resolving server will either answer the query from its 
+            cache or forward the query to a name server which is 
+            authoritative for the namespace hierarchy, as per the 
+            normal query-resolution procedure. For the purpose of this 
+            example, we will assume that the server has no information 
+            about the specified domain name, so it forwards the query 
+            to one of the root zone's authoritative servers in order to 
+            begin the iterative resolution process. 
+      
+        f.  The queried server responds with a referral, providing 
+            delegation data for a zone in the path to the queried 
+            domain name. For the purposes of this example, we will use 
+            192.in-addr.arpa. as the delegation domain specified in the 
+            referral message. 
+      
+            The specific format of the referral will depend on whether 
+            or not the queried server understands the EDNS/UTF-8 label 
+            encoding. If the server is compliant with this 
+            specification (which it is, or else it wouldn't have 
+            answered with a referral), then the referral will also 
+            provide ENDS/UTF-8 encoded domain names in the Authority 
+            and Additional-Data Sections of the referral. If the server 
+   
+  Hall                    I-D Expires: May 2002              [page 15] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            was not compliant with this specification, it would return 
+            an error upon seeing the extended label type, which would 
+            cause the resolving server to restart the query using the 
+            legacy label type. 
+      
+        g.  The resolving server decodes the UTF-8 encoded domain names 
+            to their UCS character representation, caches the resource 
+            records in their UCS form, and sends the query to one of 
+            the authoritative servers for the referral zone. Note that 
+            the cache did not normalize or case-convert the UCS 
+            characters; only the end-systems perform this work. 
+      
+        h.  In this case, the queried server does not understand the 
+            EDNS/UTF-8 label format, and has returned a FORMERR 
+            response code. 
+      
+        i.  When these errors are encountered, the current resolver 
+            (whether this is the client's stub resolver or a caching 
+            server in the query path) must convert the query domain 
+            name from its current form to a legacy-compatible encoding 
+            (either ACE or STD13 octet sequences, depending on the UCS 
+            characters which have been encoded), and then has to 
+            reissue the query in that format. 
+      
+            In this case, the domain name only contains printable 
+            characters from US-ASCII, so the STD13 octet encoding is 
+            used for the fall-back query. Because the UCS domain name 
+            was normalized and lowercased before it was passed to the 
+            client's stub resolver, the legacy domain name will also be 
+            in this format (although it will be compared in a case-
+            neutral form by the recipient server). 
+      
+            Note that once this conversion takes place, the legacy 
+            label format is used for the remainder of the current query 
+            chain (this prevents excessive delays from multiple fall-
+            back operations, which could result in timeouts at the 
+            original resolver or application).  
+      
+   
+  Hall                    I-D Expires: May 2002              [page 16] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+        j.  The queried server returns a delegation referral for the 
+            2.0.192.in-addr.arpa. zone. Since the query arrived in the 
+            STD13 octet encoding, the server has no indicator of the 
+            client's capabilities, so the referral NS resource records 
+            will also be returned in legacy compatible form (either as 
+            STD13 octet sequences or as ACE encoded data, depending on 
+            the character codes provided in each label from each of the 
+            associated domain names). 
+      
+            Note that even though these NS resource records will be 
+            restricted to legacy-compatible host names and label types, 
+            they may contain and reference ACE domain names. In this 
+            regard, a legacy server in the delegation path does not 
+            prevent internationalized domain names from being delegated 
+            or resolved, but only prevents them from being processed as 
+            EDNS/UTF-8 extended labels. 
+      
+            Also note that once the authoritative servers for a zone 
+            have been discovered and cached, any subsequent UTF-8 
+            queries which are generated for the resources in that zone 
+            will be sent directly to one of those servers, bypassing 
+            the delegation hierarchy. As such, subsequent queries which 
+            are provided in EDNS/UTF-8 labels can be processed directly 
+            by the zone's authoritative servers, without the delegation 
+            servers disrupting the process. 
+      
+        k.  The resolving server decodes the STD13 octet sequences and 
+            ACE encoded domain names to their UCS character 
+            representations, caches the resource records, and resends 
+            the query to one of the authoritative servers for the 
+            referral zone. 
+      
+        l.  The queried server processes the request. Since this query 
+            arrived as an STD13 octet sequence, the server must compare 
+            the seven-bit characters from the domain name (which is all 
+            of them, in this example) in a case-neutral form. Note that 
+            if the query had arrived as ACE or UTF-8 encoded domain 
+            names, the server would have decoded the specified domain 
+            name to its canonical UCS characters and performed a case-
+            exact match against the resulting characters. 
+      
+        m.  The queried server responds with the requested data. Note 
+            that the query was submitted in the legacy label form due 
+            to the fall-back processing which occurred in step 3.6.i, 
+            so the server will only respond to this query with STD13 
+   
+  Hall                    I-D Expires: May 2002              [page 17] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            octet sequences or ACE encoded domain names, using the 
+            STD13 legacy label. 
+      
+        n.  The resolving server decodes the STD13 octet sequences and 
+            ACE encoded domain names to their UCS character 
+            representations, and caches the resource records. Since the 
+            query was originally received as an internationalized 
+            domain name (as indicated by the EDNS/UTF-8 extended label 
+            from the original query), the resolving server has to 
+            encode the answer data as UTF-8 before passing it back to 
+            the client's stub resolver. However, since the input was 
+            not provided in an encoded UCS form, the server has to 
+            normalize and case-convert the STD13 octet sequence in 
+            order to provide a valid internationalized domain name. 
+      
+        o.  The stub resolver decodes the UTF-8 encoded domain names 
+            which have been provided in the response message to their 
+            UCS character representation, and passes the data to the 
+            original calling application using the charset or encoding 
+            favored by the resolver. 
+      
+        p.  The application validates the received domain name by 
+            decoding the internationalized domain name to its canonical 
+            UCS characters, normalizing and down-casing the resulting 
+            domain name, and comparing the results with the answer data 
+            which was provided by the resolver. 
+      
+     As can be seen, the UTF-8 name resolution process is identical to 
+     the current resolution process, with the addition of a single 
+     fall-back query in step 3.6.i which resulted in one extra 
+     query/response pair (roughly equivalent to adding one extra 
+     delegation referral into the query path), and with several 
+     different encoding conversions, as required by the participating 
+     systems and services. This example also illustrates the 
+     requirements which are placed on developers, zone administrators, 
+     and network operators in order for typical connection identifier 
+     services to function with UTF-8 domain names. 
+      
+     However, if each system and service had used UTF-8 for encoding 
+     purposes (including everything between the stub resolver's APIs 
+     and the authoritative servers for the target zone), then no 
+     additional queries or conversions would have been required (other 
+     than the direct UCS conversions required for validation and 
+     caching, the latter of which can be performed separately without 
+     affecting the processing path). In this regard, the example above 
+     illustrates how this system can function even when only a portion 
+   
+  Hall                    I-D Expires: May 2002              [page 18] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     of the participating systems utilize UTF-8, and also illustrates 
+     how effective the entire operation would be if all of the 
+     recommendations and requirements provided in this specification 
+     were adopted. 
+      
+     It is also important to reiterate here that any such costs 
+     associated with this compliance are entirely elective by the 
+     affected parties. If they want to streamline the process, the 
+     option is available to them, although the system also works when 
+     very few optimizations are implemented. 
+      
+      
+  4.      The Internationalized Namespace 
+      
+     In simple terms, this specification defines an internationalized 
+     namespace which consists of domain names and labels that contain 
+     UCS character codes, and also specifies a series of encoding 
+     formats which may be used whenever the UCS values need to be 
+     encapsulated for transmission within DNS messages or application 
+     data streams. 
+      
+     In this regard, the internationalized namespace is the UCS 
+     representation of the domain names and labels as they are used for 
+     comparison operations once a domain name arrives for processing, 
+     while the transfer encodings ensure that a domain name arrives at 
+     the destination system intact, so that it may be processed in its 
+     canonical form. 
+      
+     There are four conceptual elements to this model: 
+      
+        *   Character codes. Labels from internationalized domain names 
+            have a single logical canonical representation as sequences 
+            of UCS code point values. The UCS characters are used when 
+            a particular label from a domain name is created by an 
+            application, stored in a zone, hosts or cache database, and 
+            is used whenever two sets of domain names or labels need to 
+            be compared. However, different kinds of domain names have 
+            different rules which govern the character codes that may 
+            be used. 
+      
+        *   Storage encodings. Whenever a domain name is created or 
+            copied from the network, it must be stored in a format that 
+            is reversible to the canonical UCS character representation 
+            of that domain name. This specification does not mandate or 
+            require any particular storage encoding, and allows this 
+            decision to be made on a per-implementation basis, as long 
+   
+  Hall                    I-D Expires: May 2002              [page 19] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            as the storage encoding supports character codes which can 
+            be converted to UCS equivalent values for comparison 
+            purposes. However, the use of UTF-8 for this purpose is 
+            encouraged, since it is the most common. 
+      
+        *   Transfer encodings. Whenever a domain name needs to be sent 
+            over the network, it must be packaged in a form which is 
+            compliant with the capabilities of the transfer protocol in 
+            use. This document specifies three transfer encodings which 
+            may be used to encode canonical UCS character codes in DNS 
+            messages or application streams, which are: the octet 
+            encoding from STD13, the ACE encoding from <ACE-Z>, and the 
+            UTF-8 encoding from RFC2279. Each encoding has different 
+            costs and benefits in different usage scenarios. 
+      
+        *   Comparison operations. When two domain names need to be 
+            compared, they also follow rules which are appropriate to 
+            the type of domain name being provided, and the transfer 
+            encoding which may have been used to provide the domain 
+            name to the system. 
+      
+     This document defines four distinct types of internationalized 
+     domain names which may exist in the internationalized namespace, 
+     and also describes how each of the above considerations affect 
+     those domain names and their labels. These domain name types are 
+     described throughout the remainder of this section. 
+      
+      
+  4.1.    Internationalized Domain Names and Labels 
+      
+     This section describes the master template rules for all domain 
+     names and labels which may be used in the internationalized 
+     namespace, although subordinate rules and restrictions are also 
+     applied as secondary filters, depending on the intended usage of 
+     the domain name. 
+      
+     For example, domain names and labels which are to be used as 
+     internationalized host identifiers (either as host names, or as 
+     domain names which are used to specify a host) are restricted to a 
+     specific subset of UCS characters. Meanwhile, domain names and 
+     labels which are compliant with STD13's global rules are 
+     restricted to eight-bit code values, while the domain names and 
+     labels which are used as STD13 host identifiers are restricted to 
+     a specific subset of US-ASCII. 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 20] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+      
+     The following diagram illustrates how the subordinate rules are 
+     applied and interpreted against the master restrictions: 
+      
+                      +-----------------------+ 
+                      | Internationalized DNs | 
+                      +-----------------------+ 
+                       any UCS character codes 
+                          /       | 
+                         /        | 
+                        /         | 
+                       /          | 
+          +-----------+     +-----------+     +------------+ 
+          | Int. Host |     | STD13 DNs +-----+ STD13 Host | 
+          +-----------+     +-----------+     +------------+ 
+          normalized        character         ASCII letters, 
+          subset of         codes 0x00        numbers, and 
+          UCS chars         through 0xFF      hyphen char 
+      
+     As can be seen, the internationalized domain names and labels 
+     rules allow any UCS character code to be stored, although each 
+     particular usage of the domain names and labels will have their 
+     own secondary rules and restrictions. 
+      
+     In order to allow future documents to define additional rules as 
+     required for their usage, this document defines very few global 
+     rules on the core internationalized domain names and labels. 
+      
+      
+  4.1.1.  IDN syntax and structure 
+      
+     In this specification, an internationalized domain name consists 
+     of a variable number of labels, each of which contain a variable 
+     number of UCS character codes, not all of which will have defined 
+     UCS character interpretations. 
+      
+     Furthermore, the encoding system which is used to store and 
+     interpret those values on a system is not relevant to this 
+     specification, and is therefore not defined. The characters in a 
+     label can be stored in memory or on disk as UTF-8, UCS-4, ACE, or 
+     any other storage encoding which is desired by the operators and 
+     implementers of the affected system, as long as that encoding 
+     system is reversible to the canonical UCS character code values, 
+     and is able to represent the necessary range of UCS characters 
+     (the "necessary range" varies by operation). 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 21] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     The only universal restrictions which apply to internationalized 
+     domain names and labels are those which govern length. This 
+     specification requires that labels from internationalized domain 
+     names MUST be restricted to a minimum length of two characters and 
+     a maximum length of 63 characters, inclusive. The exception to 
+     this rule is the root domain, which is always represented by a 
+     zero-length label. Note that this rule specifically refers to the 
+     canonical UCS characters, rather than any encoded form (encoding 
+     will often result in labels and domain names with fewer actual 
+     characters, due to overhead from the encoding algorithm). 
+      
+     A fully-qualified internationalized domain name is formed by 
+     joining a series of labels together, with the most-contextually 
+     specific label in the left-most position of the label sequence, 
+     and with the root domain occupying the right-most position. The 
+     sum total of all labels in an internationalized domain name MUST 
+     NOT exceed 255 characters, inclusive. Any number of labels MAY be 
+     stored in the domain name, but the sum total of their lengths MUST 
+     NOT exceed this limit. 
+      
+     However, labels which contain UCS character codes greater than 
+     U+007F will result in multi-byte UTF-8 and ACE encodings, so the 
+     maximum length of a label or an internationalized domain name is 
+     governed by their UTF-8 and ACE encoded lengths. Both encodings 
+     MUST result in an encoded length of 63 octets or less in order to 
+     be usable, with a maximum cumulative length of 255 octets. 
+      
+      
+  4.1.2.  IDN transfer encodings 
+      
+     The UCS is currently occupies a 21-bit range of character code 
+     values, containing tens of thousands of assigned characters, and 
+     hundreds of thousands of unassigned characters. Due to the multi-
+     byte nature of the code point values, UCS characters cannot be 
+     passed as protocol or application data in most of the existing 
+     Internet protocols (including DNS messages), at least not without 
+     the help of some kind of encoding scheme. At the very least, the 
+     UCS character values have to be encoded as eight-bit sequences if 
+     they are to fit within existing eight-bit data structures, and 
+     have to be encoded as a subset of US-ASCII characters if they are 
+     to be usable with legacy protocols and applications which only use 
+     STD13's host identifier rules for their structured domain name 
+     data types. 
+      
+     With this objective in mind, this document defines three different 
+     transfer encoding systems which can be used to convert 
+   
+  Hall                    I-D Expires: May 2002              [page 22] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     internationalized domain names and labels into a form which is 
+     suitable for transfer in different data streams. These are the 
+     legacy STD13 octet encoding, ACE, and UTF-8. Each of these 
+     encoding schemes provide different benefits and capabilities to 
+     the internationalized DNS effort. 
+      
+        *   STD13 octets. The STD13 octet encoding scheme provides a 
+            direct one-to-one mapping between eight-bit characters and 
+            their eight-bit values, but it is only capable of storing 
+            character codes in the range of U+0000 through U+00FF, 
+            which severely restricts its usefulness. 
+      
+        *   ACE. The ACE encoding scheme is capable of storing UCS 
+            character code value as seven-bit sequences in STD13 legacy 
+            labels. While this makes it practically compatible with the 
+            legacy host identifier rules, the resulting data imposes 
+            additional labor on the Internet community, and the reuse 
+            of the legacy label also results in certain amounts of 
+            ambiguity with some DNS domain names and labels. 
+      
+        *   UTF-8. The UTF-8 encoding scheme is capable of encoding all 
+            UCS character code values as sequences of eight-bit data 
+            which are compatible with legacy DNS message restrictions, 
+            but the encoded output requires explicit support from 
+            internationalized applications and protocols. UTF-8 output 
+            uses a new label type in order to prevent additional 
+            ambiguity problems from arising. 
+      
+     The table below illustrates the UCS character code sequences which 
+     are supported by each of the different encoding schemes. 
+      
+                          STD13 
+                          Octets   ACE    UTF-8 
+                        +-------+-------+-------- 
+                        |       |       | 
+               US-ASCII |   Y   |       |   Y 
+                        |       |       | 
+              Eight-Bit |   Y   |   Y   |   Y 
+                        |       |       | 
+          Any UCS Chars |       |   Y   |   Y 
+                        |       |       | 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 23] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     More specifically, the character code sequence ranges and their 
+     valid encodings are: 
+      
+        *   US-ASCII. If a label only contains character codes from the 
+            range of U+0000 through U+007F, then it MAY be encoded as a 
+            legacy STD13 octet sequence or UTF-8, but MUST NOT be 
+            encoded as ACE. 
+      
+            Note that this specification explicitly prohibits seven-bit 
+            labels from being encoded as ACE data, since such an action 
+            would be redundant, results in greater processing overhead 
+            for those labels, and multiple representations introduce 
+            problems with caches on legacy systems. Furthermore, 
+            certain security risks would be introduced if this were 
+            allowed. For example, a malicious user could register or 
+            purposefully create an ACE encoded representation of the 
+            "example.com" label sequence such that users mistakenly 
+            sent sensitive data to malicious systems. 
+      
+            In order to prevent these problems from occurring, this 
+            specification requires that any ACE-encoded label which 
+            consists entirely of seven-bit characters MUST be 
+            immediately discarded with extreme prejudice. This rule 
+            applies to every implementation of this specification, 
+            including any applications, resolvers, caches or servers 
+            which process labels. 
+      
+        *   Eight-bit codes. If a label contains character codes from 
+            the eight-bit range of U+0000 through U+00FF, then it MAY 
+            be encoded as STD13 octet sequences, ACE, or UTF-8. This 
+            rule specifically requires that the label MUST contain at 
+            least one character from the eight-bit range, MAY contain 
+            any number of characters from the seven-bit range, but MUST 
+            NOT contain characters with code values which are greater 
+            than U+00FF. 
+      
+            Since the STD13 octet encoding and ACE both use the legacy 
+            STD13 label type, this specification relies on the input 
+            encoding of a domain name in order to determine the output 
+            encoding. In some cases, however, the input encoding will 
+            not be clear, or will not be specified, and this can result 
+            in some ambiguity with label sequences from this range. 
+      
+            For example, if the domain name provided in a query 
+            consists of seven-bit labels, then the STD13 octet sequence 
+            is the only valid encoding for the legacy STD13 label, 
+   
+  Hall                    I-D Expires: May 2002              [page 24] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            meaning that ACE could not have been used in the query. If 
+            the specified domain name exists as a CNAME resource record 
+            which refers to a domain name that contains eight-bit 
+            character codes, then the proper output encoding for that 
+            domain name will not be clearly discernable. Moreover, the 
+            STD13 and ACE encodings will generate different results, 
+            since the STD13 octet sequence will only contain a single 
+            octet for the eight-bit character, while the ACE encoding 
+            will contain multiple octets of encoded data. 
+      
+            When this situation arises, systems MUST give preference to 
+            the ACE encoding, on the assumption that the referenced 
+            character is more likely to represent a UCS character than 
+            an eight-bit code value (the UCS characters in this range 
+            are Latin-1, which are the most common characters after the 
+            legacy US-ASCII set). Furthermore, the ACE encoded 
+            representation of these characters allow for a broader 
+            range of subsequent operations (since it complies with the 
+            legacy host naming restrictions, it can be used with CNAME 
+            resource records that refer to hosts), while the STD13 
+            octet encoded representation does not. 
+      
+            It is possible to avoid this scenario on authoritative zone 
+            servers (and thus the affected caches) by allowing the 
+            operator to specify whether or not the input is Latin-1 UCS 
+            character data or binary data, with the server generating 
+            the proper output accordingly. Also note that the default 
+            encoding specified by this document is UTF-8, which does 
+            not suffer from the ambiguity problems described above. 
+      
+        *   Any UCS character codes. If a label consists of any 
+            character codes greater than U+00FF, then it MAY be encoded 
+            as ACE or UTF-8, but MUST NOT be encoded as STD13 octet 
+            sequences. STD13 is not capable of representing character 
+            codes greater than U+00FF, so it cannot be used with any 
+            UCS characters beyond the eight-bit range. 
+      
+     Encodings are performed on a per-label basis. Each label MUST NOT 
+     be encoded more than once. Also note that recursive encodings 
+     result in applications discarding the domain name. 
+      
+     When the STD13 octet encoding is used to encode labels for 
+     transmission, the labels are encoded according to the rules 
+     specified in STD13, and are encapsulated in STD13 legacy labels. 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 25] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     When ACE is used to encode labels for transmission, the labels are 
+     encoded according to the rules specified in <ACE-Z>, and are 
+     encapsulated in STD13 legacy labels (this process is described in 
+     section 5.2). 
+      
+     When UTF-8 is used to encode labels for transmission, the labels 
+     are encoded according to the rules specified in RFC2279, and are 
+     encapsulated in EDNS/UTF-8 extended labels (the format of this 
+     label is described in section 5.1). 
+      
+     Note that a domain name MAY contain any combination of STD13 octet 
+     encoded labels and ACE encoded labels. However, if a domain name 
+     contains any UTF-8 encoded labels, then ALL of the labels from 
+     that domain name MUST be encoded as UTF-8 data. This rule 
+     primarily exists so that DNS compression services can be 
+     maintained consistently, but it also prevents mixed referrals 
+     which can trigger unnecessary fall-back processing, and also 
+     provides a single encoding representation to internationalized 
+     systems which benefits efficiency. 
+      
+     The root domain (as specified by the zero-length label at the 
+     right edge of the domain name) MUST NOT be encoded with ACE. More 
+     specifically, zero-length labels MUST NOT contain any character 
+     data of any kind, and since ACE labels have prefix strings, they 
+     are explicitly forbidden from being used for the root domain. 
+      
+      
+  4.1.3.  IDN comparison operations 
+      
+     When an internationalized domain name label is received from the 
+     network as ACE or UTF-8 encoded data, the labels MUST be decoded 
+     to their canonical UCS character representation, and the resulting 
+     UCS characters MUST be compared as case-exact sequences to their 
+     stored equivalents. Except where specifically required in this 
+     specification (EG, validity tests which are performed by 
+     applications), normalization and case-conversion MUST NOT be 
+     performed against the resulting UCS character codes prior to any 
+     comparison operations being performed. 
+      
+     However, internationalized domain name labels which are received 
+     as STD13 octet sequences MUST be given special treatment, as these 
+     domain names could have originated from legacy systems operating 
+     under STD13's rules. In this case, the seven-bit US-ASCII 
+     alphabetic characters (U+0041 through U+005A, and U+0061 through 
+     U+007A) from those labels MUST be compared in a case-neutral form. 
+     All other code values MUST be compared as case-exact code values 
+   
+  Hall                    I-D Expires: May 2002              [page 26] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     (this particularly includes eight-bit characters, which were not 
+     defined by STD13). 
+      
+      
+  4.2.    Internationalized Host Identifiers 
+      
+     Internationalized host identifiers are a subset of the 
+     internationalized domain names described in section 4.1, which 
+     only use a subset of the allowable UCS characters, but which reuse 
+     the global transfer encodings and comparison routines. 
+      
+     Most of the displayable characters from the UCS can be used in 
+     host identifiers, and there are no additional rules governing the 
+     ordering or length of their labels. However, the characters which 
+     are used in internationalized host identifiers MUST be normalized 
+     and case-converted before they are encoded for storage or 
+     transfer. This requires more effort on the part of applications 
+     and servers when the internationalized domain names are initially 
+     created, but results in less ambiguity and lower processing 
+     requirements for servers, caches and resolvers during subsequent 
+     comparison operations. 
+      
+     The restrictions which govern the creation of internationalized 
+     host identifiers are as follows: 
+      
+        a.  Labels MUST be restricted to the subset of characters which 
+            are permitted by <nameprep> [nameprep]. Characters which 
+            are prohibited by <nameprep> MUST NOT appear in any label 
+            of any internationalized host identifier. 
+      
+        b.  Labels MUST be normalized through <nameprep> before they 
+            are stored or encoded for transfer. Internationalized host 
+            identifiers will not be normalized as part of any 
+            comparison operation, so systems MUST normalize the labels 
+            before they are stored or transmitted. 
+      
+        c.  Labels MUST be converted to lowercase according to the 
+            case-mappings rules specified in <nameprep> before they are 
+            stored or encoded for transfer. Internationalized host 
+            identifiers will not be converted to lowercase as part of 
+            any comparison operation, so systems MUST normalize the 
+            labels before they are stored or transmitted. 
+      
+     According to the rules above, a label from an internationalized 
+     host identifier which was originally created with the UCS 
+     character sequence of <LATIN CAPITAL LETTER A><COMBINING ACUTE 
+   
+  Hall                    I-D Expires: May 2002              [page 27] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     ACCENT><LATIN CAPITAL LETTER B> (U+0041 U+0301 U+0042) would be 
+     normalized and lowercased to <LATIN SMALL LETTER A WITH 
+     ACUTE><LATIN SMALL LETTER B> (U+00E1 U+0062). The normalized, 
+     lowercase form would be used as the canonical UCS character 
+     representation of that label when it was encoded for storage and 
+     transmission purposes, and would be the form which was used for 
+     comparison operations on any resolvers, caches and servers. 
+      
+     Internationalized host identifiers which are received from the 
+     network can contain labels which have been encoded as STD13 octet 
+     sequences, ACE or UTF-8. In all of these cases, the comparison 
+     rules defined in section 4.1.3 MUST be applied. 
+      
+      
+  4.3.    STD13 Domain Names 
+      
+     STD13 allows any eight-bit code values to be used in domain name 
+     labels. However, STD13 host identifiers (as described in section 
+     4.4 of this specification) are the most common form of STD13 
+     domain names, and have much tighter restrictions. 
+      
+     There are common uses of STD13 domain names which do not comply 
+     with the STD13 host identifier subset, however. One common example 
+     of this is SRV identifiers, which use an underscore character 
+     (U+005F) as part of their label syntax. Another common example is 
+     found when email addresses are provided in SOA and RP resource 
+     records, and where the left-hand side of the email address is 
+     stored as an STD13 domain name label which does not represent a 
+     host identifier. Furthermore, email addresses often contain extra 
+     characters which are not legal in STD13 host identifiers, such as 
+     a full-stop character (U+002E). For example, "joe.admin" could be 
+     stored as an STD13 domain name label in the fully-qualified domain 
+     name of "joe.admin.example.com.", which would represent the email 
+     address of "joe.admin@example.com" when that domain name was 
+     extracted from the SOA or RP resource record and processed. 
+      
+     Implementations of this specification MUST allow STD13 domain 
+     names to be created and stored, using the following rules: 
+      
+        a.  Labels MUST be restricted to the code values of U+0000 
+            through U+00FF. Restrictions on character content MUST NOT 
+            be applied (note that if this domain name will be used as 
+            part of an STD13 host identifier, the rules specified in 
+            section 4.4 MUST be used instead). 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 28] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+        b.  Labels MUST NOT be normalized or lowercased before they are 
+            stored or encoded for transfer. 
+      
+        c.  Systems MUST allow STD13 domain names to be specified as 
+            exact sequences of eight-bit octet values, and MUST NOT 
+            treat these sequences as canonical UCS characters which are 
+            normalized or lowercased. STD13 defines an escaping 
+            mechanism whereby the decimal value of the octet is 
+            prefaced with a reverse-solidus (such as "\193"), which is 
+            suggested for this usage. 
+      
+     STD13 domain names which are received from the network can contain 
+     labels which have been encoded as STD13 octet sequences, ACE or 
+     UTF-8. In all of these cases, the comparison rules defined in 
+     section 4.1.3 MUST be applied. Note that some of these sequences 
+     can contain octet code values which have not been normalized or 
+     lowercased by the originating system, since these values can be 
+     used to specify binary domain names. 
+      
+      
+  4.4.    STD13 Host Identifiers 
+      
+     This document does not deprecate, replace or modify the host name 
+     rules defined by RFC952, STD3 or STD13 as they apply to legacy 
+     host identifiers. However, there are several issues which affect 
+     the usage of these domain names and their labels in this system. 
+      
+     The range of characters which are currently defined as valid in 
+     STD13 host identifiers are the uppercase and lowercase letters, 
+     numbers and hyphen character from US-ASCII. No other characters 
+     are allowed to be used. Furthermore, the current rules also 
+     prohibit the use of the hyphen character in the first or last 
+     character position of a host identifier label. 
+      
+     Implementations of this specification MUST allow STD13 host 
+     identifiers to be created and stored, using the following rules: 
+      
+        a.  Labels MUST be restricted to the code values of U+002D, 
+            U+0031 through U+0039, U+0041 through U+005A, and U+0061 
+            through U+007A. 
+      
+        b.  Labels MUST NOT contain the code value of U+002D in either 
+            the first or last character position of the label. 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 29] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+        c.  The alphabetic characters MUST be converted to lowercase 
+            before they are stored or transmitted. STD13 host 
+            identifiers are always compared in a case-neutral form. 
+      
+     STD13 host identifiers which are received from the network can 
+     contain labels which have been encoded as STD13 octet sequences 
+     UTF-8. In both cases, the comparison rules defined in section 
+     4.1.3 MUST be applied. 
+      
+      
+  5.      Transfer Encodings and Label Types 
+      
+     As was discussed in section 4.1.2, internationalized domain names 
+     and labels are required to be encoded as either eight-bit or 
+     seven-bit data whenever they are transmitted as protocol or 
+     application data. 
+      
+     The particular output encoding format which will be used for any 
+     given label will be primarily determined by the capabilities of 
+     the participating end-point systems. If the application or 
+     protocol which is relaying the domain name labels supports 
+     internationalized domain names directly then UTF-8 encoded labels 
+     can be used, but if the protocol or application is only capable of 
+     supporting STD13 host identifiers as domain name data, then the 
+     STD13 octet and/or ACE encoded labels will have to be used. 
+      
+     With DNS messages in particular, the "data type" is the label 
+     encapsulation in use. Although STD13 legacy labels allow for the 
+     use of eight-bit codes, multiple encodings for the same basic 
+     character data result in interpretation problems without some form 
+     of ancillary tagging service. For this reason, each encoding is 
+     represented differently by this specification. When the STD13 
+     legacy label contains STD13 octet sequences then no tagging is 
+     provided, but if the STD13 legacy label contains ACE encoded data 
+     then the encoded sequence is tagged with an ACE identifier (a 
+     character prefix which does not normally appear in labels). When 
+     UTF-8 domain names are provided, an EDNS/UTF-8 extended label is 
+     used to encapsulate the internationalized domain name. 
+      
+     Furthermore, the encoding which is used for any label in the 
+     message will also determine the label type which is used to 
+     encapsulate and transfer the entire domain name. If any label 
+     contains EDNS/UTF-8 extended labels, then all of the labels from 
+     that domain name are required to be encapsulated for transfer in 
+     EDNS/UTF-8 extended labels. Conversely, if a domain name contains 
+     ACE or STD13 octet encoded labels, then all of the labels from 
+   
+  Hall                    I-D Expires: May 2002              [page 30] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     that domain name are required to be encapsulated for transfer 
+     using the STD13 legacy label format. 
+      
+     Note that other legacy applications and protocols will most likely 
+     be required to provide extended encodings or negotiation features 
+     before they can exchange internationalized domain names directly. 
+     However, new applications and protocols which are subsequently 
+     written to comply with BCP18 and this specification should not 
+     require any such effort, as they should be capable of transferring 
+     UTF-8 domain names from the beginning. 
+      
+      
+  5.1.    The EDNS/UTF-8 Label Type 
+      
+     Any internationalized domain name label which has been encoded as 
+     UTF-8 for transmission in a DNS message MUST be encapsulated as a 
+     EDNS/UTF-8 label. 
+      
+     The EDNS/UTF-8 extended label is an instance of EDNS extended 
+     label types (as defined by RFC2671). Extended labels are indicated 
+     by the leading bit pattern of 0b01 in the label type field (the 
+     first two bits from the "label length" octet of the STD13 legacy 
+     label type), with the remaining six bits of this octet indicating 
+     the extended label type in use. The EDNS/UTF-8 label type uses the 
+     binary value of 0b000011 for this indication (note that IANA may 
+     change this assignment). 
+      
+     EDNS/UTF-8 labels contain two subordinate units of data. The first 
+     octet contains a length indicator which works exactly the same as 
+     the length octet as used by STD13 legacy labels: if the first two 
+     bits of this octet are 0b00 then the rest of that octet provides 
+     the length of the label data field, but if the first two bits of 
+     this octet are 0b11 then the label is a pointer to some other 
+     label, and the remainder of the length octet provides an off-set 
+     which points to the length octet of the referenced label, as per 
+     the rules provided in section 4.1.4 of RFC 1035 (STD13, part 2). 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 31] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     The structure of the EDNS/UTF-8 extended label is illustrated by 
+     the following figure. 
+      
+                              1 1 1 1 1 1 1 1 1 1 
+          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+         |0 1|0 0 0 0 1 1|    length     |  label data  ///  | 
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+      
+          0b01 “ The extended label identifier. 
+      
+          0b000011 “ The EDNS/UTF-8 extended label type identifier. 
+      
+          Length “ The number of octets in the label data, or the off-
+            set to the length octet of another EDNS/UTF-8 label. 
+      
+          Label data “ The label data, encoded as UTF-8 octets. 
+      
+     The following example shows the domain name of me.com, where the 
+     "e" in "me" is the UCS character <LATIN SMALL LETTER E WITH ACUTE> 
+     (U+00E9), which has the UTF-8 encoded octet sequence of 0xC3A9. 
+      
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+         20 | 0  1  0  0  0  0  1  1|          0x03         | 
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+         22 |        0x6D (m)       |      0xC3 (e')        | 
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+         24 |      0xA9 (e')        | 0  1  0  0  0  0  1  1| 
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+         26 |         0x03          |        0x63 (c)       | 
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+         28 |        0x6F (o)       |        0x6D (m)       | 
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+         30 | 0  1  0  0  0  0  1  1|         0x00          | 
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
+      
+     Octet 20 identifies the EDNS/UTF-8 extended label type, while 
+     octet 21 indicates that the label is three octets long. Octet 22 
+     contains the UTF-8 value for lowercase "m", while octets 23 and 24 
+     contain the UTF-8 value for the UCS character <LATIN SMALL LETTER 
+     E WITH ACUTE> (encoded as 0xC3A9). 
+      
+     Similarly, octet 25 identifies another EDNS/UTF-8 extended label 
+     type, while octet 26 indicates that the label is three octets 
+     long, while octets 27 through 29 contain the UTF-8 values for the 
+     lowercase alphabetic sequence of "com". 
+   
+  Hall                    I-D Expires: May 2002              [page 32] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+      
+     Finally, octet 30 identifies another EDNS/UTF-8 extended label 
+     type, while octet 31 indicates that the label is zero octets in 
+     length, thereby signifying the root zone (the end of the queried 
+     domain name). 
+      
+     Note that the use of the EDNS/UTF-8 extended label type serves 
+     multiple purposes. On the one hand, it provides a method of 
+     signaling the resolver's capabilities to the server, so that the 
+     server can determine which format it needs to use when returning 
+     answers, referrals or errors. Moreover, using an encapsulation 
+     format which is not backwards compatible prevents certain 
+     ambiguity problems which can result from overloading the STD13 
+     legacy label with multiple encodings. These problems are seen in 
+     certain situations with STD13 octet encoding and ACE, where a 
+     server cannot adequately determine which encoding a resolver 
+     desires. By using a separate extended label type for UT-8, these 
+     kinds of ambiguities are avoided. 
+      
+     There are additional benefits which come from using EDNS extended 
+     label types, which are best expressed as "future possibilities". 
+     Once the EDNS extended label mechanisms are widely deployed, it 
+     becomes feasible to specify additional encoding mechanisms as soon 
+     as the Internet community deems it desirable. In this regard, 
+     defining alternative encodings is much easier the second time. 
+      
+      
+  5.2.    The STD13 Legacy Label Type 
+      
+     Any internationalized domain name label which has been encoded as 
+     ACE or STD13 octet sequences for transmission in a DNS message 
+     MUST be encapsulated within an STD13 legacy label. 
+      
+     This document does not deprecate, replace or extend the STD13 
+     octet encoding or label encapsulation rules defined by STD13. 
+     However, this document does provide some guidance on the creation 
+     and interpretation of ACE encoded labels when they are stored in 
+     legacy labels, which is necessary in order for recipient systems 
+     to properly detect and decode the label contents. 
+      
+     Note that STD13 octet sequences and ACE data MAY both be provided 
+     the same domain name. As such, each STD13 legacy label from a DNS 
+     message must be examined and processed independently. 
+      
+      
+   
+  Hall                    I-D Expires: May 2002              [page 33] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+  5.2.1.  ACE encoded labels 
+      
+     ACE encoded labels always begin with the character sequence of 
+     <TBD> (this document uses "zz--" as a placeholder sequence until a 
+     formal assignment is made). Any label which contains ACE encoded 
+     data MUST begin with this character sequence prefix. Similarly, 
+     any label which begins with this character sequence MUST be 
+     recognized and processed as an ACE encoded label, according to the 
+     rules defined in this specification. 
+      
+     Encoding and encapsulating a label as ACE data is a three-part 
+     process, as follows: 
+      
+        a.  Encode the canonical UCS character data from the 
+            internationalized domain name label into ACE using the 
+            procedure defined in <ACE-Z> 
+      
+        b.  Preface the encoded output with the "zz--" prefix sequence, 
+            thereby indicating that this label contains ACE encoded UCS 
+            character data. 
+      
+        c.  Determine the length of the encoded data and store this 
+            value in the STD13 legacy label's length octet. 
+      
+     Decoding an ACE label is the opposite of that process. 
+      
+     Note that whenever the ACE algorithm encounters a seven-bit 
+     character code in the input, it is passed through unmodified to 
+     the encoded output. If a label only contains seven-bit character 
+     codes, the label MUST NOT be encoded as ACE, and MUST be encoded 
+     as either STD13 octet sequences or UTF-8. Forcing a seven-bit 
+     label to be encoded as ACE serves no benefit, incurs additional 
+     processing on the end-point systems, and can also expose certain 
+     security risks. Any system which is capable of generating and 
+     deciphering ACE encoded labels is required to treat such sequences 
+     as hostile, and MUST dispose of them immediately without any 
+     further processing immediately; systems are forbidden to even 
+     return these labels in DNS error messages. 
+      
+     Similarly, ACE MUST NOT be used to encode any zero-length labels 
+     (including but not specifically limited to the root domain), since 
+     the presence of prefix characters in these labels can invalidate 
+     their protocol-specific interpretations. 
+      
+     When an STD13 legacy label is received which has "zz--" in the 
+     first four character positions, the label MUST be treated as an 
+   
+  Hall                    I-D Expires: May 2002              [page 34] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     ACE-encoded internationalized domain name, and MUST be decoded to 
+     its canonical UCS character values for further processing. 
+      
+     Note that STD13 legacy labels MUST be verified before the ACE 
+     encoded data is extracted (as per the rules defined in STD13 which 
+     govern the STD13 legacy label type), but systems which are 
+     compliant with this specification MUST perform all subsequent 
+     comparison, caching, or storage operations against the canonical 
+     UCS characters, and MUST NOT use the ACE encoded label sequence 
+     for any of these operations. 
+      
+     Note that the legacy systems which are not compliant with this 
+     specification will treat ACE encoded labels as any other STD13 
+     legacy label. 
+      
+      
+  5.2.2.  STD13 octet encoded labels 
+      
+     Any STD13 legacy labels which do not begin with the ACE prefix 
+     MUST be treated as STD13 octet encoding sequences. The rules for 
+     this process are defined by STD13's default label encapsulation 
+     services, although this document also provides some clarifications 
+     on the use of this encoding with internationalized domain names 
+     and labels. 
+      
+     Whenever the STD13 octet sequence is used to encode the labels 
+     from an internationalized domain name, the octet values of the 
+     canonical UCS characters are stored directly in the label. Because 
+     the DNS message is limited to octets, the range of UCS character 
+     codes which are eligible for use with STD13 octet sequences is 
+     limited to U+0000 through U+00FF. If any UCS character codes 
+     outside this range need to be transferred, the internationalized 
+     domain name label will have to be encoded as ACE or UTF-8. 
+      
+     Note that comparison operations for the seven-bit range of 
+     alphabetic character values MUST be performed in a case-neutral 
+     form, although eight-bit code values MUST NOT be normalized or 
+     case-converted as part of a comparison operation. These rules are 
+     required in order to ensure backwards compatibility with the STD13 
+     compliant systems which may be generating these labels as parts of 
+     an STD13 domain name while also supporting the normalization and 
+     case-conversion which may have been applied to the UCS characters 
+     in the storage or transfer encoding systems. 
+      
+      
+   
+  Hall                    I-D Expires: May 2002              [page 35] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+  6.      Application Guidelines 
+      
+     As was discussed in section 3.3, there are multiple scenarios in 
+     which an application can make use of internationalized domain 
+     names, ranging from simple lookups of connection identifiers to 
+     abstract encapsulations of unstructured application data. This is 
+     an extremely broad range of uses, which is complicated by the 
+     extreme pervasiveness of applications and protocols that use 
+     domain names for one or more of these purposes. 
+      
+     Furthermore, network applications face a complex array of input 
+     and output operations which will cumulatively affect the ability 
+     of that application to make use of the internationalized domain 
+     name system for various services and functions. These issues are 
+     illustrated by the figure below: 
+      
+                       [IDNs]              [IDNs] 
+                         |                   ^ 
+                         |                   | 
+                  +------V------+     +------+------+ 
+                  |    input    |     |   output    | 
+                  |   charset   |     |   charset   | 
+                  +-----------+-+     +-+-----------+ 
+                               \       / 
+                            +---+-----+---+ 
+                            | Application | 
+                            +---+-----+---+ 
+                               /       \ 
+                  +-----------+-+     +-+-----------+ 
+                  |   lookups   |     |   app data  <---> [IDNs] 
+                  +------+------+     +-------------+ 
+                         | 
+                  +------+------+ 
+                  |   resolver  <---> [IDNs] 
+                  +-------------+ 
+      
+     As can be seen, the ability for an applications to complete adopt 
+     internationalized domain names will be determined by many factors, 
+     any one of which could prevent the application from completely 
+     incorporating the restrictions and recommendations prescribed by 
+     this specification. 
+      
+     In order to allow for a flexible adoption schedule, this 
+     specification defines very few mandates that applications must 
+     adopt, but instead focuses on recommendations which applications 
+     should comply with whenever they need to use internationalized 
+   
+  Hall                    I-D Expires: May 2002              [page 36] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     domain names, and also provides recommendations for situations 
+     where the preferred behavior is not feasible. Applications which 
+     are compliant with all of the recommendations provided in this 
+     specification will be able to generate, store, transfer and 
+     resolve internationalized domain names throughout all of their 
+     operations, using UTF-8 as a common encoding for all of these 
+     operations. Meanwhile, applications which are not in complete 
+     compliance with this specification will still be able to make use 
+     of the internationalized domain names in these operations, 
+     although such access may be limited to using backwards-compatible 
+     encodings which require greater amounts of effort to implement and 
+     which provide fewer benefits. 
+      
+      
+  6.1.    Input and Output Charsets 
+      
+     If an application is unable to accept, process, store or display 
+     characters from the complete UCS repertoire, that application's 
+     support for internationalized domain names will be somewhat 
+     limited, by definition. 
+      
+     Although this document does not mandate any particular charset or 
+     encoding which all applications must use for all operations, 
+     applications SHOULD use coded character sets or encodings which 
+     can handle characters from a reasonable number of scripts. 
+      
+     In particular, the following areas have specific requirements: 
+      
+        *   Input charsets and encodings. Since UTF-8 is used as the 
+            default encoding for internationalized domain names 
+            throughout this specification (and others, such as BCP18), 
+            UTF-8 is also RECOMMENDED for use with input encodings of 
+            internationalized domain names in particular, although this 
+            is not required. Many platforms and development 
+            environments support UTF-8 as a local encoding of the UCS 
+            and it can be reasonably used with many types of input 
+            (such as configuration files), although many systems will 
+            require a specific encoding (such as UCS-2, or ISO/IEC 
+            8859-1) in situations which require memory access or 
+            keyboard input. 
+      
+            Regardless of the input encodings used, implementations 
+            MUST map domain names and labels to their canonical UCS 
+            characters for any normalization and case-conversion work 
+            which is subsequently required by any DNS lookups (see 
+            section 6.3). 
+   
+  Hall                    I-D Expires: May 2002              [page 37] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+      
+        *   Output choices will likely be limited to a system-preferred 
+            charset or encoding. In general, this document RECOMMENDS 
+            that output systems choose an output charset or encoding 
+            which reflects the data being provided. However, 
+            applications MUST NOT display unknown characters with 
+            generic replacement characters (such as boxes or circles) 
+            if it is known that the original characters are not 
+            available for display with the specified charset, as such 
+            characters will almost certainly trigger failure conditions 
+            in subsequent protocol operations. 
+      
+     In those situations where adequate input or output charsets or 
+     encodings are unavailable, applications MAY use ACE to encode 
+     internationalized domain names for the purpose of ensuring that 
+     the data is provided intact. Since ACE is capable of representing 
+     UCS characters as sequences of seven-bit characters, it is 
+     functionally usable as a last line of defense in almost any 
+     environment, with the caveat that ACE encoding sequences are 
+     extremely cryptic and will likely result in lower levels of 
+     usability and functionality. 
+      
+      
+  6.2.    Protocol and Application Data 
+      
+     There are several interrelated issues which will determine an 
+     application's ability to provide or accept internationalized 
+     domain names as protocol or application data, although the 
+     principle determining factors for any such usage will generally be 
+     the capabilities of the underlying protocol itself. 
+      
+     If a protocol allows negotiation or tagging services in order to 
+     distinguish between different encodings, that protocol can likely 
+     be extended to support the use of UTF-8 as protocol or application 
+     data through command/response negotiation options or through data-
+     type tags. Older protocols which do not provide any negotiation 
+     services or which mandate the use of US-ASCII in all data will 
+     likely require the use of ACE encoded domain names as a short-term 
+     measure until the protocol is made compliant with BCP18. 
+      
+        *   Protocol data. If the protocol supports UTF-8 encoded 
+            internationalized domain names in commands or responses, 
+            then that encoding SHOULD be used wherever it is allowed. 
+            If UTF-8 is not supported by the protocol, STD13 octet 
+            sequences and/or ACE encoded equivalents of the 
+            internationalized domain name MUST be used. 
+   
+  Hall                    I-D Expires: May 2002              [page 38] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+      
+            In some cases, this negotiation can be performed on a per-
+            session basis, while in other cases this work will need to 
+            be performed for each transaction within the session, while 
+            in other cases the internationalized domain names will have 
+            to be tagged whenever they are provided as protocol or 
+            application data. 
+      
+            The DNS protocol is itself an example of a protocol which 
+            requires tagging in order for internationalized domain 
+            names to be exchanged within the existing DNS message (with 
+            these indicators taking the form of ACE encoding prefixes 
+            and EDNS/UTF-8 extended label type codes). Meanwhile, a 
+            protocol such as WHOIS can theoretically support a session-
+            wide negotiation option that allowed the use of 
+            internationalized domain names as protocol and application 
+            data for the duration of that session. Conversely, a 
+            protocol such as SMTP will likely require the use of 
+            session-specific identifiers for some operations, while 
+            other operations may be able to use label tags (similar to 
+            the existing support for domain literals, which are 
+            identified by a pair of surrounding square brackets). 
+      
+            Regardless of the encodings which are used, implementations 
+            MUST map domain names and labels to their canonical UCS 
+            characters for any normalization and case-conversion work 
+            which is subsequently required as part of a DNS lookup (see 
+            section 6.3). 
+      
+        *   Structured application data. Structured application data 
+            such as URLs and email addresses MUST be processed 
+            according to the rules which govern those data formats. 
+            Applications MUST NOT perform any conversion or 
+            transliteration which is not explicitly prescribed by the 
+            governing documents, since non-standard usages are likely 
+            to result in misinterpreted data. 
+      
+        *   Unstructured application data. Domain names which appear as 
+            unstructured data in application content are beyond the 
+            control of this specification, and are generally subject to 
+            the encoding and formatting desires of the end-users who 
+            created the data. Generally speaking, it is RECOMMENDED 
+            that applications allow users to enter or view documents in 
+            whatever format they prefer, but that any conversion 
+            between multiple source and destination charsets and 
+            encodings use UCS as the translation intermediary, such 
+   
+  Hall                    I-D Expires: May 2002              [page 39] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            that internationalized domain names are properly converted 
+            along with the rest of the application data. 
+      
+     In some cases, the application will need to probe the resolver 
+     before it can use internationalized domain names as data. For 
+     example, a participating system may need to determine the 
+     internationalized domain name of the local system so that it can 
+     provide this data in a protocol-specific banner message, and in 
+     these cases, the application will have to communicate with the 
+     resolver before this data can be provided. 
+      
+     Due to the usage-specific nature of internationalized domain names 
+     within protocol and application data streams, each development 
+     group will have to analyze the restrictions and capabilities which 
+     affect their specific services independently. 
+      
+      
+  6.3.    DNS Lookups and Resolver Calls 
+      
+     One of the most frequent uses for domain names is for lookup 
+     operations, such as for locating the IP addresses associated with 
+     a specified domain name, determining the domain name associated 
+     with a specified IP address, or performing a protocol-specific 
+     lookup operation for a specific resource record (such as the MX or 
+     SOA resource records associated with a specific domain). 
+      
+     Since these lookup operations do not directly affect external 
+     protocols or data, internationalized domain names can be used for 
+     lookup operations at the application's discretion. For example, 
+     applications such as ping and netstat only use domain names for 
+     display purposes, and can therefore make immediate use of 
+     internationalized domain names within their protocol operations. 
+     Similarly, a protocol can be limited to STD13 host identifiers as 
+     protocol identifiers which will require the application to provide 
+     internationalized domain names as ACE encoded sequences, but any 
+     lookup operations which are necessary for the internationalized 
+     domain names can still be performed in their native form. In these 
+     cases, the protocol operations and lookup operations are separate 
+     tasks with separate rules. 
+      
+     Similarly, applications are not required to use internationalized 
+     domain names and internationalized resolver APIs for every lookup. 
+     In some cases, it may be more efficient for an application to only 
+     use internationalized domain names for lookup operations against 
+     connection identifiers, and to use STD13 octet sequences or ACE 
+     encoded legacy lookups for domain names which were obtained as 
+   
+  Hall                    I-D Expires: May 2002              [page 40] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     protocol or application data (this will be especially true in 
+     those cases where the protocol does not yet provide an 
+     internationalized domain name data-type). In those cases where an 
+     application prefers to use the legacy resolution path, the 
+     application MUST use the resolver's legacy APIs. For lookups 
+     against internationalized domain names, the application MUST use 
+     the resolver's internationalized APIs. 
+      
+     Note that this specification does not define a mandatory encoding 
+     which must be used between the applications and the local 
+     resolver. However, resolvers MUST provide at least one encoding 
+     which is capable of supporting the entire UCS repertoire of 
+     character codes, including character codes which are currently 
+     unassigned. Since UTF-8 is the default encoding which is used 
+     throughout this specification, it is also RECOMMENDED for use with 
+     resolver APIs, although this is not required. Resolvers MAY 
+     dictate a local encoding, with the only requirement being support 
+     for the entire range of UCS character codes. 
+      
+     Regardless of the data being provided or the charset or encoding 
+     which is used to provide that data, applications MUST normalize 
+     and case-convert any internationalized host identifiers which it 
+     generates or receives from a lookup operation. This process MUST 
+     use the canonical UCS characters of the domain name according to 
+     the rules specified in <nameprep> for every host identifier which 
+     is sent to or received from a resolver. 
+      
+     If the application knows that the requested data specifically 
+     refers to a host identifier, then the domain name data which is 
+     returned by the resolver MUST be normalized and case-converted, 
+     and the resulting domain name MUST be compared to the original 
+     domain name which was received prior to the normalization and 
+     case-conversion steps. If the processed domain name does not match 
+     the domain name which was received, the domain name MUST be 
+     discarded as malformed. 
+      
+     This step is necessary in order to ensure the integrity and 
+     veracity of internationalized domain names which are processed by 
+     applications, since there are multiple opportunities for errors to 
+     be introduced (such as mistyped entries in the resolver's hosts 
+     database, or malicious data which has been purposefully provided 
+     in a zone), and these errors can result in sensitive data being 
+     directed to the wrong network. Note that the above rule 
+     specifically applies to host identifiers and not to all 
+     internationalized domain names as a whole; applications MUST NOT 
+     arbitrarily normalize and case-convert any and all domain names, 
+   
+  Hall                    I-D Expires: May 2002              [page 41] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     but MUST apply these steps to any and all domain names which are 
+     known to be used as host identifiers. 
+      
+     As part of the processing rules for DNS lookups, it is expected 
+     that an application can exchange internationalized domain names 
+     with the resolver using a charset or encoding which is capable of 
+     representing the entire UCS character code range. Towards this 
+     objective, applications SHOULD test the capabilities of the 
+     resolver prior to transferring internationalized domain names. In 
+     those situations where the resolver is unable to support this 
+     usage, the application MUST encode the internationalized domain 
+     name as STD13 octet sequences or ACE, and pass the resulting STD13 
+     host identifier to the resolver. 
+      
+      
+  7.      Resolver Guidelines 
+      
+     Resolvers play a crucial role in the use of internationalized 
+     domain names, in that they provide the internationalized namespace 
+     which applications work with. As part of this service, resolvers 
+     provide encapsulation services for the internationalized domain 
+     names which are exchanged with the applications, resolve queries 
+     in the internationalized namespace on behalf of the applications, 
+     and provide lookup matching for entries which are stored in a 
+     local hosts database. Note that resolvers which cache answer data 
+     for subsequent operations are also governed by the caching 
+     restrictions provided in section 9. 
+      
+      
+  7.1.    Resolver APIs 
+      
+     Stub resolvers which communicate directly with applications that 
+     are compliant with this specification are strongly encouraged to 
+     provide a separate set of APIs for those applications to use 
+     whenever internationalized domain names need to be provided in 
+     queries or response messages. 
+      
+     The use of an internationalized API will generally facilitate 
+     smoother operations for the applications, in that it will allow 
+     the application to determine the capabilities of the resolver, to 
+     obtain the internationalized domain name of the local system, and 
+     to process queries for internationalized domain names as special 
+     data types. 
+      
+     Furthermore, the use of internationalized versus legacy APIs 
+     provides a way for resolvers to separate internationalized and 
+   
+  Hall                    I-D Expires: May 2002              [page 42] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     legacy application query paths, such that the legacy APIs only 
+     result in STD13 legacy labels, while the internationalized APIs 
+     generate and trigger EDNS/UTF-8 extended labels. The output 
+     formatting of the DNS messages are controlled by tight 
+     restrictions, and the use of alternative APIs will likely result 
+     in simpler resolver implementations. 
+      
+     For example, it is suggested that applications use the 
+     internationalized APIs for all of the DNS lookups they generate, 
+     even if the domain name only contains seven-bit characters. This 
+     is required in case the queried domain name only exists with a 
+     CNAME or PTR resource record which references an internationalized 
+     domain name, and the server has to know which encoding to use for 
+     that query. If the client had not used the internationalized API 
+     for the original lookup of the domain name, the resolver may have 
+     chosen the wrong label type, and thus the response data would only 
+     be returned as ACE encoded data. 
+      
+     Conversely, older applications which generate malformed eight-bit 
+     queries through the legacy APIs will result in those queries being 
+     properly rejected by the DNS servers, preventing undue problems 
+     with these applications from occurring. For example, an older 
+     application may process an internationalized domain name through 
+     the system-default charset or encoding (such as MacRoman), which 
+     would result in the domain name being malformed when the 
+     application tried to do something important with that domain name 
+     (such as send an email message over SMTP). The use of multiple 
+     APIs causes these malformed applications to break, and the invalid 
+     domain names are kept out of the application protocol space. 
+      
+     Internationalized APIs are optional to the extent that an 
+     application MAY use an embedded resolver which is known to be 
+     capable of generating and processing internationalized domain 
+     names through the existing function calls. However, the use of 
+     separate APIs for internationalized domain names is encouraged. 
+      
+     Although this document does not mandate any specific APIs, the 
+     following functions SHOULD be provided for in some form: 
+      
+        *   Test Wide. Applications MUST be able to test the resolver 
+            for compliance with this specification. In those cases 
+            where this function is performed by some other function 
+            (such as one of the following), the capabilities of the 
+            resolver MUST be detectable even if the requested operation 
+            fails. For example, if an application issues a call for the 
+            internationalized domain name of the local system, the 
+   
+  Hall                    I-D Expires: May 2002              [page 43] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            capability of the resolver to handle internationalized 
+            domain names MUST be uniquely represented even if the local 
+            host name cannot be determined. 
+      
+        *   Get Wide X-By-Y. Applications SHOULD be able to specify any 
+            resource record associated with any internationalized 
+            domain name as part of a lookup operation. Whether this 
+            service is provided as a series of lookup-specific APIs or 
+            as a general purpose API is up to the resolver. 
+      
+        *   Get Wide Local Name. Applications which utilize 
+            internationalized domain names as data will need to be able 
+            to determine the internationalized form of their local 
+            system name for some operations (such as a protocol-
+            specific welcome banner). When this function is called, the 
+            resulting data MUST be provided as the canonical UCS 
+            character code values, or their equivalent as represented 
+            by a locally mandated charset or encoding. 
+      
+            Note that an ACE equivalent of the system name SHOULD be 
+            returned when the relevant legacy API is queried. In those 
+            cases where the legacy and internationalized domain names 
+            both contain seven-bit character codes (possibly because 
+            the host name is only available in US-ASCII, or because the 
+            host name was assigned as ACE by an external configuration 
+            service), the internationalized host name MUST still be 
+            accessible through the internationalized function. 
+      
+     Note that this application does not specify a charset or encoding 
+     which must be used by the resolver APIs. However, wherever an 
+     internationalized API is presented, the resolver MUST utilize a 
+     charset or encoding which supports the entire UCS repertoire of 
+     character codes, including character codes which are currently 
+     unassigned. Since UTF-8 is the default charset for most of the 
+     operations specified in this document, it is also RECOMMENDED for 
+     this service, but is not required. 
+      
+      
+  7.2.    Query Processing Services 
+      
+     Resolvers which are compliant with the recommendations provided in 
+     this specification will provide two query paths, one of which 
+     supports STD13 domain names and another which supports 
+     internationalized domain names. Technically, there is no 
+     requirement for two processing paths, although these paths will 
+   
+  Hall                    I-D Expires: May 2002              [page 44] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     likely exist as conceptual paths even if they are not represented 
+     or implemented uniquely in all resolvers. 
+      
+     The legacy processing path is defined by STD13. This document does 
+     not update, modify or extend the rules that resolvers operate 
+     under when an STD13 compliant domain name is received by a legacy 
+     application through any legacy APIs which may exist. However, when 
+     an internationalized domain name is received from an 
+     internationalized application through any internationalized APIs, 
+     the processing rules defined in this section MUST be followed. 
+     Note that these rules apply to all resolvers, whether they are 
+     stub resolvers, forwarders or caching servers. 
+      
+     Generally speaking, the internationalized domain name resolution 
+     process has two major components: processing internationalized 
+     domain names as queries, and performing fall-back processing if an 
+     EDNS/UTF-8 query is rejected by an authoritative server. 
+      
+      
+  7.2.1.  Internationalized queries 
+      
+     Queries for internationalized domain names which are received 
+     through internationalized APIs can be expected to have originated 
+     at an application which is capable of accepting and processing 
+     internationalized domain names in the response messages. 
+      
+     Resolvers MUST encode the labels from the queried domain name as 
+     UTF-8 and encapsulate the resulting encoded labels into EDNS/UTF-8 
+     extended labels for transfer within DNS messages, per the 
+     instructions provided in section 5.1. 
+      
+     Any and all responses to these queries will also be encoded as 
+     UTF-8 and encapsulated in EDNS/UTF-8 extended labels. Resolvers 
+     MUST decode the provided response data, convert the labels to 
+     their canonical UCS character codes, and return the requested data 
+     to the calling application. 
+      
+     The resolver MUST NOT normalize or case convert internationalized 
+     domain names which may be received in queries or response 
+     messages. Since the queries have originated from applications 
+     which have indicated that they are compliant with this 
+     specification (via the API) while the responses will have 
+     originated from caches or servers which indicate that they are 
+     also compliant (via the EDNS/UTF-8 extended labels), those systems 
+     are assumed to have normalized and case-converted the domain names 
+     before they were generated or stored. Also note that applications 
+   
+  Hall                    I-D Expires: May 2002              [page 45] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     will validate the host identifiers that they receive in response 
+     messages, so an additional check is expected to be performed on 
+     the answer data by those systems. 
+      
+      
+  7.2.2.  Fall-back processing 
+      
+     If a queried server is unable to process EDNS/UTF-8 extended 
+     labels, then it is required by STD13 to generate an error 
+     signifying the problem. Resolvers MUST interpret these errors, 
+     decode the UTF-8 queried domain name, re-encode it as STD13 octets 
+     and/or ACE per the instructions provided in section 5.2, and then 
+     reissue the query as an STD13 legacy label sequence. 
+      
+     The legacy DNS error responses which will trigger this series of 
+     events are FORMERR and NOTIMPL. Any other errors indicate that the 
+     EDNS/UTF-8 extended label was successfully processed but that the 
+     query was not matched, and those errors MUST be returned to the 
+     application. If the fallback processing results in any error 
+     responses whatsoever, then the resolver MUST return those errors 
+     to the calling application. 
+      
+     Any servers which subsequently receive the fall-back queries and 
+     which are compliant with this specification will process the 
+     queries as internationalized domain names, and will return the 
+     answer data as STD13 octet sequences or ACE encoded data, using 
+     the STD13 legacy label. 
+      
+     Generally speaking, fall-back processing serves two purposes: 
+      
+        *   Answering the initial query. If a UTF-8 domain name cannot 
+            be resolved because a server in the delegation path does 
+            not understand the EDNS/UTF-8 label type, the resolver can 
+            reissue the query as an ACE encoded legacy label type so 
+            that the query proceeds past the problematic server. 
+      
+        *   Seeding the resolver's cache. As a result of the above, the 
+            resolver will learn about the authoritative name servers 
+            for the target zone, and this information can be used for 
+            any subsequent queries for domain names within the 
+            specified zone (for as long as the data is cached, anyway). 
+            As such, any subsequent EDNS/UTF-8 queries which are issued 
+            for the portion of the namespace served by that zone will 
+            be sent directly to one of those authoritative servers 
+            where they can be answered directly. In this regard, 
+   
+  Hall                    I-D Expires: May 2002              [page 46] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+            subsequent lookups do not require fall-back processing if 
+            they are received during the cache window. 
+      
+     Regardless of whether or not fall-back processing has been 
+     performed, if the calling application issued the original query as 
+     an internationalized domain name, then the resolver MUST respond 
+     to the query in that form as well. This means that the resolver 
+     MUST convert any STD13 octet sequences or ACE encoded labels into 
+     their canonical UCS characters, convert the answer data into the 
+     resolver's native charset or encoding, and return the data to the 
+     calling process. The resolver MUST NOT perform any normalization 
+     or case-conversion during this process, as such an action can 
+     corrupt domain names which are not used for host identifiers. 
+      
+     If the original query was received through the resolver's legacy 
+     APIs, then the query MUST be generated and returned in the legacy 
+     format, and MUST NOT be converted to an internationalized domain 
+     name prior to the query or response being passed through. 
+      
+     Once fall-back processing occurs, the process MUST NOT be repeated 
+     for any additional queries in the current lookup operation. No 
+     other queries from the current lookup operations MUST NOT be sent 
+     as EDNS/UTF-8 extended labels, since multiple fall-back operations 
+     can result in time-outs on the client systems. 
+      
+     Because the fall-back process results in two lookups being issued 
+     against the rejecting zone, eliminating the fall-back processing 
+     as soon as possible will be an operational requirement for many 
+     organizations. Any caches or forwarders which are used by stub 
+     resolvers within an end-user network are practically required to 
+     be able to process the EDNS/UTF-8 queries, since those servers 
+     will receive every query which is issued by the stub resolvers. 
+     While this isn't a technical requirement (fall-back processing 
+     will get around the problematic servers), it will likely prove to 
+     be a consideration for network operators looking to support 
+     internationalized domain names on their local networks. 
+      
+     This document also strongly encourages the root and TLD servers to 
+     be upgraded as soon as possible (even if they do not intend to 
+     directly provide UTF-8 domain name delegations), in order to allow 
+     those servers to read and process the EDNS/UTF-8 extended labels, 
+     thereby reducing the number of fall-back queries which are sent to 
+     those servers. 
+      
+      
+   
+  Hall                    I-D Expires: May 2002              [page 47] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+  7.3.    The Hosts Database 
+      
+     Generally speaking, there are two areas of consideration for stub 
+     resolvers that provide local hosts databases for name resolution 
+     services. These are the input requirements for internationalized 
+     domain names which will be added to the hosts database, and the 
+     requirements which govern how queries will be compared to the 
+     entries in the hosts database. 
+      
+     Note that resolvers are not required to implement a hosts database 
+     or local lookup services (STD3 says "a host MAY also implement a 
+     host name translation mechanism that searches a local Internet 
+     host table"). However, wherever a hosts database is provided with 
+     an internationalized resolver, compliance with the rules specified 
+     in this section is required. 
+      
+     If a stub resolver offers the capability to compare 
+     internationalized domain names against a local hosts database, 
+     that database MUST be compatible with the internationalized domain 
+     name rules specified in section 4 of this document. 
+      
+     In particular, the resolver SHOULD allow internationalized domain 
+     names with any code values to be stored, even if the canonical UCS 
+     characters for those values are undefined or are illegal for use 
+     with internationalized host identifiers (this is required to 
+     support domain names which are not host identifiers). In those 
+     cases where an internationalized domain name specifies an exact 
+     sequence of octets for binary comparison, the hosts database MUST 
+     provide a mechanism for tagging the eight-bit characters so that 
+     they are not interpreted, processed or compared as the canonical 
+     UCS character equivalents of those codes. 
+      
+     However, entries which explicitly provide host identifiers MUST be 
+     normalized and case-converted prior to being stored. In order to 
+     satisfy both of these requirements, it is RECOMMENDED that hosts 
+     databases store internationalized host identifiers as untagged 
+     data, but that they also provide some sort of tagging service for 
+     character code values which are to be returned as-is. STD13 
+     defines an escaping mechanism whereby the decimal value of the 
+     octet is prefaced with a reverse-solidus (such as "\193"), which 
+     is suggested for this usage. 
+      
+     The storage format of the hosts database MAY use any charset or 
+     encoding the resolver deems most suitable for that platform, as 
+     long as the rules and restrictions provided above are followed. 
+     Since UTF-8 is used as the default encoding throughout this 
+   
+  Hall                    I-D Expires: May 2002              [page 48] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     specification, it is RECOMMENDED as the default encoding for hosts 
+     databases as well, although this is not required. 
+      
+     Not all of the applications which use a resolver are likely to be 
+     compliant with this specification, so resolvers MUST ensure that 
+     they are able to interpret and process any queries from the legacy 
+     APIs which provide the ACE equivalent of an internationalized 
+     domain name that is stored in the hosts database. When such a 
+     query arrives, the domain name MUST be converted to the canonical 
+     UCS character codes represented by the ACE encoded sequence and 
+     compared to entries in the hosts database in that form (tagged 
+     octets excluded). Any internationalized domain names which are 
+     required to be returned through the legacy APIs MUST be converted 
+     to STD13 octet sequences and/or ACE before they are returned. 
+      
+      
+  8.      Server Guidelines 
+      
+     When a zone administrator desires to provide internationalized 
+     domain names in a zone, they are presented with two options: they 
+     can add the STD13 octets or ACE encoded internationalized domain 
+     names to an existing zone, or they can use internationalized zone 
+     databases directly. Both of these usage scenarios have their own 
+     benefits and restrictions. 
+      
+     Using STD13 octet sequences and ACE with legacy servers allows for 
+     the immediate deployment of internationalized domain names on 
+     existing servers, and within hierarchies which include 
+     internationalized domain names. However, any such queries which 
+     originate at applications that are compliant with this 
+     specification will always initially fail, guaranteeing that fall-
+     back processing will always occur for those zones. 
+      
+     Conversely, using internationalized zones directly allows servers 
+     to process legacy, ACE and EDNS/UTF-8 queries equally, thereby 
+     providing greater value to the applications and resolvers which 
+     have been made compliant with this specification. However, 
+     internationalized zones have additional requirements (most 
+     notably, they are required to be upgraded simultaneously), and 
+     these will prove burdensome to some zone operators. 
+      
+     This specification focuses on the processing requirements for 
+     internationalized zones which support the use of internationalized 
+     domain names as explicit data, and which also support the 
+     necessary subordinate mechanisms such as EDNS/UTF-8 queries. When 
+     STD13 octet sequences or ACE encoded domain names are used with 
+   
+  Hall                    I-D Expires: May 2002              [page 49] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     legacy servers, the rules defined in STD13 for those servers MUST 
+     be used. 
+      
+     Note that each zone SHOULD be configurable independently. If a 
+     server hosts multiple zones, each of those zones SHOULD be 
+     operable as independent entities, with any of them using ACE or 
+     internationalized domain names as necessary. This rule is 
+     necessary since each zone is likely to have different replication 
+     partners and configuration rules which will require different 
+     migration strategies. 
+      
+      
+  8.1.    Internationalized Zones 
+      
+     All domain names which are published by an internationalized zone 
+     MUST be compatible with the restrictions specified in section 4 of 
+     this document. In particular, the zone database MUST allow binary 
+     domain names to be stored as any octet value, but MUST also comply 
+     with the normalization and case-mapping rules when a domain name 
+     represents a host identifier. These restrictions MUST be applied 
+     as part of the process in which the domain name is being added to 
+     the zone database. In those cases where an internationalized 
+     domain name specifies an exact sequence of octets for binary 
+     comparison, the hosts database MUST provide a mechanism for 
+     tagging the eight-bit characters so that they are not interpreted, 
+     processed or compared as the canonical UCS character equivalents 
+     of those codes. STD13 defines an escaping mechanism whereby the 
+     decimal value of the octet is prefaced with a reverse-solidus 
+     (such as "\193"), which is suggested for this usage. 
+      
+     Servers which are compliant with this specification MUST be 
+     capable of providing UTF-8 and ACE encoded representations of the 
+     UCS domain names which are stored in the zone, and servers MUST 
+     restrict output to only one label type for any protocol operation, 
+     such that queries containing STD13 legacy labels MUST be answered 
+     with STD13 octet sequences and/or ACE encoded domain names, while 
+     EDNS/UTF-8 queries MUST only be answered with UTF-8 encoded domain 
+     names (this not only includes basic operations such as simple 
+     queries, but also includes advanced operations such as zone 
+     transfers; see section 8.2). Similarly, external operations such 
+     as exporting the contents of the zone to a master file (as 
+     discussed in section 8.3) MUST result in a single encoding form 
+     being used for that specific operation. 
+      
+     Note that the underlying zone database technology which may be 
+     employed by any particular server is beyond the scope of this 
+   
+  Hall                    I-D Expires: May 2002              [page 50] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     document. Servers MAY use any database technology, charset or 
+     encoding deemed appropriate for the local environment, although 
+     the contents of the zone MUST be mapped to the canonical UCS 
+     character codes for all comparison operations (octet values 
+     excluded). Since UTF-8 is used as the default encoding throughout 
+     this specification, it is RECOMMENDED for use as the default 
+     encoding with zone databases as well, but is not required. 
+      
+     Servers MUST NOT normalize or case-map any UCS characters which 
+     are decoded from UTF-8 or ACE encoded labels, and MUST restrict 
+     comparison operations of these labels to precise matches of the 
+     UCS domain names which are stored in the zone database. However, 
+     the seven bit character codes from any labels which are received 
+     as STD13 octet sequences MUST be compared in a case-neutral form, 
+     and MUST NOT be normalized as part of the comparison operation. 
+      
+     When a zone is converted to support internationalized domain 
+     names, all of the servers which replicate that zone MUST be 
+     upgraded. This is required due to ambiguities that can occur with 
+     labels which may be encoded as either STD13 octet sequences or ACE 
+     data, and where the label only uses character codes from the 
+     eight-bit range of character codes (this problem is described in 
+     detail in section 4.1.2). In order to ensure that all of the 
+     servers for a zone respond to one of those queries correctly, all 
+     of the servers which replicate the zone MUST fully support this 
+     document and its requirements. 
+      
+      
+  8.2.    Namespace Visibility Restrictions 
+      
+     In all cases, the encoding format of the domain names which are 
+     returned in response to a query MUST be the same as the encoding 
+     format which was used by the query. If the query was provided as a 
+     sequence of legacy labels, then all of the domain names which are 
+     provided in the response message MUST be provided as legacy labels 
+     (containing either ACE or STD13 octet encoded values). 
+      
+     Similarly, if a query is provided as EDNS/UTF-8 encoded data, all 
+     domain names which are provided in the response message MUST be 
+     provided as UTF-8 encoded data in EDNS/UTF-8 extended labels. In 
+     some situations, this process may require the server to perform an 
+     extra conversion. 
+      
+     For example, assume that the <idn>.example.com. domain name has 
+     two associated MX resource records, one of which points to the UCS 
+     domain name of mail.<idn>.example.com, while the other points to 
+   
+  Hall                    I-D Expires: May 2002              [page 51] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     the ACE encoded domain name of mail.<ace>.example.net. (where the 
+     "<ace>" label is the ACE equivalent of an internationalized sub-
+     domain in the example.net. zone). If a UTF-8 query arrives for the 
+     MX resource records associated with the <idn>.example.com. domain 
+     name, both resource records MUST be returned as EDNS/UTF-8 data. 
+     In order for this requirement to be satisfied, the server will 
+     have to decode the <ace> label to its UCS canonical form for zone 
+     storage purposes, and encode the domain name as UTF-8 for 
+     transmission whenever an EDNS/UTF-8 answer set is required. 
+      
+     The visibility rules specified in this section are mandatory for 
+     every domain name which is provided in any message. If a system 
+     requests a zone transfer and uses the EDNS/UTF-8 extended label 
+     type in the request, all of the domain names in all of the 
+     messages which are sent as part of the zone transfer MUST be 
+     provided in their UTF-8 encoded form. Similarly, if a zone 
+     transfer is requested and uses the legacy label type, then all of 
+     the domain names from all of the messages which are sent as part 
+     of the zone transfer MUST be provided as either STD13 octet 
+     sequences or ACE encoded data, using the legacy label type. 
+      
+      
+  8.3.    The Master File Format 
+      
+     STD13 specifies a "master file" format which is used as a 
+     platform-neutral storage and transfer format for importing and 
+     exporting the contents of a particular zone. Note that the master 
+     file is not the same as the operating database for a zone; the 
+     master file format is used (or is useful) for copying a zone to 
+     another server, storing a copy of the zone database off-line, 
+     emailing a copy of the zone to another user or system, and 
+     performing other off-line actions against the database' contents. 
+     Once a zone is loaded on a server, however, any database 
+     technology can be used for managing the zones and generating 
+     response messages. 
+      
+     In order to facilitate the continued use of master files, any zone 
+     which is compliant with this specification MUST support the use of 
+     UTF-8 as an import and export encoding format for the master file 
+     associated with that zone. 
+      
+     Furthermore, compliant versions of a master file are required to 
+     have the "$UTF-8" control literal at the beginning of the first 
+     line of text in the master file if it contains UTF-8 encoded data. 
+     Master files from zones which do not contain UTF-8 encoded domain 
+   
+  Hall                    I-D Expires: May 2002              [page 52] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     names MUST NOT contain the "$UTF-8" control literal in the first 
+     print position of any line. 
+      
+     If the master file contains the "$UTF-8" control literal, all of 
+     the data within the master file MUST be encoded in UTF-8 as 
+     specified by RFC2279, and SHOULD be managed with UTF-8 compliant 
+     tools (such as UTF-8 text editors, mailers that support UTF-8 MIME 
+     encodings, and so forth). 
+      
+      
+  9.      Caching Guidelines 
+      
+     Whenever an internationalized domain name is stored in a cache, it 
+     MUST be stored in its canonical UCS character code form, 
+     regardless of whether the domain name was received as STD13 octet 
+     encoding sequences, UTF-8, or ACE data. Caches MUST NOT normalize 
+     or case convert any domain names that they store, as such a 
+     process could invalidate domain names that are not used for host 
+     identifiers. 
+      
+     Any subsequent queries which are processed through the cache MUST 
+     be compared against the stored UCS characters. Internationalized 
+     domain name labels which are decoded from UTF-8 or ACE labels MUST 
+     NOT be normalized or case-converted as part of the comparison 
+     operation, although labels which are provided as STD13 octet 
+     sequences MUST be compared as case-neutral octet values. 
+      
+     Caches MUST be capable of providing UTF-8 and ACE encoded 
+     representations of the UCS domain names which are stored in the 
+     cache, with the appropriate format determined by the format used 
+     in the corresponding query. However, answer data MUST be 
+     restricted to only one encoding form for any protocol operation, 
+     meaning that queries containing legacy labels MUST only be 
+     answered with STD13 octet sequences and/or ACE encoded labels, 
+     while UTF-8 queries MUST only be answered with UTF-8 encoded 
+     domain names. 
+      
+      
+  10.     Security Considerations 
+      
+     This document defines an extension to the domain name system, and 
+     as such, it inherits the weaknesses which already exist in DNS. 
+     Where possible, this specification strengthens DNS with multiple 
+     checks. For example, this specification requires that domain names 
+     be validated three times before they are used by applications: 
+     once on specification, once on entry at the authoritative zone or 
+   
+  Hall                    I-D Expires: May 2002              [page 53] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+     hosts database, and once again when the answer data is received by 
+     the requesting application. Despite these checks, the root 
+     weaknesses inherent in DNS are still present. 
+      
+     This document uses multiple encoding algorithms, although boundary 
+     conditions from the existing DNS are preserved for both the source 
+     and encoded representations. 
+      
+      
+  11.     IANA Considerations 
+      
+     This document requires the use of an EDNS extended label type 
+     identification code. This document uses the b000011 ELT code. 
+      
+      
+  12.     References 
+      
+          [AMC-ACE-Z] <draft-ietf-idn-amc-ace-z>, "AMC-ACE-Z version 
+            0.3.1" 
+      
+          [NAMEPREP] <draft-ietf-idn-nameprep>, "Preparation of 
+            Internationalized Host Names" 
+      
+          [RFC2119] "Key words for use in RFCs to Indicate Requirement 
+            Levels" 
+      
+          [RFC952] "DoD Internet host table specification" 
+      
+          [STD13] (RFC 1034) "Domain names - concepts and facilities", 
+            (RFC 1035) "Domain names - implementation and 
+            specification" 
+      
+          [STD3] (RFC 1122) "Requirements for Internet Hosts -- 
+            Communication Layers", (RFC1123) "Requirements for Internet 
+            Hosts -- Application and Support" 
+      
+          [BCP18] (RFC 2277) "IETF Policy on Character Sets and 
+            Languages" 
+      
+          [RFC2279] "UTF-8, a transformation format of ISO 10646" 
+      
+          [RFC2671] "Extension Mechanisms for DNS (EDNS0)" 
+      
+          [ASCII] "ANSI X3.4-1968. USA Standard Code for Information 
+            Interchange" 
+      
+   
+  Hall                    I-D Expires: May 2002              [page 54] 
+  INTERNET-DRAFT        draft-hall-dm-idns-00.txt        November 2001 
+   
+   
+          [ISO10646] "ISO/IEC 10646-1:2000. International Standard -- 
+            Information technology -- Universal Multiple-Octet Coded 
+            Character Set (UCS) -- Part 1: Architecture and Basic 
+            Multilingual Plane" 
+      
+      
+  13.     Acknowledgements 
+      
+     This document is an assembly of multiple ideas and proposals which 
+     have been made on the IDN working group mailing list. Many of the 
+     ideas presented here have been proposed by multiple parties in one 
+     form or another, although Dan Oscarsson is credited for proposing 
+     a dual-mode operation which is capable of simultaneously 
+     supporting UTF-8 and legacy mode encodings. Other contributors to 
+     key elements from this specification (some of them unknowingly or 
+     unwillingly) include (alphabetically) Marc Blanchett, Adam 
+     Costello, Mark Davis, Martin Duerst, Patrik Faltstrom, Paul 
+     Hoffman, David Hopwood, and many others. 
+      
+      
+  14.     Editor's Address 
+      
+     Eric A. Hall 
+     ehall@ehsco.com 
+      
+      
+      
+   
+  Hall                    I-D Expires: May 2002              [page 55] 
diff --git a/Documentation/en/I-D/draft-hoffman-rfc2487bis-06.txt b/Documentation/en/I-D/draft-hoffman-rfc2487bis-06.txt
new file mode 100644
index 00000000..4a9bb62d
--- /dev/null
+++ b/Documentation/en/I-D/draft-hoffman-rfc2487bis-06.txt
@@ -0,0 +1,356 @@
+Internet Draft                                          Paul Hoffman
+draft-hoffman-rfc2487bis-06.txt             Internet Mail Consortium
+November 4, 2001
+Expires in six months
+
+            SMTP Service Extension for Secure SMTP over TLS
+
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups.  Note that other
+groups may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time.  It is inappropriate to use Internet- Drafts as reference
+material or to cite them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+1. Abstract
+
+   This document describes an extension to the SMTP service that allows
+   an SMTP server and client to use transport-layer security to provide
+   private, authenticated communication over the Internet. This gives
+   SMTP agents the ability to protect some or all of their
+   communications from eavesdroppers and attackers.
+
+   This document obsoletes RFC 2487, as described in Appendix B.
+
+2. Introduction
+
+   SMTP [RFC-2821] servers and clients normally communicate in the clear
+   over the Internet. In many cases, this communication goes through one
+   or more router that is not controlled or trusted by either entity.
+   Such an untrusted router might allow a third party to monitor or
+   alter the communications between the server and client.
+
+   Further, there is often a desire for two SMTP agents to be able to
+   authenticate each others' identities. For example, a secure SMTP
+   server might only allow communications from other SMTP agents it
+   knows, or it might act differently for messages received from an
+   agent it knows than from one it doesn't know.
+
+   TLS [TLS], more commonly known as SSL, is a popular mechanism for
+   enhancing TCP communications with privacy and authentication. TLS is
+   in wide use with the HTTP protocol, and is also being used for adding
+   security to many other common protocols that run over TCP.
+
+2.1 Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+3. STARTTLS Extension
+
+   The STARTTLS extension to SMTP is laid out as follows:
+
+   (1) the name of the SMTP service defined here is STARTTLS;
+
+   (2) the EHLO keyword value associated with the extension is STARTTLS;
+
+   (3) the STARTTLS keyword has no parameters;
+
+   (4) a new SMTP verb, "STARTTLS", is defined;
+
+   (5) no additional parameters are added to any SMTP command.
+
+4. The STARTTLS Keyword
+
+    The STARTTLS keyword is used to tell the SMTP client that the SMTP
+    server is currently able to negotiate the use of TLS. It takes no
+    parameters.
+
+5. The STARTTLS Command
+
+   The format for the STARTTLS command is:
+
+   STARTTLS
+
+   with no parameters.
+
+   After the client gives the STARTTLS command, the server responds with
+   one of the following reply codes:
+
+   220 Ready to start TLS
+   501 Syntax error (no parameters allowed)
+   454 TLS not available due to temporary reason
+
+   If the client receives the 454 response, the client must decide
+   whether or not to continue the SMTP session. Such a decision is
+   based on local policy. For instance, if TLS was being used for
+   client authentication, the client might try to continue the
+   session, in case the server allows it even with no authentication.
+   However, if TLS was being negotiated for encryption, a client
+   that gets a 454 response needs to decide whether to send the
+   message anyway with no TLS encryption, whether to wait and try
+   again later, or whether to give up and notify the sender of the
+   error.
+
+   A publicly-referenced SMTP server MUST NOT require use of the
+   STARTTLS extension in order to deliver mail locally. This rule
+   prevents the STARTTLS extension from damaging the interoperability of
+   the Internet's SMTP infrastructure. A publicly-referenced SMTP server
+   is an SMTP server which runs on port 25 of an Internet host listed in
+   the MX record (or A record if an MX record is not present) for the
+   domain name on the right hand side of an Internet mail address.
+
+   Any SMTP server may refuse to accept messages for relay based on
+   authentication supplied during the TLS negotiation. An SMTP server
+   that is not publicly referenced may refuse to accept any messages for
+   relay or local delivery based on authentication supplied during the
+   TLS negotiation.
+
+   A SMTP server that is not publicly referenced may choose to require
+   that the client perform a TLS negotiation before accepting any
+   commands. In this case, the server SHOULD return the reply code:
+
+   530 Must issue a STARTTLS command first
+
+   to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
+   client and server are using the ENHANCEDSTATUSCODES ESMTP extension
+   [RFC-2034], the status code to be returned SHOULD be 5.7.0.
+
+   After receiving a 220 response to a STARTTLS command, the client MUST
+   start the TLS negotiation before giving any other SMTP commands. If,
+   after having issued the STARTTLS command, the client finds out that
+   some failure prevents it from actually starting a TLS handshake, then
+   it SHOULD abort the connection.
+
+   If the SMTP client is using pipelining as defined in RFC 2920, the
+   STARTTLS command must be the last command in a group.
+
+5.1 Processing After the STARTTLS Command
+
+   After the TLS handshake has been completed, both parties MUST
+   immediately decide whether or not to continue based on the
+   authentication and privacy achieved. The SMTP client and server may
+   decide to move ahead even if the TLS negotiation ended with no
+   authentication and/or no privacy because most SMTP services are
+   performed with no authentication and no privacy, but some SMTP
+   clients or servers may want to continue only if a particular level of
+   authentication and/or privacy was achieved.
+
+   If the SMTP client decides that the level of authentication or
+   privacy is not high enough for it to continue, it SHOULD issue an
+   SMTP QUIT command immediately after the TLS negotiation is complete.
+   If the SMTP server decides that the level of authentication or
+   privacy is not high enough for it to continue, it SHOULD reply to
+   every SMTP command from the client (other than a QUIT command) with
+   the 554 reply code (with a possible text string such as "Command
+   refused due to lack of security").
+
+   The decision of whether or not to believe the authenticity of the
+   other party in a TLS negotiation is a local matter. However, some
+   general rules for the decisions are:
+
+    - A SMTP client would probably only want to authenticate an SMTP
+      server whose server certificate has a domain name that is the
+      domain name that the client thought it was connecting to.
+    - A publicly-referenced  SMTP server would probably want to accept
+	  any verifiable certificate from an SMTP client, and would
+	  possibly want to put distinguishing information about the
+	  certificate in the Received header of messages that were relayed
+	  or submitted from the client.
+
+5.2 Result of the STARTTLS Command
+
+   Upon completion of the TLS handshake, the SMTP protocol is reset to
+   the initial state (the state in SMTP after a server issues a 220
+   service ready greeting). The server MUST discard any knowledge
+   obtained from the client, such as the argument to the EHLO command,
+   which was not obtained from the TLS negotiation itself. The client
+   MUST discard any knowledge obtained from the server, such as the list
+   of SMTP service extensions, which was not obtained from the TLS
+   negotiation itself. The client SHOULD send an EHLO command as the
+   first command after a successful TLS negotiation.
+
+   The list of SMTP service extensions returned in response to an EHLO
+   command received after the TLS handshake MAY be different than the
+   list returned before the TLS handshake. For example, an SMTP server
+   might not want to advertise support for a particular SASL mechanism
+   [SASL] unless a client has sent an appropriate client certificate
+   during a TLS handshake.
+
+   Both the client and the server MUST know if there is a TLS session
+   active.  A client MUST NOT attempt to start a TLS session if a TLS
+   session is already active. A server MUST NOT return the STARTTLS
+   extension in response to an EHLO command received after a TLS
+   handshake has completed.
+   
+5.3 STARTTLS on the Submission Port
+
+   STARTTLS is a valid ESMTP extension when used on the Submission
+   port, as defined in [RFC-2476]. In fact, since the submission port
+   is by definition not a publicly referenced SMTP server, the STARTTLS
+   extension can be particularly useful by providing security and
+   authentication for this service.
+
+6. Usage Example
+
+   The following dialog illustrates how a client and server can start a
+   TLS session:
+
+   S: <waits for connection on TCP port 25>
+   C: <opens connection>
+   S: 220 mail.imc.org SMTP service ready
+   C: EHLO mail.example.com
+   S: 250-mail.imc.org offers a warm hug of welcome
+   S: 250-8BITMIME
+   S: 250-STARTTLS
+   S: 250 DSN
+   C: STARTTLS
+   S: 220 Go ahead
+   C: <starts TLS negotiation>
+   C & S: <negotiate a TLS session>
+   C & S: <check result of negotiation>
+   C: EHLO mail.exmaple.com
+   S: 250-mail.imc.org touches your hand gently for a moment
+   S: 250-8BITMIME
+   S: 250 DSN
+   . . .
+
+7. Security Considerations
+
+   It should be noted that SMTP is not an end-to-end mechanism. Thus, if
+   an SMTP client/server pair decide to add TLS privacy, they are not
+   securing the transport from the originating mail user agent to the
+   recipient. Further, because delivery of a single piece of mail may
+   go between more than two SMTP servers, adding TLS privacy to one pair
+   of servers does not mean that the entire SMTP chain has been made
+   private. Further, just because an SMTP server can authenticate an
+   SMTP client, it does not mean that the mail from the SMTP client was
+   authenticated by the SMTP client when the client received it.
+
+   Both the SMTP client and server must check the result of the TLS
+   negotiation to see whether an acceptable degree of authentication
+   and privacy was achieved. Ignoring this step completely invalidates
+   using TLS for security. The decision about whether acceptable
+   authentication or privacy was achieved is made locally, is
+   implementation-dependant, and is beyond the scope of this document.
+
+   The SMTP client and server should note carefully the result of the
+   TLS negotiation. If the negotiation results in no privacy, or if it
+   results in privacy using algorithms or key lengths that are deemed
+   not strong enough, or if the authentication is not good enough for
+   either party, the client may choose to end the SMTP session with an
+   immediate QUIT command, or the server may choose to not accept any
+   more SMTP commands.
+
+   A man-in-the-middle attack can be launched by deleting the "250
+   STARTTLS" response from the server. This would cause the client not
+   to try to start a TLS session. Another man-in-the-middle attack is to
+   allow the server to announce its STARTTLS capability, but to alter
+   the client's request to start TLS and the server's response. In order
+   to defend against such attacks both clients and servers MUST be able
+   to be configured to require successful TLS negotiation of an
+   appropriate cipher suite for selected hosts before messages can be
+   successfully transferred. The additional option of using TLS when
+   possible SHOULD also be provided. An implementation MAY provide the
+   ability to record that TLS was used in communicating with a given
+   peer and generating a warning if it is not used in a later session.
+
+   If the TLS negotiation fails or if the client receives a 454
+   response, the client has to decide what to do next. There are three
+   main choices: go ahead with the rest of the SMTP session, retry TLS
+   at a later time, or give up and return the mail to the sender. If a
+   failure or error occurs, the client can assume that the server may
+   be able to negotiate TLS in the future, and should try negotiate TLS
+   in a later session, until some locally-chosen timeout occurs, at
+   which point, the client should return the mail to the sender.
+   However, if the client and server were only using TLS for
+   authentication, the client may want to proceed with the SMTP
+   session, in case some of the operations the client wanted to perform
+   are accepted by the server even if the client is unauthenticated.
+
+   Before the TLS handshake has begun, any protocol interactions are
+   performed in the clear and may be modified by an active attacker. For
+   this reason, clients and servers MUST discard any knowledge obtained
+   prior to the start of the TLS handshake upon completion of the TLS
+   handshake.
+
+   The STARTTLS extension is not suitable for authenticating the author
+   of an email message unless every hop in the delivery chain, including
+   the submission to the first SMTP server, is authenticated. Another
+   proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
+   security multiparts [MIME-SEC] can be used to authenticate the author
+   of an email message. In addition, the [SMTP-AUTH] proposal offers
+   simpler and more flexible options to authenticate an SMTP client and
+   the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with
+   the STARTTLS command to provide an authorization identity.
+
+A. References
+
+   [RFC-2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+               April 2001.
+
+   [RFC-1869]  Klensin, J., Freed, N, Rose, M, Stefferud, E. and D.
+               Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
+               November 1995.
+
+   [RFC-2034]  Freed, N., "SMTP Service Extension for Returning Enhanced
+               Error Codes", RFC 2034, October 1996.
+
+   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-2476]  Gellens, R. and Klensin, J., "Message Submission",
+               RFC 2476, December 1998.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
+			   RFC 2554, March 1999.
+
+   [TLS]       Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+               RFC 2246, January 1999.
+
+B. Changes from RFC 2487
+
+   This document is a revision of RFC 2487, which is a Proposed
+   Standard. The changes from that document are:
+
+   - Section 5 and 7: More discussion of the man-in-the-middle attacks
+   - Section 5: Additional discussion of when a server should and should
+     not advertise the STARTTLS extension
+   - Section 5: Changed the requirements on SMTP clients after receiving
+     a 220 response.
+   - Section 5.1: Clarified description of verifying certificates.
+   - Section 5.3: Added the section on "STARTTLS on the Submission Port"
+   - Section 6: Bug fix in the example to indicate that the client needs
+     to issue a new EHLO command, as already is described in section 5.2.
+   - Section 7: Clarification of the paragraph on acceptable degree of
+     privacy. Significant change to the discussion of how to avoid a
+     man-in-the-middle attack.
+   - Section A: Update reference from RFC 821 to RFC 2821.
+
+
+C. Author's Address
+
+   Paul Hoffman
+   Internet Mail Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060
+
+   Phone: (831) 426-9827
+   EMail: phoffman@imc.org
diff --git a/Documentation/en/I-D/draft-huitema-shipworm-01.txt b/Documentation/en/I-D/draft-huitema-shipworm-01.txt
new file mode 100644
index 00000000..9bb0b8fd
--- /dev/null
+++ b/Documentation/en/I-D/draft-huitema-shipworm-01.txt
@@ -0,0 +1,9 @@
+

+This  document has been replaced by draft-ietf-ngtrans-shipworm-00.txt.
+For more information or a copy of the document, contact the author directly.

+

+Draft Author(s):

+

+C. Huitema: huitema@bellcore.com                                                    

+

+

diff --git a/Documentation/en/I-D/draft-ietf-impp-datetime-01.txt b/Documentation/en/I-D/draft-ietf-impp-datetime-01.txt
new file mode 100644
index 00000000..015c034f
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-impp-datetime-01.txt
@@ -0,0 +1,962 @@
+Network Working Group                   G. Klyne, Baltimore Technologies
+Internet Draft                               C. Newman, Sun Microsystems
+                                                             10 May 2001
+                                                  Expires: November 2001
+
+
+               Date and Time on the Internet: Timestamps
+                   <draft-ietf-impp-datetime-01.txt>
+
+
+Status of this memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC 2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress".
+
+     The list of current Internet-Drafts can be accessed at
+     http://www.ietf.org/1id-abstracts.html
+
+     The list of Internet-Draft Shadow Directories can be accessed at
+     http://www.ietf.org/shadow.html.
+
+
+
+   To view the entire list of current Internet-Drafts, please check the
+   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
+   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
+   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+
+Abstract
+
+   This document defines a date and time format for use in Internet
+   protocols that is a profile of the ISO 8601 [ISO8601] standard for
+   representation of dates and times using the Gregorian calendar.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 1]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Table of Contents
+
+   1. Introduction
+   2. Definitions
+   3. Two Digit Years
+   4. Local Time
+   4.1. Coordinated Universal Time (UTC)
+   4.2. Local Offsets
+   4.3. Unknown Local Offset Convention
+   4.4. Unqualified Local Time
+   5. Date and Time format
+   5.1. Ordering
+   5.2. Human Readability
+   5.3. Rarely Used Options
+   5.4. Redundant Information
+   5.5. Simplicity
+   5.6. Internet Date/Time Format
+   5.7. Restrictions
+   5.8. Examples
+   6. Acknowledgements
+   7. References
+   8. Security Considerations
+   9. Authors' Addresses
+   Appendix A. ISO 8601 Collected ABNF
+   Appendix B. Day of the Week
+   Appendix C. Leap Years
+   Appendix D. Leap Seconds
+   Appendix E. Amendment history
+   Full copyright statement
+
+
+1. Introduction
+
+   Date and time formats cause a lot of confusion and interoperability
+   problems on the Internet.  This document addresses many of the
+   problems encountered and makes recommendations to improve consistency
+   and interoperability when representing and using date and time in
+   Internet protocols.
+
+   This document includes an Internet profile of the ISO 8601 [ISO8601]
+   standard for representation of dates and times using the Gregorian
+   calendar.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 2]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   There are many ways in which date and time values might appear in
+   Internet protocols:  this document focuses on just one common usage,
+   viz. timestamps for Internet protocol events.  This limited
+   consideration has the following consequences:
+
+   o  All dates and times are assumed to be in the "current era",
+      somewhere between 0AD and 9999AD.
+
+   o  All times expressed have a stated relationship (offset) to
+      Coordinated Universal Time (UTC).  (This is distinct from some
+      usage in scheduling applications where a local time and location
+      may be known, but the actual relationship to UTC may be dependent
+      on the unknown or unknowable actions of politicians or
+      administrators.  The UTC time corresponding to 17:00 on 23rd March
+      2005 in New York may depend on administrative decisions about
+      daylight savings time.  This specification steers well clear of
+      such considerations.)
+
+   o  Date and time expressions indicate an instant in time.
+      Description of time periods, or intervals, is not covered here.
+
+
+2. Definitions
+
+
+   UTC         Coordinated Universal Time as maintained by the Bureau
+               International des Poids et Mesures (BIPM).
+
+   second      A basic unit of measurement of time in the International
+               System of Units.  It is defined as the duration of
+               9,192,631,770 cycles of microwave light absorbed or
+               emitted by the hyperfine transition of cesium-133 atoms
+               in their ground state undisturbed by external fields.
+
+   minute      A period of time of 60 seconds.
+
+   hour        A period of time of 60 minutes.
+
+   day         A period of time of 24 hours.
+
+   leap year   In the Gregorian calendar, a year which has 366 days.  A
+               leap year is a year whose number is divisible by four an
+               integral number of times, except that if it is a
+               centennial year it shall be divisible by four hundred an
+               integral number of times.
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 3]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   ABNF        Augmented Backus-Naur Form, a format used to represent
+               permissible strings in a protocol or language, as defined
+               in [ABNF].
+
+   Email Date/Time Format
+               The date/time format used by Internet Mail as defined by
+               RFC 822 [IMAIL] and amended by RFC 1123 [HOST-REQ].
+
+   Internet Date/Time Format
+               The date format defined in section 5 of this document.
+
+   For more information about time scales, see Appendix E of [NTP],
+   Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF].
+
+
+3. Two Digit Years
+
+   The following requirements are to address the problems of ambiguity
+   of 2-digit years:
+
+   o  Internet Protocols MUST generate four digit years in dates.
+
+   o  The use of 2-digit years is deprecated.  If a 2-digit year is
+      received, it should be accepted ONLY if an incorrect
+      interpretation will not cause a protocol or processing failure
+      (e.g. if used only for logging or tracing purposes).
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as three digits.  This occurs if the program
+      simply subtracts 1900 from the year and doesn't check the number
+      of digits.  Programs wishing to robustly deal with dates generated
+      by such broken software may add 1900 to three digit years.
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as ":0", ":1", ... ":9", ";0", ...  This occurs
+      if the program simply subtracts 1900 from the year and adds the
+      decade to the US-ASCII character zero. Programs wishing to
+      robustly deal with dates generated by such broken software should
+      detect non-numeric decades and interpret appropriately.
+
+   The problems with two digit years amply demonstrate why all dates and
+   times used in Internet protocols MUST be fully qualified.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 4]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+4. Local Time
+
+4.1. Coordinated Universal Time (UTC)
+
+   Because the daylight rules for local timezones are so convoluted and
+   can change based on local law at unpredictable times, true
+   interoperability is best achieved by using Coordinated Universal Time
+   (UTC).  This specification does not cater to local timezone rules.
+
+4.2. Local Offsets
+
+   The offset between local time and UTC is often useful information.
+   For example, in electronic mail [IMAIL] the local offset provides a
+   useful heuristic to determine the probability of a prompt response.
+   Attempts to label local offsets with alphabetic strings have resulted
+   in poor interoperability in the past [IMAIL], [HOST-REQ].  Therefore
+   numeric offsets are now REQUIRED in Internet Mail Date/Time Format.
+
+   Numeric offsets are calculated as "local time minus UTC".  So the
+   equivalent time in UTC can be determined by subtracting the offset
+   from the local time.  For example, 18:50:00-04:00 is the same time as
+   22:50:00Z.
+
+4.3. Unknown Local Offset Convention
+
+   If the time in UTC is known, but the offset to local time is unknown,
+   this can be represented with an offset of "-00:00".  This differs
+   semantically from an offset of "Z" which implies that UTC is the
+   preferred reference point for the specified time.  This convention
+   MAY also be used in the Email Date/Time Format.
+
+4.4. Unqualified Local Time
+
+   A number of devices currently connected to the Internet run their
+   internal clocks in local time and are unaware of UTC.  While the
+   Internet does have a tradition of accepting reality when creating
+   specifications, this should not be done at the expense of
+   interoperability.  Since interpretation of an unqualified local
+   timezone will fail in approximately 23/24 of the globe, the
+   interoperability problems of unqualified local time are deemed
+   unacceptable for the Internet.  Systems that are configured with a
+   local time, are unaware of the corresponding UTC offset, and depend
+   on time synchronization with other Internet systems, MUST use a
+   mechanism that ensures correct synchronization with UTC.  Some
+   suitable mechanisms are:
+
+   o  Use Network Time Protocol [NTP] to obtain the time in UTC.
+
+
+
+
+Newman & Klyne                                                  [Page 5]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   o  Use another host in the same local timezone as a gateway to the
+      Internet.  This host MUST correct unqualified local times before
+      they are transmitted to other hosts.
+
+   o  Prompt the user for the local timezone and daylight savings
+      settings.
+
+
+5. Date and Time format
+
+   This section discusses desirable qualities of date and time formats
+   and defines a profile of ISO 8601 for use in Internet protocols.
+
+5.1. Ordering
+
+   If date and time components are ordered from least precise to most
+   precise, then a useful property is achieved.  Assuming that the
+   timezones of the dates and times are the same (e.g. all in UTC), then
+   the date and time strings may be sorted as strings (e.g. using the
+   strcmp() function in C) and a time-ordered sequence will result.  The
+   presence of optional punctuation would violate this characteristic.
+
+5.2. Human Readability
+
+   Human readability has proved to be a valuable feature of Internet
+   protocols.  Human readable protocols greatly reduce the costs of
+   debugging since telnet often suffices as a test client and network
+   analysers need not be modified with knowledge of the protocol.  On
+   the other hand, human readability sometimes results in
+   interoperability problems.  For example, the date format "10/11/1996"
+   is completely unsuitable for global interchange because it is
+   interpreted differently in different countries.  In addition, the
+   date format in [IMAIL] has resulted in interoperability problems when
+   people assumed any text string was permitted and translated the three
+   letter abbreviations to other languages or substituted date formats
+   which were easier to generate (e.g. the format used by the C function
+   ctime).  For this reason, a balance must be struck between human
+   readability and interoperability.
+
+   Because no date and time format is readable according to the
+   conventions of all countries, Internet clients SHOULD be prepared to
+   transform dates into a display format suitable for the locality.
+   This may include translating UTC to local time.
+
+5.3. Rarely Used Options
+
+   A format which includes rarely used options is likely to cause
+   interoperability problems.  This is because rarely used options are
+
+
+
+Newman & Klyne                                                  [Page 6]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   less likely to be used in alpha or beta testing, so bugs in parsing
+   are less likely to be discovered.  Rarely used options should be made
+   mandatory or omitted for the sake of interoperability whenever
+   possible.
+
+   The format defined below includes only one rarely used option:
+   fractions of a second.  It is expected that this will be used only by
+   applications which require strict ordering of date/time stamps or
+   which have an unusual precision requirement.
+
+5.4. Redundant Information
+
+   If a date/time format includes redundant information, that introduces
+   the possibility that the redundant information will not correlate.
+   For example, including the day of the week in a date/time format
+   introduces the possibility that the day of week is incorrect but the
+   date is correct, or vice versa.  Since it is not difficult to compute
+   the day of week from a date (see Appendix B), the day of week should
+   not be included in a date/time format.
+
+5.5. Simplicity
+
+   The complete set of date and time formats specified in ISO 8601
+   [ISO8601] is quite complex in an attempt to provide multiple
+   representations and partial representations.  Appendix A contains an
+   attempt to translate the complete syntax of ISO 8601 into ABNF.
+   Internet protocols have somewhat different requirements and
+   simplicity has proved to be an important characteristic.  In
+   addition, Internet protocols usually need complete specification of
+   data in order to achieve true interoperability.  Therefore, the
+   complete grammar for ISO 8601 is deemed too complex for most Internet
+   protocols.
+
+   The following section defines a profile of ISO 8601 for use on the
+   Internet.  It is a conformant subset of the ISO 8601 extended format.
+   Simplicity is achieved by making most fields and punctuation
+   mandatory.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 7]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+5.6. Internet Date/Time Format
+
+   The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
+   new protocols on the Internet.  This is specified using the syntax
+   description notation defined in [ABNF].
+
+      date-fullyear   = 4DIGIT
+      date-month      = 2DIGIT  ; 01-12
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      time-hour       = 2DIGIT  ; 00-23
+      time-minute     = 2DIGIT  ; 00-59
+      time-second     = 2DIGIT  ; 00-59, 00-60 based on leap second rules
+      time-secfrac    = "." 1*DIGIT
+      time-numoffset  = ("+" / "-") time-hour ":" time-minute
+      time-offset     = "Z" / time-numoffset
+
+      partial-time    = time-hour ":" time-minute ":" time-second
+                        [time-secfrac]
+      full-date       = date-fullyear "-" date-month "-" date-mday
+      full-time       = partial-time time-offset
+
+      date-time       = full-date "T" full-time
+
+
+     NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in
+     this syntax may alternatively be lower case "t" or "z"
+     respectively.
+
+     NOTE: ISO 8601 defines date and time separated by "T".
+     Applications using this syntax may choose, for the sake of
+     readability, to specify a full-date and full-time separated by
+     (say) a space character.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 8]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+5.7. Restrictions
+
+   The grammar element date-mday represents the day number within the
+   current month.  The maximum value varies based on the month and year
+   as follows:
+
+      Month Number  Month/Year           Maximum value of date-mday
+      ------------  ----------           --------------------------
+      01            January              31
+      02            February, normal     28
+      02            February, leap year  29
+      03            March                31
+      04            April                30
+      05            May                  31
+      06            June                 30
+      07            July                 31
+      08            August               31
+      09            September            30
+      10            October              31
+      11            November             30
+      12            December             31
+
+   Appendix C contains sample C code to determine if a year is a leap
+   year.
+
+   The grammar element time-second may have the value "60" at the end of
+   June (XXXX-06-30T23:59:60Z) or December (XXXX-12-31T23:59:60Z) if
+   there is a leap second at that time (see Appendix D for a table of
+   leap seconds).  At all other times the maximum value of time-second
+   is "59".  Further, in timezones other than "Z", the leap second point
+   is shifted by the zone offset (so it happens at the same instant
+   around the globe).
+
+   Although ISO 8601 permits the hour to be "24", this profile of ISO
+   8601 only allows values between "00" and "23" for the hour in order
+   to reduce confusion.
+
+
+5.8. Examples
+
+   Here are three examples of Internet date/time format.
+
+      1985-04-12T23:20:50.52Z
+
+   This represents 20 minutes and 50.52 seconds after the 23rd hour of
+   April 12th, 1985 in UTC.
+
+
+
+
+
+Newman & Klyne                                                  [Page 9]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+      1996-12-19T16:39:57-08:00
+
+   This represents 39 minutes and 57 seconds after the 16th hour of
+   December 19th, 1996 with an offset of -08:00 from UTC (Pacific
+   Standard Time).  Note that this is equivalent to 1996-12-20T00:39:57Z
+   in UTC.
+
+      1990-12-31T23:59:60Z
+
+   This represents the leap second inserted at the end of 1990.
+
+      1990-12-31T15:59:60-08:00
+
+   This represents the same leap second in Pacific Standard Time, 8
+   hours behind UTC.
+
+
+6. Acknowledgements
+
+   The following people provided helpful advice for an earlier
+   incarnation of this document: Ned Freed, Neal McBurnett, David
+   Keegel, Markus Kuhn, Paul Eggert and Robert Elz.  Thanks are also due
+   to participants of the IETF Calendaring/Scheduling working group
+   mailing list, and participants of the timezone mailing list.
+
+   The following reviewers contributed helpful suggestions for the
+   present revision: Tom Harsch, Markus Kuhn, [[[...]]]
+
+
+7. References
+
+   [Zeller]    Chr. Zeller, "Kalender-Formeln", Acta Mathematica, Vol.
+               9, Nov 1886.
+
+   [IMAIL]     Crocker, D., "Standard for the Format of Arpa Internet
+               Text Messages", RFC 822, August 1982.
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [ISO8601]   "Data elements and interchange formats -- Information
+               interchange -- Representation of dates and times", ISO
+               8601:1988(E), International Organization for
+               Standardization, June, 1988.
+
+               ***UPDATE***
+
+               "Data elements and interchange formats -- Information
+
+
+
+Newman & Klyne                                                 [Page 10]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+               interchange -- Representation of dates and times", ISO
+               8601:2000, International Organization for
+               Standardization, December, 2000.
+
+
+   [HOST-REQ]  Braden, R., "Requirements for Internet Hosts --
+               Application and Support", RFC 1123, Internet Engineering
+               Task Force, October 1989.
+
+   [NTP]       Mills, D., "Network Time Protocol (Version 3)
+               Specification, Implementation and Analysis", RFC 1305,
+               University of Delaware, March 1992.
+
+   [ITU-R-TF]  International Telecommunication Union Recommendations for
+               Time Signals and Frequency Standards Emissions.
+               <http://www.itu.ch/publications/itu-r/iturtf.htm>
+
+
+
+8. Security Considerations
+
+   Since the local time zone of a site may be useful for determining a
+   time when systems are less likely to be monitored and might be more
+   susceptible to a security probe, some sites may wish to emit times in
+   UTC only.  Others might consider this to be loss of useful
+   functionality at the hands of paranoia.
+
+
+9. Authors' Addresses
+
+   Chris Newman
+   Sun Microsystems
+   1050 Lakes Drive, Suite 250
+   West Covina, CA 91790 USA
+
+   Email: cnewman@iplanet.com
+
+   Graham Klyne (editor, this revision)
+   Baltimore Technologies - Content Security Group
+   1310 Waterside
+   Arlington Business Park
+   Theale
+   Reading, RG7 4SA
+   United Kingdom.
+   Telephone: +44 118 903 8000
+   Facsimile: +44 118 903 9000
+   E-mail:    GK@ACM.ORG
+
+
+
+
+Newman & Klyne                                                 [Page 11]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Appendix A. ISO 8601 Collected ABNF
+
+   This information is based on the 1988 version of ISO 8601.  There may
+   be some changes in the 2000 revision.
+
+   ISO 8601 does not specify a formal grammar for the date and time
+   formats it defines.  The following is an attempt to create a formal
+   grammar from ISO 8601.  This is informational only and may contain
+   errors.  ISO 8601 remains the authoritative reference.
+
+   Note that due to ambiguities in ISO 8601, some interpretations had to
+   be made.  First, ISO 8601 is not clear if mixtures of basic and
+   extended format are permissible.  This grammar permits mixtures.  ISO
+   8601 is not clear on whether an hour of 24 is permissible only if
+   minutes and seconds are 0.  This assumes that an hour of 24 is
+   permissible in any context.  Restrictions on date-mday in section 5.7
+   apply.  ISO 8601 states that the "T" may be omitted under some
+   circumstances.  This grammar requires the "T" to avoid ambiguity.
+
+   ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
+   be proceeded by a "0" if less than unity.  Annex B.2 of ISO 8601
+   gives examples where the decimal fractions are not preceeded by a
+   "0".  This grammar assumes section 5.3.1.3 is correct and that Annex
+   B.2 is in error.
+
+      date-century    = 2DIGIT  ; 00-99
+      date-decade     =  DIGIT  ; 0-9
+      date-subdecade  =  DIGIT  ; 0-9
+      date-year       = date-decade date-subdecade
+      date-fullyear   = date-century date-year
+      date-month      = 2DIGIT  ; 01-12
+      date-wday       =  DIGIT  ; 1-7  ; 1 is Monday, 7 is Sunday
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      date-yday       = 3DIGIT  ; 001-365, 001-366 based on year
+      date-week       = 2DIGIT  ; 01-52, 01-53 based on year
+
+      datepart-fullyear = [date-century] date-year ["-"]
+      datepart-ptyear   = "-" [date-subdecade ["-"]]
+      datepart-wkyear   = datepart-ptyear / datepart-fullyear
+
+      dateopt-century   = "-" / date-century
+      dateopt-fullyear  = "-" / datepart-fullyear
+      dateopt-year      = "-" / (date-year ["-"])
+      dateopt-month     = "-" / (date-month ["-"])
+      dateopt-week      = "-" / (date-week ["-"])
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 12]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+      datespec-full     = datepart-fullyear date-month ["-"] date-mday
+      datespec-year     = date-century / dateopt-century date-year
+      datespec-month    = "-" dateopt-year date-month [["-"] date-mday]
+      datespec-mday     = "--" dateopt-month date-mday
+      datespec-week     = datepart-wkyear "W"
+                          (date-week / dateopt-week date-wday)
+      datespec-wday     = "---" date-wday
+      datespec-yday     = dateopt-fullyear date-yday
+
+      date              = datespec-full / datespec-year / datespec-month /
+          datespec-mday / datespec-week / datespec-wday / datespec-yday
+
+   Time:
+
+      time-hour         = 2DIGIT ; 00-24
+      time-minute       = 2DIGIT ; 00-59
+      time-second       = 2DIGIT ; 00-59, 00-60 based on leap-second rules
+      time-fraction     = ("," / ".") 1*DIGIT
+      time-numoffset    = ("+" / "-") time-hour [[":"] time-minute]
+      time-zone         = "Z" / time-numoffset
+
+      timeopt-hour      = "-" / (time-hour [":"])
+      timeopt-minute    = "-" / (time-minute [":"])
+
+      timespec-hour     = time-hour [[":"] time-minute [[":"] time-second]]
+      timespec-minute   = timeopt-hour time-minute [[":"] time-second]
+      timespec-second   = "-" timeopt-minute time-second
+      timespec-base     = timespec-hour / timespec-minute / timespec-second
+
+      time              = timespec-base [time-fraction] [time-zone]
+
+      iso-date-time     = date "T" time
+
+   Durations:
+
+      dur-second        = 1*DIGIT "S"
+      dur-minute        = 1*DIGIT "M" [dur-second]
+      dur-hour          = 1*DIGIT "H" [dur-minute]
+      dur-time          = "T" (dur-hour / dur-minute / dur-second)
+      dur-day           = 1*DIGIT "D"
+      dur-week          = 1*DIGIT "W"
+      dur-month         = 1*DIGIT "M" [dur-day]
+      dur-year          = 1*DIGIT "Y" [dur-month]
+      dur-date          = (dur-day / dur-month / dur-year) [dur-time]
+
+      duration          = "P" (dur-date / dur-time / dur-week)
+
+
+
+
+
+Newman & Klyne                                                 [Page 13]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   Periods:
+
+      period-explicit   = date-time "/" date-time
+      period-start      = date-time "/" duration
+      period-end        = duration "/" date-time
+
+      period            = period-explicit / period-start / period-end
+
+
+Appendix B. Day of the Week
+
+   The following is a sample C subroutine loosly based on Zeller's
+   Congruence [Zeller] which may be used to obtain the day of the week:
+
+
+      char *day_of_week(int day, int month, int year)
+      {
+          char *dayofweek[] = {
+              "Sunday", "Monday", "Tuesday", "Wednesday",
+              "Thursday", "Friday", "Saturday"
+          };
+
+          /* adjust months so February is the last one */
+          month -= 2;
+          if (month < 1) {
+              month += 12;
+              --year;
+          }
+          /* split by century */
+          cent = year / 100;
+          year %= 100;
+          return (dayofweek[((26 * month - 2) / 10 + day + year
+                            + year / 4 + cent / 4 - 2 * cent) % 7]);
+      }
+
+
+
+Appendix C. Leap Years
+
+   Here is a sample C subroutine to calculate if a year is a leap year:
+
+
+      /* This returns non-zero if year is a leap year.  Must use 4 digit year.
+       */
+      int leap_year(int year)
+      {
+          return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
+      }
+
+
+
+Newman & Klyne                                                 [Page 14]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Appendix D. Leap Seconds
+
+   This table is an excerpt from the table maintained by the United
+   States Naval Observatory.  The source data is located at:
+
+      <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
+
+   This table shows the date of the leap second, and the difference
+   between the time standard TAI (which isn't adjusted by leap seconds)
+   and UTC after that leap second.
+
+
+      UTC Date  TAI - UTC After Leap Second
+      --------  ---------------------------
+      1972-06-30     11
+      1972-12-31     12
+      1973-12-31     13
+      1974-12-31     14
+      1975-12-31     15
+      1976-12-31     16
+      1977-12-31     17
+      1978-12-31     18
+      1979-12-31     19
+      1981-06-30     20
+      1982-06-30     21
+      1983-06-30     22
+      1985-06-30     23
+      1987-12-31     24
+      1989-12-31     25
+      1990-12-31     26
+      1992-06-30     27
+      1993-06-30     28
+      1994-06-30     29
+      1995-12-31     30
+      1997-06-30     31
+      1998-12-31     32
+
+
+Appendix E. Amendment history
+
+
+00a 30-Mar-2001 This document version created from Chris Newman's
+                original 'draft-ietf-impp-datetime-00.txt'.  Material
+                relating to future times (schedule events) and timezone
+                names has been removed.  Added introductory text setting
+                the scope for this document.  Various small editorial
+                changes.
+
+
+
+
+Newman & Klyne                                                 [Page 15]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+00b 03-Apr-2001 Added reference [ABNF], and updated citations.  Added
+                comment about possible use of space-separated date/time
+                fields.  Added comment about possible use of lower case
+                "t" and "z" in syntax.  Corrected leap-second examples
+                and noted that leap second point is offset by time zone.
+
+01a 06-Apr-2001 Updated author affiliation and contact details.  Udated
+                leap-second table.
+
+01b 10-May-2001 Clarified provenance of (non-normative) information in
+                appendix A.
+
+
+
+Full copyright statement
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 16]
+
+
diff --git a/Documentation/en/I-D/draft-ietf-impp-datetime-02.txt b/Documentation/en/I-D/draft-ietf-impp-datetime-02.txt
new file mode 100644
index 00000000..43025ed7
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-impp-datetime-02.txt
@@ -0,0 +1,1081 @@
+Network Working Group                   G. Klyne, Baltimore Technologies
+Internet Draft                               C. Newman, Sun Microsystems
+                                                             15 May 2001
+                                                  Expires: November 2001
+
+
+               Date and Time on the Internet: Timestamps
+                   <draft-ietf-impp-datetime-02.txt>
+
+
+Status of this memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC 2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress".
+
+     The list of current Internet-Drafts can be accessed at
+     http://www.ietf.org/1id-abstracts.html
+
+     The list of Internet-Draft Shadow Directories can be accessed at
+     http://www.ietf.org/shadow.html.
+
+
+
+   To view the entire list of current Internet-Drafts, please check the
+   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
+   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
+   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+
+Abstract
+
+   This document defines a date and time format for use in Internet
+   protocols that is a profile of the ISO 8601 [ISO8601] standard for
+   representation of dates and times using the Gregorian calendar.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 1]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Table of Contents
+
+   1. Introduction
+   2. Definitions
+   3. Two Digit Years
+   4. Local Time
+   4.1. Coordinated Universal Time (UTC)
+   4.2. Local Offsets
+   4.3. Unknown Local Offset Convention
+   4.4. Unqualified Local Time
+   5. Date and Time format
+   5.1. Ordering
+   5.2. Human Readability
+   5.3. Rarely Used Options
+   5.4. Redundant Information
+   5.5. Simplicity
+   5.6. Internet Date/Time Format
+   5.7. Restrictions
+   5.8. Examples
+   6. Acknowledgements
+   7. References
+   8. Security Considerations
+   9. Authors' Addresses
+   Appendix A. ISO 8601 Collected ABNF
+   Appendix B. Day of the Week
+   Appendix C. Leap Years
+   Appendix D. Leap Seconds
+   Appendix E. Amendment history
+   Full copyright statement
+
+
+1. Introduction
+
+   Date and time formats cause a lot of confusion and interoperability
+   problems on the Internet.  This document addresses many of the
+   problems encountered and makes recommendations to improve consistency
+   and interoperability when representing and using date and time in
+   Internet protocols.
+
+   This document includes an Internet profile of the ISO 8601 [ISO8601]
+   standard for representation of dates and times using the Gregorian
+   calendar.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 2]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   There are many ways in which date and time values might appear in
+   Internet protocols:  this document focuses on just one common usage,
+   viz. timestamps for Internet protocol events.  This limited
+   consideration has the following consequences:
+
+   o  All dates and times are assumed to be in the "current era",
+      somewhere between 0000AD and 9999AD.
+
+   o  All times expressed have a stated relationship (offset) to
+      Coordinated Universal Time (UTC).  (This is distinct from some
+      usage in scheduling applications where a local time and location
+      may be known, but the actual relationship to UTC may be dependent
+      on the unknown or unknowable actions of politicians or
+      administrators.  The UTC time corresponding to 17:00 on 23rd March
+      2005 in New York may depend on administrative decisions about
+      daylight savings time.  This specification steers well clear of
+      such considerations.)
+
+   o  Timestamps can express times that occurred before the introduction
+      of UTC.  Such timestamps are expressed relative to universal time,
+      using the best available practice at the stated time.
+
+   o  Date and time expressions indicate an instant in time.
+      Description of time periods, or intervals, is not covered here.
+
+
+2. Definitions
+
+
+   UTC         Coordinated Universal Time as maintained by the Bureau
+               International des Poids et Mesures (BIPM).
+
+   second      A basic unit of measurement of time in the International
+               System of Units.  It is defined as the duration of
+               9,192,631,770 cycles of microwave light absorbed or
+               emitted by the hyperfine transition of cesium-133 atoms
+               in their ground state undisturbed by external fields.
+
+   minute      A period of time of 60 seconds.
+
+   hour        A period of time of 60 minutes.
+
+   day         A period of time of 24 hours.
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 3]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   leap year   In the Gregorian calendar, a year which has 366 days.  A
+               leap year is a year whose number is divisible by four an
+               integral number of times, except that if it is a
+               centennial year (i.e. divisible by one hundred) it shall
+               also be divisible by four hundred an integral number of
+               times.
+
+   ABNF        Augmented Backus-Naur Form, a format used to represent
+               permissible strings in a protocol or language, as defined
+               in [ABNF].
+
+   Email Date/Time Format
+               The date/time format used by Internet Mail as defined by
+               RFC 2822 [IMAIL-UPDATE].
+
+   Internet Date/Time Format
+               The date format defined in section 5 of this document.
+
+   For more information about time scales, see Appendix E of [NTP],
+   Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF].
+
+
+3. Two Digit Years
+
+   The following requirements are to address the problems of ambiguity
+   of 2-digit years:
+
+   o  Internet Protocols MUST generate four digit years in dates.
+
+   o  The use of 2-digit years is deprecated.  If a 2-digit year is
+      received, it should be accepted ONLY if an incorrect
+      interpretation will not cause a protocol or processing failure
+      (e.g. if used only for logging or tracing purposes).
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as three digits.  This occurs if the program
+      simply subtracts 1900 from the year and doesn't check the number
+      of digits.  Programs wishing to robustly deal with dates generated
+      by such broken software may add 1900 to three digit years.
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as ":0", ":1", ... ":9", ";0", ...  This occurs
+      if the program simply subtracts 1900 from the year and adds the
+      decade to the US-ASCII character zero. Programs wishing to
+      robustly deal with dates generated by such broken software should
+      detect non-numeric decades and interpret appropriately.
+
+
+
+
+
+Newman & Klyne                                                  [Page 4]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   The problems with two digit years amply demonstrate why all dates and
+   times used in Internet protocols MUST be fully qualified.
+
+
+
+4. Local Time
+
+4.1. Coordinated Universal Time (UTC)
+
+   Because the daylight saving rules for local time zones are so
+   convoluted and can change based on local law at unpredictable times,
+   true interoperability is best achieved by using Coordinated Universal
+   Time (UTC).  This specification does not cater to local time zone
+   rules.
+
+4.2. Local Offsets
+
+   The offset between local time and UTC is often useful information.
+   For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local
+   offset provides a useful heuristic to determine the probability of a
+   prompt response.  Attempts to label local offsets with alphabetic
+   strings have resulted in poor interoperability in the past [IMAIL],
+   [HOST-REQ].  As a result, RFC2822 [IMAIL-UPDATE] has made numeric
+   offsets mandatory.
+
+   Numeric offsets are calculated as "local time minus UTC".  So the
+   equivalent time in UTC can be determined by subtracting the offset
+   from the local time.  For example, 18:50:00-04:00 is the same time as
+   22:50:00Z.
+
+4.3. Unknown Local Offset Convention
+
+   If the time in UTC is known, but the offset to local time is unknown,
+   this can be represented with an offset of "-00:00".  This differs
+   semantically from an offset of "Z" or "+00:00", which imply that UTC
+   is the preferred reference point for the specified time.  RFC2822
+   [IMAIL-UPDATE] describes a similar convention for email.
+
+4.4. Unqualified Local Time
+
+   A number of devices currently connected to the Internet run their
+   internal clocks in local time and are unaware of UTC.  While the
+   Internet does have a tradition of accepting reality when creating
+   specifications, this should not be done at the expense of
+   interoperability.  Since interpretation of an unqualified local time
+   zone will fail in approximately 23/24 of the globe, the
+   interoperability problems of unqualified local time are deemed
+   unacceptable for the Internet.  Systems that are configured with a
+
+
+
+Newman & Klyne                                                  [Page 5]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   local time, are unaware of the corresponding UTC offset, and depend
+   on time synchronization with other Internet systems, MUST use a
+   mechanism that ensures correct synchronization with UTC.  Some
+   suitable mechanisms are:
+
+   o  Use Network Time Protocol [NTP] to obtain the time in UTC.
+
+   o  Use another host in the same local time zone as a gateway to the
+      Internet.  This host MUST correct unqualified local times they are
+      transmitted to other hosts.
+
+   o  Prompt the user for the local time zone and daylight saving rule
+      settings.
+
+
+5. Date and Time format
+
+   This section discusses desirable qualities of date and time formats
+   and defines a profile of ISO 8601 for use in Internet protocols.
+
+5.1. Ordering
+
+   If date and time components are ordered from least precise to most
+   precise, then a useful property is achieved.  Assuming that the time
+   zones of the dates and times are the same (e.g. all in UTC),
+   expressed using the same string (e.g. all "Z" or all "+00:00"), and
+   all times have the same number of fractional second digits, then the
+   date and time strings may be sorted as strings (e.g. using the
+   strcmp() function in C) and a time-ordered sequence will result.  The
+   presence of optional punctuation would violate this characteristic.
+
+5.2. Human Readability
+
+   Human readability has proved to be a valuable feature of Internet
+   protocols.  Human readable protocols greatly reduce the costs of
+   debugging since telnet often suffices as a test client and network
+   analyzers need not be modified with knowledge of the protocol.  On
+   the other hand, human readability sometimes results in
+   interoperability problems.  For example, the date format "10/11/1996"
+   is completely unsuitable for global interchange because it is
+   interpreted differently in different countries.  In addition, the
+   date format in [IMAIL] has resulted in interoperability problems when
+   people assumed any text string was permitted and translated the three
+   letter abbreviations to other languages or substituted date formats
+   which were easier to generate (e.g. the format used by the C function
+   ctime).  For this reason, a balance must be struck between human
+   readability and interoperability.
+
+
+
+
+Newman & Klyne                                                  [Page 6]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   Because no date and time format is readable according to the
+   conventions of all countries, Internet clients SHOULD be prepared to
+   transform dates into a display format suitable for the locality.
+   This may include translating UTC to local time.
+
+5.3. Rarely Used Options
+
+   A format which includes rarely used options is likely to cause
+   interoperability problems.  This is because rarely used options are
+   less likely to be used in alpha or beta testing, so bugs in parsing
+   are less likely to be discovered.  Rarely used options should be made
+   mandatory or omitted for the sake of interoperability whenever
+   possible.
+
+   The format defined below includes only one rarely used option:
+   fractions of a second.  It is expected that this will be used only by
+   applications which require strict ordering of date/time stamps or
+   which have an unusual precision requirement.
+
+5.4. Redundant Information
+
+   If a date/time format includes redundant information, that introduces
+   the possibility that the redundant information will not correlate.
+   For example, including the day of the week in a date/time format
+   introduces the possibility that the day of week is incorrect but the
+   date is correct, or vice versa.  Since it is not difficult to compute
+   the day of week from a date (see Appendix B), the day of week should
+   not be included in a date/time format.
+
+5.5. Simplicity
+
+   The complete set of date and time formats specified in ISO 8601
+   [ISO8601] is quite complex in an attempt to provide multiple
+   representations and partial representations.  Appendix A contains an
+   attempt to translate the complete syntax of ISO 8601 into ABNF.
+   Internet protocols have somewhat different requirements and
+   simplicity has proved to be an important characteristic.  In
+   addition, Internet protocols usually need complete specification of
+   data in order to achieve true interoperability.  Therefore, the
+   complete grammar for ISO 8601 is deemed too complex for most Internet
+   protocols.
+
+   The following section defines a profile of ISO 8601 for use on the
+   Internet.  It is a conformant subset of the ISO 8601 extended format.
+   Simplicity is achieved by making most fields and punctuation
+   mandatory.
+
+
+
+
+
+Newman & Klyne                                                  [Page 7]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+5.6. Internet Date/Time Format
+
+   The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
+   new protocols on the Internet.  This is specified using the syntax
+   description notation defined in [ABNF].
+
+      date-fullyear   = 4DIGIT
+      date-month      = 2DIGIT  ; 01-12
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      time-hour       = 2DIGIT  ; 00-23
+      time-minute     = 2DIGIT  ; 00-59
+      time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second rules
+      time-secfrac    = "." 1*DIGIT
+      time-numoffset  = ("+" / "-") time-hour ":" time-minute
+      time-offset     = "Z" / time-numoffset
+
+      partial-time    = time-hour ":" time-minute ":" time-second
+                        [time-secfrac]
+      full-date       = date-fullyear "-" date-month "-" date-mday
+      full-time       = partial-time time-offset
+
+      date-time       = full-date "T" full-time
+
+
+     NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in
+     this syntax may alternatively be lower case "t" or "z"
+     respectively.
+
+     NOTE: ISO 8601 defines date and time separated by "T".
+     Applications using this syntax may choose, for the sake of
+     readability, to specify a full-date and full-time separated by
+     (say) a space character.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 8]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+5.7. Restrictions
+
+   The grammar element date-mday represents the day number within the
+   current month.  The maximum value varies based on the month and year
+   as follows:
+
+      Month Number  Month/Year           Maximum value of date-mday
+      ------------  ----------           --------------------------
+      01            January              31
+      02            February, normal     28
+      02            February, leap year  29
+      03            March                31
+      04            April                30
+      05            May                  31
+      06            June                 30
+      07            July                 31
+      08            August               31
+      09            September            30
+      10            October              31
+      11            November             30
+      12            December             31
+
+   Appendix C contains sample C code to determine if a year is a leap
+   year.
+
+   The grammar element time-second may have the value "60" at the end of
+   months in which a leap second occurs -- to date: June
+   (XXXX-06-30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see
+   Appendix D for a table of leap seconds.  It is also possible for a
+   leap second to be subtracted, at which times the maximum value of
+   time-second is "58".  At all other times the maximum value of time-
+   second is "59".  Further, in time zones other than "Z", the leap
+   second point is shifted by the zone offset (so it happens at the same
+   instant around the globe).
+
+   Leap seconds cannot be predicted far into the future.  The
+   International Earth Rotation Service publishes bulletins [IERS] that
+   announce leap seconds with a few weeks' warning.  Applications should
+   not generate time stamps involving inserted leap seconds until after
+   the leap seconds are announced.
+
+   Although ISO 8601 permits the hour to be "24", this profile of ISO
+   8601 only allows values between "00" and "23" for the hour in order
+   to reduce confusion.
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 9]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+5.8. Examples
+
+   Here are some examples of Internet date/time format.
+
+      1985-04-12T23:20:50.52Z
+
+   This represents 20 minutes and 50.52 seconds after the 23rd hour of
+   April 12th, 1985 in UTC.
+
+      1996-12-19T16:39:57-08:00
+
+   This represents 39 minutes and 57 seconds after the 16th hour of
+   December 19th, 1996 with an offset of -08:00 from UTC (Pacific
+   Standard Time).  Note that this is equivalent to 1996-12-20T00:39:57Z
+   in UTC.
+
+      1990-12-31T23:59:60Z
+
+   This represents the leap second inserted at the end of 1990.
+
+      1990-12-31T15:59:60-08:00
+
+   This represents the same leap second in Pacific Standard Time, 8
+   hours behind UTC.
+
+
+6. Acknowledgements
+
+   The following people provided helpful advice for an earlier
+   incarnation of this document: Ned Freed, Neal McBurnett, David
+   Keegel, Markus Kuhn, Paul Eggert and Robert Elz.  Thanks are also due
+   to participants of the IETF Calendaring/Scheduling working group
+   mailing list, and participants of the time zone mailing list.
+
+   The following reviewers contributed helpful suggestions for the
+   present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn,
+   Paul Eggert, [[[...]]]
+
+
+7. References
+
+   [Zeller]    Chr. Zeller, "Kalender-Formeln", Acta Mathematica, Vol.
+               9, Nov 1886.
+
+   [IMAIL]     Crocker, D., "Standard for the Format of Arpa Internet
+               Text Messages", RFC 822, August 1982.
+
+
+
+
+
+Newman & Klyne                                                 [Page 10]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   [IMAIL-UPDATE]
+               Resnick, P., "Internet Message Format", RFC 2822, April
+               2001.
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [ISO8601]   "Data elements and interchange formats -- Information
+               interchange -- Representation of dates and times", ISO
+               8601:1988(E), International Organization for
+               Standardization, June, 1988.
+
+   [ISO8601:2000]
+               "Data elements and interchange formats -- Information
+               interchange -- Representation of dates and times", ISO
+               8601:2000, International Organization for
+               Standardization, December, 2000.
+
+   [HOST-REQ]  Braden, R., "Requirements for Internet Hosts --
+               Application and Support", RFC 1123, Internet Engineering
+               Task Force, October 1989.
+
+   [IERS]      International Earth Rotation Service Bulletins,
+               <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.
+
+   [NTP]       Mills, D., "Network Time Protocol (Version 3)
+               Specification, Implementation and Analysis", RFC 1305,
+               University of Delaware, March 1992.
+
+   [ITU-R-TF]  International Telecommunication Union Recommendations for
+               Time Signals and Frequency Standards Emissions.
+               <http://www.itu.ch/publications/itu-r/iturtf.htm>
+
+
+
+8. Security Considerations
+
+   Since the local time zone of a site may be useful for determining a
+   time when systems are less likely to be monitored and might be more
+   susceptible to a security probe, some sites may wish to emit times in
+   UTC only.  Others might consider this to be loss of useful
+   functionality at the hands of paranoia.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 11]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+9. Authors' Addresses
+
+   Chris Newman
+   Sun Microsystems
+   1050 Lakes Drive, Suite 250
+   West Covina, CA 91790 USA
+
+   Email: cnewman@iplanet.com
+
+   Graham Klyne (editor, this revision)
+   Baltimore Technologies - Content Security Group
+   1310 Waterside
+   Arlington Business Park
+   Theale
+   Reading, RG7 4SA
+   United Kingdom.
+   Telephone: +44 118 903 8000
+   Facsimile: +44 118 903 9000
+   E-mail:    GK@ACM.ORG
+
+
+Appendix A. ISO 8601 Collected ABNF
+
+   This information is based on the 1988 version of ISO 8601.  There may
+   be some changes in the 2000 revision.
+
+   ISO 8601 does not specify a formal grammar for the date and time
+   formats it defines.  The following is an attempt to create a formal
+   grammar from ISO 8601.  This is informational only and may contain
+   errors.  ISO 8601 remains the authoritative reference.
+
+   Note that due to ambiguities in ISO 8601, some interpretations had to
+   be made.  First, ISO 8601 is not clear if mixtures of basic and
+   extended format are permissible.  This grammar permits mixtures.  ISO
+   8601 is not clear on whether an hour of 24 is permissible only if
+   minutes and seconds are 0.  This assumes that an hour of 24 is
+   permissible in any context.  Restrictions on date-mday in section 5.7
+   apply.  ISO 8601 states that the "T" may be omitted under some
+   circumstances.  This grammar requires the "T" to avoid ambiguity.
+
+   ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
+   be proceeded by a "0" if less than unity.  Annex B.2 of ISO 8601
+   gives examples where the decimal fractions are not preceded by a "0".
+   This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is
+   in error.
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 12]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+      date-century    = 2DIGIT  ; 00-99
+      date-decade     =  DIGIT  ; 0-9
+      date-subdecade  =  DIGIT  ; 0-9
+      date-year       = date-decade date-subdecade
+      date-fullyear   = date-century date-year
+      date-month      = 2DIGIT  ; 01-12
+      date-wday       =  DIGIT  ; 1-7  ; 1 is Monday, 7 is Sunday
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      date-yday       = 3DIGIT  ; 001-365, 001-366 based on year
+      date-week       = 2DIGIT  ; 01-52, 01-53 based on year
+
+      datepart-fullyear = [date-century] date-year ["-"]
+      datepart-ptyear   = "-" [date-subdecade ["-"]]
+      datepart-wkyear   = datepart-ptyear / datepart-fullyear
+
+      dateopt-century   = "-" / date-century
+      dateopt-fullyear  = "-" / datepart-fullyear
+      dateopt-year      = "-" / (date-year ["-"])
+      dateopt-month     = "-" / (date-month ["-"])
+      dateopt-week      = "-" / (date-week ["-"])
+
+      datespec-full     = datepart-fullyear date-month ["-"] date-mday
+      datespec-year     = date-century / dateopt-century date-year
+      datespec-month    = "-" dateopt-year date-month [["-"] date-mday]
+      datespec-mday     = "--" dateopt-month date-mday
+      datespec-week     = datepart-wkyear "W"
+                          (date-week / dateopt-week date-wday)
+      datespec-wday     = "---" date-wday
+      datespec-yday     = dateopt-fullyear date-yday
+
+      date              = datespec-full / datespec-year / datespec-month /
+          datespec-mday / datespec-week / datespec-wday / datespec-yday
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 13]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   Time:
+
+      time-hour         = 2DIGIT ; 00-24
+      time-minute       = 2DIGIT ; 00-59
+      time-second       = 2DIGIT ; 00-59, 00-60 based on leap-second rules
+      time-fraction     = ("," / ".") 1*DIGIT
+      time-numoffset    = ("+" / "-") time-hour [[":"] time-minute]
+      time-zone         = "Z" / time-numoffset
+
+      timeopt-hour      = "-" / (time-hour [":"])
+      timeopt-minute    = "-" / (time-minute [":"])
+
+      timespec-hour     = time-hour [[":"] time-minute [[":"] time-second]]
+      timespec-minute   = timeopt-hour time-minute [[":"] time-second]
+      timespec-second   = "-" timeopt-minute time-second
+      timespec-base     = timespec-hour / timespec-minute / timespec-second
+
+      time              = timespec-base [time-fraction] [time-zone]
+
+      iso-date-time     = date "T" time
+
+   Durations:
+
+      dur-second        = 1*DIGIT "S"
+      dur-minute        = 1*DIGIT "M" [dur-second]
+      dur-hour          = 1*DIGIT "H" [dur-minute]
+      dur-time          = "T" (dur-hour / dur-minute / dur-second)
+      dur-day           = 1*DIGIT "D"
+      dur-week          = 1*DIGIT "W"
+      dur-month         = 1*DIGIT "M" [dur-day]
+      dur-year          = 1*DIGIT "Y" [dur-month]
+      dur-date          = (dur-day / dur-month / dur-year) [dur-time]
+
+      duration          = "P" (dur-date / dur-time / dur-week)
+
+   Periods:
+
+      period-explicit   = date-time "/" date-time
+      period-start      = date-time "/" duration
+      period-end        = duration "/" date-time
+
+      period            = period-explicit / period-start / period-end
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 14]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Appendix B. Day of the Week
+
+   The following is a sample C subroutine loosely based on Zeller's
+   Congruence [Zeller] which may be used to obtain the day of the week
+   for dates on or after 0000-02-01:
+
+
+      char *day_of_week(int day, int month, int year)
+      {
+          int cent;
+          char *dayofweek[] = {
+              "Sunday", "Monday", "Tuesday", "Wednesday",
+              "Thursday", "Friday", "Saturday"
+          };
+
+          /* adjust months so February is the last one */
+          month -= 2;
+          if (month < 1) {
+              month += 12;
+              --year;
+          }
+          /* split by century */
+          cent = year / 100;
+          year %= 100;
+          return (dayofweek[((26 * month - 2) / 10 + day + year
+                            + year / 4 + cent / 4 - 2 * cent) % 7]);
+      }
+
+
+
+Appendix C. Leap Years
+
+   Here is a sample C subroutine to calculate if a year is a leap year:
+
+
+      /* This returns non-zero if year is a leap year.  Must use 4 digit year.
+       */
+      int leap_year(int year)
+      {
+          return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
+      }
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 15]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Appendix D. Leap Seconds
+
+   Information about leap seconds can be found at:
+   <http://tycho.usno.navy.mil/leapsec.html>.  In particular, it notes
+   that:
+
+      The decision to introduce a leap second in UTC is the
+      responsibility of the International Earth Rotation Service (IERS).
+      According to the CCIR Recommendation, first preference is given to
+      the opportunities at the end of December and June, and second
+      preference to those at the end of March and September.
+
+   The following table is an excerpt from the table maintained by the
+   United States Naval Observatory.  The source data is located at:
+
+      <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
+
+   This table shows the date of the leap second, and the difference
+   between the time standard TAI (which isn't adjusted by leap seconds)
+   and UTC after that leap second.
+
+
+      UTC Date  TAI - UTC After Leap Second
+      --------  ---------------------------
+      1972-06-30     11
+      1972-12-31     12
+      1973-12-31     13
+      1974-12-31     14
+      1975-12-31     15
+      1976-12-31     16
+      1977-12-31     17
+      1978-12-31     18
+      1979-12-31     19
+      1981-06-30     20
+      1982-06-30     21
+      1983-06-30     22
+      1985-06-30     23
+      1987-12-31     24
+      1989-12-31     25
+      1990-12-31     26
+      1992-06-30     27
+      1993-06-30     28
+      1994-06-30     29
+      1995-12-31     30
+      1997-06-30     31
+      1998-12-31     32
+
+
+
+
+
+Newman & Klyne                                                 [Page 16]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Appendix E. Amendment history
+
+
+00a 30-Mar-2001 This document version created from Chris Newman's
+                original 'draft-ietf-impp-datetime-00.txt'.  Material
+                relating to future times (schedule events) and time zone
+                names has been removed.  Added introductory text setting
+                the scope for this document.  Various small editorial
+                changes.
+
+00b 03-Apr-2001 Added reference [ABNF], and updated citations.  Added
+                comment about possible use of space-separated date/time
+                fields.  Added comment about possible use of lower case
+                "t" and "z" in syntax.  Corrected leap-second examples
+                and noted that leap second point is offset by time zone.
+
+01a 06-Apr-2001 Updated author affiliation and contact details.  Udated
+                leap-second table.
+
+01b 10-May-2001 Clarified provenance of (non-normative) information in
+                appendix A.
+
+02a 11-May-2001 Reference updated email specification (RFC2822).
+
+02b 14-May-2001 Fix up some detailed information concerning leap
+                seconds.  Include text describing timestamps for times
+                before introduction of UTC.  Caution against the use of
+                future timestamps using leap seconds.  Correction to
+                day-of-week sample code, and note restriction on
+                applicability.  Various editorial corrections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 17]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Full copyright statement
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 18]
+
+
diff --git a/Documentation/en/I-D/draft-ietf-impp-datetime-03.txt b/Documentation/en/I-D/draft-ietf-impp-datetime-03.txt
new file mode 100644
index 00000000..1ae7cd3d
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-impp-datetime-03.txt
@@ -0,0 +1,1141 @@
+Network Working Group                   G. Klyne, Baltimore Technologies
+Internet Draft                               C. Newman, Sun Microsystems
+                                                             25 May 2001
+                                                  Expires: November 2001
+
+
+               Date and Time on the Internet: Timestamps
+                   <draft-ietf-impp-datetime-03.txt>
+
+
+Status of this memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC 2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress".
+
+     The list of current Internet-Drafts can be accessed at
+     http://www.ietf.org/1id-abstracts.html
+
+     The list of Internet-Draft Shadow Directories can be accessed at
+     http://www.ietf.org/shadow.html.
+
+
+   To view the entire list of current Internet-Drafts, please check the
+   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
+   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
+   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+
+Abstract
+
+   This document defines a date and time format for use in Internet
+   protocols that is a profile of the ISO 8601 [ISO8601] standard for
+   representation of dates and times using the Gregorian calendar.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 1]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Table of Contents
+
+   1. Introduction
+   2. Definitions
+   3. Two Digit Years
+   4. Local Time
+   4.1. Coordinated Universal Time (UTC)
+   4.2. Local Offsets
+   4.3. Unknown Local Offset Convention
+   4.4. Unqualified Local Time
+   5. Date and Time format
+   5.1. Ordering
+   5.2. Human Readability
+   5.3. Rarely Used Options
+   5.4. Redundant Information
+   5.5. Simplicity
+   5.6. Internet Date/Time Format
+   5.7. Restrictions
+   5.8. Examples
+   6. Acknowledgements
+   7. References
+   8. Security Considerations
+   9. Authors' Addresses
+   Appendix A. ISO 8601 Collected ABNF
+   Appendix B. Day of the Week
+   Appendix C. Leap Years
+   Appendix D. Leap Seconds
+   Appendix E. Amendment history
+   Full copyright statement
+
+
+1. Introduction
+
+   Date and time formats cause a lot of confusion and interoperability
+   problems on the Internet.  This document addresses many of the
+   problems encountered and makes recommendations to improve consistency
+   and interoperability when representing and using date and time in
+   Internet protocols.
+
+   This document includes an Internet profile of the ISO 8601 [ISO8601]
+   standard for representation of dates and times using the Gregorian
+   calendar.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 2]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   There are many ways in which date and time values might appear in
+   Internet protocols:  this document focuses on just one common usage,
+   viz. timestamps for Internet protocol events.  This limited
+   consideration has the following consequences:
+
+   o  All dates and times are assumed to be in the "current era",
+      somewhere between 0000AD and 9999AD.
+
+   o  All times expressed have a stated relationship (offset) to
+      Coordinated Universal Time (UTC).  (This is distinct from some
+      usage in scheduling applications where a local time and location
+      may be known, but the actual relationship to UTC may be dependent
+      on the unknown or unknowable actions of politicians or
+      administrators.  The UTC time corresponding to 17:00 on 23rd March
+      2005 in New York may depend on administrative decisions about
+      daylight savings time.  This specification steers well clear of
+      such considerations.)
+
+   o  Timestamps can express times that occurred before the introduction
+      of UTC.  Such timestamps are expressed relative to universal time,
+      using the best available practice at the stated time.
+
+   o  Date and time expressions indicate an instant in time.
+      Description of time periods, or intervals, is not covered here.
+
+
+2. Definitions
+
+
+   UTC         Coordinated Universal Time as maintained by the Bureau
+               International des Poids et Mesures (BIPM).
+
+   second      A basic unit of measurement of time in the International
+               System of Units.  It is defined as the duration of
+               9,192,631,770 cycles of microwave light absorbed or
+               emitted by the hyperfine transition of cesium-133 atoms
+               in their ground state undisturbed by external fields.
+
+   minute      A period of time of 60 seconds.  However, see also the
+               restrictions in section 5.7 and Appendix D for how leap
+               seconds are denoted within minutes.
+
+   hour        A period of time of 60 minutes.
+
+   day         A period of time of 24 hours.
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 3]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   leap year   In the Gregorian calendar, a year which has 366 days.  A
+               leap year is a year whose number is divisible by four an
+               integral number of times, except that if it is a
+               centennial year (i.e. divisible by one hundred) it shall
+               also be divisible by four hundred an integral number of
+               times.
+
+   ABNF        Augmented Backus-Naur Form, a format used to represent
+               permissible strings in a protocol or language, as defined
+               in [ABNF].
+
+   Email Date/Time Format
+               The date/time format used by Internet Mail as defined by
+               RFC 2822 [IMAIL-UPDATE].
+
+   Internet Date/Time Format
+               The date format defined in section 5 of this document.
+
+   For more information about time scales, see Appendix E of [NTP],
+   Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF].
+
+
+3. Two Digit Years
+
+   The following requirements are to address the problems of ambiguity
+   of 2-digit years:
+
+   o  Internet Protocols MUST generate four digit years in dates.
+
+   o  The use of 2-digit years is deprecated.  If a 2-digit year is
+      received, it should be accepted ONLY if an incorrect
+      interpretation will not cause a protocol or processing failure
+      (e.g. if used only for logging or tracing purposes).
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as three digits.  This occurs if the program
+      simply subtracts 1900 from the year and doesn't check the number
+      of digits.  Programs wishing to robustly deal with dates generated
+      by such broken software may add 1900 to three digit years.
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as ":0", ":1", ... ":9", ";0", ...  This occurs
+      if the program simply subtracts 1900 from the year and adds the
+      decade to the US-ASCII character zero. Programs wishing to
+      robustly deal with dates generated by such broken software should
+      detect non-numeric decades and interpret appropriately.
+
+
+
+
+
+Newman & Klyne                                                  [Page 4]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   The problems with two digit years amply demonstrate why all dates and
+   times used in Internet protocols MUST be fully qualified.
+
+
+
+4. Local Time
+
+4.1. Coordinated Universal Time (UTC)
+
+   Because the daylight saving rules for local time zones are so
+   convoluted and can change based on local law at unpredictable times,
+   true interoperability is best achieved by using Coordinated Universal
+   Time (UTC).  This specification does not cater to local time zone
+   rules.
+
+4.2. Local Offsets
+
+   The offset between local time and UTC is often useful information.
+   For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local
+   offset provides a useful heuristic to determine the probability of a
+   prompt response.  Attempts to label local offsets with alphabetic
+   strings have resulted in poor interoperability in the past [IMAIL],
+   [HOST-REQ].  As a result, RFC2822 [IMAIL-UPDATE] has made numeric
+   offsets mandatory.
+
+   Numeric offsets are calculated as "local time minus UTC".  So the
+   equivalent time in UTC can be determined by subtracting the offset
+   from the local time.  For example, 18:50:00-04:00 is the same time as
+   22:50:00Z.
+
+
+      NOTE: Following ISO 8601, numeric offsets represent only time
+      zones that differ from UTC by an integral number of minutes.
+      However, many historical time zones differ from UTC by a non-
+      integral number of minutes.  To represent such historical time
+      stamps exactly, applications must convert them to a representable
+      time zone.
+
+
+4.3. Unknown Local Offset Convention
+
+   If the time in UTC is known, but the offset to local time is unknown,
+   this can be represented with an offset of "-00:00".  This differs
+   semantically from an offset of "Z" or "+00:00", which imply that UTC
+   is the preferred reference point for the specified time.  RFC2822
+   [IMAIL-UPDATE] describes a similar convention for email.
+
+
+
+
+
+Newman & Klyne                                                  [Page 5]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+4.4. Unqualified Local Time
+
+   A number of devices currently connected to the Internet run their
+   internal clocks in local time and are unaware of UTC.  While the
+   Internet does have a tradition of accepting reality when creating
+   specifications, this should not be done at the expense of
+   interoperability.  Since interpretation of an unqualified local time
+   zone will fail in approximately 23/24 of the globe, the
+   interoperability problems of unqualified local time are deemed
+   unacceptable for the Internet.  Systems that are configured with a
+   local time, are unaware of the corresponding UTC offset, and depend
+   on time synchronization with other Internet systems, MUST use a
+   mechanism that ensures correct synchronization with UTC.  Some
+   suitable mechanisms are:
+
+   o  Use Network Time Protocol [NTP] to obtain the time in UTC.
+
+   o  Use another host in the same local time zone as a gateway to the
+      Internet.  This host MUST correct unqualified local times they are
+      transmitted to other hosts.
+
+   o  Prompt the user for the local time zone and daylight saving rule
+      settings.
+
+
+5. Date and Time format
+
+   This section discusses desirable qualities of date and time formats
+   and defines a profile of ISO 8601 for use in Internet protocols.
+
+5.1. Ordering
+
+   If date and time components are ordered from least precise to most
+   precise, then a useful property is achieved.  Assuming that the time
+   zones of the dates and times are the same (e.g. all in UTC),
+   expressed using the same string (e.g. all "Z" or all "+00:00"), and
+   all times have the same number of fractional second digits, then the
+   date and time strings may be sorted as strings (e.g. using the
+   strcmp() function in C) and a time-ordered sequence will result.  The
+   presence of optional punctuation would violate this characteristic.
+
+5.2. Human Readability
+
+   Human readability has proved to be a valuable feature of Internet
+   protocols.  Human readable protocols greatly reduce the costs of
+   debugging since telnet often suffices as a test client and network
+   analyzers need not be modified with knowledge of the protocol.  On
+   the other hand, human readability sometimes results in
+
+
+
+Newman & Klyne                                                  [Page 6]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   interoperability problems.  For example, the date format "10/11/1996"
+   is completely unsuitable for global interchange because it is
+   interpreted differently in different countries.  In addition, the
+   date format in [IMAIL] has resulted in interoperability problems when
+   people assumed any text string was permitted and translated the three
+   letter abbreviations to other languages or substituted date formats
+   which were easier to generate (e.g. the format used by the C function
+   ctime).  For this reason, a balance must be struck between human
+   readability and interoperability.
+
+   Because no date and time format is readable according to the
+   conventions of all countries, Internet clients SHOULD be prepared to
+   transform dates into a display format suitable for the locality.
+   This may include translating UTC to local time.
+
+5.3. Rarely Used Options
+
+   A format which includes rarely used options is likely to cause
+   interoperability problems.  This is because rarely used options are
+   less likely to be used in alpha or beta testing, so bugs in parsing
+   are less likely to be discovered.  Rarely used options should be made
+   mandatory or omitted for the sake of interoperability whenever
+   possible.
+
+   The format defined below includes only one rarely used option:
+   fractions of a second.  It is expected that this will be used only by
+   applications which require strict ordering of date/time stamps or
+   which have an unusual precision requirement.
+
+5.4. Redundant Information
+
+   If a date/time format includes redundant information, that introduces
+   the possibility that the redundant information will not correlate.
+   For example, including the day of the week in a date/time format
+   introduces the possibility that the day of week is incorrect but the
+   date is correct, or vice versa.  Since it is not difficult to compute
+   the day of week from a date (see Appendix B), the day of week should
+   not be included in a date/time format.
+
+5.5. Simplicity
+
+   The complete set of date and time formats specified in ISO 8601
+   [ISO8601] is quite complex in an attempt to provide multiple
+   representations and partial representations.  Appendix A contains an
+   attempt to translate the complete syntax of ISO 8601 into ABNF.
+   Internet protocols have somewhat different requirements and
+   simplicity has proved to be an important characteristic.  In
+   addition, Internet protocols usually need complete specification of
+
+
+
+Newman & Klyne                                                  [Page 7]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   data in order to achieve true interoperability.  Therefore, the
+   complete grammar for ISO 8601 is deemed too complex for most Internet
+   protocols.
+
+   The following section defines a profile of ISO 8601 for use on the
+   Internet.  It is a conformant subset of the ISO 8601 extended format.
+   Simplicity is achieved by making most fields and punctuation
+   mandatory.
+
+5.6. Internet Date/Time Format
+
+   The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
+   new protocols on the Internet.  This is specified using the syntax
+   description notation defined in [ABNF].
+
+      date-fullyear   = 4DIGIT
+      date-month      = 2DIGIT  ; 01-12
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      time-hour       = 2DIGIT  ; 00-23
+      time-minute     = 2DIGIT  ; 00-59
+      time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second rules
+      time-secfrac    = "." 1*DIGIT
+      time-numoffset  = ("+" / "-") time-hour ":" time-minute
+      time-offset     = "Z" / time-numoffset
+
+      partial-time    = time-hour ":" time-minute ":" time-second
+                        [time-secfrac]
+      full-date       = date-fullyear "-" date-month "-" date-mday
+      full-time       = partial-time time-offset
+
+      date-time       = full-date "T" full-time
+
+
+     NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in
+     this syntax may alternatively be lower case "t" or "z"
+     respectively.
+
+     NOTE: ISO 8601 defines date and time separated by "T".
+     Applications using this syntax may choose, for the sake of
+     readability, to specify a full-date and full-time separated by
+     (say) a space character.
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 8]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+5.7. Restrictions
+
+   The grammar element date-mday represents the day number within the
+   current month.  The maximum value varies based on the month and year
+   as follows:
+
+      Month Number  Month/Year           Maximum value of date-mday
+      ------------  ----------           --------------------------
+      01            January              31
+      02            February, normal     28
+      02            February, leap year  29
+      03            March                31
+      04            April                30
+      05            May                  31
+      06            June                 30
+      07            July                 31
+      08            August               31
+      09            September            30
+      10            October              31
+      11            November             30
+      12            December             31
+
+   Appendix C contains sample C code to determine if a year is a leap
+   year.
+
+   The grammar element time-second may have the value "60" at the end of
+   months in which a leap second occurs -- to date: June
+   (XXXX-06-30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see
+   Appendix D for a table of leap seconds.  It is also possible for a
+   leap second to be subtracted, at which times the maximum value of
+   time-second is "58".  At all other times the maximum value of
+   time-second is "59".  Further, in time zones other than "Z", the leap
+   second point is shifted by the zone offset (so it happens at the same
+   instant around the globe).
+
+   Leap seconds cannot be predicted far into the future.  The
+   International Earth Rotation Service publishes bulletins [IERS] that
+   announce leap seconds with a few weeks' warning.  Applications should
+   not generate timestamps involving inserted leap seconds until after
+   the leap seconds are announced.
+
+   Although ISO 8601 permits the hour to be "24", this profile of ISO
+   8601 only allows values between "00" and "23" for the hour in order
+   to reduce confusion.
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 9]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+5.8. Examples
+
+   Here are some examples of Internet date/time format.
+
+      1985-04-12T23:20:50.52Z
+
+   This represents 20 minutes and 50.52 seconds after the 23rd hour of
+   April 12th, 1985 in UTC.
+
+      1996-12-19T16:39:57-08:00
+
+   This represents 39 minutes and 57 seconds after the 16th hour of
+   December 19th, 1996 with an offset of -08:00 from UTC (Pacific
+   Standard Time).  Note that this is equivalent to 1996-12-20T00:39:57Z
+   in UTC.
+
+      1990-12-31T23:59:60Z
+
+   This represents the leap second inserted at the end of 1990.
+
+      1990-12-31T15:59:60-08:00
+
+   This represents the same leap second in Pacific Standard Time, 8
+   hours behind UTC.
+
+      1937-01-01T11:59:27.87+00:20
+
+   This represents the same instant of time as noon, January 1, 1937,
+   Netherlands time.  Standard time in the Netherlands was exactly 19
+   minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
+   1937-06-30.  This time zone cannot be represented exactly using the
+   HH:MM format, and this timestamp uses the closest representable UTC
+   offset.
+
+
+
+6. Acknowledgements
+
+   The following people provided helpful advice for an earlier
+   incarnation of this document: Ned Freed, Neal McBurnett, David
+   Keegel, Markus Kuhn, Paul Eggert and Robert Elz.  Thanks are also due
+   to participants of the IETF Calendaring/Scheduling working group
+   mailing list, and participants of the time zone mailing list.
+
+   The following reviewers contributed helpful suggestions for the
+   present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn.
+   Paul Eggert provided many careful observations regarding the
+   subtleties of leap seconds and time zone offsets.
+
+
+
+Newman & Klyne                                                 [Page 10]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+7. References
+
+   [Zeller]    Chr. Zeller, "Kalender-Formeln", Acta Mathematica, Vol.
+               9, Nov 1886.
+
+   [IMAIL]     Crocker, D., "Standard for the Format of Arpa Internet
+               Text Messages", RFC 822, August 1982.
+
+   [IMAIL-UPDATE]
+               Resnick, P., "Internet Message Format", RFC 2822, April
+               2001.
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [ISO8601]   "Data elements and interchange formats -- Information
+               interchange -- Representation of dates and times", ISO
+               8601:1988(E), International Organization for
+               Standardization, June, 1988.
+
+   [ISO8601:2000]
+               "Data elements and interchange formats -- Information
+               interchange -- Representation of dates and times", ISO
+               8601:2000, International Organization for
+               Standardization, December, 2000.
+
+   [HOST-REQ]  Braden, R., "Requirements for Internet Hosts --
+               Application and Support", RFC 1123, Internet Engineering
+               Task Force, October 1989.
+
+   [IERS]      International Earth Rotation Service Bulletins,
+               <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.
+
+   [NTP]       Mills, D., "Network Time Protocol (Version 3)
+               Specification, Implementation and Analysis", RFC 1305,
+               University of Delaware, March 1992.
+
+   [ITU-R-TF]  International Telecommunication Union Recommendations for
+               Time Signals and Frequency Standards Emissions.
+               <http://www.itu.ch/publications/itu-r/iturtf.htm>
+
+
+
+8. Security Considerations
+
+   Since the local time zone of a site may be useful for determining a
+   time when systems are less likely to be monitored and might be more
+   susceptible to a security probe, some sites may wish to emit times in
+
+
+
+Newman & Klyne                                                 [Page 11]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   UTC only.  Others might consider this to be loss of useful
+   functionality at the hands of paranoia.
+
+
+9. Authors' Addresses
+
+   Chris Newman
+   Sun Microsystems
+   1050 Lakes Drive, Suite 250
+   West Covina, CA 91790 USA
+
+   Email: cnewman@iplanet.com
+
+   Graham Klyne (editor, this revision)
+   Baltimore Technologies - Content Security Group
+   1310 Waterside
+   Arlington Business Park
+   Theale
+   Reading, RG7 4SA
+   United Kingdom.
+   Telephone: +44 118 903 8000
+   Facsimile: +44 118 903 9000
+   E-mail:    GK@ACM.ORG
+
+
+Appendix A. ISO 8601 Collected ABNF
+
+   This information is based on the 1988 version of ISO 8601.  There may
+   be some changes in the 2000 revision.
+
+   ISO 8601 does not specify a formal grammar for the date and time
+   formats it defines.  The following is an attempt to create a formal
+   grammar from ISO 8601.  This is informational only and may contain
+   errors.  ISO 8601 remains the authoritative reference.
+
+   Note that due to ambiguities in ISO 8601, some interpretations had to
+   be made.  First, ISO 8601 is not clear if mixtures of basic and
+   extended format are permissible.  This grammar permits mixtures.  ISO
+   8601 is not clear on whether an hour of 24 is permissible only if
+   minutes and seconds are 0.  This assumes that an hour of 24 is
+   permissible in any context.  Restrictions on date-mday in section 5.7
+   apply.  ISO 8601 states that the "T" may be omitted under some
+   circumstances.  This grammar requires the "T" to avoid ambiguity.
+
+   ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
+   be proceeded by a "0" if less than unity.  Annex B.2 of ISO 8601
+   gives examples where the decimal fractions are not preceded by a "0".
+   This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is
+
+
+
+Newman & Klyne                                                 [Page 12]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   in error.
+
+      date-century    = 2DIGIT  ; 00-99
+      date-decade     =  DIGIT  ; 0-9
+      date-subdecade  =  DIGIT  ; 0-9
+      date-year       = date-decade date-subdecade
+      date-fullyear   = date-century date-year
+      date-month      = 2DIGIT  ; 01-12
+      date-wday       =  DIGIT  ; 1-7  ; 1 is Monday, 7 is Sunday
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      date-yday       = 3DIGIT  ; 001-365, 001-366 based on year
+      date-week       = 2DIGIT  ; 01-52, 01-53 based on year
+
+      datepart-fullyear = [date-century] date-year ["-"]
+      datepart-ptyear   = "-" [date-subdecade ["-"]]
+      datepart-wkyear   = datepart-ptyear / datepart-fullyear
+
+      dateopt-century   = "-" / date-century
+      dateopt-fullyear  = "-" / datepart-fullyear
+      dateopt-year      = "-" / (date-year ["-"])
+      dateopt-month     = "-" / (date-month ["-"])
+      dateopt-week      = "-" / (date-week ["-"])
+
+      datespec-full     = datepart-fullyear date-month ["-"] date-mday
+      datespec-year     = date-century / dateopt-century date-year
+      datespec-month    = "-" dateopt-year date-month [["-"] date-mday]
+      datespec-mday     = "--" dateopt-month date-mday
+      datespec-week     = datepart-wkyear "W"
+                          (date-week / dateopt-week date-wday)
+      datespec-wday     = "---" date-wday
+      datespec-yday     = dateopt-fullyear date-yday
+
+      date              = datespec-full / datespec-year / datespec-month /
+          datespec-mday / datespec-week / datespec-wday / datespec-yday
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 13]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   Time:
+
+      time-hour         = 2DIGIT ; 00-24
+      time-minute       = 2DIGIT ; 00-59
+      time-second       = 2DIGIT ; 00-58, 00-59, 00-60 based on leap-second rules
+      time-fraction     = ("," / ".") 1*DIGIT
+      time-numoffset    = ("+" / "-") time-hour [[":"] time-minute]
+      time-zone         = "Z" / time-numoffset
+
+      timeopt-hour      = "-" / (time-hour [":"])
+      timeopt-minute    = "-" / (time-minute [":"])
+
+      timespec-hour     = time-hour [[":"] time-minute [[":"] time-second]]
+      timespec-minute   = timeopt-hour time-minute [[":"] time-second]
+      timespec-second   = "-" timeopt-minute time-second
+      timespec-base     = timespec-hour / timespec-minute / timespec-second
+
+      time              = timespec-base [time-fraction] [time-zone]
+
+      iso-date-time     = date "T" time
+
+   Durations:
+
+      dur-second        = 1*DIGIT "S"
+      dur-minute        = 1*DIGIT "M" [dur-second]
+      dur-hour          = 1*DIGIT "H" [dur-minute]
+      dur-time          = "T" (dur-hour / dur-minute / dur-second)
+      dur-day           = 1*DIGIT "D"
+      dur-week          = 1*DIGIT "W"
+      dur-month         = 1*DIGIT "M" [dur-day]
+      dur-year          = 1*DIGIT "Y" [dur-month]
+      dur-date          = (dur-day / dur-month / dur-year) [dur-time]
+
+      duration          = "P" (dur-date / dur-time / dur-week)
+
+   Periods:
+
+      period-explicit   = date-time "/" date-time
+      period-start      = date-time "/" duration
+      period-end        = duration "/" date-time
+
+      period            = period-explicit / period-start / period-end
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 14]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Appendix B. Day of the Week
+
+   The following is a sample C subroutine loosely based on Zeller's
+   Congruence [Zeller] which may be used to obtain the day of the week
+   for dates on or after 0000-02-01:
+
+
+      char *day_of_week(int day, int month, int year)
+      {
+          int cent;
+          char *dayofweek[] = {
+              "Sunday", "Monday", "Tuesday", "Wednesday",
+              "Thursday", "Friday", "Saturday"
+          };
+
+          /* adjust months so February is the last one */
+          month -= 2;
+          if (month < 1) {
+              month += 12;
+              --year;
+          }
+          /* split by century */
+          cent = year / 100;
+          year %= 100;
+          return (dayofweek[((26 * month - 2) / 10 + day + year
+                            + year / 4 + cent / 4 - 2 * cent) % 7]);
+      }
+
+
+
+Appendix C. Leap Years
+
+   Here is a sample C subroutine to calculate if a year is a leap year:
+
+
+      /* This returns non-zero if year is a leap year.  Must use 4 digit year.
+       */
+      int leap_year(int year)
+      {
+          return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
+      }
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 15]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Appendix D. Leap Seconds
+
+   Information about leap seconds can be found at:
+   <http://tycho.usno.navy.mil/leapsec.html>.  In particular, it notes
+   that:
+
+      The decision to introduce a leap second in UTC is the
+      responsibility of the International Earth Rotation Service (IERS).
+      According to the CCIR Recommendation, first preference is given to
+      the opportunities at the end of December and June, and second
+      preference to those at the end of March and September.
+
+   When required, insertion of a leap second occurs as an extra second
+   at the end of a day in UTC, represented by a timestamp of the form
+   YYYY-MM-DDT23:59:60Z.  A leap second occurs simultaneously in all
+   time zones, so that time zone relationships are not affected.  See
+   section 5.8 for some examples of leap second times.
+
+   The following table is an excerpt from the table maintained by the
+   United States Naval Observatory.  The source data is located at:
+
+      <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 16]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+   This table shows the date of the leap second, and the difference
+   between the time standard TAI (which isn't adjusted by leap seconds)
+   and UTC after that leap second.
+
+
+      UTC Date  TAI - UTC After Leap Second
+      --------  ---------------------------
+      1972-06-30     11
+      1972-12-31     12
+      1973-12-31     13
+      1974-12-31     14
+      1975-12-31     15
+      1976-12-31     16
+      1977-12-31     17
+      1978-12-31     18
+      1979-12-31     19
+      1981-06-30     20
+      1982-06-30     21
+      1983-06-30     22
+      1985-06-30     23
+      1987-12-31     24
+      1989-12-31     25
+      1990-12-31     26
+      1992-06-30     27
+      1993-06-30     28
+      1994-06-30     29
+      1995-12-31     30
+      1997-06-30     31
+      1998-12-31     32
+
+
+Appendix E. Amendment history
+
+
+00a 30-Mar-2001 This document version created from Chris Newman's
+                original 'draft-ietf-impp-datetime-00.txt'.  Material
+                relating to future times (schedule events) and time zone
+                names has been removed.  Added introductory text setting
+                the scope for this document.  Various small editorial
+                changes.
+
+00b 03-Apr-2001 Added reference [ABNF], and updated citations.  Added
+                comment about possible use of space-separated date/time
+                fields.  Added comment about possible use of lower case
+                "t" and "z" in syntax.  Corrected leap-second examples
+                and noted that leap second point is offset by time zone.
+
+
+
+
+
+Newman & Klyne                                                 [Page 17]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+01a 06-Apr-2001 Updated author affiliation and contact details.  Udated
+                leap-second table.
+
+01b 10-May-2001 Clarified provenance of (non-normative) information in
+                appendix A.
+
+02a 11-May-2001 Reference updated email specification (RFC2822).
+
+02b 14-May-2001 Fix up some detailed information concerning leap
+                seconds.  Include text describing timestamps for times
+                before introduction of UTC.  Caution against the use of
+                future timestamps using leap seconds.  Correction to
+                day-of-week sample code, and note restriction on
+                applicability.  Various editorial corrections.
+
+03a 23-May-2001 Editorial fixes.  Minor clarification of leap seconds.
+
+03b 24-May-2001 More clarification of leap seconds and time zones.
+
+03c 25-May-2001 More minor editorial fixes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 18]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps               May 2001
+
+
+Full copyright statement
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 19]
+
+
diff --git a/Documentation/en/I-D/draft-ietf-impp-datetime-04.txt b/Documentation/en/I-D/draft-ietf-impp-datetime-04.txt
new file mode 100644
index 00000000..8b9bee79
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-impp-datetime-04.txt
@@ -0,0 +1,1140 @@
+Network Working Group                   G. Klyne, Baltimore Technologies
+Internet Draft                               C. Newman, Sun Microsystems
+                                                             3 July 2001
+                                                   Expires: January 2002
+
+
+               Date and Time on the Internet: Timestamps
+                   <draft-ietf-impp-datetime-04.txt>
+
+
+Status of this memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC 2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress".
+
+     The list of current Internet-Drafts can be accessed at
+     http://www.ietf.org/1id-abstracts.html
+
+     The list of Internet-Draft Shadow Directories can be accessed at
+     http://www.ietf.org/shadow.html.
+
+   To view the entire list of current Internet-Drafts, please check the
+   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
+   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
+   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+
+Abstract
+
+   This document defines a date and time format for use in Internet
+   protocols that is a profile of the ISO 8601 [ISO8601] standard for
+   representation of dates and times using the Gregorian calendar.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 1]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+Table of Contents
+
+   1. Introduction
+   2. Definitions
+   3. Two Digit Years
+   4. Local Time
+   4.1. Coordinated Universal Time (UTC)
+   4.2. Local Offsets
+   4.3. Unknown Local Offset Convention
+   4.4. Unqualified Local Time
+   5. Date and Time format
+   5.1. Ordering
+   5.2. Human Readability
+   5.3. Rarely Used Options
+   5.4. Redundant Information
+   5.5. Simplicity
+   5.6. Internet Date/Time Format
+   5.7. Restrictions
+   5.8. Examples
+   6. Acknowledgements
+   7. References
+   8. Security Considerations
+   9. Authors' Addresses
+   Appendix A. ISO 8601 Collected ABNF
+   Appendix B. Day of the Week
+   Appendix C. Leap Years
+   Appendix D. Leap Seconds
+   Appendix E. Amendment history
+   Full copyright statement
+
+1. Introduction
+
+   Date and time formats cause a lot of confusion and interoperability
+   problems on the Internet.  This document addresses many of the
+   problems encountered and makes recommendations to improve consistency
+   and interoperability when representing and using date and time in
+   Internet protocols.
+
+   This document includes an Internet profile of the ISO 8601 [ISO8601]
+   standard for representation of dates and times using the Gregorian
+   calendar.
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 2]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+   There are many ways in which date and time values might appear in
+   Internet protocols:  this document focuses on just one common usage,
+   viz. timestamps for Internet protocol events.  This limited
+   consideration has the following consequences:
+
+   o  All dates and times are assumed to be in the "current era",
+      somewhere between 0000AD and 9999AD.
+
+   o  All times expressed have a stated relationship (offset) to
+      Coordinated Universal Time (UTC).  (This is distinct from some
+      usage in scheduling applications where a local time and location
+      may be known, but the actual relationship to UTC may be dependent
+      on the unknown or unknowable actions of politicians or
+      administrators.  The UTC time corresponding to 17:00 on 23rd March
+      2005 in New York may depend on administrative decisions about
+      daylight savings time.  This specification steers well clear of
+      such considerations.)
+
+   o  Timestamps can express times that occurred before the introduction
+      of UTC.  Such timestamps are expressed relative to universal time,
+      using the best available practice at the stated time.
+
+   o  Date and time expressions indicate an instant in time.
+      Description of time periods, or intervals, is not covered here.
+
+
+2. Definitions
+
+
+   UTC         Coordinated Universal Time as maintained by the Bureau
+               International des Poids et Mesures (BIPM).
+
+   second      A basic unit of measurement of time in the International
+               System of Units.  It is defined as the duration of
+               9,192,631,770 cycles of microwave light absorbed or
+               emitted by the hyperfine transition of cesium-133 atoms
+               in their ground state undisturbed by external fields.
+
+   minute      A period of time of 60 seconds.  However, see also the
+               restrictions in section 5.7 and Appendix D for how leap
+               seconds are denoted within minutes.
+
+   hour        A period of time of 60 minutes.
+
+   day         A period of time of 24 hours.
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 3]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+   leap year   In the Gregorian calendar, a year which has 366 days.  A
+               leap year is a year whose number is divisible by four an
+               integral number of times, except that if it is a
+               centennial year (i.e. divisible by one hundred) it shall
+               also be divisible by four hundred an integral number of
+               times.
+
+   ABNF        Augmented Backus-Naur Form, a format used to represent
+               permissible strings in a protocol or language, as defined
+               in [ABNF].
+
+   Email Date/Time Format
+               The date/time format used by Internet Mail as defined by
+               RFC 2822 [IMAIL-UPDATE].
+
+   Internet Date/Time Format
+               The date format defined in section 5 of this document.
+
+   For more information about time scales, see Appendix E of [NTP],
+   Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF].
+
+
+3. Two Digit Years
+
+   The following requirements are to address the problems of ambiguity
+   of 2-digit years:
+
+   o  Internet Protocols MUST generate four digit years in dates.
+
+   o  The use of 2-digit years is deprecated.  If a 2-digit year is
+      received, it should be accepted ONLY if an incorrect
+      interpretation will not cause a protocol or processing failure
+      (e.g. if used only for logging or tracing purposes).
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as three digits.  This occurs if the program
+      simply subtracts 1900 from the year and doesn't check the number
+      of digits.  Programs wishing to robustly deal with dates generated
+      by such broken software may add 1900 to three digit years.
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as ":0", ":1", ... ":9", ";0", ...  This occurs
+      if the program simply subtracts 1900 from the year and adds the
+      decade to the US-ASCII character zero. Programs wishing to
+      robustly deal with dates generated by such broken software should
+      detect non-numeric decades and interpret appropriately.
+
+
+
+
+
+Newman & Klyne                                                  [Page 4]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+      The problems with two digit years amply demonstrate why all dates
+      and times used in Internet protocols MUST be fully qualified.
+
+
+
+4. Local Time
+
+4.1. Coordinated Universal Time (UTC)
+
+   Because the daylight saving rules for local time zones are so
+   convoluted and can change based on local law at unpredictable times,
+   true interoperability is best achieved by using Coordinated Universal
+   Time (UTC).  This specification does not cater to local time zone
+   rules.
+
+4.2. Local Offsets
+
+   The offset between local time and UTC is often useful information.
+   For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local
+   offset provides a useful heuristic to determine the probability of a
+   prompt response.  Attempts to label local offsets with alphabetic
+   strings have resulted in poor interoperability in the past [IMAIL],
+   [HOST-REQ].  As a result, RFC2822 [IMAIL-UPDATE] has made numeric
+   offsets mandatory.
+
+   Numeric offsets are calculated as "local time minus UTC".  So the
+   equivalent time in UTC can be determined by subtracting the offset
+   from the local time.  For example, 18:50:00-04:00 is the same time as
+   22:50:00Z.
+
+
+      NOTE: Following ISO 8601, numeric offsets represent only time
+      zones that differ from UTC by an integral number of minutes.
+      However, many historical time zones differ from UTC by a non-
+      integral number of minutes.  To represent such historical time
+      stamps exactly, applications must convert them to a representable
+      time zone.
+
+
+4.3. Unknown Local Offset Convention
+
+   If the time in UTC is known, but the offset to local time is unknown,
+   this can be represented with an offset of "-00:00".  This differs
+   semantically from an offset of "Z" or "+00:00", which imply that UTC
+   is the preferred reference point for the specified time.  RFC2822
+   [IMAIL-UPDATE] describes a similar convention for email.
+
+
+
+
+
+Newman & Klyne                                                  [Page 5]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+4.4. Unqualified Local Time
+
+   A number of devices currently connected to the Internet run their
+   internal clocks in local time and are unaware of UTC.  While the
+   Internet does have a tradition of accepting reality when creating
+   specifications, this should not be done at the expense of
+   interoperability.  Since interpretation of an unqualified local time
+   zone will fail in approximately 23/24 of the globe, the
+   interoperability problems of unqualified local time are deemed
+   unacceptable for the Internet.  Systems that are configured with a
+   local time, are unaware of the corresponding UTC offset, and depend
+   on time synchronization with other Internet systems, MUST use a
+   mechanism that ensures correct synchronization with UTC.  Some
+   suitable mechanisms are:
+
+   o  Use Network Time Protocol [NTP] to obtain the time in UTC.
+
+   o  Use another host in the same local time zone as a gateway to the
+      Internet.  This host MUST correct unqualified local times they are
+      transmitted to other hosts.
+
+   o  Prompt the user for the local time zone and daylight saving rule
+      settings.
+
+
+5. Date and Time format
+
+   This section discusses desirable qualities of date and time formats
+   and defines a profile of ISO 8601 for use in Internet protocols.
+
+5.1. Ordering
+
+   If date and time components are ordered from least precise to most
+   precise, then a useful property is achieved.  Assuming that the time
+   zones of the dates and times are the same (e.g. all in UTC),
+   expressed using the same string (e.g. all "Z" or all "+00:00"), and
+   all times have the same number of fractional second digits, then the
+   date and time strings may be sorted as strings (e.g. using the
+   strcmp() function in C) and a time-ordered sequence will result.  The
+   presence of optional punctuation would violate this characteristic.
+
+5.2. Human Readability
+
+   Human readability has proved to be a valuable feature of Internet
+   protocols.  Human readable protocols greatly reduce the costs of
+   debugging since telnet often suffices as a test client and network
+   analyzers need not be modified with knowledge of the protocol.  On
+   the other hand, human readability sometimes results in
+
+
+
+Newman & Klyne                                                  [Page 6]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+   interoperability problems.  For example, the date format "10/11/1996"
+   is completely unsuitable for global interchange because it is
+   interpreted differently in different countries.  In addition, the
+   date format in [IMAIL] has resulted in interoperability problems when
+   people assumed any text string was permitted and translated the three
+   letter abbreviations to other languages or substituted date formats
+   which were easier to generate (e.g. the format used by the C function
+   ctime).  For this reason, a balance must be struck between human
+   readability and interoperability.
+
+   Because no date and time format is readable according to the
+   conventions of all countries, Internet clients SHOULD be prepared to
+   transform dates into a display format suitable for the locality.
+   This may include translating UTC to local time.
+
+5.3. Rarely Used Options
+
+   A format which includes rarely used options is likely to cause
+   interoperability problems.  This is because rarely used options are
+   less likely to be used in alpha or beta testing, so bugs in parsing
+   are less likely to be discovered.  Rarely used options should be made
+   mandatory or omitted for the sake of interoperability whenever
+   possible.
+
+   The format defined below includes only one rarely used option:
+   fractions of a second.  It is expected that this will be used only by
+   applications which require strict ordering of date/time stamps or
+   which have an unusual precision requirement.
+
+5.4. Redundant Information
+
+   If a date/time format includes redundant information, that introduces
+   the possibility that the redundant information will not correlate.
+   For example, including the day of the week in a date/time format
+   introduces the possibility that the day of week is incorrect but the
+   date is correct, or vice versa.  Since it is not difficult to compute
+   the day of week from a date (see Appendix B), the day of week should
+   not be included in a date/time format.
+
+5.5. Simplicity
+
+   The complete set of date and time formats specified in ISO 8601
+   [ISO8601] is quite complex in an attempt to provide multiple
+   representations and partial representations.  Appendix A contains an
+   attempt to translate the complete syntax of ISO 8601 into ABNF.
+   Internet protocols have somewhat different requirements and
+   simplicity has proved to be an important characteristic.  In
+   addition, Internet protocols usually need complete specification of
+
+
+
+Newman & Klyne                                                  [Page 7]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+   data in order to achieve true interoperability.  Therefore, the
+   complete grammar for ISO 8601 is deemed too complex for most Internet
+   protocols.
+
+   The following section defines a profile of ISO 8601 for use on the
+   Internet.  It is a conformant subset of the ISO 8601 extended format.
+   Simplicity is achieved by making most fields and punctuation
+   mandatory.
+
+5.6. Internet Date/Time Format
+
+   The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
+   new protocols on the Internet.  This is specified using the syntax
+   description notation defined in [ABNF].
+
+      date-fullyear   = 4DIGIT
+      date-month      = 2DIGIT  ; 01-12
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      time-hour       = 2DIGIT  ; 00-23
+      time-minute     = 2DIGIT  ; 00-59
+      time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second rules
+      time-secfrac    = "." 1*DIGIT
+      time-numoffset  = ("+" / "-") time-hour ":" time-minute
+      time-offset     = "Z" / time-numoffset
+
+      partial-time    = time-hour ":" time-minute ":" time-second
+                        [time-secfrac]
+      full-date       = date-fullyear "-" date-month "-" date-mday
+      full-time       = partial-time time-offset
+
+      date-time       = full-date "T" full-time
+
+
+     NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in
+     this syntax may alternatively be lower case "t" or "z"
+     respectively.
+
+     NOTE: ISO 8601 defines date and time separated by "T".
+     Applications using this syntax may choose, for the sake of
+     readability, to specify a full-date and full-time separated by
+     (say) a space character.
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 8]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+5.7. Restrictions
+
+   The grammar element date-mday represents the day number within the
+   current month.  The maximum value varies based on the month and year
+   as follows:
+
+      Month Number  Month/Year           Maximum value of date-mday
+      ------------  ----------           --------------------------
+      01            January              31
+      02            February, normal     28
+      02            February, leap year  29
+      03            March                31
+      04            April                30
+      05            May                  31
+      06            June                 30
+      07            July                 31
+      08            August               31
+      09            September            30
+      10            October              31
+      11            November             30
+      12            December             31
+
+   Appendix C contains sample C code to determine if a year is a leap
+   year.
+
+   The grammar element time-second may have the value "60" at the end of
+   months in which a leap second occurs -- to date: June
+   (XXXX-06-30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see
+   Appendix D for a table of leap seconds.  It is also possible for a
+   leap second to be subtracted, at which times the maximum value of
+   time-second is "58".  At all other times the maximum value of
+   time-second is "59".  Further, in time zones other than "Z", the leap
+   second point is shifted by the zone offset (so it happens at the same
+   instant around the globe).
+
+   Leap seconds cannot be predicted far into the future.  The
+   International Earth Rotation Service publishes bulletins [IERS] that
+   announce leap seconds with a few weeks' warning.  Applications should
+   not generate timestamps involving inserted leap seconds until after
+   the leap seconds are announced.
+
+   Although ISO 8601 permits the hour to be "24", this profile of ISO
+   8601 only allows values between "00" and "23" for the hour in order
+   to reduce confusion.
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 9]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+5.8. Examples
+
+   Here are some examples of Internet date/time format.
+
+      1985-04-12T23:20:50.52Z
+
+   This represents 20 minutes and 50.52 seconds after the 23rd hour of
+   April 12th, 1985 in UTC.
+
+      1996-12-19T16:39:57-08:00
+
+   This represents 39 minutes and 57 seconds after the 16th hour of
+   December 19th, 1996 with an offset of -08:00 from UTC (Pacific
+   Standard Time).  Note that this is equivalent to 1996-12-20T00:39:57Z
+   in UTC.
+
+      1990-12-31T23:59:60Z
+
+   This represents the leap second inserted at the end of 1990.
+
+      1990-12-31T15:59:60-08:00
+
+   This represents the same leap second in Pacific Standard Time, 8
+   hours behind UTC.
+
+      1937-01-01T12:00:27.87+00:20
+
+   This represents the same instant of time as noon, January 1, 1937,
+   Netherlands time.  Standard time in the Netherlands was exactly 19
+   minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
+   1937-06-30.  This time zone cannot be represented exactly using the
+   HH:MM format, and this timestamp uses the closest representable UTC
+   offset.
+
+
+
+6. Acknowledgements
+
+   The following people provided helpful advice for an earlier
+   incarnation of this document: Ned Freed, Neal McBurnett, David
+   Keegel, Markus Kuhn, Paul Eggert and Robert Elz.  Thanks are also due
+   to participants of the IETF Calendaring/Scheduling working group
+   mailing list, and participants of the time zone mailing list.
+
+   The following reviewers contributed helpful suggestions for the
+   present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn.
+   Paul Eggert provided many careful observations regarding the
+   subtleties of leap seconds and time zone offsets.
+
+
+
+Newman & Klyne                                                 [Page 10]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+7. References
+
+   [Zeller]    Chr. Zeller, "Kalender-Formeln", Acta Mathematica, Vol.
+               9, Nov 1886.
+
+   [IMAIL]     Crocker, D., "Standard for the Format of Arpa Internet
+               Text Messages", RFC 822, August 1982.
+
+   [IMAIL-UPDATE]
+               Resnick, P., "Internet Message Format", RFC 2822, April
+               2001.
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [ISO8601]   "Data elements and interchange formats -- Information
+               interchange -- Representation of dates and times", ISO
+               8601:1988(E), International Organization for
+               Standardization, June, 1988.
+
+   [ISO8601:2000]
+               "Data elements and interchange formats -- Information
+               interchange -- Representation of dates and times", ISO
+               8601:2000, International Organization for
+               Standardization, December, 2000.
+
+   [HOST-REQ]  Braden, R., "Requirements for Internet Hosts --
+               Application and Support", RFC 1123, Internet Engineering
+               Task Force, October 1989.
+
+   [IERS]      International Earth Rotation Service Bulletins,
+               <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.
+
+   [NTP]       Mills, D., "Network Time Protocol (Version 3)
+               Specification, Implementation and Analysis", RFC 1305,
+               University of Delaware, March 1992.
+
+   [ITU-R-TF]  International Telecommunication Union Recommendations for
+               Time Signals and Frequency Standards Emissions.
+               <http://www.itu.ch/publications/itu-r/iturtf.htm>
+
+
+
+8. Security Considerations
+
+   Since the local time zone of a site may be useful for determining a
+   time when systems are less likely to be monitored and might be more
+   susceptible to a security probe, some sites may wish to emit times in
+
+
+
+Newman & Klyne                                                 [Page 11]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+   UTC only.  Others might consider this to be loss of useful
+   functionality at the hands of paranoia.
+
+
+9. Authors' Addresses
+
+   Chris Newman
+   Sun Microsystems
+   1050 Lakes Drive, Suite 250
+   West Covina, CA 91790 USA
+
+   Email: cnewman@iplanet.com
+
+   Graham Klyne (editor, this revision)
+   Baltimore Technologies - Content Security Group
+   1310 Waterside
+   Arlington Business Park
+   Theale
+   Reading, RG7 4SA
+   United Kingdom.
+   Telephone: +44 118 903 8000
+   Facsimile: +44 118 903 9000
+   E-mail:    GK@ACM.ORG
+
+
+Appendix A. ISO 8601 Collected ABNF
+
+   This information is based on the 1988 version of ISO 8601.  There may
+   be some changes in the 2000 revision.
+
+   ISO 8601 does not specify a formal grammar for the date and time
+   formats it defines.  The following is an attempt to create a formal
+   grammar from ISO 8601.  This is informational only and may contain
+   errors.  ISO 8601 remains the authoritative reference.
+
+   Note that due to ambiguities in ISO 8601, some interpretations had to
+   be made.  First, ISO 8601 is not clear if mixtures of basic and
+   extended format are permissible.  This grammar permits mixtures.  ISO
+   8601 is not clear on whether an hour of 24 is permissible only if
+   minutes and seconds are 0.  This assumes that an hour of 24 is
+   permissible in any context.  Restrictions on date-mday in section 5.7
+   apply.  ISO 8601 states that the "T" may be omitted under some
+   circumstances.  This grammar requires the "T" to avoid ambiguity.
+
+   ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
+   be proceeded by a "0" if less than unity.  Annex B.2 of ISO 8601
+   gives examples where the decimal fractions are not preceded by a "0".
+   This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is
+
+
+
+Newman & Klyne                                                 [Page 12]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+   in error.
+
+      date-century    = 2DIGIT  ; 00-99
+      date-decade     =  DIGIT  ; 0-9
+      date-subdecade  =  DIGIT  ; 0-9
+      date-year       = date-decade date-subdecade
+      date-fullyear   = date-century date-year
+      date-month      = 2DIGIT  ; 01-12
+      date-wday       =  DIGIT  ; 1-7  ; 1 is Monday, 7 is Sunday
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      date-yday       = 3DIGIT  ; 001-365, 001-366 based on year
+      date-week       = 2DIGIT  ; 01-52, 01-53 based on year
+
+      datepart-fullyear = [date-century] date-year ["-"]
+      datepart-ptyear   = "-" [date-subdecade ["-"]]
+      datepart-wkyear   = datepart-ptyear / datepart-fullyear
+
+      dateopt-century   = "-" / date-century
+      dateopt-fullyear  = "-" / datepart-fullyear
+      dateopt-year      = "-" / (date-year ["-"])
+      dateopt-month     = "-" / (date-month ["-"])
+      dateopt-week      = "-" / (date-week ["-"])
+
+      datespec-full     = datepart-fullyear date-month ["-"] date-mday
+      datespec-year     = date-century / dateopt-century date-year
+      datespec-month    = "-" dateopt-year date-month [["-"] date-mday]
+      datespec-mday     = "--" dateopt-month date-mday
+      datespec-week     = datepart-wkyear "W"
+                          (date-week / dateopt-week date-wday)
+      datespec-wday     = "---" date-wday
+      datespec-yday     = dateopt-fullyear date-yday
+
+      date              = datespec-full / datespec-year / datespec-month /
+          datespec-mday / datespec-week / datespec-wday / datespec-yday
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 13]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+   Time:
+
+      time-hour         = 2DIGIT ; 00-24
+      time-minute       = 2DIGIT ; 00-59
+      time-second       = 2DIGIT ; 00-58, 00-59, 00-60 based on leap-second rules
+      time-fraction     = ("," / ".") 1*DIGIT
+      time-numoffset    = ("+" / "-") time-hour [[":"] time-minute]
+      time-zone         = "Z" / time-numoffset
+
+      timeopt-hour      = "-" / (time-hour [":"])
+      timeopt-minute    = "-" / (time-minute [":"])
+
+      timespec-hour     = time-hour [[":"] time-minute [[":"] time-second]]
+      timespec-minute   = timeopt-hour time-minute [[":"] time-second]
+      timespec-second   = "-" timeopt-minute time-second
+      timespec-base     = timespec-hour / timespec-minute / timespec-second
+
+      time              = timespec-base [time-fraction] [time-zone]
+
+      iso-date-time     = date "T" time
+
+   Durations:
+
+      dur-second        = 1*DIGIT "S"
+      dur-minute        = 1*DIGIT "M" [dur-second]
+      dur-hour          = 1*DIGIT "H" [dur-minute]
+      dur-time          = "T" (dur-hour / dur-minute / dur-second)
+      dur-day           = 1*DIGIT "D"
+      dur-week          = 1*DIGIT "W"
+      dur-month         = 1*DIGIT "M" [dur-day]
+      dur-year          = 1*DIGIT "Y" [dur-month]
+      dur-date          = (dur-day / dur-month / dur-year) [dur-time]
+
+      duration          = "P" (dur-date / dur-time / dur-week)
+
+   Periods:
+
+      period-explicit   = date-time "/" date-time
+      period-start      = date-time "/" duration
+      period-end        = duration "/" date-time
+
+      period            = period-explicit / period-start / period-end
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 14]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+Appendix B. Day of the Week
+
+   The following is a sample C subroutine loosely based on Zeller's
+   Congruence [Zeller] which may be used to obtain the day of the week
+   for dates on or after 0000-02-01:
+
+
+      char *day_of_week(int day, int month, int year)
+      {
+          int cent;
+          char *dayofweek[] = {
+              "Sunday", "Monday", "Tuesday", "Wednesday",
+              "Thursday", "Friday", "Saturday"
+          };
+
+          /* adjust months so February is the last one */
+          month -= 2;
+          if (month < 1) {
+              month += 12;
+              --year;
+          }
+          /* split by century */
+          cent = year / 100;
+          year %= 100;
+          return (dayofweek[((26 * month - 2) / 10 + day + year
+                            + year / 4 + cent / 4 - 2 * cent) % 7]);
+      }
+
+
+
+Appendix C. Leap Years
+
+   Here is a sample C subroutine to calculate if a year is a leap year:
+
+
+      /* This returns non-zero if year is a leap year.  Must use 4 digit year.
+       */
+      int leap_year(int year)
+      {
+          return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
+      }
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 15]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+Appendix D. Leap Seconds
+
+   Information about leap seconds can be found at:
+   <http://tycho.usno.navy.mil/leapsec.html>.  In particular, it notes
+   that:
+
+      The decision to introduce a leap second in UTC is the
+      responsibility of the International Earth Rotation Service (IERS).
+      According to the CCIR Recommendation, first preference is given to
+      the opportunities at the end of December and June, and second
+      preference to those at the end of March and September.
+
+   When required, insertion of a leap second occurs as an extra second
+   at the end of a day in UTC, represented by a timestamp of the form
+   YYYY-MM-DDT23:59:60Z.  A leap second occurs simultaneously in all
+   time zones, so that time zone relationships are not affected.  See
+   section 5.8 for some examples of leap second times.
+
+   The following table is an excerpt from the table maintained by the
+   United States Naval Observatory.  The source data is located at:
+
+      <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 16]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+   This table shows the date of the leap second, and the difference
+   between the time standard TAI (which isn't adjusted by leap seconds)
+   and UTC after that leap second.
+
+
+      UTC Date  TAI - UTC After Leap Second
+      --------  ---------------------------
+      1972-06-30     11
+      1972-12-31     12
+      1973-12-31     13
+      1974-12-31     14
+      1975-12-31     15
+      1976-12-31     16
+      1977-12-31     17
+      1978-12-31     18
+      1979-12-31     19
+      1981-06-30     20
+      1982-06-30     21
+      1983-06-30     22
+      1985-06-30     23
+      1987-12-31     24
+      1989-12-31     25
+      1990-12-31     26
+      1992-06-30     27
+      1993-06-30     28
+      1994-06-30     29
+      1995-12-31     30
+      1997-06-30     31
+      1998-12-31     32
+
+
+Appendix E. Amendment history
+
+
+00a 30-Mar-2001 This document version created from Chris Newman's
+                original 'draft-ietf-impp-datetime-00.txt'.  Material
+                relating to future times (schedule events) and time zone
+                names has been removed.  Added introductory text setting
+                the scope for this document.  Various small editorial
+                changes.
+
+00b 03-Apr-2001 Added reference [ABNF], and updated citations.  Added
+                comment about possible use of space-separated date/time
+                fields.  Added comment about possible use of lower case
+                "t" and "z" in syntax.  Corrected leap-second examples
+                and noted that leap second point is offset by time zone.
+
+
+
+
+
+Newman & Klyne                                                 [Page 17]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+01a 06-Apr-2001 Updated author affiliation and contact details.  Udated
+                leap-second table.
+
+01b 10-May-2001 Clarified provenance of (non-normative) information in
+                appendix A.
+
+02a 11-May-2001 Reference updated email specification (RFC2822).
+
+02b 14-May-2001 Fix up some detailed information concerning leap
+                seconds.  Include text describing timestamps for times
+                before introduction of UTC.  Caution against the use of
+                future timestamps using leap seconds.  Correction to
+                day-of-week sample code, and note restriction on
+                applicability.  Various editorial corrections.
+
+03a 23-May-2001 Editorial fixes.  Minor clarification of leap seconds.
+
+03b 24-May-2001 More clarification of leap seconds and time zones.
+
+03c 25-May-2001 More minor editorial fixes.
+
+04a 03-Jul-2001 Fix off-by-one error in Netherlands example.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 18]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps              July 2001
+
+
+Full copyright statement
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 19]
+
+
diff --git a/Documentation/en/I-D/draft-ietf-impp-datetime-05.txt b/Documentation/en/I-D/draft-ietf-impp-datetime-05.txt
new file mode 100644
index 00000000..28e49597
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-impp-datetime-05.txt
@@ -0,0 +1,1140 @@
+
+
+
+
+
+
+Network Working Group                        G. Klyne, MIMEsweeper Group
+Internet Draft                               C. Newman, Sun Microsystems
+                                                         2 November 2001
+                                                       Expires: May 2002
+
+
+               Date and Time on the Internet: Timestamps
+                   <draft-ietf-impp-datetime-05.txt>
+
+
+Status of this memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC 2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress".
+
+     The list of current Internet-Drafts can be accessed at
+     http://www.ietf.org/1id-abstracts.html
+
+     The list of Internet-Draft Shadow Directories can be accessed at
+     http://www.ietf.org/shadow.html
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+
+Abstract
+
+   This document defines a date and time format for use in Internet
+   protocols that is a profile of the ISO 8601 [ISO8601] standard for
+   representation of dates and times using the Gregorian calendar.
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 1]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+Table of Contents
+
+   1. Introduction
+   2. Definitions
+   3. Two Digit Years
+   4. Local Time
+   4.1. Coordinated Universal Time (UTC)
+   4.2. Local Offsets
+   4.3. Unknown Local Offset Convention
+   4.4. Unqualified Local Time
+   5. Date and Time format
+   5.1. Ordering
+   5.2. Human Readability
+   5.3. Rarely Used Options
+   5.4. Redundant Information
+   5.5. Simplicity
+   5.6. Internet Date/Time Format
+   5.7. Restrictions
+   5.8. Examples
+   6. Acknowledgements
+   7. References
+   8. Security Considerations
+   9. Authors' Addresses
+   Appendix A. ISO 8601 Collected ABNF
+   Appendix B. Day of the Week
+   Appendix C. Leap Years
+   Appendix D. Leap Seconds
+   Appendix E. Amendment history
+   Full copyright statement
+
+1. Introduction
+
+   Date and time formats cause a lot of confusion and interoperability
+   problems on the Internet.  This document addresses many of the
+   problems encountered and makes recommendations to improve consistency
+   and interoperability when representing and using date and time in
+   Internet protocols.
+
+   This document includes an Internet profile of the ISO 8601 [ISO8601]
+   standard for representation of dates and times using the Gregorian
+   calendar.
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 2]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+   There are many ways in which date and time values might appear in
+   Internet protocols:  this document focuses on just one common usage,
+   viz. timestamps for Internet protocol events.  This limited
+   consideration has the following consequences:
+
+   o  All dates and times are assumed to be in the "current era",
+      somewhere between 0000AD and 9999AD.
+
+   o  All times expressed have a stated relationship (offset) to
+      Coordinated Universal Time (UTC).  (This is distinct from some
+      usage in scheduling applications where a local time and location
+      may be known, but the actual relationship to UTC may be dependent
+      on the unknown or unknowable actions of politicians or
+      administrators.  The UTC time corresponding to 17:00 on 23rd March
+      2005 in New York may depend on administrative decisions about
+      daylight savings time.  This specification steers well clear of
+      such considerations.)
+
+   o  Timestamps can express times that occurred before the introduction
+      of UTC.  Such timestamps are expressed relative to universal time,
+      using the best available practice at the stated time.
+
+   o  Date and time expressions indicate an instant in time.
+      Description of time periods, or intervals, is not covered here.
+
+
+2. Definitions
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   UTC         Coordinated Universal Time as maintained by the Bureau
+               International des Poids et Mesures (BIPM).
+
+   second      A basic unit of measurement of time in the International
+               System of Units.  It is defined as the duration of
+               9,192,631,770 cycles of microwave light absorbed or
+               emitted by the hyperfine transition of cesium-133 atoms
+               in their ground state undisturbed by external fields.
+
+   minute      A period of time of 60 seconds.  However, see also the
+               restrictions in section 5.7 and Appendix D for how leap
+               seconds are denoted within minutes.
+
+   hour        A period of time of 60 minutes.
+
+
+
+
+
+Newman & Klyne                                                  [Page 3]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+   day         A period of time of 24 hours.
+
+   leap year   In the Gregorian calendar, a year which has 366 days.  A
+               leap year is a year whose number is divisible by four an
+               integral number of times, except that if it is a
+               centennial year (i.e. divisible by one hundred) it shall
+               also be divisible by four hundred an integral number of
+               times.
+
+   ABNF        Augmented Backus-Naur Form, a format used to represent
+               permissible strings in a protocol or language, as defined
+               in [ABNF].
+
+   Email Date/Time Format
+               The date/time format used by Internet Mail as defined by
+               RFC 2822 [IMAIL-UPDATE].
+
+   Internet Date/Time Format
+               The date format defined in section 5 of this document.
+
+   Timestamp   This term is used in this document to refer to an
+               unambiguous representation of some instant in time.
+
+   For more information about time scales, see Appendix E of [NTP],
+   Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF].
+
+
+3. Two Digit Years
+
+   The following requirements are to address the problems of ambiguity
+   of 2-digit years:
+
+   o  Internet Protocols MUST generate four digit years in dates.
+
+   o  The use of 2-digit years is deprecated.  If a 2-digit year is
+      received, it should be accepted ONLY if an incorrect
+      interpretation will not cause a protocol or processing failure
+      (e.g. if used only for logging or tracing purposes).
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as three digits.  This occurs if the program
+      simply subtracts 1900 from the year and doesn't check the number
+      of digits.  Programs wishing to robustly deal with dates generated
+      by such broken software may add 1900 to three digit years.
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 4]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+   o  It is possible that a program using two digit years will represent
+      years after 1999 as ":0", ":1", ... ":9", ";0", ...  This occurs
+      if the program simply subtracts 1900 from the year and adds the
+      decade to the US-ASCII character zero. Programs wishing to
+      robustly deal with dates generated by such broken software should
+      detect non-numeric decades and interpret appropriately.
+
+   The problems with two digit years amply demonstrate why all dates and
+   times used in Internet protocols MUST be fully qualified.
+
+
+4. Local Time
+
+4.1. Coordinated Universal Time (UTC)
+
+   Because the daylight saving rules for local time zones are so
+   convoluted and can change based on local law at unpredictable times,
+   true interoperability is best achieved by using Coordinated Universal
+   Time (UTC).  This specification does not cater to local time zone
+   rules.
+
+4.2. Local Offsets
+
+   The offset between local time and UTC is often useful information.
+   For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local
+   offset provides a useful heuristic to determine the probability of a
+   prompt response.  Attempts to label local offsets with alphabetic
+   strings have resulted in poor interoperability in the past [IMAIL],
+   [HOST-REQ].  As a result, RFC2822 [IMAIL-UPDATE] has made numeric
+   offsets mandatory.
+
+   Numeric offsets are calculated as "local time minus UTC".  So the
+   equivalent time in UTC can be determined by subtracting the offset
+   from the local time.  For example, 18:50:00-04:00 is the same time as
+   22:50:00Z.
+
+
+      NOTE: Following ISO 8601, numeric offsets represent only time
+      zones that differ from UTC by an integral number of minutes.
+      However, many historical time zones differ from UTC by a non-
+      integral number of minutes.  To represent such historical time
+      stamps exactly, applications must convert them to a representable
+      time zone.
+
+
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 5]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+4.3. Unknown Local Offset Convention
+
+   If the time in UTC is known, but the offset to local time is unknown,
+   this can be represented with an offset of "-00:00".  This differs
+   semantically from an offset of "Z" or "+00:00", which imply that UTC
+   is the preferred reference point for the specified time.  RFC2822
+   [IMAIL-UPDATE] describes a similar convention for email.
+
+4.4. Unqualified Local Time
+
+   A number of devices currently connected to the Internet run their
+   internal clocks in local time and are unaware of UTC.  While the
+   Internet does have a tradition of accepting reality when creating
+   specifications, this should not be done at the expense of
+   interoperability.  Since interpretation of an unqualified local time
+   zone will fail in approximately 23/24 of the globe, the
+   interoperability problems of unqualified local time are deemed
+   unacceptable for the Internet.  Systems that are configured with a
+   local time, are unaware of the corresponding UTC offset, and depend
+   on time synchronization with other Internet systems, MUST use a
+   mechanism that ensures correct synchronization with UTC.  Some
+   suitable mechanisms are:
+
+   o  Use Network Time Protocol [NTP] to obtain the time in UTC.
+
+   o  Use another host in the same local time zone as a gateway to the
+      Internet.  This host MUST correct unqualified local times they are
+      transmitted to other hosts.
+
+   o  Prompt the user for the local time zone and daylight saving rule
+      settings.
+
+
+5. Date and Time format
+
+   This section discusses desirable qualities of date and time formats
+   and defines a profile of ISO 8601 for use in Internet protocols.
+
+5.1. Ordering
+
+   If date and time components are ordered from least precise to most
+   precise, then a useful property is achieved.  Assuming that the time
+   zones of the dates and times are the same (e.g. all in UTC),
+   expressed using the same string (e.g. all "Z" or all "+00:00"), and
+   all times have the same number of fractional second digits, then the
+   date and time strings may be sorted as strings (e.g. using the
+   strcmp() function in C) and a time-ordered sequence will result.  The
+   presence of optional punctuation would violate this characteristic.
+
+
+
+Newman & Klyne                                                  [Page 6]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+5.2. Human Readability
+
+   Human readability has proved to be a valuable feature of Internet
+   protocols.  Human readable protocols greatly reduce the costs of
+   debugging since telnet often suffices as a test client and network
+   analyzers need not be modified with knowledge of the protocol.  On
+   the other hand, human readability sometimes results in
+   interoperability problems.  For example, the date format "10/11/1996"
+   is completely unsuitable for global interchange because it is
+   interpreted differently in different countries.  In addition, the
+   date format in [IMAIL] has resulted in interoperability problems when
+   people assumed any text string was permitted and translated the three
+   letter abbreviations to other languages or substituted date formats
+   which were easier to generate (e.g. the format used by the C function
+   ctime).  For this reason, a balance must be struck between human
+   readability and interoperability.
+
+   Because no date and time format is readable according to the
+   conventions of all countries, Internet clients SHOULD be prepared to
+   transform dates into a display format suitable for the locality.
+   This may include translating UTC to local time.
+
+5.3. Rarely Used Options
+
+   A format which includes rarely used options is likely to cause
+   interoperability problems.  This is because rarely used options are
+   less likely to be used in alpha or beta testing, so bugs in parsing
+   are less likely to be discovered.  Rarely used options should be made
+   mandatory or omitted for the sake of interoperability whenever
+   possible.
+
+   The format defined below includes only one rarely used option:
+   fractions of a second.  It is expected that this will be used only by
+   applications which require strict ordering of date/time stamps or
+   which have an unusual precision requirement.
+
+5.4. Redundant Information
+
+   If a date/time format includes redundant information, that introduces
+   the possibility that the redundant information will not correlate.
+   For example, including the day of the week in a date/time format
+   introduces the possibility that the day of week is incorrect but the
+   date is correct, or vice versa.  Since it is not difficult to compute
+   the day of week from a date (see Appendix B), the day of week should
+   not be included in a date/time format.
+
+
+
+
+
+
+Newman & Klyne                                                  [Page 7]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+5.5. Simplicity
+
+   The complete set of date and time formats specified in ISO 8601
+   [ISO8601] is quite complex in an attempt to provide multiple
+   representations and partial representations.  Appendix A contains an
+   attempt to translate the complete syntax of ISO 8601 into ABNF.
+   Internet protocols have somewhat different requirements and
+   simplicity has proved to be an important characteristic.  In
+   addition, Internet protocols usually need complete specification of
+   data in order to achieve true interoperability.  Therefore, the
+   complete grammar for ISO 8601 is deemed too complex for most Internet
+   protocols.
+
+   The following section defines a profile of ISO 8601 for use on the
+   Internet.  It is a conformant subset of the ISO 8601 extended format.
+   Simplicity is achieved by making most fields and punctuation
+   mandatory.
+
+5.6. Internet Date/Time Format
+
+   The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
+   new protocols on the Internet.  This is specified using the syntax
+   description notation defined in [ABNF].
+
+      date-fullyear   = 4DIGIT
+      date-month      = 2DIGIT  ; 01-12
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      time-hour       = 2DIGIT  ; 00-23
+      time-minute     = 2DIGIT  ; 00-59
+      time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second rules
+      time-secfrac    = "." 1*DIGIT
+      time-numoffset  = ("+" / "-") time-hour ":" time-minute
+      time-offset     = "Z" / time-numoffset
+
+      partial-time    = time-hour ":" time-minute ":" time-second
+                        [time-secfrac]
+      full-date       = date-fullyear "-" date-month "-" date-mday
+      full-time       = partial-time time-offset
+
+      date-time       = full-date "T" full-time
+
+
+     NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in
+     this syntax may alternatively be lower case "t" or "z"
+     respectively.
+
+     NOTE: ISO 8601 defines date and time separated by "T".
+     Applications using this syntax may choose, for the sake of
+
+
+
+Newman & Klyne                                                  [Page 8]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+     readability, to specify a full-date and full-time separated by
+     (say) a space character.
+
+
+5.7. Restrictions
+
+   The grammar element date-mday represents the day number within the
+   current month.  The maximum value varies based on the month and year
+   as follows:
+
+      Month Number  Month/Year           Maximum value of date-mday
+      ------------  ----------           --------------------------
+      01            January              31
+      02            February, normal     28
+      02            February, leap year  29
+      03            March                31
+      04            April                30
+      05            May                  31
+      06            June                 30
+      07            July                 31
+      08            August               31
+      09            September            30
+      10            October              31
+      11            November             30
+      12            December             31
+
+   Appendix C contains sample C code to determine if a year is a leap
+   year.
+
+   The grammar element time-second may have the value "60" at the end of
+   months in which a leap second occurs -- to date: June
+   (XXXX-06-30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see
+   Appendix D for a table of leap seconds.  It is also possible for a
+   leap second to be subtracted, at which times the maximum value of
+   time-second is "58".  At all other times the maximum value of
+   time-second is "59".  Further, in time zones other than "Z", the leap
+   second point is shifted by the zone offset (so it happens at the same
+   instant around the globe).
+
+   Leap seconds cannot be predicted far into the future.  The
+   International Earth Rotation Service publishes bulletins [IERS] that
+   announce leap seconds with a few weeks' warning.  Applications should
+   not generate timestamps involving inserted leap seconds until after
+   the leap seconds are announced.
+
+   Although ISO 8601 permits the hour to be "24", this profile of ISO
+   8601 only allows values between "00" and "23" for the hour in order
+   to reduce confusion.
+
+
+
+Newman & Klyne                                                  [Page 9]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+5.8. Examples
+
+   Here are some examples of Internet date/time format.
+
+      1985-04-12T23:20:50.52Z
+
+   This represents 20 minutes and 50.52 seconds after the 23rd hour of
+   April 12th, 1985 in UTC.
+
+      1996-12-19T16:39:57-08:00
+
+   This represents 39 minutes and 57 seconds after the 16th hour of
+   December 19th, 1996 with an offset of -08:00 from UTC (Pacific
+   Standard Time).  Note that this is equivalent to 1996-12-20T00:39:57Z
+   in UTC.
+
+      1990-12-31T23:59:60Z
+
+   This represents the leap second inserted at the end of 1990.
+
+      1990-12-31T15:59:60-08:00
+
+   This represents the same leap second in Pacific Standard Time, 8
+   hours behind UTC.
+
+      1937-01-01T12:00:27.87+00:20
+
+   This represents the same instant of time as noon, January 1, 1937,
+   Netherlands time.  Standard time in the Netherlands was exactly 19
+   minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
+   1937-06-30.  This time zone cannot be represented exactly using the
+   HH:MM format, and this timestamp uses the closest representable UTC
+   offset.
+
+
+
+6. Acknowledgements
+
+   The following people provided helpful advice for an earlier
+   incarnation of this document:  Ned Freed, Neal McBurnett, David
+   Keegel, Markus Kuhn, Paul Eggert and Robert Elz.  Thanks are also due
+   to participants of the IETF Calendaring/Scheduling working group
+   mailing list, and participants of the time zone mailing list.
+
+   The following reviewers contributed helpful suggestions for the
+   present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn.
+   Paul Eggert provided many careful observations regarding the
+   subtleties of leap seconds and time zone offsets.
+
+
+
+Newman & Klyne                                                 [Page 10]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+7. References
+
+   [Zeller]    Chr. Zeller, "Kalender-Formeln", Acta Mathematica, Vol.
+               9, Nov 1886.
+
+   [IMAIL]     Crocker, D., "Standard for the Format of Arpa Internet
+               Text Messages", RFC 822, August 1982.
+
+   [IMAIL-UPDATE]
+               Resnick, P., "Internet Message Format", RFC 2822, April
+               2001.
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [ISO8601]   "Data elements and interchange formats -- Information
+               interchange -- Representation of dates and times", ISO
+               8601:1988(E), International Organization for
+               Standardization, June, 1988.
+
+   [ISO8601:2000]
+               "Data elements and interchange formats -- Information
+               interchange -- Representation of dates and times", ISO
+               8601:2000, International Organization for
+               Standardization, December, 2000.
+
+   [HOST-REQ]  Braden, R., "Requirements for Internet Hosts --
+               Application and Support", RFC 1123, Internet Engineering
+               Task Force, October 1989.
+
+   [IERS]      International Earth Rotation Service Bulletins,
+               <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.
+
+   [NTP]       Mills, D., "Network Time Protocol (Version 3)
+               Specification, Implementation and Analysis", RFC 1305,
+               University of Delaware, March 1992.
+
+   [ITU-R-TF]  International Telecommunication Union Recommendations for
+               Time Signals and Frequency Standards Emissions.
+               <http://www.itu.ch/publications/itu-r/iturtf.htm>
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", RFC 2119, Internet Engineering Task
+               Force, March 1997.
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 11]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+8. Security Considerations
+
+   Since the local time zone of a site may be useful for determining a
+   time when systems are less likely to be monitored and might be more
+   susceptible to a security probe, some sites may wish to emit times in
+   UTC only.  Others might consider this to be loss of useful
+   functionality at the hands of paranoia.
+
+
+9. Authors' Addresses
+
+   Chris Newman
+   Sun Microsystems
+   1050 Lakes Drive, Suite 250
+   West Covina, CA 91790 USA
+
+   Email: cnewman@iplanet.com
+
+   Graham Klyne (editor, this revision)
+   MIMEsweeper Group
+   1310 Waterside
+   Arlington Business Park
+   Theale
+   Reading, RG7 4SA
+   United Kingdom.
+   Telephone: +44 118 903 8000
+   Facsimile: +44 118 903 9000
+   E-mail:    GK@ACM.ORG
+
+
+Appendix A. ISO 8601 Collected ABNF
+
+   This information is based on the 1988 version of ISO 8601.  There may
+   be some changes in the 2000 revision.
+
+   ISO 8601 does not specify a formal grammar for the date and time
+   formats it defines.  The following is an attempt to create a formal
+   grammar from ISO 8601.  This is informational only and may contain
+   errors.  ISO 8601 remains the authoritative reference.
+
+   Note that due to ambiguities in ISO 8601, some interpretations had to
+   be made.  First, ISO 8601 is not clear if mixtures of basic and
+   extended format are permissible.  This grammar permits mixtures.  ISO
+   8601 is not clear on whether an hour of 24 is permissible only if
+   minutes and seconds are 0.  This assumes that an hour of 24 is
+   permissible in any context.  Restrictions on date-mday in section 5.7
+   apply.  ISO 8601 states that the "T" may be omitted under some
+   circumstances.  This grammar requires the "T" to avoid ambiguity.
+
+
+
+Newman & Klyne                                                 [Page 12]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+   ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
+   be proceeded by a "0" if less than unity.  Annex B.2 of ISO 8601
+   gives examples where the decimal fractions are not preceded by a "0".
+   This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is
+   in error.
+
+      date-century    = 2DIGIT  ; 00-99
+      date-decade     =  DIGIT  ; 0-9
+      date-subdecade  =  DIGIT  ; 0-9
+      date-year       = date-decade date-subdecade
+      date-fullyear   = date-century date-year
+      date-month      = 2DIGIT  ; 01-12
+      date-wday       =  DIGIT  ; 1-7  ; 1 is Monday, 7 is Sunday
+      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
+      date-yday       = 3DIGIT  ; 001-365, 001-366 based on year
+      date-week       = 2DIGIT  ; 01-52, 01-53 based on year
+
+      datepart-fullyear = [date-century] date-year ["-"]
+      datepart-ptyear   = "-" [date-subdecade ["-"]]
+      datepart-wkyear   = datepart-ptyear / datepart-fullyear
+
+      dateopt-century   = "-" / date-century
+      dateopt-fullyear  = "-" / datepart-fullyear
+      dateopt-year      = "-" / (date-year ["-"])
+      dateopt-month     = "-" / (date-month ["-"])
+      dateopt-week      = "-" / (date-week ["-"])
+
+      datespec-full     = datepart-fullyear date-month ["-"] date-mday
+      datespec-year     = date-century / dateopt-century date-year
+      datespec-month    = "-" dateopt-year date-month [["-"] date-mday]
+      datespec-mday     = "--" dateopt-month date-mday
+      datespec-week     = datepart-wkyear "W"
+                          (date-week / dateopt-week date-wday)
+      datespec-wday     = "---" date-wday
+      datespec-yday     = dateopt-fullyear date-yday
+
+      date              = datespec-full / datespec-year / datespec-month /
+          datespec-mday / datespec-week / datespec-wday / datespec-yday
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 13]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+   Time:
+
+      time-hour         = 2DIGIT ; 00-24
+      time-minute       = 2DIGIT ; 00-59
+      time-second       = 2DIGIT ; 00-58, 00-59, 00-60 based on leap-second rules
+      time-fraction     = ("," / ".") 1*DIGIT
+      time-numoffset    = ("+" / "-") time-hour [[":"] time-minute]
+      time-zone         = "Z" / time-numoffset
+
+      timeopt-hour      = "-" / (time-hour [":"])
+      timeopt-minute    = "-" / (time-minute [":"])
+
+      timespec-hour     = time-hour [[":"] time-minute [[":"] time-second]]
+      timespec-minute   = timeopt-hour time-minute [[":"] time-second]
+      timespec-second   = "-" timeopt-minute time-second
+      timespec-base     = timespec-hour / timespec-minute / timespec-second
+
+      time              = timespec-base [time-fraction] [time-zone]
+
+      iso-date-time     = date "T" time
+
+   Durations:
+
+      dur-second        = 1*DIGIT "S"
+      dur-minute        = 1*DIGIT "M" [dur-second]
+      dur-hour          = 1*DIGIT "H" [dur-minute]
+      dur-time          = "T" (dur-hour / dur-minute / dur-second)
+      dur-day           = 1*DIGIT "D"
+      dur-week          = 1*DIGIT "W"
+      dur-month         = 1*DIGIT "M" [dur-day]
+      dur-year          = 1*DIGIT "Y" [dur-month]
+      dur-date          = (dur-day / dur-month / dur-year) [dur-time]
+
+      duration          = "P" (dur-date / dur-time / dur-week)
+
+   Periods:
+
+      period-explicit   = date-time "/" date-time
+      period-start      = date-time "/" duration
+      period-end        = duration "/" date-time
+
+      period            = period-explicit / period-start / period-end
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 14]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+Appendix B. Day of the Week
+
+   The following is a sample C subroutine loosely based on Zeller's
+   Congruence [Zeller] which may be used to obtain the day of the week
+   for dates on or after 0000-02-01:
+
+
+      char *day_of_week(int day, int month, int year)
+      {
+          int cent;
+          char *dayofweek[] = {
+              "Sunday", "Monday", "Tuesday", "Wednesday",
+              "Thursday", "Friday", "Saturday"
+          };
+
+          /* adjust months so February is the last one */
+          month -= 2;
+          if (month < 1) {
+              month += 12;
+              --year;
+          }
+          /* split by century */
+          cent = year / 100;
+          year %= 100;
+          return (dayofweek[((26 * month - 2) / 10 + day + year
+                            + year / 4 + cent / 4 - 2 * cent) % 7]);
+      }
+
+
+
+Appendix C. Leap Years
+
+   Here is a sample C subroutine to calculate if a year is a leap year:
+
+
+      /* This returns non-zero if year is a leap year.  Must use 4 digit year.
+       */
+      int leap_year(int year)
+      {
+          return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
+      }
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 15]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+Appendix D. Leap Seconds
+
+   Information about leap seconds can be found at:
+   <http://tycho.usno.navy.mil/leapsec.html>.  In particular, it notes
+   that:
+
+      The decision to introduce a leap second in UTC is the
+      responsibility of the International Earth Rotation Service (IERS).
+      According to the CCIR Recommendation, first preference is given to
+      the opportunities at the end of December and June, and second
+      preference to those at the end of March and September.
+
+   When required, insertion of a leap second occurs as an extra second
+   at the end of a day in UTC, represented by a timestamp of the form
+   YYYY-MM-DDT23:59:60Z.  A leap second occurs simultaneously in all
+   time zones, so that time zone relationships are not affected.  See
+   section 5.8 for some examples of leap second times.
+
+   The following table is an excerpt from the table maintained by the
+   United States Naval Observatory.  The source data is located at:
+
+      <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 16]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+   This table shows the date of the leap second, and the difference
+   between the time standard TAI (which isn't adjusted by leap seconds)
+   and UTC after that leap second.
+
+
+      UTC Date  TAI - UTC After Leap Second
+      --------  ---------------------------
+      1972-06-30     11
+      1972-12-31     12
+      1973-12-31     13
+      1974-12-31     14
+      1975-12-31     15
+      1976-12-31     16
+      1977-12-31     17
+      1978-12-31     18
+      1979-12-31     19
+      1981-06-30     20
+      1982-06-30     21
+      1983-06-30     22
+      1985-06-30     23
+      1987-12-31     24
+      1989-12-31     25
+      1990-12-31     26
+      1992-06-30     27
+      1993-06-30     28
+      1994-06-30     29
+      1995-12-31     30
+      1997-06-30     31
+      1998-12-31     32
+
+
+Appendix E. Amendment history
+
+[[[RFC editor:  please remove this appendix on publication.]]]
+
+
+00a 30-Mar-2001 This document version created from Chris Newman's
+                original as 'draft-ietf-impp-datetime-00.txt'.  Material
+                relating to future times (schedule events) and time zone
+                names has been removed.  Added introductory text setting
+                the scope for this document.  Various small editorial
+                changes.
+
+00b 03-Apr-2001 Added reference [ABNF], and updated citations.  Added
+                comment about possible use of space-separated date/time
+                fields.  Added comment about possible use of lower case
+                "t" and "z" in syntax.  Corrected leap-second examples
+                and noted that leap second point is offset by time zone.
+
+
+
+Newman & Klyne                                                 [Page 17]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+01a 06-Apr-2001 Updated author affiliation and contact details.  Udated
+                leap-second table.
+
+01b 10-May-2001 Clarified provenance of (non-normative) information in
+                appendix A.
+
+02a 11-May-2001 Reference updated email specification (RFC2822).
+
+02b 14-May-2001 Fix up some detailed information concerning leap
+                seconds.  Include text describing timestamps for times
+                before introduction of UTC.  Caution against the use of
+                future timestamps using leap seconds.  Correction to
+                day-of-week sample code, and note restriction on
+                applicability.  Various editorial corrections.
+
+03a 23-May-2001 Editorial fixes.  Minor clarification of leap seconds.
+
+03b 24-May-2001 More clarification of leap seconds and time zones.
+
+03c 25-May-2001 More minor editorial fixes.
+
+04a 03-Jul-2001 Fix off-by-one error in Netherlands example.
+
+05a 03-Jul-2001 Add note requesting that this appendix be removed on RFC
+                publication.  Revised author affiliation.  Add
+                boilerplate and reference for RFC2119 language usage.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 18]
+
+
+
+
+
+Internet Draft         Date and Time - Timestamps          November 2001
+
+
+Full copyright statement
+
+   Copyright (C) The Internet Society 2001.  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Klyne                                                 [Page 19]
+
+
diff --git a/Documentation/en/I-D/draft-ietf-ldapbis-url-01.txt b/Documentation/en/I-D/draft-ietf-ldapbis-url-01.txt
new file mode 100644
index 00000000..809b9703
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-ldapbis-url-01.txt
@@ -0,0 +1,637 @@
+
+
+
+
+
+
+Network Working Group                                Mark Smith, Editor
+Request for Comments: DRAFT               Netscape Communications Corp.
+Obsoletes: RFC 2255                                           Tim Howes
+                                                        Loudcloud, Inc.
+
+                                                            10 May 2001
+
+
+                          The LDAP URL Format
+                    <draft-ietf-ldapbis-url-01.txt>
+
+
+
+1.  Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet- Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   Discussion of this document should take place on the LDAP (v3)
+   Revison (ldapbis) Working Group mailing list <ietf-
+   ldapbis@openldap.org>.  After appropriate review and discussion, this
+   document will be submitted as a Standards Track replacement for RFC
+   2255.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+2.  Abstract
+
+   LDAP is the Lightweight Directory Access Protocol, defined in
+   [RFC2251bis], [RFC2252bis], and [RFC2253bis].  This document
+   describes a format for an LDAP Uniform Resource Locator.  The format
+   describes an LDAP search operation used to retrieve information from
+
+
+
+Smith & Howes      Intended Category: Standards Track           [Page 1]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+   an LDAP directory, or, in the context of an LDAPv3 referral or
+   reference, the format describes a service where an LDAP operation may
+   be progressed.  Note:  not all of the parameters of the LDAP search
+   operation described in [RFC2251bis] can be expressed using the format
+   defined in this document.
+
+   This document specifies the LDAP URL format for version 3 of LDAP and
+   clarifies how LDAP URLs are resolved. This document also defines an
+   extension mechanism for LDAP URLs, so that future documents can
+   extend their functionality, for example, to provide access to new
+   LDAPv3 extensions as they are defined.
+
+   This document replaces RFC 2255. See Appendix A for a list of changes
+   relative to RFC 2255.
+
+   The key words "MUST", "MAY", and "SHOULD" used in this document are
+   to be interpreted as described in [RFC2119].
+
+3.  URL Definition
+
+   An LDAP URL begins with the protocol prefix "ldap" and is defined by
+   the following grammar, following the ABNF notation defined in
+   [RFC2234].
+
+       ldapurl    = scheme "://" [hostport] ["/" dn
+                    ["?" [attributes] ["?" [scope]
+                    ["?" [filter] ["?" extensions]]]]]
+       scheme     = "ldap"
+       hostport   = <hostport from Section 3.2.2 of [RFC2396]>
+       dn         = <distinguishedName from Section 3 of [RFC2253bis]>
+       attributes = attrdesc *("," attrdesc)
+       attrdesc   = <AttributeDescription from Section 4.1.5 of [RFC2251bis]> / "*"
+       scope      = "base" / "one" / "sub"
+       filter     = <filter from Section 4 of [RFC2254bis]>
+       extensions = extension *("," extension)
+       extension  = ["!"] extype ["=" exvalue]
+       extype     = oid / oiddescr
+       exvalue    = <LDAPString from section 4.1.2 of [RFC2251bis]>
+       oid        = <LDAPOID from section 4.1.2 of [RFC2251bis]>
+       oiddescr   = <name from section 3.2 of [LDAP-IANA]>
+
+   The "ldap" prefix indicates an entry or entries residing in the LDAP
+   server running on the given hostname at the given portnumber.
+
+   The dn is an LDAP Distinguished Name using the string format
+   described in [RFC2253bis]. It identifies the base object of the LDAP
+   search or the target of a non-search operation.
+
+
+
+
+Smith & Howes      Intended Category: Standards Track           [Page 2]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+   The attributes construct is used to indicate which attributes should
+   be returned from the entry or entries.  Individual attrdesc names are
+   as defined for AttributeDescription in [RFC2251bis].
+
+   The scope construct is used to specify the scope of the search to
+   perform in the given LDAP server.  The allowable scopes are "base"
+   for a base object search, "one" for a one-level search, or "sub" for
+   a subtree search.
+
+   The filter is used to specify the search filter to apply to entries
+   within the specified scope during the search.  It has the format
+   specified in [RFC2254bis].
+
+   The extensions construct provides the LDAP URL with an extensibility
+   mechanism, allowing the capabilities of the URL to be extended in the
+   future. Extensions are a simple comma-separated list of type=value
+   pairs, where the =value portion MAY be omitted for options not
+   requiring it. Each type=value pair is a separate extension. These
+   LDAP URL extensions are not necessarily related to any of the LDAPv3
+   extension mechanisms. Extensions may be supported or unsupported by
+   the client resolving the URL. An extension prefixed with a '!'
+   character (ASCII 33) is critical. An extension not prefixed with a
+   '!' character is non-critical.
+
+   If an extension is supported by the client, the client MUST obey the
+   extension if the extension is critical. The client SHOULD obey
+   supported extensions that are non-critical.
+
+   If an extension is unsupported by the client, the client MUST NOT
+   process the URL if the extension is critical.  If an unsupported
+   extension is non-critical, the client MUST ignore the extension.
+
+   If a critical extension cannot be processed successfully by the
+   client, the client MUST NOT process the URL. If a non-critical
+   extension cannot be processed successfully by the client, the client
+   SHOULD ignore the extension.
+
+   The extension type (extype) MAY be specified using the oid form
+   (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension).  Use
+   of the oiddesc form SHOULD be restricted to registered object
+   identifier descriptive names.  See [LDAP-IANA] for registration
+   details and usage guidelines for descriptive names.
+
+   No LDAP URL extensions are defined in this document.  Other documents
+   or a future version of this document MAY define other extensions.
+
+   Note that characters that are not safe (e.g., spaces) (as defined in
+   section 2.1 of [RFC2396]), and the single Reserved character '?'
+
+
+
+Smith & Howes      Intended Category: Standards Track           [Page 3]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+   occurring inside a dn, filter, or other element of an LDAP URL MUST
+   be escaped using the % method described in section 2.4 of [RFC2396].
+   If a comma character ',' occurs inside an extension value, the
+   character MUST also be escaped using the % method.
+
+
+4.  Defaults for Fields of the LDAP URL
+
+   Some fields of the LDAP URL are optional, as described above.  In the
+   absence of any other specification, the following general defaults
+   SHOULD be used when a field is absent.  Note:  other documents MAY
+   specify different defaulting rules; for example, section 4.1.11 of
+   [RFC2251bis] specifies a different rule for determining the correct
+   DN to use when it is absent in an LDAP URL that is returned as a
+   referral.
+
+   hostport
+      The default LDAP port is TCP port 389. If no hostport is given,
+      the client must have some apriori knowledge of an appropriate LDAP
+      server to contact.
+
+   dn
+      If no dn is given, the default is the zero-length DN, "".
+
+   attributes
+      If the attributes part is omitted, all user attributes of the
+      entry or entries should be requested (e.g., by setting the
+      attributes field AttributeDescriptionList in the LDAP search
+      request to a NULL list, or (in LDAPv3) by requesting the special
+      attribute name "*").
+
+   scope
+      If scope is omitted, a scope of "base" is assumed.
+
+   filter
+      If filter is omitted, a filter of "(objectClass=*)" is assumed.
+
+   extensions
+      If extensions is omitted, no extensions are assumed.
+
+
+5.  Examples
+
+   The following are some example LDAP URLs using the format defined
+   above.  The first example is an LDAP URL referring to the University
+   of Michigan entry, available from an LDAP server of the client's
+   choosing:
+
+
+
+
+Smith & Howes      Intended Category: Standards Track           [Page 4]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+     ldap:///o=University%20of%20Michigan,c=US
+
+   The next example is an LDAP URL referring to the University of
+   Michigan entry in a particular ldap server:
+
+     ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
+
+   Both of these URLs correspond to a base object search of the
+   "o=University of Michigan,c=US" entry using a filter of
+   "(objectclass=*)", requesting all attributes.
+
+   The next example is an LDAP URL referring to only the postalAddress
+   attribute of the University of Michigan entry:
+
+     ldap://ldap1.example.net/o=University%20of%20Michigan,
+            c=US?postalAddress
+
+   The corresponding LDAP search operation is the same as in the
+   previous example, except that only the postalAddress attribute is
+   requested.
+
+   The next example is an LDAP URL referring to the set of entries found
+   by querying the given LDAP server on port 6666 and doing a subtree
+   search of the University of Michigan for any entry with a common name
+   of "Babs Jensen", retrieving all attributes:
+
+     ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
+            c=US??sub?(cn=Babs%20Jensen)
+
+   The next example is an LDAP URL referring to all children of the c=GB
+   entry:
+
+     ldap://ldap1.example.com/c=GB?objectClass?one
+
+   The objectClass attribute is requested to be returned along with the
+   entries, and the default filter of "(objectclass=*)" is used.
+
+   The next example is an LDAP URL to retrieve the mail attribute for
+   the LDAP entry named "o=Question?,c=US" is given below, illustrating
+   the use of the escaping mechanism on the reserved character '?'.
+
+     ldap://ldap2.example.com/o=Question%3f,c=US?mail
+
+   The next example illustrates the interaction between LDAP and URL
+   quoting mechanisms.
+
+     ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04)
+
+
+
+
+Smith & Howes      Intended Category: Standards Track           [Page 5]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+   The filter in this example uses the LDAP escaping mechanism of \ to
+   encode three zero or null bytes in the value. In LDAP, the filter
+   would be written as (int=\00\00\00\04). Because the \ character must
+   be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
+
+   The following three URLs that are equivalent, assuming that the
+   defaulting rules specified in section 4 of this document are used:
+
+     ldap://ldap.example.net
+     ldap://ldap.example.net/
+     ldap://ldap.example.net/?
+
+   These three URLs all point to the root DSE on the ldap.example.net
+   server.
+
+The final two examples show use of a hypothetical, experimental bind
+name extension (the value associated with the extension is an LDAP DN).
+
+     ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
+     ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
+
+   The two URLs are the same, except that the second one marks the e-
+   bindname extension as critical. Notice the use of the % encoding
+   method to encode the commas within the distinguished name value in
+   the e-bindname extension.
+
+
+6.  Security Considerations
+
+   General URL security considerations discussed in [RFC2396] are
+   relevant for LDAP URLs.
+
+   The use of security mechanisms when processing LDAP URLs requires
+   particular care, since clients may encounter many different servers
+   via URLs, and since URLs are likely to be processed automatically,
+   without user intervention. A client SHOULD have a user-configurable
+   policy about which servers to connect to using which security
+   mechanisms, and SHOULD NOT make connections that are inconsistent
+   with this policy.  If a client chooses to reuse an existing
+   connection when resolving one or more LDAP URL, it MUST ensure that
+   the connection is compatible with the URL and that no security
+   policies are violated.
+
+   Sending authentication information, no matter the mechanism, may
+   violate a user's privacy requirements.  In the absence of specific
+   policy permitting authentication information to be sent to a server,
+   a client should use an anonymous connection.  (Note that clients
+   conforming to previous LDAP URL specifications, where all connections
+
+
+
+Smith & Howes      Intended Category: Standards Track           [Page 6]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+   are anonymous and unprotected, are consistent with this
+   specification; they simply have the default security policy.)  Simply
+   opening a connection to another server may violate some users'
+   privacy requirements, so clients should provide the user with a way
+   to control URL processing.
+
+   Some authentication methods, in particular reusable passwords sent to
+   the server, may reveal easily-abused information to the remote server
+   or to eavesdroppers in transit, and should not be used in URL
+   processing unless explicitly permitted by policy.  Confirmation by
+   the human user of the use of authentication information is
+   appropriate in many circumstances.  Use of strong authentication
+   methods that do not reveal sensitive information is much preferred.
+   If the URL represents a referral for an update operation, strong
+   authentication methods SHOULD be used.  Please refer to the Security
+   Considerations section of [RFC2829bis] for more information.
+
+   The LDAP URL format allows the specification of an arbitrary LDAP
+   search operation to be performed when evaluating the LDAP URL.
+   Following an LDAP URL may cause unexpected results, for example, the
+   retrieval of large amounts of data, the initiation of a long-lived
+   search, etc.  The security implications of resolving an LDAP URL are
+   the same as those of resolving an LDAP search query.
+
+7.  Acknowledgements
+
+   The LDAP URL format was originally defined at the University of
+   Michigan. This material is based upon work supported by the National
+   Science Foundation under Grant No. NCR-9416667. The support of both
+   the University of Michigan and the National Science Foundation is
+   gratefully acknowledged.
+
+   This document is an update to RFC 2255 by Tim Howes and Mark Smith.
+   Changes included in this revised specification are based upon
+   discussions among the authors, discussions within the LDAP (v3)
+   Revision Working Group (ldapbis), and discussions within other IETF
+   Working Groups.  The contributions of individuals in these working
+   groups is gratefully acknowledged.  Several people in particular have
+   made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
+   Kurt Zeilenga, and Jim Sermersheim deserve special thanks for their
+   contributions.
+
+8.  References
+
+   [LDAP-IANA] IETF LDAPBis WG, "IANA Considerations for LDAP", a work
+   in progress.
+
+   [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+
+
+
+Smith & Howes      Intended Category: Standards Track           [Page 7]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+   Requirement Levels," RFC 2119, March 1997.
+
+   [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
+   Specifications:  ABNF", RFC 2234, November 1997.
+
+   [RFC2251bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
+   (v3)", a work in progress.
+
+   [RFC2252bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
+   (v3): Attribute Syntax Definitions", a work in progress.
+
+   [RFC2253bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
+   (v3): UTF-8 String Representation of Distinguished Names", a work in
+   progress.
+
+   [RFC2254bis] IETF LDAPBis WG, "A String Representation of LDAP Search
+   Filters", a work in progress.
+
+   [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+   RFC 2279, January 1998.
+
+   [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
+   Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+   [RFC2829bis] IETF LDAPBis WG, "Authentication Methods for LDAP", a
+   work in progress.
+
+
+9.  Authors' Address
+
+   Mark Smith, Editor
+   Netscape Communications Corp.
+   Mailstop USCA17-201
+   4170 Network Circle
+   Santa Clara, CA 95054
+   USA
+   +1 650 937-3477
+   mcs@netscape.com
+
+   Tim Howes
+   Loudcloud, Inc.
+   599 N. Mathilda Ave.
+   Sunnyvale, CA 94086
+   USA
+   +1 408 744-7509
+   howes@loudcloud.com
+
+
+
+
+
+Smith & Howes      Intended Category: Standards Track           [Page 8]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+11.  Appendix A: Changes Since RFC 2255
+
+11.1.  Technical Changes
+
+   "URL Definition" section: added missing "*" as an alternative for the
+   attrdesc part of the URL.  It is believed that existing
+   implementations of RFC 2255 already support this.  Added angle
+   brackets around free-form prose in the "dn", "hostport", "attrdesc",
+   "filter", and "exvalue" rules.  Changed the ABNF for ldapurl to group
+   the dn component with the preceding slash.  Changed the extype rule
+   to be an LDAPOID from RFC2251bis or an OID description from LDAP-
+   IANA.  Changed the text about extension types so it references LDAP-
+   IANA.  Reordered rules to more closely follow the order the elements
+   appear in the URL.
+
+   "Bindname Extension": removed due to lack of known implementations.
+
+
+
+
+
+
+Smith & Howes      Intended Category: Standards Track           [Page 9]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+11.2.  Editorial Changes
+
+   "Abstract" section: changed the text indicate that RFC 2255 is
+   replaced by this document (instead of RFC 1959).  Added text to
+   indicate that LDAP URLs are used for references and referrals.  Fixed
+   typo (replaced the nonsense phrase "to perform to retrieve" with
+   "used to retrieve").  Added a note to let the reader know that not
+   all of the parameters of the LDAP search operation described in
+   [RFC2251bis] can be expressed using this format.
+
+   IESG Note: removed note about lack of satisfactory mandatory
+   authentication mechanisms.
+
+   "URL Definition" section: removed second copy of ldapurl grammar and
+   following two paragraphs (editorial error in RFC 2255).  Fixed line
+   break within '!' sequence.  Reworded last paragraph to clarify which
+   characters must be URL escaped.   Added text to indicate that LDAP
+   URLs are used for references and referrals.  Added text that refers
+   to the ABNF from RFC 2234.
+
+   "Defaults for Fields of the LDAP URL" section: added; formed by
+   moving text about defaults out of the "URL Definition" section.
+
+   "URL Processing" section: clarified that connections MAY be reused
+   only if the open connection is compatible with the URL.  Added text
+   to indicate that use of security services is encouraged and that they
+   SHOULD be used when updates are involved.  Removed "dn" from
+   discussion of authentication methods.  Added note that the client MAY
+   interrogate the server to determine the most appropriate method.
+
+   "Examples" section: Modified examples to use example.com and
+   example.net hostnames.  Added missing '?' to the LDAP URL example
+   whose filter contains three null bytes.  Removed space after one
+   comma within a DN.  Revised the bindname example to use e-bindname.
+   Added some examples to show URL equivalence with respect to the dn
+   portion of the URL.
+
+   "Security Considerations" section: Added a note about connection
+   reuse.  Added a note about using strong authentication methods for
+   updates.  Added a reference to RFC 2829.  Added note that simply
+   opening a connection may violate some users' privacy requirements.
+
+   "Acknowledgements" section: added statement about this being an
+   update to RFC 2255.  Added added Kurt Zeilenga and Jim Sermersheim.
+
+   "References" section: changed from [1] style to [RFC2251bis] style
+   throughout the document.  Added references to RFCs 2234 and 2829.
+   Updated RFC 1738 references to the appropriate sections within RFC
+
+
+
+Smith & Howes      Intended Category: Standards Track          [Page 10]
+
+INTERNET-DRAFT            The LDAP URL Format                10 May 2001
+
+
+   2396.  Updated the references to refer to LDAPBis WG documents.
+   Added a reference to the LDAP IANA document.
+
+   Header and "Authors' Addresses" sections: added "editor" next to Mark
+   Smith's name.  Updated affiliation and contact information.
+
+   Copyright: updated the year.
+
+   "Table of Contents" section: added.
+
+
+12.  Appendix B: Changes Since Previous Document Revision
+
+   This appendix lists all changes relative to the last published
+   revision, draft-ietf-ldapbis-url-00.txt.  Note that these changes are
+   also included in Appendix A, but are included here for those who have
+   already reviewed draft-ietf-ldapbis-url-00.txt.
+
+
+12.1.  Technical Changes
+
+   "URL Definition" section: changed the ABNF for ldapurl to group the
+   dn component with the preceding slash.  Changed the extype rule to be
+   is an LDAPOID from RFC2251bis or an OID description from LDAP-IANA.
+   Changed the text about extension types so it references LDAP-IANA.
+
+   "Bindname Extension": removed due to lack of known implementations.
+
+
+
+12.2.  Editorial Changes
+
+   "Examples" section: revised the bindname example to use e-bindname
+   and added some examples to show URL equivalence with respect to the
+   dn portion of the URL.
+
+   "Appendix C: Loose Ends": removed this section entirely.
+
+   References: updated references to refer to LDAPBis WG documents.
+   Added a reference to the LDAP IANA document.
+
+
+This Internet Draft expires on 10 November 2001.
+
+
+
+
+
+
+
+
+Smith & Howes      Intended Category: Standards Track          [Page 11]
+
+
+
+1.     Status of this Memo............................................1
+2.     Abstract.......................................................1
+3.     URL Definition.................................................2
+4.     Defaults for Fields of the LDAP URL............................4
+5.     Examples.......................................................4
+6.     Security Considerations........................................6
+7.     Acknowledgements...............................................7
+8.     References.....................................................7
+9.     Authors' Address...............................................8
+10.    Full Copyright Statement.......................................9
+11.    Appendix A: Changes Since RFC 2255.............................9
+11.1.     Technical Changes...........................................9
+11.2.     Editorial Changes...........................................10
+12.    Appendix B: Changes Since Previous Document Revision...........11
+12.1.     Technical Changes...........................................11
+12.2.     Editorial Changes...........................................11
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt b/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt
new file mode 100644
index 00000000..51677c0d
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+T. Hansen: tony@att.com                                                            

+

+

diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-03.txt b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-03.txt
new file mode 100644
index 00000000..2a49b521
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-03.txt
@@ -0,0 +1,954 @@
+
+
+
+
+
+
+Internet Draft                                                 T. Hansen
+draft-ietf-msgtrk-mtqp-03.txt                          AT&T Laboratories
+Valid for six months                                        July 1, 2001
+
+
+
+                    Message Tracking Query Protocol
+
+                    <draft-ietf-msgtrk-mtqp-03.txt>
+
+                         Authors' version: 1.7
+
+     Status of this Memo
+
+     This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC2026.
+
+     Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that other
+groups may also distribute working documents as Internet-Drafts.
+
+     Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other documents at
+any time.  It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+     The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt.
+
+     The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+     This memo and its companions are discussed on the MSGTRK working
+group mailing list, ietf-msgtrk@imc.org.  To subscribe, send a message
+with the word "subscribe" in the body (on a line by itself) to the
+address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
+be found at http://www.ietf.org/archive/msgtrk.
+
+Copyright Notice
+
+     Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+     Customers buying enterprise message systems often ask: Can I track
+the messages?  Message tracking is the ability to find out the path that
+a particular message has taken through a messaging system and the
+current routing status of that message.  This document describes the
+
+
+
+Hansen                                                          [Page 1]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+Message Tracking Query Protocol that is used in conjunction with exten-
+sions to the ESMTP protocol to provide a complete message tracking solu-
+tion for the Internet.
+
+1.  Introduction
+
+     The Message Tracking Models and Requirements document [DRAFT-
+TRACK-MODEL] discusses the models that message tracking solutions could
+follow, along with requirements for a message tracking solution that can
+be used with the Internet-wide message infrastructure.  This memo and
+its companions, [DRAFT-TRACK-ESMTP] and [DRAFT-TRACK-TSN], describe a
+complete message tracking solution that satisfies those requirements.
+The memo [DRAFT-TRACK-ESMTP] defines an extension to the SMTP service
+that provides the information necessary to track messages.  This memo
+defines a protocol that can be used to query the status of messages that
+have been transmitted on the Internet via SMTP.  The memo [DRAFT-TRACK-
+TSN] describes the message/tracking-status MIME media type that is used
+to report tracking status information.  Using the model document's ter-
+minology, this solution uses active enabling and active requests with
+both request and chaining referrals.
+
+1.1.  Terminology
+
+     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in [RFC-KEYWORDS].
+
+     All syntax descriptions use the ABNF specified by [RFC-ABNF].  Ter-
+minal nodes not defined elsewhere in this document are defined in [RFC-
+ABNF], [RFC-URI], [DRAFT-TRACK-ESMTP] or [RFC-SMTPEXT].
+
+1.2.  Changes Made for -02
+
+     This section will be removed before publication.
+
+     Provided information on lookup for an MTQP server: SRV MTQP, then
+MX, then A.
+
+     Provided a section on firewall considerations
+
+     Provided a section on service DNS considerations
+
+     At IANA's request, left the port number as XXXX and added more
+information on the option registry.
+
+     Added text on various error conditions and fixed ABNF for error
+response codes.
+
+
+
+
+Hansen                                                          [Page 2]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     Fleshed out the tracking examples.
+
+2.  Basic Operation
+
+     The Message Tracking Query Protocol (MTQP) is similar to many other
+line-oriented Internet protocols, such as [POP3] and [NNTP].  Initially,
+the server host starts the MTQP service by listening on TCP port XXXX
+(TBD by IANA).
+
+     When an MTQP client wishes to make use of the message tracking ser-
+vice, it establishes a TCP connection with the server host.  To find the
+server host, the MTQP client first does an SRV lookup for the server
+host using DNS SRV records, with a service name of "mtqp".  (See the
+"Usage rules" section in [RFC-SRV] for details.)  If the host is not
+found, the MTQP client then does an MX lookup for the server host using
+DNS MX records, as specified in [RFC-DNS] and revised by [RFC-HOSTS].
+If the host is still not found, the MTQP client then does an A record
+lookup for the server host.
+
+     When the connection is established, the MTQP server sends a greet-
+ing.  The MTQP client and MTQP server then exchange commands and
+responses (respectively) until the connection is closed or aborted.
+
+2.1.  Tracking Service DNS Considerations
+
+     Because of the ways server host lookups are performed, many dif-
+ferent tracking server host configurations are supported.
+
+     A mail system that uses a single mail server host and has the MTQP
+server host on the same server host will most likely have a single MX
+record pointing at the server host, and if not, will have an A record.
+Both mail and MTQP clients will access that host directly.
+
+     A mail system that uses a single mail server host, but wants track-
+ing queries to be performed on a different machine, MUST have an SRV
+MTQP record pointing at that different machine.
+
+     A mail system that uses multiple mail servers has two choices for
+providing tracking services: either all mail servers must be running
+tracking servers that are able to retrieve information on all messages,
+or the tracking service must be performed on one (or more) machine(s)
+that are able to retrieve information on all messages.  In the former
+case, no additional DNS records are needed beyond the MX records already
+in place for the mail system.  In the latter case, SRV MTQP records are
+needed that point at the machine(s) that are running the tracking ser-
+vice.  In both cases, note that the tracking service for a given mail
+domain MUST be able to handle the queries for all messages destined for
+that mail domain.
+
+
+
+Hansen                                                          [Page 3]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+2.2.  Commands
+
+     Commands in MTQP consist of a case-insensitive keyword, possibly
+followed by one or more parameters.  All commands are terminated by a
+CRLF pair.  Keywords and parameters consist of printable ASCII charac-
+ters.  Keywords and parameters are separated by whitespace (one or more
+space or tab characters).  A command line is limited to 998 characters
+before the CRLF.
+
+2.3.  Responses
+
+     Responses in MTQP consist of a status indicator that indicates suc-
+cess or failure.  Successful commands may also be followed by additional
+lines of data.  All response lines are terminated by a CRLF pair and are
+limited to 998 characters before the CRLF.  There are several status
+indicators:  "+OK" indicates success; "+OK+" indicates a success fol-
+lowed by additional lines of data, a multi-line success response; "-
+TEMP" indicates a temporary failure; "-ERR" indicates a permanent
+failure; and "-BAD" indicates a protocol error (such as for unrecognized
+commands).
+
+     A status indicator MAY be followed by a series of machine-
+parseable, case-insensitive response information giving more data about
+the errors.  These are separated from the status indicator and each
+other by a single slash character ("/", decimal code 47).  Following
+that, there MAY be white space and a human-readable text message.  The
+human-readable text message is not intended to be presented to the end
+user, but should be appropriate for putting in a log for use in debug-
+ging problems.
+
+     In a multi-line success response, each subsequent line is ter-
+minated by a CRLF pair and limited to 998 characters before the CRLF.
+When all lines of the response have been sent, a final line is sent con-
+sisting of a single period (".", decimal code 046) and a CRLF pair.  If
+any line of the multi-line response begins with a period, the line is
+"dot-stuffed" by prepending the period with a second period.  When exa-
+mining a multi-line response, the client checks to see if the line
+begins with a period.  If so, and octets other than CRLF follow, the
+first octet of the line (the period) is stripped away.  If so, and if
+CRLF immediately follows the period, then the response from the MTQP
+server is ended and the line containing the ".CRLF" is not considered
+part of the multi-line response.
+
+     An MTQP server MUST respond to an unrecognized, unimplemented, or
+syntactically invalid command by responding with a negative -BAD status
+indicator.  A server MUST respond to a command issued when the session
+is in an incorrect state by responding with a negative -ERR status indi-
+cator.
+
+
+
+Hansen                                                          [Page 4]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+2.4.  Optional Timers
+
+     An MTQP server MAY have an inactivity autologout timer.  Such a
+timer MUST be of at least 10 minutes in duration.  The receipt of any
+command from the client during that interval should suffice to reset the
+autologout timer.  An MTQP server MAY limit the number of commands or
+total connection time to prevent denial of service attacks.
+
+2.5.  Firewall Considerations
+
+     A firewall mail gateway has two choices when receiving a tracking
+query for a host within its domain: it may return a response to the
+query that says the message has been passed on, but no further informa-
+tion is available; or it may perform a chaining operation itself, gath-
+ering information on the message from the mail hosts behind the
+firewall, and returning to the MTQP client the information for each
+behind-the-firewall hop, or possibly just the final hop information,
+possibly also disguising the names of any hosts behind the firewall.
+Which option is picked is an adminstrative decision and is not further
+mandated by this document.
+
+3.  Initialization and Option Response
+
+     Once the TCP connection has been opened by an MTQP client, the MTQP
+server issues an initial status response that indicates its readiness.
+If the status response is positive (+OK or +OK+), the client may proceed
+with other commands.
+
+     The initial status response MUST include the response information
+"/MTQP".  Negative responses MUST include a reason code as response
+information.  The following reason codes are defined here; unrecognized
+reason codes added in the future may be treated as equivalent to "una-
+vailable".
+     "/" "unavailable"
+     "/" "admin"
+
+     The reason code "/admin" may be used when the service is unavail-
+able for administrative reasons.  The reason code "/unavailable" may be
+used when the service is unavailable for other reasons.
+
+     If the server has any options enabled, they are listed as the
+multi-line response of the initial status response, one per line.  An
+option specification consists of an identifier, optionally followed by
+option-specific parameters.  An option specification may be continued
+onto additional lines by starting the continuation lines with white
+space.  The option identifier is case insensitive.  Option identifiers
+beginning with the characters "vnd." are reserved for vendor use.
+
+
+
+
+Hansen                                                          [Page 5]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     One option specification is defined here:
+
+     STARTTLS
+
+This capability MUST be listed if the optional STARTTLS command is sup-
+ported by the MTQP server.  It has no parameters.
+
+     Example #1 (no options):
+     S: +OK/MTQP MTQP server ready
+
+     Example #2 (service temporarily unavailable):
+     S: -TEMP/MTQP/admin Service down for admin, call back later
+
+     Example #3 (service permanently unavailable):
+     S: -ERR/MTQP/unavailable Service down
+
+     Example #4 (alternative for no options):
+     S: +OK+/MTQP MTQP server ready
+     S: .
+
+     Example #5 (options available):
+     S: +OK+/MTQP MTQP server ready
+     S: starttls
+     S: Option2 with parameters
+     S: Option3 with a very long
+     S:  list of parameters
+     S: .
+
+4.  TRACK Command
+
+     Syntax:
+          "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF
+
+          mtrk-secret = base64
+
+     Envid is defined in [DRAFT-TRACK-ESMTP].  Mtrk-secret is the secret
+A described in [DRAFT-TRACK-ESMTP], encoded using base64.
+
+     When the client issues the TRACK command, and the user is vali-
+dated, the MTQP server retrieves tracking information about an email
+message.  To validate the user, the value of mtrk-secret is hashed using
+SHA1, as described in [NIST-SHA1].  The hash value is then compared with
+the value passed with the message when it was originally sent.  If the
+hash values match, the user is validated.
+
+     A successful response MUST be multi-line, consisting of a [MIME]
+body part.  The MIME body part must be of type multipart/related, with
+subparts of message/tracking-status, as defined in [DRAFT-TRACK-TSN].
+
+
+
+Hansen                                                          [Page 6]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+The response contains the tracking information about the email message
+that used the given tracking-id.
+
+
+     In each of the examples below, the envid is "<12345-
+20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B
+is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94".  The message
+came from example.com and the MTQP server is example2.com.
+
+     Example #6 Message Delivered:
+     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
+     S: +OK+ Tracking information follows
+     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
+     S:
+     S: --%%%%
+     S: Content-Type: message/tracking-status
+     S:
+     S: Original-Envelope-Id: 12345-20010101@example.com
+     S: Reporting-MTA: dns; example2.com
+     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
+     S:
+     S: Original-Recipient: rfc822; user1@example1.com
+     S: Final-Recipient: rfc822; user1@example1.com
+     S: Action: delivered
+     S: Status: 2.5.0
+     S:
+     S: --%%%%--
+     S: .
+
+     Example #7 Message Transferred:
+     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
+     S: +OK+ Tracking information follows
+     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
+     S:
+     S: --%%%%
+     S: Content-Type: message/tracking-status
+     S:
+     S: Original-Envelope-Id: 12345-20010101@example.com
+     S: Reporting-MTA: dns; example2.com
+     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
+     S:
+     S: Original-Recipient: rfc822; user1@example1.com
+     S: Final-Recipient: rfc822; user1@example1.com
+     S: Action: transferred
+     S: Remote-MTA: dns; example3.com
+     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
+     S: Status: 2.4.0
+     S:
+
+
+
+Hansen                                                          [Page 7]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     S: --%%%%--
+     S: .
+
+     Example #8 Message Delayed and a DotStuffed Header:
+     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
+     S: +OK+ Tracking information follows
+     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
+     S: ..Dot-Stuffed-Header: as an example
+     S:
+     S: --%%%%
+     S: Content-Type: message/tracking-status
+     S:
+     S: Original-Envelope-Id: 12345-20010101@example.com
+     S: Reporting-MTA: dns; example2.com
+     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
+     S:
+     S: Original-Recipient: rfc822; user1@example1.com
+     S: Final-Recipient: rfc822; user1@example1.com
+     S: Action: delayed
+     S: Status: 4.4.1 (No answer from host)
+     S: Remote-MTA: dns; example3.com
+     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
+     S: Will-Retry-Until: Thu,  4 Jan 2001 15:15:15 -0500
+     S:
+     S: --%%%%--
+     S: .
+
+     Example #9 Two Users, One Relayed, One Failed:
+     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
+     S: +OK+ Tracking information follows
+     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
+     S:
+     S: --%%%%
+     S: Content-Type: message/tracking-status
+     S:
+     S: Original-Envelope-Id: 12345-20010101@example.com
+     S: Reporting-MTA: dns; example2.com
+     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
+     S:
+     S: Original-Recipient: rfc822; user1@example1.com
+     S: Final-Recipient: rfc822; user1@example1.com
+     S: Action: relayed
+     S: Status: 2.1.9
+     S: Remote-MTA: dns; example3.com
+     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
+     S:
+     S: Original-Recipient: rfc822; user2@example1.com
+     S: Final-Recipient: rfc822; user2@example1.com
+
+
+
+Hansen                                                          [Page 8]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     S: Action: failed
+     S: Status 5.2.2 (Mailbox full)
+     S: Remote-MTA: dns; example3.com
+     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
+     S:
+     S: --%%%%--
+     S: .
+
+     Example #10 Firewall, Hiding System Names Behind the Firewall:
+     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
+     S: +OK+ Tracking information follows
+     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
+     S:
+     S: --%%%%
+     S: Content-Type: message/tracking-status
+     S:
+     S: Original-Envelope-Id: 12345-20010101@example.com
+     S: Reporting-MTA: dns; example2.com
+     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
+     S:
+     S: Original-Recipient: rfc822; user1@example1.com
+     S: Final-Recipient: rfc822; user1@example1.com
+     S: Action: relayed
+     S: Status: 2.1.9
+     S: Remote-MTA: dns; example2.com
+     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
+     S:
+     S: --%%%%
+     S: Content-Type: message/tracking-status
+     S:
+     S: Original-Envelope-Id: 12345-20010101@example.com
+     S: Reporting-MTA: dns; example2.com
+     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
+     S:
+     S: Original-Recipient: rfc822; user1@example1.com
+     S: Final-Recipient: rfc822; user1@example1.com
+     S: Action: delivered
+     S: Status: 2.5.0
+     S:
+     S: --%%%%--
+     S: .
+
+5.  COMMENT Command
+
+     Syntax:
+          "COMMENT" opt-text CRLF
+
+          opt-text = [WSP *(VCHAR / WSP)]
+
+
+
+Hansen                                                          [Page 9]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     When the client issues the COMMENT command, the MTQP server MUST
+respond with a successful response (+OK or +OK+).  All optional text
+provided with the COMMENT command are ignored.
+
+6.  STARTTLS Command
+
+     Syntax:
+          "STARTTLS" CRLF
+
+     TLS [TLS], more commonly known as SSL, is a popular mechanism for
+enhancing TCP communications with privacy and authentication.  An MTQP
+server MAY support TLS.  If an MTQP server supports TLS, it MUST include
+"STARTTLS" in the option specifications list on protocol startup.
+
+     If the server returns a negative response, it MAY use one of the
+following response codes:
+     "/" "unsupported"
+     "/" "unavailable"
+
+     If a TLS session is already in progress, then it is a protocol
+error and "-BAD" MUST be returned with a response code of "/tlsinpro-
+gress".
+
+     After receiving a positive response to a STARTTLS command, the
+client MUST start the TLS negotiation before giving any other MTQP com-
+mands.
+
+     If the MTQP client is using pipelining, the STARTTLS command must
+be the last command in a group.
+
+6.1.  Processing After the STARTTLS Command
+
+     If the TLS handshake fails, the server SHOULD abort the connection.
+
+     After the TLS handshake has been completed, both parties MUST
+immediately decide whether or not to continue based on the authentica-
+tion and privacy achieved. The MTQP client and server may decide to move
+ahead even if the TLS negotiation ended with no authentication and/or no
+privacy because most MTQP services are performed with no authentication
+and no privacy, but some MTQP clients or servers may want to continue
+only if a particular level of authentication and/or privacy was
+achieved.
+
+     If the MTQP client decides that the level of authentication or
+privacy is not high enough for it to continue, it SHOULD issue an MTQP
+QUIT command immediately after the TLS negotiation is complete.  If the
+MTQP server decides that the level of authentication or privacy is not
+high enough for it to continue, it SHOULD reply to every MTQP command
+
+
+
+Hansen                                                         [Page 10]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+from the client (other than a QUIT command) with a negative "-ERR"
+response and a response code of "/insecure".
+
+6.2.  Result of the STARTTLS Command
+
+     Upon completion of the TLS handshake, the MTQP protocol is reset to
+the initial state (the state in MTQP after a server starts up).  The
+server MUST discard any knowledge obtained from the client prior to the
+TLS negotiation itself. The client MUST discard any knowledge obtained
+from the server, such as the list of MTQP options, which was not
+obtained from the TLS negotiation itself.
+
+     At the end of the TLS handshake, the server acts as if the connec-
+tion had been initiated and responds with an initial status response
+and, optionally, a list of server options.  The list of MTQP server
+options received after the TLS handshake MUST be different than the list
+returned before the TLS handshake.  In particular, a server MUST NOT
+return the STARTTLS option in the list of server options after a TLS
+handshake has completed.
+
+     Both the client and the server MUST know if there is a TLS session
+active.  A client MUST NOT attempt to start a TLS session if a TLS ses-
+sion is already active.
+
+7.  QUIT Command
+
+     Syntax:
+          "QUIT" CRLF
+
+     When the client issues the QUIT command, the MTQP session ter-
+minates.  The QUIT command has no parameters.  The server MUST respond
+with a successful response.  The client may close the session from its
+end immediately after issuing this command.
+
+8.  Pipelining
+
+     The MTQP client may elect to transmit groups of MTQP commands in
+batches without waiting for a response to each individual command.  The
+MTQP server MUST process the commands in the order received.
+
+     Specific commands may place further constraints on pipelining.  For
+example, STARTTLS must be the last command in a batch of MTQP commands.
+
+     The following two examples are identical:
+
+     Example #11 :
+     C: TRACK <tracking-id> YWJjZGVmZ2gK
+     S: +OK+ Tracking information follows
+
+
+
+Hansen                                                         [Page 11]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     S:
+     S: ... tracking details #1 go here ...
+     S: .
+     C: TRACK <tracking-id-2> QUJDREVGR0gK
+     S: +OK+ Tracking information follows
+     S:
+     S: ... tracking details #2 go here ...
+     S: .
+
+     Example #12 :
+     C: TRACK <tracking-id> YWJjZGVmZ2gK
+     C: TRACK <tracking-id-2> QUJDREVGR0gK
+     S: +OK+ Tracking information follows
+     S:
+     S: ... tracking details #1 go here ...
+     S: .
+     S: +OK+ Tracking information follows
+     S:
+     S: ... tracking details #2 go here ...
+     S: .
+
+9.  URL Format
+
+     The MTQP URL scheme is used to designate MTQP servers on Internet
+hosts accessible using the MTQP protocol.  An MTQP URL takes one of the
+following forms:
+
+     mtqp://<mserver>/track/<envid>/<mtrk-secret>
+     mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret>
+
+     The first form is used to refer to an MTQP server on the standard
+port, while the second form specifies a non-standard port.  Both of
+these forms specify that the TRACK command is to be issued using the
+given tracking id and authorization cookie.  The path element "/track/"
+is case insensitive, but the envid and mtrk-secret may not be.
+
+9.1.  MTQP URL Syntax
+
+     This is an ABNF description of the MTQP URL.
+
+     mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret
+
+10.  IANA Considerations
+
+     System port number XXXX - TBA by IANA
+
+     The service name to be registered with the Internet Assigned Number
+Authority (IANA) is "MTQP".
+
+
+
+Hansen                                                         [Page 12]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     This document requests that IANA maintain one new registry: MTQP
+options.  The registry's purpose is to register options to this proto-
+col.  Options whose names do not begin with "vnd." MUST be defined in a
+standards track or IESG approved experimental RFC.  New MTQP options
+MUST include the following information as part of their definition:
+
+     option identifier
+     option parameters
+     added commands
+     standard commands affected
+     specification reference
+     discussion
+
+     Additional vendor-specific options for this protocol whose names
+begin with "vnd."  MUST be registered with IANA on a Firt Come First
+Served basis.  It is expected that after the "vnd." would appear an
+abbreviated form of the vendor's name that is registering the option,
+followed by a second dot "." and a name for the option itself.  For
+example, "vnd.example.extinfo" might represent a vendor-specific exten-
+sion providing extended information being registered by the "Example,
+Inc." company.
+
+11.  Security Considerations
+
+     If the originator of a message were to delegate his or her tracking
+request to a third party, this would be vulnerable to snooping over
+unencrypted sessions.  The user can decide on a message-by-message basis
+if this risk is acceptable.
+
+     The security of tracking information is dependent on the randomness
+of the secret chosen for each message and the level of exposure of that
+secret.  If different secrets are used for each message, then the max-
+imum exposure from tracking any message will be that single message for
+the time that the tracking information is kept on any MTQP server.  If
+this level of exposure is too much, TLS may be used to reduce the expo-
+sure further.
+
+     It should be noted that message tracking is not an end-to-end
+mechanism.  Thus, if an MTQP client/server pair decide to use TLS
+privacy, they are not securing tracking queries with any prior or suc-
+cessive MTQP servers.
+
+     Both the STMP client and server must check the result of the TLS
+negotiation to see whether acceptable authentication or privacy was
+achieved.  Ignoring this step completely invalidates using TLS for secu-
+rity.  The decision about whether acceptable authentication or privacy
+was achieved is made locally, is implementation-dependant, and is beyond
+the scope of this document.
+
+
+
+Hansen                                                         [Page 13]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     The SMTP client and server should note carefully the result of the
+TLS negotiation.  If the negotiation results in no privacy, or if it
+results in privacy using algorithms or key lengths that are deemed not
+strong enough, or if the authentication is not good enough for either
+party, the client may choose to end the MTQP session with an immediate
+QUIT command, or the server may choose to not accept any more MTQP com-
+mands.
+
+     A man-in-the-middle attack can be launched by deleting the
+"STARTTLS" option response from the server.  This would cause the client
+not to try to start a TLS session.  An MTQP client can protect against
+this attack by recording the fact that a particular MTQP server offers
+TLS during one session and generating an alarm if it does not appear in
+an option response for a later session.
+
+     If TLS is not used, a tracking request is vulnerable to replay
+attacks, such that a snoop can later replay the same handshake again to
+potentially gain more information about a message's status.
+
+     Before the TLS handshake has begun, any protocol interactions are
+performed in the clear and may be modified by an active attacker.  For
+this reason, clients and servers MUST discard any knowledge obtained
+prior to the start of the TLS handshake upon completion of the TLS
+handshake.
+
+     If a client/server pair successfully performs a TLS handshake and
+the server does chaining referrals, then the server SHOULD attempt to
+negotiate TLS at the same security level at the next hop.  In a hop-by-
+hop scenario, STARTTLS is a request for "best effort" security and
+should be treated as such.
+
+     SASL is not used because authentication is per message rather than
+per user.
+
+12.  Protocol Syntax
+
+     This is a collected ABNF description of the MTQP protocol.
+     conversation = command-response *( client-command command-response )
+
+     # client side
+     client-command = track-command / starttls-command / quit-command / comment-command
+
+     track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF
+
+     mtrk-secret = base64
+
+     starttls-command = "STARTTLS" CRLF
+
+
+
+
+Hansen                                                         [Page 14]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     quit-command = "QUIT" CRLF
+
+     comment-command = "COMMENT" opt-text CRLF
+
+     # server side
+     command-response = success-response / temp-response / error-response / bad-response
+
+     temp-response = "-TEMP" response-info opt-text CRLF
+
+     opt-text = [WSP *(VCHAR / WSP)]
+
+     error-response = "-ERR" response-info opt-text CRLF
+
+     bad-response = "-BAD" response-info opt-text CRLF
+
+     success-response = single-line-success / multi-line-success
+
+     single-line-success = "+OK" response-info opt-text CRLF
+
+     multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf
+
+     dataline = *998OCTET CRLF
+
+     dotcrlf = "." CRLF
+
+     option-list = *option-line
+
+     option-line = identifier opt-text *[CRLF WSP opt-text] CRLF
+
+     identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_")
+
+     response-info = *( "/" 1*(ALPHA / DIGIT / "-" / "_")
+
+
+13.  Acknowledgements
+
+     The description of STARTTLS is based on [RFC-SMTP-TLS].
+
+14.  References
+
+     [NIST-SHA1] NIST FIPS  PUB  180-1, "Secure  Hash  Standard",
+National Institute of Standards and Technology, U.S. Department of Com-
+merce, May 1994.
+
+     [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet
+Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
+Innosoft, First Virtual, November 1996.
+
+
+
+
+Hansen                                                         [Page 15]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+     [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto-
+col", University of Southern California / Information Sciences Insti-
+tute, August 1982.
+
+     [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of
+ARPA Internet Text Messages", University of Delaware, August 1982.
+
+     [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
+BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Demon
+Internet Ltd., November 1997.
+
+     [RFC-DNS] RFC 974, "Mail routing and the domain system", C. Par-
+tridge, January 1986.
+
+     [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud,
+and D. Crocker, "SMTP Service Extensions", MCI, Innosoft, Dover Beach
+Consulting, Inc., network Management Associates, Inc., Silicon Graphics,
+Inc., July 1994.
+
+     [RFC-HOSTS] "Requirements for Internet Hosts - Application and Sup-
+port", R. Braden, Ed., October 1989.
+
+     [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to
+Indicate Requirement Levels", Harvard University, March 1997.
+
+     [RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm",
+MIT Laboratory for Computer Science and RSA Data Security, Inc., April
+1992.
+
+     [RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for
+Authentication", Netscape Communications, March 1999.
+
+     [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for
+Secure SMTP over TLS", Internet Mail Consortium, January 1999.
+
+     [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR
+for specifying the location of services (DNS SRV)" Troll Technologies,
+Internet Software Consortium, Microsoft Corp., February 2000
+
+     [DRAFT-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T.
+Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc.,
+AT&T Laboratories, TBD 2000.
+
+     [DRAFT-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen,
+"Message Tracking Models and Requirements", AT&T Laboratories, November
+2000.
+
+     [DRAFT-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
+
+
+
+Hansen                                                         [Page 16]
+
+Internet Draft      Message Tracking Query Protocol         July 1, 2001
+
+
+Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000.
+
+     [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
+form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine,
+Xerox Corporation, August 1998.
+
+15.  Author's Address
+
+     Tony Hansen
+     AT&T Laboratories
+     Lincroft, NJ 07738
+     USA
+
+     Phone: +1.732.576.3207
+     E-Mail: tony@att.com
+
+16.  Full Copyright Statement
+
+     Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+     This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it or
+assist in its implmentation may be prepared, copied, published and dis-
+tributed, in whole or in part, without restriction of any kind, provided
+that the above copyright notice and this paragraph are included on all
+such copies and derivative works.  However, this document itself may not
+be modified in any way, such as by removing the copyright notice or
+references to the Internet Society or other Internet organisations,
+except as needed for the purpose of developing Internet standards in
+which case the procedures for copyrights defined in the Internet Stan-
+dards process must be followed, or as required to translate it into
+languages other than English.
+
+     The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+     This document and the information contained herein is provided on
+an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
+NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
+NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
+FITNESS FOR A PARTICULAR PURPOSE.
+
+     This document expires January 1, 2002.
+
+
+
+
+
+
+
+Hansen                                                         [Page 17]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-02.txt b/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-02.txt
new file mode 100644
index 00000000..4c3edb74
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-02.txt
@@ -0,0 +1,434 @@
+
+
+
+
+Internet Draft                                               E. Allman
+draft-ietf-msgtrk-smtpext-02.txt                        Sendmail, Inc.
+Valid for six months                                         T. Hansen
+Updates: RFC 1891                                    AT&T Laboratories
+                                                          July 6, 2001
+
+
+
+
+                        SMTP Service Extension
+                         for Message Tracking
+
+                  <draft-ietf-msgtrk-smtpext-02.txt>
+
+Status of This Memo
+
+     This  document  is  an  Internet-Draft and is in full conformance
+with all provisions of Section 10  of  RFC2026.   Internet-Drafts  are
+working  documents  of the Internet Engineering Task Force (IETF), its
+areas, and its working groups.  Note that other groups may  also  dis-
+tribute working documents as Internet-Drafts.
+
+     Internet-Drafts  are  draft  documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by  other  documents
+at  any time.  It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+     The list of current Internet-Drafts can be accessed at:
+
+    http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at:
+
+    http://www.ietf.org/shadow.html
+
+
+     This document is a submission by the MSGTRK Working Group of  the
+Internet  Engineering Task Force (IETF).  Comments should be submitted
+to the ietf-msgtrk@imc.org mailing list.  An archive  of  the  mailing
+list may be found at
+
+    http://www.imc.org/ietf-msgtrk/index.html
+
+
+     Distribution of this memo is unlimited.
+
+
+1.  Abstract
+
+        This  memo  defines an extension to the SMTP service whereby a
+   client may mark a message for future tracking.
+
+Internet Draft     Message Tracking ESMTP Extension       July 6, 2001
+
+
+2.  Other Documents and Conformance
+
+        The model used for Message Tracking is  described  in  [DRAFT-
+   MTRK-MODEL].
+
+        Doing  a Message Tracking query is intended as a "last resort"
+   mechanism.  Normally, Delivery Status  Notifications  (DSNs)  [RFC-
+   DSN-SMTP]  and  Message  Disposition Notifications (MDNs) [RFC-MDN]
+   would provide the primary delivery status.  Only if the message  is
+   not  received,  or there is no response from either of these mecha-
+   nisms should a Message Tracking query be issued.
+
+        The definition of the base64 token is  imported  from  section
+   6.8 of [RFC-MIME].
+
+        Syntax notation in this document conforms to [RFC-ABNF].
+
+        The  key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL"
+   in  this  document  are  to be interpreted as described in RFC 2119
+   [RFC-KEYWORDS].
+
+
+3.  SMTP Extension Overview
+
+        The Message Tracking SMTP service extension uses the SMTP ser-
+   vice  extension  mechanism described in [RFC-ESMTP].  The following
+   service extension is hereby defined:
+
+    (1)   The name of the SMTP service extension  is  "Message  Track-
+          ing".
+
+    (2)   The  EHLO  keyword  value  associated with this extension is
+          "MTRK".
+
+    (3)   No parameters are allowed  with  this  EHLO  keyword  value.
+          Future documents may extend this specification by specifying
+          options.
+
+    (4)   One optional parameter using the keyword "MTRK" is added  to
+          the  MAIL  FROM  command.   In addition, the ENVID and ORCPT
+          parameters (as defined in RFC  1891  sections  5.4  and  5.2
+          respectively)   MUST   be   supported,  with  extensions  as
+          described below.
+
+    (5)   The maximum length of a MAIL FROM command line is  increased
+          by  40  characters by the possible addition of the MTRK key-
+          word and value.  Note that a further extension of 614  char-
+          acters  for  the  ORCPT  and ENVID parameters is required by
+          [RFC-DSN-EXT].
+
+    (6)   No SMTP verbs are defined by this extension.
+
+
+
+
+
+
+Allman & Hansen                                               [Page 2]
+
+Internet Draft     Message Tracking ESMTP Extension       July 6, 2001
+
+
+4.  The Extended MAIL FROM Command
+
+        The extended MAIL FROM command is issued  by  an  SMTP  client
+   when  it  wishes  to  inform  an  SMTP server that message tracking
+   information should be retained for future querying.   The  extended
+   MAIL  FROM command is identical to the MAIL FROM command as defined
+   in [RFC-SMTP], except that MTRK, ORCPT, and ENVID parameters appear
+   after the address.
+
+   4.1.  The MTRK parameter to the ESMTP MAIL command
+
+           Any  sender  wishing to track a message must first tag that
+      message as trackable by creating two values A and B:
+
+          A = some-large-random-number
+          B = SHA1(A)
+
+      The large random number A  is  calculated  on  a  host-dependent
+      basis.   See [RFC-RANDOM] for a discussion of choosing good ran-
+      dom numbers.  This random number MUST be at least 128  bits  but
+      MUST NOT be more than 1024 bits.
+
+           The  128-bit  hash  B of A is then computed using the SHA-1
+      algorithm as described in [NIST-SHA1].
+
+           The sender then base64 encodes  value  B  and  passes  that
+      value as the mtrk-certifier on the MAIL FROM command:
+
+          mtrk-parameter  = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
+          mtrk-certifier  = base64        ; authenticator
+          mtrk-timeout    = 1*9digit      ; seconds until timeout
+
+
+           A  is stored in the originator's tracking database to vali-
+      date future tracking requests as described in [DRAFT-MTRK-MTQP].
+      B  is stored in tracking databases of compliant MTAs and used to
+      authenticate future tracking requests.
+
+           The mtrk-timeout field indicates the number of seconds that
+      the  client  requests that this tracking information be retained
+      on intermediate servers, as measured from the initial receipt of
+      the message at that server.  Servers MAY ignore this value if it
+      violates local policy.   In  particular,  servers  MAY  silently
+      enforce  an  upper  limit  to how long they will retain tracking
+      data; this limit MUST be at least one day.
+
+           If no mtrk-timeout  field  is  specified  then  the  server
+      should  use  a  local default.  This default SHOULD be 8-10 days
+      and MUST be at least one day.  Notwithstanding this clause,  the
+      information MUST NOT be expired while the message remains in the
+      queue for this server: that is, an MTQP  server  MUST  NOT  deny
+      knowledge  of  a message while that same message sits in the MTA
+      queue.
+
+           If the message is relayed to another compliant SMTP server,
+      the  MTA  acting as the client SHOULD pass an mtrk-timeout field
+
+
+Allman & Hansen                                               [Page 3]
+
+Internet Draft     Message Tracking ESMTP Extension       July 6, 2001
+
+
+      equal to the remaining life of that  message  tracking  informa-
+      tion.   Specifically, the tracking timeout is decremented by the
+      number of seconds the message has lingered at this MTA and  then
+      passed  to the next MTA.  If the decremented tracking timeout is
+      less than or equal to zero, the entire MTRK parameter  MUST  NOT
+      be passed to the next MTA; essentially, the entire tracking path
+      is considered to be lost at that point.
+
+           See [RFC-DELIVERYBY] section 4 for an explanation of why  a
+      timeout is used instead of an absolute time.
+
+   4.2.  Use of ENVID
+
+           To  function  properly, Message Tracking requires that each
+      message have a unique identifier that is  never  reused  by  any
+      other  message.   For  that  purpose,  if  the MTRK parameter is
+      given, an ENVID parameter MUST be included, and  the  syntax  of
+      ENVID from RFC 1891 section 5.4 is extended as follows:
+
+          envid-parameter = "ENVID=" unique-envid
+          unique-envid    = local-envid "@" fqhn
+          local-envid     = xtext
+          fqhn            = xtext
+
+      The  unique-envid  MUST  be  chosen  in such a way that the same
+      ENVID will never be used by any other  message  sent  from  this
+      system  or  any other system.  In most cases, this means setting
+      fqhn to be the fully qualified host name of the system  generat-
+      ing  this  ENVID, and local-envid to an identifier that is never
+      re-used by that host.
+
+           Any resubmissions of this message into the  message  trans-
+      mission  system  MUST  assign  a  new  ENVID.   In this context,
+      "resubmission" includes forwarding or resending a message from a
+      user  agent, but does not include MTA-level aliasing or forward-
+      ing where the message does not leave and  re-enter  the  message
+      transmission system.
+
+   4.3.  Forwarding Tracking Certifiers
+
+           MTAs  SHOULD  forward unexpired tracking certifiers to com-
+      pliant mailers as the mail is transferred during regular hop-to-
+      hop  transfers.   If the "downstream" MTA is not MTRK-compliant,
+      then the MTRK= parameter MUST be deleted.  If the downstream MTA
+      is  DSN-compliant,  then the ENVID and ORCPT parameters MUST NOT
+      be deleted.
+
+           If aliasing, forwarding, or other redirection  of  messages
+      to  a single recipient occurs, then the MTA SHOULD treat this as
+      an ordinary hop-to-hop transfer and forward the  MTRK=,  ENVID=,
+      and ORCPT= values; these values MUST NOT be modified.
+
+           MTAs  MUST NOT copy MTRK certifiers when relaying a message
+      to multiple recipients.  An MTA MAY designate one recipient in a
+      multi-recipient alias as the "primary" recipient to which track-
+      ing requests shall  be  forwarded;  other  addresses  SHALL  NOT
+
+
+Allman & Hansen                                               [Page 4]
+
+Internet Draft     Message Tracking ESMTP Extension       July 6, 2001
+
+
+      receive  tracking certifiers.  MTAs MUST NOT forward MTRK certi-
+      fiers when doing mailing list expansion.
+
+
+5.  Security Issues
+
+   5.1.  Denial of service
+
+           An attacker could attempt to flood the database of a server
+      by submitting large numbers of small, tracked messages.  In this
+      case, a site may elect to lower  its  maximum  retention  period
+      retroactively.
+
+   5.2.  Confidentiality
+
+           The  mtrk-authenticator  value (``A'') must be hard to pre-
+      dict and not reused.
+
+           The originating client must take reasonable precautions  to
+      protect  the  secret.  For example, if the secret is stored in a
+      message store (e.g., a "Sent" folder), the client must make sure
+      the  secret  isn't  accessible  by  attackers, particularly on a
+      shared store.
+
+           Many site administrators believe that concealing names  and
+      topologies  of  internal  systems  and  networks is an important
+      security feature.  MTAs need to balance such  desires  with  the
+      need to provide adequate tracking information.
+
+           In  some cases site administrators may want to treat deliv-
+      ery to an alias as final delivery in  order  to  separate  roles
+      from  individuals.   For  example, sites implementing ``postmas-
+      ter'' or ``webmaster'' as aliases may not  wish  to  expose  the
+      identity  of  those  individuals  by permitting tracking through
+      those aliases.  In other cases, providing the tracking  informa-
+      tion for an alias is important, such as when the alias points to
+      the user's preferred public address.
+
+6.  References
+
+   [DRAFT-MTRK-MODEL]
+        T.  Hansen,  ``Message  Tracking  Model  and   Requirements.''
+        draft-ietf-msgtrk-model-03.txt.  November 2000.
+
+   [DRAFT-MTRK-MTQP]
+        T.  Hansen,  ``Message Tracking Query Protocol.''  draft-ietf-
+        msgtrk-mtqp-01.txt.  November 2000.
+
+   [RFC-ABNF]
+        Crocker, D., Editor, and P. Overell, ``Augmented BNF for  Syn-
+        tax Specifications: ABNF'', RFC 2234, November 1997.
+
+   [RFC-DELIVERYBY]
+        D.  Newman,  ``Deliver By SMTP Service Extension.''  RFC 2852.
+        June 2000.
+
+
+
+Allman & Hansen                                               [Page 5]
+
+Internet Draft     Message Tracking ESMTP Extension       July 6, 2001
+
+
+   [RFC-DSN-REPT]
+        G. Vaudreuil, ``The  Multipart/Report  Content  Type  for  the
+        Reporting of Mail System Administrative Messages.''  RFC 1892.
+        January 1996.
+
+   [RFC-DSN-SMTP]
+        K. Moore, ``SMTP Service Extension for Delivery Status Notifi-
+        cations.''  RFC 1891.  January 1996.
+
+   [RFC-DSN-STAT]
+        K.  Moore and G. Vaudreuil, ``An Extensible Message Format for
+        Delivery Status Notifications.''  RFC 1894.  January 1996.
+
+   [RFC-EMSSC]
+        G. Vaudreuil, ``Enhanced  Mail  System  Status  Codes.''   RFC
+        1893.  January 1996.
+
+   [RFC-ESMTP]
+        Rose,  M.,  Stefferud,  E.,  Crocker,  D.,  Klensin, J. and N.
+        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.  Novem-
+        ber 1995.
+
+   [RFC-KEYWORDS]
+        S.  Bradner,  ``Key words for use in RFCs to Indicate Require-
+        ment Levels.''  RFC 2119.  March 1997.
+
+   [RFC-MDN]
+        R. Fajman, ``An Extensible Message Format for Message Disposi-
+        tion Notifications.''  RFC 2298.  March 1998.
+
+   [RFC-MIME]
+        N.  Freed  and  N.  Borenstein,  ``Multipurpose  Internet Mail
+        Extensions (MIME) Part One: Format of  Internet  Message  Bod-
+        ies.''  RFC 2045.  November 1996.
+
+   [RFC-MSGFMT]
+        D.  Crocker,  ``Standard  for the Format of ARPA Internet Text
+        Messages.''  RFC 822.  August 1982.
+
+   [RFC-RANDOM]
+        D. Eastlake, S. Crocker, and J. Schiller, ``Randomness  Recom-
+        mendations for Security.''  RFC 1750.  December 1994.
+
+   [RFC-RELATED]
+        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
+        2387.  August 1998.
+
+   [NIST-SHA1]
+        NIST FIPS  PUB  180-1,  ``Secure  Hash  Standard.''   National
+        Institute of Standards and Technology, U.S. Department of Com-
+        merce.  May 1994.  DRAFT.
+
+   [RFC-SMTP]
+        J. Postel,  ``Simple  Mail  Transport  Protocol.''   RFC  821.
+        August 1982.
+
+
+
+Allman & Hansen                                               [Page 6]
+
+Internet Draft     Message Tracking ESMTP Extension       July 6, 2001
+
+
+7.  Authors' Addresses
+
+       Eric Allman
+       Sendmail, Inc.
+       6603 Shellmound
+       Emeryville, CA  94608
+       U.S.A.
+
+       E-Mail: eric@Sendmail.COM
+       Phone: +1 510 594 5501
+       Fax: +1 510 594 5411
+
+
+       Tony Hansen
+       AT&T Laboratories
+       Lincroft, NJ 07738
+       U.S.A.
+
+       Phone: +1 732 576 3207
+       E-Mail: tony@att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman & Hansen                                               [Page 7]
+
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-03.txt b/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-03.txt
new file mode 100644
index 00000000..932877c2
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-03.txt
@@ -0,0 +1,434 @@
+
+
+
+
+Internet Draft                                               E. Allman
+draft-ietf-msgtrk-smtpext-03.txt                        Sendmail, Inc.
+Valid for six months                                         T. Hansen
+Updates: RFC 1891                                    AT&T Laboratories
+                                                      November 2, 2001
+
+
+
+
+                        SMTP Service Extension
+                         for Message Tracking
+
+                  <draft-ietf-msgtrk-smtpext-03.txt>
+
+Status of This Memo
+
+     This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.  Internet-Drafts are
+working documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups.  Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+     Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other documents
+at any time.  It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+     The list of current Internet-Drafts can be accessed at:
+
+    http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at:
+
+    http://www.ietf.org/shadow.html
+
+
+     This document is a submission by the MSGTRK Working Group of the
+Internet Engineering Task Force (IETF).  Comments should be submitted
+to the ietf-msgtrk@imc.org mailing list.  An archive of the mailing
+list may be found at
+
+    http://www.imc.org/ietf-msgtrk/index.html
+
+
+     Distribution of this memo is unlimited.
+
+
+1.  Abstract
+
+        This memo defines an extension to the SMTP service whereby a
+   client may mark a message for future tracking.
+
+Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
+
+
+2.  Other Documents and Conformance
+
+        The model used for Message Tracking is described in [DRAFT-
+   MTRK-MODEL].
+
+        Doing a Message Tracking query is intended as a "last resort"
+   mechanism.  Normally, Delivery Status Notifications (DSNs) [RFC-
+   DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]
+   would provide the primary delivery status.  Only if the message is
+   not received, or there is no response from either of these
+   mechanisms should a Message Tracking query be issued.
+
+        The definition of the base64 token is imported from section
+   6.8 of [RFC-MIME].
+
+        Syntax notation in this document conforms to [RFC-ABNF].
+
+        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
+   in this document are to be interpreted as described in RFC 2119
+   [RFC-KEYWORDS].
+
+
+3.  SMTP Extension Overview
+
+        The Message Tracking SMTP service extension uses the SMTP
+   service extension mechanism described in [RFC-ESMTP].  The
+   following service extension is hereby defined:
+
+    (1)   The name of the SMTP service extension is "Message
+          Tracking".
+
+    (2)   The EHLO keyword value associated with this extension is
+          "MTRK".
+
+    (3)   No parameters are allowed with this EHLO keyword value.
+          Future documents may extend this specification by specifying
+          options.
+
+    (4)   One optional parameter using the keyword "MTRK" is added to
+          the MAIL command.  In addition, the ENVID parameter of the
+          MAIL command (as defined in RFC 1891 sections 5.4) MUST be
+          supported, with extensions as described below.  The ORCPT
+          parameter of the RCPT command (as defined in RFC 1891
+          section 5.2) MUST also be supported.
+
+    (5)   The maximum length of a MAIL command line is increased by 40
+          characters by the possible addition of the MTRK keyword and
+          value.  Note that the 507 character extension of RCPT
+          commands for the ORCPT parameter and the 107 character
+          extension of MAIL commands for the ENVID parameter as
+          mandated by RFC 1891 [RFC-DSN-SMTP] must also be included.
+
+    (6)   No SMTP verbs are defined by this extension.
+
+
+
+
+Allman & Hansen                                               [Page 2]
+
+Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
+
+
+4.  The Extended MAIL Command
+
+        The extended MAIL command is issued by an SMTP client when it
+   wishes to inform an SMTP server that message tracking information
+   should be retained for future querying.  The extended MAIL command
+   is identical to the MAIL command as defined in [RFC-SMTP], except
+   that MTRK, ORCPT, and ENVID parameters appear after the address.
+
+   4.1.  The MTRK parameter to the ESMTP MAIL command
+
+           Any sender wishing to request the retention of data for
+      further tracking of message must first tag that message as
+      trackable by creating two values A and B:
+
+          A = some-large-random-number
+          B = SHA1(A)
+
+      The large random number A is calculated on a host-dependent
+      basis.  See [RFC-RANDOM] for a discussion of choosing good
+      random numbers.  This random number MUST be at least 128 bits
+      but MUST NOT be more than 1024 bits.
+
+           The 128-bit hash B of A is then computed using the SHA-1
+      algorithm as described in [NIST-SHA1].
+
+           The sender then base64 encodes value B and passes that
+      value as the mtrk-certifier on the MAIL command:
+
+          mtrk-parameter  = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
+          mtrk-certifier  = base64        ; authenticator
+          mtrk-timeout    = 1*9digit      ; seconds until timeout
+
+
+           A is stored in the originator's tracking database to
+      validate future tracking requests as described in [DRAFT-MTRK-
+      MTQP].  B is stored in tracking databases of compliant receiver
+      MTAs and used to authenticate future tracking requests.
+
+           The mtrk-timeout field indicates the number of seconds that
+      the client requests that this tracking information be retained
+      on intermediate servers, as measured from the initial receipt of
+      the message at that server.  Servers MAY ignore this value if it
+      violates local policy.  In particular, servers MAY silently
+      enforce an upper limit to how long they will retain tracking
+      data; this limit MUST be at least one day.
+
+           If no mtrk-timeout field is specified then the server
+      should use a local default.  This default SHOULD be 8-10 days
+      and MUST be at least one day.  Notwithstanding this clause, the
+      information MUST NOT be expired while the message remains in the
+      queue for this server: that is, an MTQP server MUST NOT deny
+      knowledge of a message while that same message sits in the MTA
+      queue.
+
+           If the message is relayed to another compliant SMTP server,
+      the MTA acting as the client SHOULD pass an mtrk-timeout field
+
+
+Allman & Hansen                                               [Page 3]
+
+Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
+
+
+      equal to the remaining life of that message tracking
+      information.  Specifically, the tracking timeout is decremented
+      by the number of seconds the message has lingered at this MTA
+      and then passed to the next MTA.  If the decremented tracking
+      timeout is less than or equal to zero, the entire MTRK parameter
+      MUST NOT be passed to the next MTA; essentially, the entire
+      tracking path is considered to be lost at that point.
+
+           See [RFC-DELIVERYBY] section 4 for an explanation of why a
+      timeout is used instead of an absolute time.
+
+   4.2.  Use of ENVID
+
+           To function properly, Message Tracking requires that each
+      message have a unique identifier that is never reused by any
+      other message.  For that purpose, if the MTRK parameter is
+      given, an ENVID parameter MUST be included, and the syntax of
+      ENVID from RFC 1891 section 5.4 is extended as follows:
+
+          envid-parameter = "ENVID=" unique-envid
+          unique-envid    = local-envid "@" fqhn
+          local-envid     = xtext
+          fqhn            = xtext
+
+      The unique-envid MUST be chosen in such a way that the same
+      ENVID will never be used by any other message sent from this
+      system or any other system.  In most cases, this means setting
+      fqhn to be the fully qualified host name of the system
+      generating this ENVID, and local-envid to an identifier that is
+      never re-used by that host.
+
+           In some cases, the total length of (local-envid + fqhn + 1)
+      (for the `@' sign) may exceed the total acceptable length of
+      ENVID (100).  In this case, the fqhn SHOULD be replaced by the
+      SHA1(fqhn) encoded into BASE64.  After encoding, the 160 bit
+      SHA-1 will be a 27 octet string, which limits local-envid to 72
+      octets.  Implementors are encouraged to use an algorithm for the
+      local-envid that is reasonably unique.  For example, sequential
+      integers have a high probability of intersecting with sequential
+      integers generated by a different host, but a SHA-1 of the
+      current time of day concatenated with the host's IP address and
+      a random number are unlikely to intersect with the same
+      algorithm generated by a different host.
+
+           Any resubmissions of this message into the message
+      transmission system MUST assign a new ENVID.  In this context,
+      "resubmission" includes forwarding or resending a message from a
+      user agent, but does not include MTA-level aliasing or
+      forwarding where the message does not leave and re-enter the
+      message transmission system.
+
+   4.3.  Forwarding Tracking Certifiers
+
+           MTAs SHOULD forward unexpired tracking certifiers to
+      compliant mailers as the mail is transferred during regular hop-
+      to-hop transfers.  If the "downstream" MTA is not MTRK-
+
+
+Allman & Hansen                                               [Page 4]
+
+Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
+
+
+      compliant, then the MTRK= parameter MUST be deleted.  If the
+      downstream MTA is DSN-compliant, then the ENVID and ORCPT
+      parameters MUST NOT be deleted.
+
+           If aliasing, forwarding, or other redirection of a
+      recipient occurs, and the result of the redirection is exactly
+      one recipient, then the MTA SHOULD treat this as an ordinary
+      hop-to-hop transfer and forward the MTRK=, ENVID=, and ORCPT=
+      values; these values MUST NOT be modified.
+
+           MTAs MUST NOT copy MTRK certifiers when a recipient is
+      aliased, forwarded, or otherwise redirected and the redirection
+      results in more than one recipient.  However, an MTA MAY
+      designate one of the multiple recipients as the "primary"
+      recipient to which tracking requests shall be forwarded; other
+      addresses MUST NOT receive tracking certifiers.  MTAs MUST NOT
+      forward MTRK certifiers when doing mailing list expansion.
+
+
+5.  Security Issues
+
+   5.1.  Denial of service
+
+           An attacker could attempt to flood the database of a server
+      by submitting large numbers of small, tracked messages.  In this
+      case, a site may elect to lower its maximum retention period
+      retroactively.
+
+   5.2.  Confidentiality
+
+           The mtrk-authenticator value (``A'') must be hard to
+      predict and not reused.
+
+           The originating client must take reasonable precautions to
+      protect the secret.  For example, if the secret is stored in a
+      message store (e.g., a "Sent" folder), the client must make sure
+      the secret isn't accessible by attackers, particularly on a
+      shared store.
+
+           Many site administrators believe that concealing names and
+      topologies of internal systems and networks is an important
+      security feature.  MTAs need to balance such desires with the
+      need to provide adequate tracking information.
+
+           In some cases site administrators may want to treat
+      delivery to an alias as final delivery in order to separate
+      roles from individuals.  For example, sites implementing
+      ``postmaster'' or ``webmaster'' as aliases may not wish to
+      expose the identity of those individuals by permitting tracking
+      through those aliases.  In other cases, providing the tracking
+      information for an alias is important, such as when the alias
+      points to the user's preferred public address.
+
+           Therefore, implementors are encouraged to provide
+      mechanisms by which site administrators can choose between these
+      alternatives.
+
+
+Allman & Hansen                                               [Page 5]
+
+Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
+
+
+6.  Acknowledgements
+
+        Several individuals have commented on and enhanced this draft,
+   including Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris
+   Newman, and Gregory Neil Shapiro.
+
+7.  References
+
+   [DRAFT-MTRK-MODEL]
+        T. Hansen, ``Message Tracking Model and Requirements.''
+        draft-ietf-msgtrk-model-03.txt.  November 2000.
+
+   [DRAFT-MTRK-MTQP]
+        T. Hansen, ``Message Tracking Query Protocol.''  draft-ietf-
+        msgtrk-mtqp-01.txt.  November 2000.
+
+   [RFC-ABNF]
+        Crocker, D., Editor, and P. Overell, ``Augmented BNF for
+        Syntax Specifications: ABNF'', RFC 2234, November 1997.
+
+   [RFC-DELIVERYBY]
+        D. Newman, ``Deliver By SMTP Service Extension.''  RFC 2852.
+        June 2000.
+
+   [RFC-DSN-REPT]
+        G. Vaudreuil, ``The Multipart/Report Content Type for the
+        Reporting of Mail System Administrative Messages.''  RFC 1892.
+        January 1996.
+
+   [RFC-DSN-SMTP]
+        K. Moore, ``SMTP Service Extension for Delivery Status
+        Notifications.''  RFC 1891.  January 1996.
+
+   [RFC-DSN-STAT]
+        K. Moore and G. Vaudreuil, ``An Extensible Message Format for
+        Delivery Status Notifications.''  RFC 1894.  January 1996.
+
+   [RFC-EMSSC]
+        G. Vaudreuil, ``Enhanced Mail System Status Codes.''  RFC
+        1893.  January 1996.
+
+   [RFC-ESMTP]
+        Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N.
+        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.
+        November 1995.
+
+   [RFC-KEYWORDS]
+        S. Bradner, ``Key words for use in RFCs to Indicate
+        Requirement Levels.''  RFC 2119.  March 1997.
+
+   [RFC-MDN]
+        R. Fajman, ``An Extensible Message Format for Message
+        Disposition Notifications.''  RFC 2298.  March 1998.
+
+   [RFC-MIME]
+        N. Freed and N. Borenstein, ``Multipurpose Internet Mail
+
+
+Allman & Hansen                                               [Page 6]
+
+Internet Draft     Message Tracking ESMTP Extension   November 2, 2001
+
+
+        Extensions (MIME) Part One: Format of Internet Message
+        Bodies.''  RFC 2045.  November 1996.
+
+   [RFC-MSGFMT]
+        P. Resnick, editor, ``Internet Message Format.''  RFC 2822.
+        April 2001.
+
+   [RFC-RANDOM]
+        D. Eastlake, S. Crocker, and J. Schiller, ``Randomness
+        Recommendations for Security.''  RFC 1750.  December 1994.
+
+   [RFC-RELATED]
+        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
+        2387.  August 1998.
+
+   [NIST-SHA1]
+        NIST FIPS PUB 180-1, ``Secure Hash Standard.''  National
+        Institute of Standards and Technology, U.S. Department of
+        Commerce.  May 1994.  DRAFT.
+
+   [RFC-SMTP]
+        J. Klensin, editor, ``Simple Mail Transfer Protocol.''  RFC
+        2821.  April 2001.
+
+8.  Authors' Addresses
+
+       Eric Allman
+       Sendmail, Inc.
+       6425 Christie Ave, 4th Floor
+       Emeryville, CA  94608
+       U.S.A.
+
+       E-Mail: eric@Sendmail.COM
+       Phone: +1 510 594 5501
+       Fax: +1 510 594 5429
+
+
+       Tony Hansen
+       AT&T Laboratories
+       Lincroft, NJ 07738
+       U.S.A.
+
+       Phone: +1 732 576 3207
+       E-Mail: tony@att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman & Hansen                                               [Page 7]
+
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-02.txt b/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-02.txt
new file mode 100644
index 00000000..cc008806
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-02.txt
@@ -0,0 +1,565 @@
+
+
+
+
+Internet Draft                                               E. Allman
+draft-ietf-msgtrk-trkstat-02.txt                        Sendmail, Inc.
+Valid for six months                                      July 6, 2001
+Updates: RFC 1893
+
+
+
+
+              The Message/Tracking-Status MIME Extension
+
+                  <draft-ietf-msgtrk-trkstat-02.txt>
+
+Status of This Memo
+
+     This  document  is  an  Internet-Draft and is in full conformance
+with all provisions of Section 10  of  RFC2026.   Internet-Drafts  are
+working  documents  of the Internet Engineering Task Force (IETF), its
+areas, and its working groups.  Note that other groups may  also  dis-
+tribute working documents as Internet-Drafts.
+
+     Internet-Drafts  are  draft  documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by  other  documents
+at  any time.  It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+     The list of current Internet-Drafts can be accessed at:
+
+    http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at:
+
+    http://www.ietf.org/shadow.html
+
+
+     This document is a submission by the MSGTRK Working Group of  the
+Internet  Engineering Task Force (IETF).  Comments should be submitted
+to the ietf-msgtrk@imc.org mailing list.  An archive  of  the  mailing
+list may be found at
+
+    http://www.imc.org/ietf-msgtrk/index.html
+
+
+     Distribution of this memo is unlimited.
+
+1.  Abstract
+
+        Message  Tracking is expected to be used to determine the sta-
+   tus of undelivered e-mail upon request.  Tracking is used  in  con-
+   junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes-
+   sage Disposition  Notifications  [RFC-MDN];  generally,  a  message
+   tracking request will be issued only when a DSN or MDN has not been
+   received within a reasonable timeout period.
+
+        This memo defines a MIME [RFC-MIME] content-type  for  message
+   tracking  status  in  the  same spirit as RFC 1894, ``An Extensible
+   Message Format for Delivery Status Notifications''  [RFC-DSN-STAT].
+
+Internet Draft          Message/Tracking-Status           July 6, 2001
+
+
+   It  is to be issued upon a request as described in ``Message Track-
+   ing Query Protocol'' [DRAFT-MTRK-MTQP].  This memo defines only the
+   format of the status information.  An extension to SMTP [RFC-ESMTP]
+   to label messages for further tracking and request tracking  status
+   is defined in a separate memo [DRAFT-MTRK-SMTPEXT].
+
+2.  Other Documents and Conformance
+
+        The  model  used  for Message Tracking is described in [DRAFT-
+   MTRK-MODEL].
+
+        Message tracking is intended for use as a "last resort" mecha-
+   nism.   Normally,  Delivery  Status  Notifications (DSNs) [RFC-DSN-
+   SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]  would
+   provide  the  primary  delivery  status.   Only  if  no response is
+   received from either of these mechanisms would Message Tracking  be
+   used.
+
+        This  document is based on [RFC-DSN-STAT].  Sections 1.3 (Ter-
+   minology),  2.1.1  (General  conventions  for  DSN  fields),  2.1.2
+   ("*-type"  subfields),  and 2.1.3 (Lexical tokens imported from RFC
+   822) of [RFC-DSN-STAT] are included into this  document  by  refer-
+   ence.  Other sections are further incorporated as described herein.
+
+        Syntax notation in this document conforms to [RFC-ABNF].
+
+        The following lexical tokens,  defined  in  [RFC-MSGFMT],  are
+   used  in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF,
+   DIGIT, LF, linear-white-space, SPACE, text.  The date-time  lexical
+   token is defined in [RFC-HOSTREQ].
+
+        The  key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL"
+   in  this  document  are  to be interpreted as described in RFC 2119
+   [RFC-KEYWORDS].
+
+
+3.  Format of a Message Tracking Status Notification
+
+        A Message Tracking Status Notification (MTSN) is  intended  to
+   be  returned as the body of a Message Tracking request [DRAFT-MTRK-
+   MTQP].  The actual body MUST be a  multipart/related  [RFC-RELATED]
+   with type parameter of "message/tracking-status"; each subpart MUST
+   be type "message/tracking-status" as described herein.
+
+   3.1.  The message/tracking-status content-type
+
+           The message/tracking-status content-type is defined as fol-
+      lows:
+
+
+
+
+
+
+
+
+
+Allman                                                        [Page 2]
+
+Internet Draft          Message/Tracking-Status           July 6, 2001
+
+
+          MIME type name:           message
+          MIME subtype name:        tracking-status
+          Optional parameters:      none
+          Encoding considerations:  "7bit" encoding is sufficient and
+                                    MUST be used to maintain readability
+                                    when viewed by non-MIME mail readers.
+          Security considerations:  discussed in section 4 of this memo.
+
+
+           The  body  of  a  message/tracking-status  is modeled after
+      [RFC-DSN-STAT].  That body consists of one or more "fields" for-
+      matted  to according to the ABNF of RFC 822 header "fields" (see
+      [RFC-MSGFMT]).  The per-message fields appear first, followed by
+      a  blank line.  Following the per-message fields are one or more
+      groups of per-recipient fields.   Each  group  of  per-recipient
+      fields  is  preceded by a blank line.  Note that there will be a
+      blank line between the final per-recipient field  and  the  MIME
+      boundary,  since  one  CRLF is necessary to terminate the field,
+      and a second is necessary to introduce the MIME boundary.   For-
+      mally,  the  syntax of the message/tracking-status content is as
+      follows:
+
+          tracking-status-content =
+                    per-message-fields 1*( CRLF per-recipient-fields )
+
+      The per-message fields are described in section 3.2.   The  per-
+      recipient fields are described in section 3.3.
+
+      3.1.1.  General conventions for MTSN fields
+
+              Section  2.1.1  (General  conventions for DSN fields) of
+         [RFC-DSN-STAT] is included herein by reference.  Notably, the
+         definition of xtext is identical to that of that document.
+
+      3.1.2.  *-type subfields
+
+              Section  2.1.2  (*-type  subfields) of [RFC-DSN-STAT] is
+         included herein by reference.  Notably,  the  definitions  of
+         address-type,  diagnostic-type, and MTA-name type are identi-
+         cal to that of RFC 1894.
+
+
+   3.2.  Per-Message MTSN Fields
+
+           Some fields of an MTSN apply to all of the addresses  in  a
+      single  envelope.   These  fields may appear at most once in any
+      MTSN.  These fields are used to  correlate  the  MTSN  with  the
+      original  message transaction and to provide additional informa-
+      tion which may be useful to gateways.
+
+          per-message-fields =
+                    original-envelope-id-field CRLF
+                    reporting-mta-field CRLF
+                    arrival-date CRLF
+                    *( extension-field CRLF )
+
+
+
+Allman                                                        [Page 3]
+
+Internet Draft          Message/Tracking-Status           July 6, 2001
+
+
+      3.2.1.  The Original-Envelope-Id field
+
+              The optional Original-Envelope-Id field is defined as in
+         section 2.2.1 of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.2.2.  The Reporting-MTA field
+
+              The  Reporting-MTA  field is defined as in section 2.2.2
+         of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.2.3.  The Arrival-Date field
+
+              The Arrival-Date field is defined as in section 2.2.5 of
+         [RFC-DSN-STAT].  This field is REQUIRED.
+
+
+   3.3.  Per-Recipient MTSN fields
+
+           An  MTSN  contains  information about attempts to deliver a
+      message to one or more recipients.  The delivery information for
+      any  particular  recipient is contained in a group of contiguous
+      per-recipient fields.  Each group  of  per-recipient  fields  is
+      preceded by a blank line.
+
+           The syntax for the group of per-recipient fields is as fol-
+      lows:
+
+          per-recipient-fields =
+                    original-recipient-field CRLF
+                    final-recipient-field CRLF
+                    action-field CRLF
+                    status-field CRLF
+                    [ remote-mta-field CRLF ]
+                    [ last-attempt-date-field CRLF ]
+                    [ will-retry-until-field CRLF ]
+                    *( extension-field CRLF )
+
+
+      3.3.1.  Original-Recipient field
+
+              The optional Original-Recipient field is defined  as  in
+         section 2.3.1 of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.3.2.  Final-Recipient field
+
+              The required Final-Recipient field is defined as in sec-
+         tion 2.3.2 of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.3.3.  Action field
+
+              The required Action field indicates the action performed
+         by  the  Reporting-MTA  as a result of its attempt to deliver
+         the message to this recipient address.  This  field  MUST  be
+         present  for each recipient named in the MTSN.  The syntax is
+         as defined in section 2.3.3  of  RFC  1894.   This  field  is
+         REQUIRED.
+
+
+Allman                                                        [Page 4]
+
+Internet Draft          Message/Tracking-Status           July 6, 2001
+
+
+              Valid actions are:
+
+         failed       The  message  could  not  be delivered.  If DSNs
+                      have been enabled, a "failed" DSN should already
+                      have been returned.
+
+         delayed      The  message  is  currently  waiting  in the MTA
+                      queue for future  delivery.   Essentially,  this
+                      action  means "the message is located, and it is
+                      here."
+
+         delivered    The message has been successfully  delivered  to
+                      the  final  recipient.  This includes "delivery"
+                      to a mailing list exploder.  It does  not  indi-
+                      cate that the message has been read.  No further
+                      information is  available;  in  particular,  the
+                      tracking agent SHOULD NOT attempt further "down-
+                      stream" tracking requests.
+
+         expanded     The message has been successfully  delivered  to
+                      the   recipient  address  as  specified  by  the
+                      sender,  and  forwarded  by  the   Reporting-MTA
+                      beyond  that  destination to multiple additional
+                      recipient addresses.  However, these  additional
+                      addresses  are  not  trackable, and the tracking
+                      agent SHOULD NOT  attempt  further  "downstream"
+                      tracking requests.
+
+         relayed      The  message has been delivered into an environ-
+                      ment that does not support message tracking.  No
+                      further information is available; in particular,
+                      the tracking agent SHOULD  NOT  attempt  further
+                      "downstream" tracking requests.
+
+         transferred  The  message  has  been  transferred  to another
+                      MTRK-compliant MTA.  The tracking  agent  SHOULD
+                      attempt  further "downstream" tracking requests.
+
+         opaque       The message may or may not  have  been  seen  by
+                      this  system.   No further information is avail-
+                      able or forthcoming.
+
+              There  may  be  some  confusion  between  when  to   use
+         "expanded" versus "delivered".  Whenever possible, "expanded"
+         should be used when the MTA knows that the  message  will  be
+         sent  to  multiple  addresses.   However,  in  some cases the
+         delivery occurs to a  program  which,  unknown  to  the  MTA,
+         causes  mailing  list  expansion;  in  the  extreme case, the
+         delivery may be to a real mailbox that has the side effect of
+         list  expansion.  If the MTA cannot ensure that this delivery
+         will cause list  expansion,  it  should  set  the  action  to
+         "delivered".
+
+
+
+
+
+
+Allman                                                        [Page 5]
+
+Internet Draft          Message/Tracking-Status           July 6, 2001
+
+
+      3.3.4.  Status field
+
+              The  Status  field  is  defined  as  in RFC 1894 section
+         2.3.4.   A  new  code  is  added  to  RFC  1893  [RFC-EMSSC],
+         "Enhanced Mail System Status Codes",
+
+             X.1.9   Message relayed to non-compliant mailer"
+
+                 The mailbox address specified was valid, but the mes-
+                 sage has been relayed to a system that does not speak
+                 this  protocol;  no  further  information can be pro-
+                 vided.
+         A  2.1.9  Status  field  MUST  be  used  exclusively  with  a
+         "relayed" Action field.  This field is REQUIRED.
+
+      3.3.5.  Remote-MTA field
+
+              The  Remote-MTA field is defined as in section Reference
+         2.3.5 of [RFC-DSN-STAT].  This field MUST NOT be included  if
+         no  delivery  attempts  have been made or if the Action field
+         has value "opaque".  If delivery to some agent other than  an
+         MTA (for example, a Local Delivery Agent) then this field MAY
+         be included, giving the name of the host on which that  agent
+         was contacted.
+
+      3.3.6.  Last-Attempt-Date field
+
+              The  Last-Attempt-Date  field  is  defined as in section
+         Reference 2.3.7 of [RFC-DSN-STAT].  This field is REQUIRED if
+         any  delivery attempt has been made and the Action field does
+         not have value "opaque", in which case it will  specify  when
+         it  last  attempted to deliver this message to another MTA or
+         other Delivery Agent.  This field MUST NOT be included if  no
+         delivery attempts have been made.
+
+      3.3.7.  Will-Retry-Until field
+
+              The Will-Retry-Until field is defined as in section Ref-
+         erence 2.3.8 of [RFC-DSN-STAT].  If the message is not in the
+         local  queue or the Action field has the value ``opaque'' the
+         Will-Retry-Until field MUST NOT be included; otherwise,  this
+         field is REQUIRED.
+
+   3.4.  Extension fields
+
+           Future  extension  fields may be defined as defined in sec-
+      tion 2.4 of [RFC-DSN-STAT].
+
+   3.5.  Interaction Between MTAs and LDAs
+
+           A message that has been delivered to a Local Delivery Agent
+      (LDA)  that  understands message tracking (in particular, an LDA
+      speaking LMTP  [RFC-LMTP]  that  supports  the  MTRK  extension)
+      SHOULD  pass the tracking request to the LDA.  In this case, the
+      Action field for the MTA->LDA exchange will look the same  as  a
+      transfer  to  a compliant MTA; that is, a "transferred" tracking
+
+
+Allman                                                        [Page 6]
+
+Internet Draft          Message/Tracking-Status           July 6, 2001
+
+
+      status will be issued.
+
+
+4.  Security Issues
+
+   4.1.  Forgery
+
+           Malicious servers may attempt to subvert  message  tracking
+      and return false information.  This could result in misdirection
+      or misinterpretation of results.
+
+   4.2.  Confidentiality
+
+           Another dimension of security  is  confidentiality.   There
+      may be cases in which a message recipient is autoforwarding mes-
+      sages but does not wish to divulge the address to which the mes-
+      sages  are  autoforwarded.   The desire for such confidentiality
+      will probably be heightened as  "wireless  mailboxes",  such  as
+      pagers, become more widely used as autoforward addresses.
+
+           MTA  authors  are  encouraged  to provide a mechanism which
+      enables the end user to preserve the confidentiality of  a  for-
+      warding  address.   Depending  on  the degree of confidentiality
+      required, and the nature of the environment to which  a  message
+      were  being forwarded, this might be accomplished by one or more
+      of:
+
+      (a)  respond with a "relayed" tracking status when a message  is
+           forwarded  to  a  confidential forwarding address, and dis-
+           abling further message tracking requests.
+
+      (b)  declaring the message to be delivered,  issuing  a  "deliv-
+           ered" tracking status, re-sending the message to the confi-
+           dential forwarding address, and disabling  further  message
+           tracking requests.
+
+           The  tracking  algorithms  MUST  NOT allow tracking through
+      list expansions.  When a message  is  delivered  to  a  list,  a
+      tracking request MUST respond with an "expanded" tracking status
+      and MUST NOT display the contents of the list.
+
+5.  References
+
+   [DRAFT-MTRK-MODEL]
+        T.  Hansen,  ``Message  Tracking  Model  and   Requirements.''
+        draft-ietf-msgtrk-model-03.txt.  November 2000.
+
+   [DRAFT-MTRK-MTQP]
+        T.  Hansen,  ``Message Tracking Query Protocol.''  draft-ietf-
+        msgtrk-mtqp-01.txt.  November 2000.
+
+   [DRAFT-MTRK-SMTPEXT]
+        E. Allman, ``SMTP Service Extension  for  Message  Tracking.''
+        draft-ietf-msgtrk-smtpext-00.txt.  December 2000.
+
+
+
+
+Allman                                                        [Page 7]
+
+Internet Draft          Message/Tracking-Status           July 6, 2001
+
+
+   [RFC-ABNF]
+        Crocker,  D., Editor, and P. Overell, ``Augmented BNF for Syn-
+        tax Specifications: ABNF'', RFC 2234, November 1997.
+
+   [RFC-DSN-REPT]
+        G. Vaudreuil, ``The  Multipart/Report  Content  Type  for  the
+        Reporting of Mail System Administrative Messages.''  RFC 1892.
+        January 1996.
+
+   [RFC-DSN-SMTP]
+        K. Moore, ``SMTP Service Extension for Delivery Status Notifi-
+        cations.''  RFC 1891.  January 1996.
+
+   [RFC-DSN-STAT]
+        K.  Moore and G. Vaudreuil, ``An Extensible Message Format for
+        Delivery Status Notifications.''  RFC 1894.  January 1996.
+
+   [RFC-EMSSC]
+        G. Vaudreuil, ``Enhanced  Mail  System  Status  Codes.''   RFC
+        1893.  January 1996.
+
+   [RFC-ESMTP]
+        Rose,  M.,  Stefferud,  E.,  Crocker,  D.,  Klensin, J. and N.
+        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.  Novem-
+        ber 1995.
+
+   [RFC-HOSTREQ]
+        R. Braden (ed.), ``Requirements for Internet Hosts -- Applica-
+        tion and Support.''  STD 3, RFC 1123.  October 1989.
+
+   [RFC-KEYWORDS]
+        S. Bradner, ``Key words for use in RFCs to  Indicate  Require-
+        ment Levels.''  RFC 2119.  March 1997.
+
+   [RFC-LMTP]
+        J.  Myers, ``Local Mail Transfer Protocol.''  RFC 2033.  Octo-
+        ber 1996.
+
+   [RFC-MDN]
+        R. Fajman, ``An Extensible Message Format for Message Disposi-
+        tion Notifications.''  RFC 2298.  March 1998.
+
+   [RFC-MIME]
+        N.  Freed  and  N.  Borenstein,  ``Multipurpose  Internet Mail
+        Extensions (MIME) Part One: Format of  Internet  Message  Bod-
+        ies.''  RFC 2045.  November 1996.
+
+   [RFC-MSGFMT]
+        D.  Crocker,  ``Standard  for the Format of ARPA Internet Text
+        Messages.''  RFC 822.  August 1982.
+
+   [RFC-RELATED]
+        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
+        2387.  August 1998.
+
+
+
+
+Allman                                                        [Page 8]
+
+Internet Draft          Message/Tracking-Status           July 6, 2001
+
+
+6.  Author's Address
+
+       Eric Allman
+       Sendmail, Inc.
+       6603 Shellmound
+       Emeryville, CA  94608
+       U.S.A.
+
+       E-Mail: eric@Sendmail.COM
+       Phone: +1 510 594 5501
+       Fax: +1 510 594 5411
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman                                                        [Page 9]
+
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-03.txt b/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-03.txt
new file mode 100644
index 00000000..5ef65831
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-03.txt
@@ -0,0 +1,565 @@
+
+
+
+
+Internet Draft                                               E. Allman
+draft-ietf-msgtrk-trkstat-03.txt                        Sendmail, Inc.
+Valid for six months                                  November 2, 2001
+Updates: RFC 1893
+
+
+
+
+              The Message/Tracking-Status MIME Extension
+
+                  <draft-ietf-msgtrk-trkstat-03.txt>
+
+Status of This Memo
+
+     This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.  Internet-Drafts are
+working documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups.  Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+     Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other documents
+at any time.  It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+     The list of current Internet-Drafts can be accessed at:
+
+    http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at:
+
+    http://www.ietf.org/shadow.html
+
+
+     This document is a submission by the MSGTRK Working Group of the
+Internet Engineering Task Force (IETF).  Comments should be submitted
+to the ietf-msgtrk@imc.org mailing list.  An archive of the mailing
+list may be found at
+
+    http://www.imc.org/ietf-msgtrk/index.html
+
+
+     Distribution of this memo is unlimited.
+
+1.  Abstract
+
+        Message Tracking is expected to be used to determine the
+   status of undelivered e-mail upon request.  Tracking is used in
+   conjunction with Delivery Status Notifications [RFC-DSN-SMTP] and
+   Message Disposition Notifications [RFC-MDN]; generally, a message
+   tracking request will be issued only when a DSN or MDN has not been
+   received within a reasonable timeout period.
+
+        This memo defines a MIME [RFC-MIME] content-type for message
+   tracking status in the same spirit as RFC 1894, ``An Extensible
+   Message Format for Delivery Status Notifications'' [RFC-DSN-STAT].
+
+Internet Draft          Message/Tracking-Status       November 2, 2001
+
+
+   It is to be issued upon a request as described in ``Message
+   Tracking Query Protocol'' [DRAFT-MTRK-MTQP].  This memo defines
+   only the format of the status information.  An extension to SMTP
+   [RFC-ESMTP] to label messages for further tracking and request
+   tracking status is defined in a separate memo [DRAFT-MTRK-SMTPEXT].
+
+2.  Other Documents and Conformance
+
+        The model used for Message Tracking is described in [DRAFT-
+   MTRK-MODEL].
+
+        Message tracking is intended for use as a "last resort"
+   mechanism.  Normally, Delivery Status Notifications (DSNs) [RFC-
+   DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]
+   would provide the primary delivery status.  Only if no response is
+   received from either of these mechanisms would Message Tracking be
+   used.
+
+        This document is based on [RFC-DSN-STAT].  Sections 1.3
+   (Terminology), 2.1.1 (General conventions for DSN fields), 2.1.2
+   ("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC
+   822) of [RFC-DSN-STAT] are included into this document by
+   reference.  Other sections are further incorporated as described
+   herein.
+
+        Syntax notation in this document conforms to [RFC-ABNF].
+
+        The following lexical tokens, defined in [RFC-MSGFMT], are
+   used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF,
+   DIGIT, LF, linear-white-space, SPACE, text.  The date-time lexical
+   token is defined in [RFC-HOSTREQ].
+
+        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
+   in this document are to be interpreted as described in RFC 2119
+   [RFC-KEYWORDS].
+
+
+3.  Format of a Message Tracking Status Notification
+
+        A Message Tracking Status Notification (MTSN) is intended to
+   be returned as the body of a Message Tracking request [DRAFT-MTRK-
+   MTQP].  The actual body MUST be a multipart/related [RFC-RELATED]
+   with type parameter of "message/tracking-status"; each subpart MUST
+   be of type "message/tracking-status" as described herein.  The
+   multipart/related body can include multiple message/tracking-status
+   parts if an MTQP server chains requests to the next server; see
+   [DRAFT-MTRK-MODEL] and [DRAFT-MTRK-MTQP] for more information about
+   chaining.
+
+   3.1.  The message/tracking-status content-type
+
+           The message/tracking-status content-type is defined as
+      follows:
+
+
+
+
+Allman                                                        [Page 2]
+
+Internet Draft          Message/Tracking-Status       November 2, 2001
+
+
+          MIME type name:           message
+          MIME subtype name:        tracking-status
+          Optional parameters:      none
+          Encoding considerations:  "7bit" encoding is sufficient and
+                                    MUST be used to maintain readability
+                                    when viewed by non-MIME mail readers.
+          Security considerations:  discussed in section 4 of this memo.
+
+
+           The body of a message/tracking-status is modeled after
+      [RFC-DSN-STAT].  That body consists of one or more "fields"
+      formatted to according to the ABNF of RFC 2822 header "fields"
+      (see [RFC-MSGFMT]).  The per-message fields appear first,
+      followed by a blank line.  Following the per-message fields are
+      one or more groups of per-recipient fields.  Each group of per-
+      recipient fields is preceded by a blank line.  Note that there
+      will be a blank line between the final per-recipient field and
+      the MIME boundary, since one CRLF is necessary to terminate the
+      field, and a second is necessary to introduce the MIME boundary.
+      Formally, the syntax of the message/tracking-status content is
+      as follows:
+
+          tracking-status-content =
+                    per-message-fields 1*( CRLF per-recipient-fields )
+
+      The per-message fields are described in section 3.2.  The per-
+      recipient fields are described in section 3.3.
+
+      3.1.1.  General conventions for MTSN fields
+
+              Section 2.1.1 (General conventions for DSN fields) of
+         [RFC-DSN-STAT] is included herein by reference.  Notably, the
+         definition of xtext is identical to that of that document.
+
+      3.1.2.  *-type subfields
+
+              Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is
+         included herein by reference.  Notably, the definitions of
+         address-type, diagnostic-type, and MTA-name type are
+         identical to that of RFC 1894.
+
+
+   3.2.  Per-Message MTSN Fields
+
+           Some fields of an MTSN apply to all of the addresses in a
+      single envelope.  These fields may appear at most once in any
+      MTSN.  These fields are used to correlate the MTSN with the
+      original message transaction and to provide additional
+      information which may be useful to gateways.
+
+          per-message-fields =
+                    original-envelope-id-field CRLF
+                    reporting-mta-field CRLF
+                    arrival-date CRLF
+                    *( extension-field CRLF )
+
+
+
+Allman                                                        [Page 3]
+
+Internet Draft          Message/Tracking-Status       November 2, 2001
+
+
+      3.2.1.  The Original-Envelope-Id field
+
+              The Original-Envelope-Id field is defined as in section
+         2.2.1 of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.2.2.  The Reporting-MTA field
+
+              The Reporting-MTA field is defined as in section 2.2.2
+         of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.2.3.  The Arrival-Date field
+
+              The Arrival-Date field is defined as in section 2.2.5 of
+         [RFC-DSN-STAT].  This field is REQUIRED.
+
+
+   3.3.  Per-Recipient MTSN fields
+
+           An MTSN contains information about attempts to deliver a
+      message to one or more recipients.  The delivery information for
+      any particular recipient is contained in a group of contiguous
+      per-recipient fields.  Each group of per-recipient fields is
+      preceded by a blank line.
+
+           The syntax for the group of per-recipient fields is as
+      follows:
+
+          per-recipient-fields =
+                    original-recipient-field CRLF
+                    final-recipient-field CRLF
+                    action-field CRLF
+                    status-field CRLF
+                    [ remote-mta-field CRLF ]
+                    [ last-attempt-date-field CRLF ]
+                    [ will-retry-until-field CRLF ]
+                    *( extension-field CRLF )
+
+
+      3.3.1.  Original-Recipient field
+
+              The Original-Recipient field is defined as in section
+         2.3.1 of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.3.2.  Final-Recipient field
+
+              The required Final-Recipient field is defined as in
+         section 2.3.2 of [RFC-DSN-STAT].  This field is REQUIRED.
+
+      3.3.3.  Action field
+
+              The required Action field indicates the action performed
+         by the Reporting-MTA as a result of its attempt to deliver
+         the message to this recipient address.  This field MUST be
+         present for each recipient named in the MTSN.  The syntax is
+         as defined in section 2.3.3 of RFC 1894.  This field is
+         REQUIRED.
+
+
+Allman                                                        [Page 4]
+
+Internet Draft          Message/Tracking-Status       November 2, 2001
+
+
+              Valid actions are:
+
+         failed       The message could not be delivered.  If DSNs
+                      have been enabled, a "failed" DSN should already
+                      have been returned.
+
+         delayed      The message is currently waiting in the MTA
+                      queue for future delivery.  Essentially, this
+                      action means "the message is located, and it is
+                      here."
+
+         delivered    The message has been successfully delivered to
+                      the final recipient.  This includes "delivery"
+                      to a mailing list exploder.  It does not
+                      indicate that the message has been read.  No
+                      further information is available; in particular,
+                      the tracking agent SHOULD NOT attempt further
+                      "downstream" tracking requests.
+
+         expanded     The message has been successfully delivered to
+                      the recipient address as specified by the
+                      sender, and forwarded by the Reporting-MTA
+                      beyond that destination to multiple additional
+                      recipient addresses.  However, these additional
+                      addresses are not trackable, and the tracking
+                      agent SHOULD NOT attempt further "downstream"
+                      tracking requests.
+
+         relayed      The message has been delivered into an
+                      environment that does not support message
+                      tracking.  No further information is available;
+                      in particular, the tracking agent SHOULD NOT
+                      attempt further "downstream" tracking requests.
+
+         transferred  The message has been transferred to another
+                      MTRK-compliant MTA.  The tracking agent SHOULD
+                      attempt further "downstream" tracking requests
+                      unless that information is already given in a
+                      chaining response.
+
+         opaque       The message may or may not have been seen by
+                      this system.  No further information is
+                      available or forthcoming.
+
+              There may be some confusion between when to use
+         "expanded" versus "delivered".  Whenever possible, "expanded"
+         should be used when the MTA knows that the message will be
+         sent to multiple addresses.  However, in some cases the
+         delivery occurs to a program which, unknown to the MTA,
+         causes mailing list expansion; in the extreme case, the
+         delivery may be to a real mailbox that has the side effect of
+         list expansion.  If the MTA cannot ensure that this delivery
+         will cause list expansion, it should set the action to
+         "delivered".
+
+
+
+
+Allman                                                        [Page 5]
+
+Internet Draft          Message/Tracking-Status       November 2, 2001
+
+
+      3.3.4.  Status field
+
+              The Status field is defined as in RFC 1894 section
+         2.3.4.  A new code is added to RFC 1893 [RFC-EMSSC],
+         "Enhanced Mail System Status Codes",
+
+             X.1.9   Message relayed to non-compliant mailer"
+
+                 The mailbox address specified was valid, but the
+                 message has been relayed to a system that does not
+                 speak this protocol; no further information can be
+                 provided.
+         A 2.1.9 Status field MUST be used exclusively with a
+         "relayed" Action field.  This field is REQUIRED.
+
+      3.3.5.  Remote-MTA field
+
+              The Remote-MTA field is defined as in section Reference
+         2.3.5 of [RFC-DSN-STAT].  This field MUST NOT be included if
+         no delivery attempts have been made or if the Action field
+         has value "opaque".  If delivery to some agent other than an
+         MTA (for example, a Local Delivery Agent) then this field MAY
+         be included, giving the name of the host on which that agent
+         was contacted.
+
+      3.3.6.  Last-Attempt-Date field
+
+              The Last-Attempt-Date field is defined as in section
+         Reference 2.3.7 of [RFC-DSN-STAT].  This field is REQUIRED if
+         any delivery attempt has been made and the Action field does
+         not have value "opaque", in which case it will specify when
+         it last attempted to deliver this message to another MTA or
+         other Delivery Agent.  This field MUST NOT be included if no
+         delivery attempts have been made.
+
+      3.3.7.  Will-Retry-Until field
+
+              The Will-Retry-Until field is defined as in section
+         Reference 2.3.8 of [RFC-DSN-STAT].  If the message is not in
+         the local queue or the Action field has the value ``opaque''
+         the Will-Retry-Until field MUST NOT be included; otherwise,
+         this field SHOULD be included.
+
+   3.4.  Extension fields
+
+           Future extension fields may be defined as defined in
+      section 2.4 of [RFC-DSN-STAT].
+
+   3.5.  Interaction Between MTAs and LDAs
+
+           A message that has been delivered to a Local Delivery Agent
+      (LDA) that understands message tracking (in particular, an LDA
+      speaking LMTP [RFC-LMTP] that supports the MTRK extension)
+      SHOULD pass the tracking request to the LDA.  In this case, the
+      Action field for the MTA->LDA exchange will look the same as a
+      transfer to a compliant MTA; that is, a "transferred" tracking
+
+
+Allman                                                        [Page 6]
+
+Internet Draft          Message/Tracking-Status       November 2, 2001
+
+
+      status will be issued.
+
+
+4.  Security Issues
+
+   4.1.  Forgery
+
+           Malicious servers may attempt to subvert message tracking
+      and return false information.  This could result in misdirection
+      or misinterpretation of results.
+
+   4.2.  Confidentiality
+
+           Another dimension of security is confidentiality.  There
+      may be cases in which a message recipient is autoforwarding
+      messages but does not wish to divulge the address to which the
+      messages are autoforwarded.  The desire for such confidentiality
+      will probably be heightened as "wireless mailboxes", such as
+      pagers, become more widely used as autoforward addresses.
+
+           MTA authors are encouraged to provide a mechanism which
+      enables the end user to preserve the confidentiality of a
+      forwarding address.  Depending on the degree of confidentiality
+      required, and the nature of the environment to which a message
+      were being forwarded, this might be accomplished by one or more
+      of:
+
+      (a)  respond with a "relayed" tracking status when a message is
+           forwarded to a confidential forwarding address, and
+           disabling further message tracking requests.
+
+      (b)  declaring the message to be delivered, issuing a
+           "delivered" tracking status, re-sending the message to the
+           confidential forwarding address, and disabling further
+           message tracking requests.
+
+           The tracking algorithms MUST NOT allow tracking through
+      list expansions.  When a message is delivered to a list, a
+      tracking request MUST respond with an "expanded" tracking status
+      and MUST NOT display the contents of the list.
+
+5.  Acknowledgements
+
+        Several individuals have commented on and enhanced this draft,
+   including Tony Hansen, Philip Hazel, Alexey Melnikov, Lyndon
+   Nerenberg, Chris Newman, Gregory Neil Shapiro, and Dan Wing.
+
+6.  References
+
+   [DRAFT-MTRK-MODEL]
+        T. Hansen, ``Message Tracking Model and Requirements.''
+        draft-ietf-msgtrk-model-03.txt.  November 2000.
+
+   [DRAFT-MTRK-MTQP]
+        T. Hansen, ``Message Tracking Query Protocol.''  draft-ietf-
+        msgtrk-mtqp-01.txt.  November 2000.
+
+
+Allman                                                        [Page 7]
+
+Internet Draft          Message/Tracking-Status       November 2, 2001
+
+
+   [DRAFT-MTRK-SMTPEXT]
+        E. Allman, ``SMTP Service Extension for Message Tracking.''
+        draft-ietf-msgtrk-smtpext-00.txt.  December 2000.
+
+   [RFC-ABNF]
+        Crocker, D., Editor, and P. Overell, ``Augmented BNF for
+        Syntax Specifications: ABNF'', RFC 2234, November 1997.
+
+   [RFC-DSN-REPT]
+        G. Vaudreuil, ``The Multipart/Report Content Type for the
+        Reporting of Mail System Administrative Messages.''  RFC 1892.
+        January 1996.
+
+   [RFC-DSN-SMTP]
+        K. Moore, ``SMTP Service Extension for Delivery Status
+        Notifications.''  RFC 1891.  January 1996.
+
+   [RFC-DSN-STAT]
+        K. Moore and G. Vaudreuil, ``An Extensible Message Format for
+        Delivery Status Notifications.''  RFC 1894.  January 1996.
+
+   [RFC-EMSSC]
+        G. Vaudreuil, ``Enhanced Mail System Status Codes.''  RFC
+        1893.  January 1996.
+
+   [RFC-ESMTP]
+        Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N.
+        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.
+        November 1995.
+
+   [RFC-HOSTREQ]
+        R. Braden (ed.), ``Requirements for Internet Hosts --
+        Application and Support.''  STD 3, RFC 1123.  October 1989.
+
+   [RFC-KEYWORDS]
+        S. Bradner, ``Key words for use in RFCs to Indicate
+        Requirement Levels.''  RFC 2119.  March 1997.
+
+   [RFC-LMTP]
+        J. Myers, ``Local Mail Transfer Protocol.''  RFC 2033.
+        October 1996.
+
+   [RFC-MDN]
+        R. Fajman, ``An Extensible Message Format for Message
+        Disposition Notifications.''  RFC 2298.  March 1998.
+
+   [RFC-MIME]
+        N. Freed and N. Borenstein, ``Multipurpose Internet Mail
+        Extensions (MIME) Part One: Format of Internet Message
+        Bodies.''  RFC 2045.  November 1996.
+
+   [RFC-MSGFMT]
+        P. Resnick, editor, ``Internet Message Format.''  RFC 2822.
+        April 2001.
+
+
+
+
+Allman                                                        [Page 8]
+
+Internet Draft          Message/Tracking-Status       November 2, 2001
+
+
+   [RFC-RELATED]
+        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
+        2387.  August 1998.
+
+7.  Author's Address
+
+       Eric Allman
+       Sendmail, Inc.
+       6425 Christie Ave, 4th Floor
+       Emeryville, CA  94608
+       U.S.A.
+
+       E-Mail: eric@Sendmail.COM
+       Phone: +1 510 594 5501
+       Fax: +1 510 594 5429
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman                                                        [Page 9]
+
diff --git a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt b/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt
new file mode 100644
index 00000000..9ad33375
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt
@@ -0,0 +1,413 @@
+
+
+
+Internet Engineering Task Force                        Motonori Nakamura
+INTERNET-DRAFT                                          Kyoto University
+Expires: January 13, 2002                       Jun-ichiro itojun Hagino
+                                                 IIJ Research Laboratory
+                                                           July 13, 2001
+
+
+                   IPv6 SMTP operational requirements
+            draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt
+
+Status of this Memo
+
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups.  Note that other groups
+may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time.  It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as ``work in progress.''
+
+To view the list Internet-Draft Shadow Directories, see
+http://www.ietf.org/shadow.html.
+
+Distribution of this memo is unlimited.
+
+The internet-draft will expire in 6 months.  The date of expiration will
+be January 13, 2002.
+
+
+Abstract
+
+The memo lists operational requirements for IPv6 SMTP, and IPv6-capable
+MX DNS records.  As we deploy IPv6 SMTP servers, it became apparent that
+we need certain configuration in IPv6-capable MX DNS record, for stable
+dual-stack (IPv4 and IPv6) SMTP operations.  The document tries to
+clarify the problems we have in transition period between IPv4 SMTP and
+IPv6 SMTP, and operational requirements for stable IPv4/v6 SMTP
+operation.
+
+The document does not try to define any new protocol.
+
+
+1.  Summary of IPv4 MX operation
+
+For reference purpose, the section outlines how mail message delivery is
+performed in IPv4-only environment [Partridge, 1986] .
+
+
+
+NAKAMURA, HAGINO        Expires: January 13, 2002               [Page 1]
+
+
+DRAFT              IPv6 SMTP operational requirements          July 2001
+
+In IPv4 SMTP operation, we register MX records like below, for
+"example.org."  domain:
+
+     example.org.            IN MX   1  mx1.example.org.
+                             IN MX   10 mx10.example.org.
+     mx1.example.org.        IN A    1.0.0.1
+     mx10.example.org.       IN A    1.0.0.2
+
+When an MTA delivers a message to a particular destination (say it is to
+foo@example.org), the MTA would send DNS queries to lookup DNS database
+in the following order:
+
+o Lookup MX record for "example.org.".
+
+  o If an MX record is returned, try to lookup A record on the righthand
+    side of the MX record.
+
+  o If a CNAME record is returned, try to chase the CNAME chain.
+    Eventually we will reach some A record.
+
+    NOTE: from RFC2181 MX records must not point CNAME records [Elz,
+    1997] .  However, it has been permitted in older RFCs [Partridge,
+    1986] .  We mention CNAME chasing logic here just for backward
+    compatibility.  Implementers may want to avoid CNAME chasing to be
+    more conformant to RFC2181.
+
+  o If MX lookup failed with NO_DATA, it means that there is no MX
+    record but there can be other record for "example.org.".  Lookup A
+    record for "example.org.".
+
+  o If MX lookup failed with HOST_NOT_FOUND, it means that there is no
+    record at all for "example.org.".  This means a delivery failure.
+
+
+2.  MX records and IPv6 SMTP operation
+
+The following sections talk about how to make IPv4 SMTP and IPv6 SMTP
+coexist, under dual-stack environment during the transition period
+between IPv4 to IPv6.  In the future, when we have completely migrated
+to IPv6-only network, we can forget about IPv4/v6 SMTP interaction.
+
+As IPv6 DNS lookup RFCs [Thomson, 1995; Crawford, 2000] use IN class for
+both IPv4 and IPv6, we will use IN MX records for both IPv4 and IPv6.
+
+For simplicity, the document lists DNS records for IPv6 address as AAAA
+records, not as A6 records [Crawford, 2000] .  In reality, we can use a
+chain of A6 records, instead of AAAA records.
+
+There are couple of technologies defined for IPv4 and IPv6 transition.
+The document concentrates on issues with dual stack environment.
+Translators do not need special consideration from SMTP point of view;
+If we have SMTP traffic from IPv6 MTA to IPv4 MTA over an IPv6-to-IPv4
+
+
+NAKAMURA, HAGINO        Expires: January 13, 2002               [Page 2]
+
+
+DRAFT              IPv6 SMTP operational requirements          July 2001
+
+translator, the traffic will be considered as a normal IPv4 SMTP
+traffic, from the IPv4 MTA point of view.  We may, however, need some
+consideration on translators for protocols like IDENT [StJohns, 1993] .
+
+
+3.  SMTP sender algorithm in dual stack environment
+
+When we lookup MX records for the domain in IPv4/v6 dual stack
+environment, we will see records like below:
+
+     example.org.            IN MX   1  mx1.example.org.
+                             IN MX   10 mx10.example.org.
+     mx1.example.org.        IN A    1.0.0.1          ; IPv4/v6 dual stack
+                             IN AAAA 3ffe:501:ffff::1
+     mx10.example.org.       IN AAAA 3ffe:501:ffff::2 ; IPv6 only
+
+For single MX record, we have many possibility for the final lookup
+result, including: (a) single, or multiple A records for IPv4
+destination, (b) single, or multiple AAAA records for IPv6 destination,
+(c) mixture of A and AAAA records.  As we can define multiple MX records
+with different preference value, we also need to go through multiple
+addresses based on multiple MXes.  We need to cope with domains without
+MX records, and failure recovery cases too.
+
+The algorithm for a SMTP sender would be like this.
+
+(1)  Lookup MX record for the destination domain.  If a CNAME record is
+     returned, go back to step (1) with the queried result.  If MX
+     records are returned, go to step (2) with the result.  If NO_DATA
+     is returned, go to step (3) as there is no MX record.  If
+     HOST_NOT_FOUND is returned, there is no domain, raise permanent
+     email delivery failure (finish).
+
+     NOTE: regarding to MX records pointing CNAME records, see a note in
+     the previous section.
+
+(2)  We have multiple MX records with us.  Loop steps from (3) to (8),
+     based on MX preference values, in ascending order.
+
+(3)  If the source MTA has IPv4 capability, lookup A record.  Keep the
+     resulting address till step (5).
+
+(4)  If the source MTA has IPv6 capability, lookup AAAA record.
+
+(5)  Reorder queried result based on implementation-dependent preference
+     between A and AAAA records.  If you would like to encourage the
+     transition from IPv4 SMTP to IPv6 SMTP, AAAAs should take
+     precedence.
+
+(6)  Loop steps from (7) to (8), for all the addresses (or part of the
+     list of addresses) we have.  If no reachable destination is found,
+     and if we are going through a list of MX records, go back to (3)
+
+
+NAKAMURA, HAGINO        Expires: January 13, 2002               [Page 3]
+
+
+DRAFT              IPv6 SMTP operational requirements          July 2001
+
+     and try the next MX record.  If we do not have a list of MX
+     records, or we have reached the end of the list of MX records,
+     raise temporary delivery failure (finish).
+
+(7)  Try to make a TCP connection to the destination.  If it fails, try
+     the next address we have.  If it succeeds, go to step (8).
+
+(8)  Try a SMTP protocol negotiation.  If SMTP protocol negotiation
+     fails with TEMPFAIL (4xx), go back to (3) and try the next MX
+     record.  If it succeeds, SMTP delivery was successful (finish).
+
+
+4.  MX configuration in receipient domain
+
+4.1.  Ensuring reachability for both protocol versions
+
+If a site has IPv4/v6 dual stack reachability, the site SHOULD configure
+both A and AAAA records onto its MX hosts.  It will help both IPv4 and
+IPv6 senders to reach the site efficienlty.
+
+4.2.  Reachability between primary and secondary MX
+
+When we configure MX records onto DNS database in dual-stack
+environment, we need to be careful about reachability between MX hosts.
+Suppose we try to gather all inbound email to primary MX host,
+mx1.example.org.
+
+     example.org.    IN MX   1   mx1.example.org.
+                     IN MX   10  mx10.example.org.
+                     IN MX   100 mx100.example.org.
+
+If mx1.example.org is an IPv6 only node and the rest are IPv4 only node,
+we have no reachability between primary MX host and the rest.  Once an
+email reaches one of secondary MX host, the email will never reach the
+primary MX.
+
+     ; the configuration is troublesome.
+     ; no secondary MX can reach mx1.example.org.
+     example.org.    IN MX   1   mx1.example.org.     ; IPv6 only
+                     IN MX   10  mx10.example.org.    ; IPv4 only
+                     IN MX   100 mx100.example.org.   ; IPv4 only
+
+The easiest possible configuration is to configure the primary MX host
+as an IPv4/v6 dual stack node.  By doing so, secondaries will have no
+problem reaching the primary MX host.
+
+     ; the configuration works just fine.
+     ; emails reaches from secondary MX to primary with no trouble.
+     example.org.    IN MX   1   mx1.example.org.     ; IPv4/v6 dual stack
+                     IN MX   10  mx10.example.org.    ; IPv4 only
+                     IN MX   100 mx100.example.org.   ; IPv6 only
+
+
+
+NAKAMURA, HAGINO        Expires: January 13, 2002               [Page 4]
+
+
+DRAFT              IPv6 SMTP operational requirements          July 2001
+
+There are many other ways to ensure the reachability between secondary
+MX and primary MX.  For example, we could configure secondary MX to
+route emails statically, without considering DNS MX configuration.  Or
+we could estalish alternative email routing path (i.e. UUCP, or via
+IPv4/v6 translator) between secondary MX and the primary MX.
+
+
+5.  Operational experiences
+
+Many of the existing IPv6-ready MTAs seem to work in the way documented
+in section 3.
+
+>From past experiments and operatinal experiences, it is known that none
+of the existing IPv4-only MTAs will get confused by AAAA records,
+registered for MX hostnames.  No experiments were conducted with A6
+records.
+
+
+6.  Open issues
+
+o How to interpret scoped address on MTAs.  As we relay emails between
+  MTAs, interpretation of scoped address can be different between MTAs,
+  as intermediate MTAs may be in different scope zone as the originator.
+  If we get scoped IPv6 address as a result of DNS lookups, how MTAs
+  should behave?
+
+  If we consider scoped address in ``route-addr'' specification
+  [Crocker, 1982] like
+
+                 <@kame.net,@[fec0::1]:itojun@itojun.org>
+
+  it gets more trickier.  Luckily, route-addr form was obsoleted by
+  RFC2822 [Resnick, 2001] .
+
+
+7.  Security consideration
+
+As presented in ``Open issues'' section, it could be problematical if
+route-addr email address format is used across multiple scope zones.
+MTAs would need to reject emails with improper route-addr email address
+formats.  A possible example of improper route-addr format would be like
+this: an email from outside of the site border, which carries numeric
+site-local address in route-addr format.
+
+
+References
+
+Partridge, 1986.
+C. Partridge, "Mail routing and the domain system" in RFC974 (January
+1986). ftp://ftp.isi.edu/in-notes/rfc974.txt.
+
+
+
+
+NAKAMURA, HAGINO        Expires: January 13, 2002               [Page 5]
+
+
+DRAFT              IPv6 SMTP operational requirements          July 2001
+
+Elz, 1997.
+R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181
+(July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt.
+
+Thomson, 1995.
+S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
+RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
+
+Crawford, 2000.
+M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
+Address Aggregation and Renumbering" in RFC2874 (July 2000).
+ftp://ftp.isi.edu/in-notes/rfc2874.txt.
+
+StJohns, 1993.
+M. StJohns, "Identification Protocol" in RFC1413 (January 1993).
+ftp://ftp.isi.edu/in-notes/rfc1413.txt.
+
+Crocker, 1982.
+D. Crocker, "Standard for the format of ARPA Internet text messages" in
+RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt.
+
+Resnick, 2001.
+P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001).
+ftp://ftp.isi.edu/in-notes/rfc2822.txt.
+
+
+Change history
+
+00 -> 01
+     Correct email address notation for source-routed emails, based on a
+     comment from Gregory Neil Shapiro.
+
+01 -> 02
+     Refer RFC2822, not 822.  Use example.org, not sample.org.  Based on
+     comments from Arnt Gulbrandse.  Add Operational experiences
+     section.  Clarify MX-points-to-CNAME, based on comments from Mohsen
+     Souissi.
+
+
+Acknowledgements
+
+The draft was written based on discussions with Japanese IPv6 users, and
+help from WIDE research group.
+
+
+Author's address
+
+
+
+
+
+
+
+
+NAKAMURA, HAGINO        Expires: January 13, 2002               [Page 6]
+
+
+DRAFT              IPv6 SMTP operational requirements          July 2001
+
+     Motonori NAKAMURA
+     Center for Information and Multimedia Studies, Kyoto University
+     Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN
+     Tel: +81-75-753-9063
+     Fax: +81-75-753-9056
+     Email: motonori@media.kyoto-u.ac.jp
+
+     Jun-ichiro itojun HAGINO
+     Research Laboratory, Internet Initiative Japan Inc.
+     Takebashi Yasuda Bldg.,
+     3-13 Kanda Nishiki-cho,
+     Chiyoda-ku,Tokyo 101-0054, JAPAN
+     Tel: +81-3-5259-6350
+     Fax: +81-3-5259-6351
+     Email: itojun@iijlab.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NAKAMURA, HAGINO        Expires: January 13, 2002               [Page 7]
+
diff --git a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt b/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt
new file mode 100644
index 00000000..ad9e0a68
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt
@@ -0,0 +1,413 @@
+
+
+
+Internet Engineering Task Force                        Motonori Nakamura
+INTERNET-DRAFT                                          Kyoto University
+Expires: April 24, 2002                         Jun-ichiro itojun Hagino
+                                                 IIJ Research Laboratory
+                                                        October 24, 2001
+
+
+                   IPv6 SMTP operational requirements
+            draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt
+
+Status of this Memo
+
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups.  Note that other groups
+may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time.  It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as ``work in progress.''
+
+To view the list Internet-Draft Shadow Directories, see
+http://www.ietf.org/shadow.html.
+
+Distribution of this memo is unlimited.
+
+The internet-draft will expire in 6 months.  The date of expiration will
+be April 24, 2002.
+
+
+Abstract
+
+The memo lists operational requirements for IPv6 SMTP, and IPv6-capable
+MX DNS records.  As we deploy IPv6 SMTP servers, it became apparent that
+we need certain configuration in IPv6-capable MX DNS record, for stable
+dual-stack (IPv4 and IPv6) SMTP operations.  The document tries to
+clarify the problems we have in transition period between IPv4 SMTP and
+IPv6 SMTP, and operational requirements for stable IPv4/v6 SMTP
+operation.
+
+The document does not try to define any new protocol.
+
+
+1.  Summary of IPv4 MX operation
+
+For reference purpose, the section outlines how mail message delivery is
+performed in IPv4-only environment [Partridge, 1986] .
+
+
+
+NAKAMURA, HAGINO         Expires: April 24, 2002                [Page 1]
+
+
+DRAFT              IPv6 SMTP operational requirements       October 2001
+
+In IPv4 SMTP operation, we register MX records like below, for
+"example.org."  domain:
+
+     example.org.            IN MX   1  mx1.example.org.
+                             IN MX   10 mx10.example.org.
+     mx1.example.org.        IN A    1.0.0.1
+     mx10.example.org.       IN A    1.0.0.2
+
+When an MTA delivers a message to a particular destination (say it is to
+foo@example.org), the MTA would send DNS queries to lookup DNS database
+in the following order:
+
+o Lookup MX record for "example.org.".
+
+  o If an MX record is returned, try to lookup A record on the righthand
+    side of the MX record.
+
+  o If a CNAME record is returned, try to chase the CNAME chain.
+    Eventually we will reach some A record.
+
+    NOTE: from RFC2181 MX records must not point CNAME records [Elz,
+    1997] .  However, it has been permitted in older RFCs [Partridge,
+    1986] .  We mention CNAME chasing logic here just for backward
+    compatibility.  Implementers may want to avoid CNAME chasing to be
+    more conformant to RFC2181.
+
+  o If MX lookup failed with NO_DATA, it means that there is no MX
+    record but there can be other record for "example.org.".  Lookup A
+    record for "example.org.".
+
+  o If MX lookup failed with HOST_NOT_FOUND, it means that there is no
+    record at all for "example.org.".  This means a delivery failure.
+
+
+2.  MX records and IPv6 SMTP operation
+
+The following sections talk about how to make IPv4 SMTP and IPv6 SMTP
+coexist, under dual-stack environment during the transition period
+between IPv4 to IPv6.  In the future, when we have completely migrated
+to IPv6-only network, we can forget about IPv4/v6 SMTP interaction.
+
+As IPv6 DNS lookup RFCs [Thomson, 1995; Crawford, 2000] use IN class for
+both IPv4 and IPv6, we will use IN MX records for both IPv4 and IPv6.
+
+For simplicity, the document lists DNS records for IPv6 address as AAAA
+records, not as A6 records [Crawford, 2000] .  In reality, we can use a
+chain of A6 records, instead of AAAA records.
+
+There are couple of technologies defined for IPv4 and IPv6 transition.
+The document concentrates on issues with dual stack environment.
+Translators do not need special consideration from SMTP point of view;
+If we have SMTP traffic from IPv6 MTA to IPv4 MTA over an IPv6-to-IPv4
+
+
+NAKAMURA, HAGINO         Expires: April 24, 2002                [Page 2]
+
+
+DRAFT              IPv6 SMTP operational requirements       October 2001
+
+translator, the traffic will be considered as a normal IPv4 SMTP
+traffic, from the IPv4 MTA point of view.  We may, however, need some
+consideration on translators for protocols like IDENT [StJohns, 1993] .
+
+
+3.  SMTP sender algorithm in dual stack environment
+
+When we lookup MX records for the domain in IPv4/v6 dual stack
+environment, we will see records like below:
+
+     example.org.            IN MX   1  mx1.example.org.
+                             IN MX   10 mx10.example.org.
+     mx1.example.org.        IN A    1.0.0.1          ; IPv4/v6 dual stack
+                             IN AAAA 3ffe:501:ffff::1
+     mx10.example.org.       IN AAAA 3ffe:501:ffff::2 ; IPv6 only
+
+For single MX record, we have many possibility for the final lookup
+result, including: (a) single, or multiple A records for IPv4
+destination, (b) single, or multiple AAAA records for IPv6 destination,
+(c) mixture of A and AAAA records.  As we can define multiple MX records
+with different preference value, we also need to go through multiple
+addresses based on multiple MXes.  We need to cope with domains without
+MX records, and failure recovery cases too.
+
+The algorithm for a SMTP sender would be like this.
+
+(1)  Lookup MX record for the destination domain.  If a CNAME record is
+     returned, go back to step (1) with the queried result.  If MX
+     records are returned, go to step (2) with the result.  If NO_DATA
+     is returned, go to step (3) as there is no MX record.  If
+     HOST_NOT_FOUND is returned, there is no domain, raise permanent
+     email delivery failure (finish).
+
+     NOTE: regarding to MX records pointing CNAME records, see a note in
+     the previous section.
+
+(2)  We have multiple MX records with us.  Loop steps from (3) to (8),
+     based on MX preference values, in ascending order.
+
+(3)  If the source MTA has IPv4 capability, lookup A record.  Keep the
+     resulting address till step (5).
+
+(4)  If the source MTA has IPv6 capability, lookup AAAA record.
+
+(5)  Reorder queried result based on implementation-dependent preference
+     between A and AAAA records.  If you would like to encourage the
+     transition from IPv4 SMTP to IPv6 SMTP, AAAAs should take
+     precedence.
+
+(6)  Loop steps from (7) to (8), for all the addresses (or part of the
+     list of addresses) we have.  If no reachable destination is found,
+     and if we are going through a list of MX records, go back to (3)
+
+
+NAKAMURA, HAGINO         Expires: April 24, 2002                [Page 3]
+
+
+DRAFT              IPv6 SMTP operational requirements       October 2001
+
+     and try the next MX record.  If we do not have a list of MX
+     records, or we have reached the end of the list of MX records,
+     raise temporary delivery failure (finish).
+
+(7)  Try to make a TCP connection to the destination.  If it fails, try
+     the next address we have.  If it succeeds, go to step (8).
+
+(8)  Try a SMTP protocol negotiation.  If SMTP protocol negotiation
+     fails with TEMPFAIL (4xx), go back to (3) and try the next MX
+     record.  If it succeeds, SMTP delivery was successful (finish).
+
+
+4.  MX configuration in receipient domain
+
+4.1.  Ensuring reachability for both protocol versions
+
+If a site has IPv4/v6 dual stack reachability, the site SHOULD configure
+both A and AAAA records onto its MX hosts.  It will help both IPv4 and
+IPv6 senders to reach the site efficienlty.
+
+4.2.  Reachability between primary and secondary MX
+
+When we configure MX records onto DNS database in dual-stack
+environment, we need to be careful about reachability between MX hosts.
+Suppose we try to gather all inbound email to primary MX host,
+mx1.example.org.
+
+     example.org.    IN MX   1   mx1.example.org.
+                     IN MX   10  mx10.example.org.
+                     IN MX   100 mx100.example.org.
+
+If mx1.example.org is an IPv6 only node and the rest are IPv4 only node,
+we have no reachability between primary MX host and the rest.  Once an
+email reaches one of secondary MX host, the email will never reach the
+primary MX.
+
+     ; the configuration is troublesome.
+     ; no secondary MX can reach mx1.example.org.
+     example.org.    IN MX   1   mx1.example.org.     ; IPv6 only
+                     IN MX   10  mx10.example.org.    ; IPv4 only
+                     IN MX   100 mx100.example.org.   ; IPv4 only
+
+The easiest possible configuration is to configure the primary MX host
+as an IPv4/v6 dual stack node.  By doing so, secondaries will have no
+problem reaching the primary MX host.
+
+     ; the configuration works just fine.
+     ; emails reaches from secondary MX to primary with no trouble.
+     example.org.    IN MX   1   mx1.example.org.     ; IPv4/v6 dual stack
+                     IN MX   10  mx10.example.org.    ; IPv4 only
+                     IN MX   100 mx100.example.org.   ; IPv6 only
+
+
+
+NAKAMURA, HAGINO         Expires: April 24, 2002                [Page 4]
+
+
+DRAFT              IPv6 SMTP operational requirements       October 2001
+
+There are many other ways to ensure the reachability between secondary
+MX and primary MX.  For example, we could configure secondary MX to
+route emails statically, without considering DNS MX configuration.  Or
+we could estalish alternative email routing path (i.e. UUCP, or via
+IPv4/v6 translator) between secondary MX and the primary MX.
+
+
+5.  Operational experiences
+
+Many of the existing IPv6-ready MTAs seem to work in the way documented
+in section 3.
+
+>From past experiments and operational experiences, it is known that most
+of the existing IPv4-only MTAs will not get confused by AAAA records,
+registered for MX hostnames.  No experiments were conducted with A6
+records.
+
+There were, however, cases where IPv6-ready MTAs get confused by broken
+DNS servers.  When attempting to canonify a hostname, some broken name
+servers will return SERVFAIL (a temporary failure) on AAAA record
+lookups.  Upon this temporary failure, the mail is queued up for a later
+attempt.  These broken DNS servers should get fixed, for this issue as
+well as for other IPv6 operations.
+
+
+6.  Open issues
+
+o How to interpret scoped address in email addresses, on MTAs.  As we
+  relay emails between MTAs, interpretation of scoped address can be
+  different between MTAs, as intermediate MTAs may be in different scope
+  zone as the originator.  If we get scoped IPv6 address as a result of
+  DNS lookups, how MTAs should behave?
+
+  If we consider scoped address in ``route-addr'' specification
+  [Crocker, 1982] like
+
+                 <@kame.net,@[fec0::1]:itojun@itojun.org>
+
+  it gets more trickier.  Luckily, route-addr form was obsoleted by
+  RFC2822 [Resnick, 2001] .
+
+
+7.  Security consideration
+
+As presented in ``Open issues'' section, it could be problematical if
+route-addr email address format is used across multiple scope zones.
+MTAs would need to reject emails with improper route-addr email address
+formats.  A possible example of improper route-addr format would be like
+this: an email from outside of the site border, which carries numeric
+site-local address in route-addr format.
+
+
+
+
+NAKAMURA, HAGINO         Expires: April 24, 2002                [Page 5]
+
+
+DRAFT              IPv6 SMTP operational requirements       October 2001
+
+References
+
+Partridge, 1986.
+C. Partridge, "Mail routing and the domain system" in RFC974 (January
+1986). ftp://ftp.isi.edu/in-notes/rfc974.txt.
+
+Elz, 1997.
+R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181
+(July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt.
+
+Thomson, 1995.
+S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
+RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
+
+Crawford, 2000.
+M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
+Address Aggregation and Renumbering" in RFC2874 (July 2000).
+ftp://ftp.isi.edu/in-notes/rfc2874.txt.
+
+StJohns, 1993.
+M. StJohns, "Identification Protocol" in RFC1413 (January 1993).
+ftp://ftp.isi.edu/in-notes/rfc1413.txt.
+
+Crocker, 1982.
+D. Crocker, "Standard for the format of ARPA Internet text messages" in
+RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt.
+
+Resnick, 2001.
+P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001).
+ftp://ftp.isi.edu/in-notes/rfc2822.txt.
+
+
+Change history
+
+00 -> 01
+     Correct email address notation for source-routed emails, based on a
+     comment from Gregory Neil Shapiro.
+
+01 -> 02
+     Refer RFC2822, not 822.  Use example.org, not sample.org.  Based on
+     comments from Arnt Gulbrandse.  Add Operational experiences
+     section.  Clarify MX-points-to-CNAME, based on comments from Mohsen
+     Souissi.
+
+02 -> 03
+     Some cases, IPv6-ready MTAs gets troubled by wrong DNS server
+     responses for AAAA queries.  From Gregory Neil Shapiro.
+
+
+
+
+
+
+
+NAKAMURA, HAGINO         Expires: April 24, 2002                [Page 6]
+
+
+DRAFT              IPv6 SMTP operational requirements       October 2001
+
+Acknowledgements
+
+The draft was written based on discussions with Japanese IPv6 users, and
+help from WIDE research group.  Here are a (probably incomplete) list of
+people contributed to the draft: Gregory Neil Shapiro, Arnt Gulbrandse,
+and Mohsen Souissi.
+
+
+Author's address
+
+     Motonori NAKAMURA
+     Center for Information and Multimedia Studies, Kyoto University
+     Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN
+     Tel: +81-75-753-9063
+     Fax: +81-75-753-9056
+     Email: motonori@media.kyoto-u.ac.jp
+
+     Jun-ichiro itojun HAGINO
+     Research Laboratory, Internet Initiative Japan Inc.
+     Takebashi Yasuda Bldg.,
+     3-13 Kanda Nishiki-cho,
+     Chiyoda-ku,Tokyo 101-0054, JAPAN
+     Tel: +81-3-5259-6350
+     Fax: +81-3-5259-6351
+     Email: itojun@iijlab.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NAKAMURA, HAGINO         Expires: April 24, 2002                [Page 7]
+
diff --git a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt b/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
new file mode 100644
index 00000000..f8198f1a
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
@@ -0,0 +1,472 @@
+
+
+
+Internet Engineering Task Force                        Motonori Nakamura
+INTERNET-DRAFT                                          Kyoto University
+Expires: May 8, 2002                            Jun-ichiro itojun Hagino
+                                                 IIJ Research Laboratory
+                                                        November 8, 2001
+
+
+                   IPv6 SMTP operational requirements
+            draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
+
+Status of this Memo
+
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups.  Note that other groups
+may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time.  It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as ``work in progress.''
+
+To view the list Internet-Draft Shadow Directories, see
+http://www.ietf.org/shadow.html.
+
+Distribution of this memo is unlimited.
+
+The internet-draft will expire in 6 months.  The date of expiration will
+be May 8, 2002.
+
+
+Abstract
+
+This document lists operational requirements for IPv6 SMTP and
+IPv6-capable MX DNS records.  As IPv6 SMTP servers are deployed, it has
+become apparent that certain configurations are necessary in
+IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP
+operation.  This document clarifies the problems that exist in the
+transition period between IPv4 SMTP and IPv6 SMTP.  It also defines
+operational requirements for stable IPv4/v6 SMTP operation.
+
+This document does not define any new protocol.
+
+
+1.  Summary of IPv4 MX operation
+
+For reference purposes, this section outlines how email message delivery
+is performed in an IPv4-only environment [Partridge, 1986] .
+
+
+
+NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 1]
+
+
+DRAFT              IPv6 SMTP operational requirements      November 2001
+
+In IPv4 SMTP operation, the MX record "example.org." would be registered
+as follows:
+
+     example.org.            IN MX   1  mx1.example.org.
+                             IN MX   10 mx10.example.org.
+     mx1.example.org.        IN A    192.0.2.1
+     mx10.example.org.       IN A    192.0.2.2
+
+When an MTA wishes to deliver a message to a particular destination
+(e.g.  "foo@example.org"), the MTA sends DNS queries in the following
+order:
+
+o Lookup MX record for "example.org.".
+
+  o If an MX record is returned, lookup an A record for the right-hand
+    side of the MX record.
+
+  o If a CNAME record is returned, try to chase the CNAME chain.
+    Eventually an A record will be reached.
+
+    NOTE: RFC2181 [Elz, 1997] prohibits MX records from pointing to
+    CNAME records.  However, this was not prohibited in earlier RFCs.
+    [Partridge, 1986] CNAME chasing logic is mentioned here just for
+    backwards compatibility.  Implementers may want to avoid CNAME
+    chasing to better conform with RFC2181.
+
+  o If the MX lookup fails with NO_DATA, it means that there is no MX
+    record, but there may be other records (e.g. "example.org.").
+    Lookup the A record for "example.org.".
+
+  o If the MX lookup fails with HOST_NOT_FOUND, it means that there is
+    no record at all for "example.org.".  This results in a delivery
+    failure.
+
+
+2.  MX records and IPv6 SMTP operation
+
+The following sections explain how to make IPv4 SMTP and IPv6 SMTP
+coexist in a dual-stack environment during the transition period between
+an IPv4-only environment and an IPv6-only environment.  In the future,
+when the migration to an IPv6-only network is complete, IPv4/v6 SMTP
+interaction will be ignored.
+
+Similar to the way RFC's for IPv6 DNS lookup [Thomson, 1995; Crawford,
+2000] use IN class for both IPv4 and IPv6, IN MX records will be used
+for both IPv4 and IPv6.
+
+For simplicity, this document lists DNS records for IPv6 addresses as
+AAAA records, not as A6 records [Crawford, 2000] .  In reality, a chain
+of A6 records can be used, instead of AAAA records.
+
+
+
+
+NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 2]
+
+
+DRAFT              IPv6 SMTP operational requirements      November 2001
+
+There are several technologies defined for the transition from IPv4 to
+IPv6.  This document concentrates on SMTP issues in a dual-stack
+environment.  Afterall, there are no special SMTP considerations for
+translators; If there is SMTP traffic from an IPv6 MTA to an IPv4 MTA
+over an IPv6-to-IPv4 translator, the IPv4 MTA will consider this normal
+IPv4 SMTP traffic.  Protocols like IDENT [StJohns, 1993] , however, may
+require special consideration when translators are used.
+
+This document does not discuss the problems encountered when the sending
+MTA and the receiving MTA have no common protocol (e.g. the sending MTA
+is IPv4-only while the receiving MTA is IPv6-only).  Such a situation
+should be resolved by making either side dual-stack or by making either
+side use a protocol translator.
+
+
+3.  SMTP sender algorithm in a dual-stack environment
+
+In a dual-stack environment MX records for a domain resemble the
+following:
+
+     example.org.            IN MX   1  mx1.example.org.
+                             IN MX   10 mx10.example.org.
+     mx1.example.org.        IN A    192.0.2.1        ; dual-stack
+                             IN AAAA 3ffe:501:ffff::1
+     mx10.example.org.       IN AAAA 3ffe:501:ffff::2 ; IPv6 only
+
+For a single MX record there are many possible final states, including:
+(a) one or more A records for the IPv4 destination, (b) one or more AAAA
+records for the IPv6 destination, (c) a mixture of A and AAAA records.
+Because multiple MX records may be defined using different preference
+values, multiple addresses based on multiple MX's must be traversed.
+Domains without MX records and failure recovery cases must be handled
+properly as well.
+
+The algorithm for an SMTP sender is basically the same as that for an
+IPv4-only sender, but it now includes AAAA lookups of MX records for
+SMTP-over-IPv6 delivery.  IPv4/v6 dual stack destinations should be
+treated just like multihomed destinations as described in RFC2821
+[Klensin, 2001] section 5.  When there is no reachable destionation
+address record found (for example, the sender MTA is IPv4 only and there
+are no A records available) the case should be treated just like MX
+records without address records.
+
+     ; if the sender MTA is IPv4 only, email delivery to a.example.org
+     ; should fail with the same error as deliveries to b.example.org.
+     a.example.org.          IN MX    1  mx1.a.example.org.
+     mx1.a.example.org.      IN AAAA  3ffe:501:ffff::1 ; IPv6 only
+     b.example.org.          IN MX    1  mx1.b.example.org.
+     mx1.b.example.org.      IN HINFO "NO ADDRESS RECORDS"
+
+
+
+
+
+NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 3]
+
+
+DRAFT              IPv6 SMTP operational requirements      November 2001
+
+(1)  Lookup the MX record for the destination domain.  If a CNAME record
+     is returned, go to step (1) with the query's result.  If any MX
+     records are returned, go to step (2) with the query's result.  If
+     NO_DATA is returned, there is no MX record.  Go to step (3).  If
+     HOST_NOT_FOUND is returned, there is no domain.  Raise a permanent
+     email delivery failure.  Finish.
+
+     NOTE:  the previous section contains a note about MX records that
+     point to CNAME records.
+
+(2)  There are multiple MX records.  Sort the MX records in ascending
+     order based on their preference values, and loop over steps (3) to
+     (8).
+
+(3)  If the sending MTA has IPv4 capability, lookup the A record.  Keep
+     the resulting address until step (5).
+
+(4)  If the sending MTA has IPv6 capability, lookup the AAAA record.
+
+(5)  If there is no A or AAAA record present, try the next MX record (go
+     to step (3)).  Sort the query's result based on the
+     implementation's preference of A or AAAA records.  If it is
+     desirable to encourage the transition from IPv4 SMTP to IPv6 SMTP,
+     AAAA records should take precedence.
+
+(6)  For each of the addresses or each part of the list of addresses,
+     loop over steps (7) to (8).  If no reachable destination is found,
+     and if a list of MX records is being traversed, try the next MX
+     record (go to step (3)).  If there is no list of MX records, or if
+     the end of the list of MX records has been reached, raise a
+     temporary email delivery failure.  Finish.
+
+(7)  Try to make a TCP connection to the destination.  If unsuccessful,
+     try the next available address.  If successful, go to step (8).
+
+(8)  Try an SMTP protocol negotiation.  If the SMTP protocol negotiation
+     fails with TEMPFAIL (4xx), try the next MX record (go to step (3)).
+     If successful, SMTP delivery has succeeded.  Finish.
+
+
+4.  MX configuration in the recipient domain
+
+4.1.  Ensuring reachability for both protocol versions
+
+If a site has dual-stack reachability, the site SHOULD configure both A
+and AAAA records for its MX hosts.  This will help both IPv4 and IPv6
+senders to reach the site efficiently.
+
+4.2.  Reachability between the primary and secondary MX
+
+When entering MX records in a DNS database in a dual-stack environment,
+reachability between MX hosts must be considered carefully.  Suppose all
+
+
+NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 4]
+
+
+DRAFT              IPv6 SMTP operational requirements      November 2001
+
+inbound email is to be gathered at the primary MX host,
+"mx1.example.org.":
+
+     example.org.    IN MX   1   mx1.example.org.
+                     IN MX   10  mx10.example.org.
+                     IN MX   100 mx100.example.org.
+
+If "mx1.example.org" is an IPv6-only node, and the others are IPv4-only
+nodes, there is no reachability between the primary MX host and the
+other MX hosts.  When email reaches one of the secondary MX hosts, it
+cannot be relayed to the primary MX host.
+
+     ; This configuration is troublesome.
+     ; No secondary MX can reach mx1.example.org.
+     example.org.    IN MX   1   mx1.example.org.     ; IPv6 only
+                     IN MX   10  mx10.example.org.    ; IPv4 only
+                     IN MX   100 mx100.example.org.   ; IPv4 only
+
+The easiest possible configuration is to configure the primary MX host
+as a dual-stack node.  By doing so, secondary MX hosts will have no
+problem reaching the primary MX host.
+
+     ; This configuration works well.
+     ; The secondary MX hosts are able to relay email to the primary MX host
+     ; without any problems.
+     example.org.    IN MX   1   mx1.example.org.     ; dual-stack
+                     IN MX   10  mx10.example.org.    ; IPv4 only
+                     IN MX   100 mx100.example.org.   ; IPv6 only
+
+There are many other ways to ensure that the primary MX host and the
+secondary MX hosts can reach one another.  For example, it is possible
+to configure the secondary MX hosts to route email statically, i.e.
+without considering the DNS MX configuration.  It is also possible to
+establish an alternate email routing path (e.g. UUCP or an IPv4/v6
+translator) between the secondary MX host and the primary MX host.
+
+
+5.  Operational experience
+
+Many of the existing IPv6-ready MTA's appear to work in the way
+documented in section 3.
+
+>From past experiments and operational experience, it is known that most
+of the existing IPv4-only MTA's will not be confused by AAAA records
+that are registered for MX hostnames.  No experiments were conducted
+with A6 records.
+
+There were, however, cases where IPv6-ready MTA's were confused by
+broken DNS servers.  When attempting to canonify a hostname, some broken
+name servers return SERVFAIL, a temporary failure, on AAAA record
+lookups.  Upon this temporary failure, the email is queued for a later
+attempt.  In the interest of IPv4/v6 interoperability, these broken DNS
+
+
+NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 5]
+
+
+DRAFT              IPv6 SMTP operational requirements      November 2001
+
+servers should be fixed.
+
+
+6.  Open issues
+
+o How should scoped addresses in email addresses be interpreted on
+  MTA's?  As email is relayed between MTA's, interpretation of scoped
+  addresses can be different between MTA's.  Afterall, intermediate
+  MTA's may be in different scope zones than the originator.  If a
+  scoped IPv6 address is returned as the result of a DNS lookup, how
+  should MTA's behave?
+
+  If scoped addresses in ``route-addr'' specifications  [Crocker, 1982]
+  are considered, e.g.
+
+                 <@kame.net,@[fec0::1]:itojun@itojun.org>
+
+  it gets even trickier.  Luckily, the route-addr form was obsoleted by
+  RFC2822 [Resnick, 2001] .
+
+
+7.  Security considerations
+
+As mentioned in the ``Open issues'' section, it could be problematic if
+the route-addr email address format is used across multiple scope zones.
+MTA's would need to reject email with improper route-addr email address
+formats.  One example of an improper route-addr format is an email from
+outside the site border which carries a numeric site-local address in
+the route-addr format.
+
+
+References
+
+Partridge, 1986.
+C. Partridge, "Mail routing and the domain system" in RFC974 (January
+1986). ftp://ftp.isi.edu/in-notes/rfc974.txt.
+
+Elz, 1997.
+R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181
+(July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt.
+
+Thomson, 1995.
+S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
+RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
+
+Crawford, 2000.
+M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
+Address Aggregation and Renumbering" in RFC2874 (July 2000).
+ftp://ftp.isi.edu/in-notes/rfc2874.txt.
+
+StJohns, 1993.
+M. StJohns, "Identification Protocol" in RFC1413 (January 1993).
+
+
+NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 6]
+
+
+DRAFT              IPv6 SMTP operational requirements      November 2001
+
+ftp://ftp.isi.edu/in-notes/rfc1413.txt.
+
+Klensin, 2001.
+J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April
+2001). ftp://ftp.isi.edu/in-notes/rfc2821.txt.
+
+Crocker, 1982.
+D. Crocker, "Standard for the format of ARPA Internet text messages" in
+RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt.
+
+Resnick, 2001.
+P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001).
+ftp://ftp.isi.edu/in-notes/rfc2822.txt.
+
+
+Change history
+
+00 -> 01
+     Corrected the email address notation for source-routed emails,
+     based on a comment from Gregory Neil Shapiro.
+
+01 -> 02
+     Change a reference to refer to RFC2822, not 822.  Used
+     "example.org", not "sample.org".  These changes were based on
+     comments from Arnt Gulbrandsen.  Added an ``Operational
+     experiences'' section.  Clarified the case where an MX record
+     points to a CNAME record, based on comments from Mohsen Souissi.
+
+02 -> 03
+     In some cases, IPv6-ready MTA's are troubled by incorrect DNS
+     server responses for AAAA queries.  This change was based on
+     comments from Gregory Neil Shapiro.
+
+03 -> 04
+     Grammar cleanups by JJ Behrens.  More text on the delivery error
+     cases.
+
+
+Acknowledgements
+
+This draft was written based on discussions with Japanese IPv6 users and
+help from the WIDE research group.  Here is a (probably incomplete) list
+of people who contributed to the draft: Gregory Neil Shapiro, Arnt
+Gulbrandsen, Mohsen Souissi, and JJ Behrens.
+
+
+Author's address
+
+
+
+
+
+
+
+NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 7]
+
+
+DRAFT              IPv6 SMTP operational requirements      November 2001
+
+     Motonori NAKAMURA
+     Center for Information and Multimedia Studies, Kyoto University
+     Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN
+     Tel: +81-75-753-9063
+     Fax: +81-75-753-9056
+     Email: motonori@media.kyoto-u.ac.jp
+
+     Jun-ichiro itojun HAGINO
+     Research Laboratory, Internet Initiative Japan Inc.
+     Takebashi Yasuda Bldg.,
+     3-13 Kanda Nishiki-cho,
+     Chiyoda-ku,Tokyo 101-0054, JAPAN
+     Tel: +81-3-5259-6350
+     Fax: +81-3-5259-6351
+     Email: itojun@iijlab.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NAKAMURA, HAGINO          Expires: May 8, 2002                  [Page 8]
+
diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-05.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-05.txt
new file mode 100644
index 00000000..7ad94698
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-hint-05.txt
@@ -0,0 +1,1116 @@
+
+
+Network Working Group                                           E. Burger 
+Internet Draft                                         SnowShore Networks 
+Document: draft-ietf-vpim-hint-05.txt                          E. Candell 
+Category: Standards Track                        Comverse Network Systems 
+Expires October 2001                                             C. Eliot 
+                                                    Microsoft Corporation 
+                                                                 G. Klyne 
+                                                   Baltimore Technologies 
+                                                           April 16, 2001 
+ 
+ 
+                   Message Context for Internet Mail 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1].  
+    
+   Internet-Drafts are working documents of the Internet Engineering 
+   Task Force (IETF), its areas, and its working groups. Note that 
+   other groups may also distribute working documents as Internet-
+   Drafts. 
+    
+   Internet-Drafts are draft documents valid for a maximum of six 
+   months and may be updated, replaced, or obsoleted by other documents 
+   at any time. It is inappropriate to use Internet-Drafts as reference 
+   material or to cite them other than as "work in progress." 
+    
+   The list of current Internet-Drafts can be accessed at 
+   http://www.ietf.org/ietf/1id-abstracts.txt . 
+    
+   The list of Internet-Draft Shadow Directories can be accessed at 
+   http://www.ietf.org/shadow.html . 
+    
+   This document is a work product of the IETF Voice Profile for 
+   Internet Mail (VPIM) Work Group. 
+    
+    
+    
+1. Abstract 
+    
+   This memo describes a new RFC822 message header, "Message-Context".  
+   This header provides information about the context and presentation 
+   characteristics of a message. 
+    
+   A receiving user agent (UA) may use this information as a hint to 
+   optimally present the message. 
+    
+
+
+
+
+
+ 
+                           Expires 10/16/01                   [Page 1] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+Table of Contents 
+    
+1. Abstract...........................................................1 
+2. Introduction.......................................................3 
+3. Conventions used in this document..................................3 
+4. Motivation.........................................................4 
+5. Functional Requirements............................................5 
+6. Determining the Message Context....................................6 
+7. Message-Context Reference Field....................................7 
+7.1. Message-Context Syntax...........................................7 
+7.2. message-context-class Syntax.....................................7 
+7.2.1. voice-message..................................................8 
+7.2.2. fax-message....................................................8 
+7.2.3. pager-message..................................................8 
+7.2.4. multimedia-message.............................................8 
+7.2.5. text-message...................................................8 
+7.2.6. none...........................................................9 
+8. Security Considerations............................................9 
+9. IANA Considerations................................................9 
+9.1. Message-Context Registration.....................................9 
+9.2. Primary Context Class Registrations.............................10 
+9.2.1. Registration Template.........................................10 
+9.2.2. voice-message.................................................10 
+9.2.3. fax-message...................................................11 
+9.2.4. pager-message.................................................11 
+9.2.5. multimedia-message............................................12 
+9.2.6. text-message..................................................12 
+9.2.7. none..........................................................13 
+10. APPENDIX: Some messaging scenarios...............................13 
+10.1. Internet e-mail................................................14 
+10.2. Pager service..................................................14 
+10.3. Facsimile......................................................15 
+10.4. Voice mail.....................................................15 
+10.5. Multimedia message.............................................16 
+11. References.......................................................16 
+12. Acknowledgments..................................................17 
+13. Author's Addresses...............................................18 
+14. Full Copyright Statement.........................................19 
+    
+
+
+
+
+
+
+
+
+  
+Burger et. al.             Expires 10/16/01                   [Page 2] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+2. Introduction 
+    
+   This document describes a mechanism to allow senders of an Internet 
+   mail message to convey the message's contextual information.  Taking 
+   account of this information, the receiving user agent (UA) can make 
+   decisions that improve message presentation for the user in the 
+   context the sender and receiver expects. 
+    
+   In this document, the "message context" conveys information about 
+   the way the user expects to interact with the message.  For example, 
+   a message may be e-mail, voice mail, fax mail, etc.  A smart UA may 
+   have specialized behavior based on the context of the message. 
+    
+   This document specifies a RFC 822 header called "Message-Context".  
+   The mechanism is in some ways similar to the use of the Content-
+   Disposition MIME entity described in [2].  Content-Disposition gives 
+   clues to the receiving User Agent (UA) for how to display a given 
+   body part.  Message-Context can give clues to the receiving UA for 
+   the presentation of the message.  This allows the receiving UA to 
+   present the message in a meaningful and helpful way to the 
+   recipient. 
+    
+   Typical uses for this mechanism include: 
+   o    Selecting a special viewer for a given message. 
+   o    Selecting an icon indicating the kind of message in a displayed 
+        list of messages. 
+   o    Arranging messages in an inbox display. 
+   o    Filtering messages the UA presents when the user has limited 
+        access. 
+ 
+ 
+3. Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [3]. 
+    
+   FORMATTING NOTE: Notes, such at this one, provide additional 
+   nonessential information that the reader may skip without missing 
+   anything essential.  The primary purpose of these non-essential 
+   notes is to convey information about the rationale of this document, 
+   or to place this document in the proper historical or evolutionary 
+   context.  Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+  
+Burger et. al.             Expires 10/16/01                   [Page 3] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+    
+4. Motivation 
+    
+   Multimedia messaging systems receive messages that a UA may present 
+   in variety of ways.  For example, traditional e-mail uses simple 
+   text messages that the recipient displays and edits.  One UA may 
+   automatically print Fax images.  Another UA may play voice messages 
+   through a telephone handset.  Likewise, a receiving desktop computer 
+   may process or present documents transferred over e-mail using a 
+   local application.  Emerging and future developments may deliver 
+   other forms of information that have their own characteristics for 
+   user presentation, such as video messages and pager messages. 
+    
+   An often-requested characteristic for multimedia messaging systems 
+   is to collect received messages in a "universal inbox", and to offer 
+   them to the user as a combined list. 
+    
+   In the context of "unified messaging", different message contexts 
+   may have different implied semantics.  For example, some users may 
+   perceive voicemail to have an implicit assumption of urgency.  Thus 
+   they may wish to gather them together and process them before other 
+   messages.  This results in the end-user receiving agent needing to 
+   be able to identify voicemail and distinguish it from other 
+   messages. 
+    
+   The uses of this kind of presentation characteristic for each 
+   message is multi-fold: 
+    
+   o    Display an indication to the user (e.g., by a suitably 
+        evocative icon along with other summary fields), 
+    
+   o    Auto-forward a given message type into another messaging 
+        environment (e.g., a page to a mobile short message service), 
+    
+   o    Prioritize and group messages in an inbox display list, 
+    
+   o    Suggest appropriate default handling for presentation, 
+    
+   o    Suggest appropriate default handling for reply, forward, etc., 
+        and 
+    
+   A problem faced by multimedia messaging systems is that it is not 
+   always easy to decide the context of a received message.  For 
+   example, consider the following scenarios. 
+    
+   o    A message that contains audio and image data:  Is this a fax 
+        message that happens to have some voice commentary?  Is it a 
+        voice message that is accompanied by some supplementary 
+        diagrams?  Is it a fully multimedia message, in which all parts 
+        are expected to carry equal significance? 
+    
+
+  
+Burger et. al.             Expires 10/16/01                   [Page 4] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+   o    A message containing text and audio data:  Is this e-mail with 
+        an MP3 music attachment?  Is it a voice message that happens to 
+        have been generated with an initial text header for the benefit 
+        of non-voice-enabled e-mail receivers? 
+    
+   The message context does relate to the message media content.  
+   However, it is not the same thing.  As shown above, the media type 
+   used in a message is not sufficient to indicate the message context.  
+   One cannot determine a priori which media types to use in 
+   alternative (gateway) message.  Also, what if the user cares about 
+   distinguishing traditional e-mail text from SMS messages?  They are 
+   both the same media type, text, but they have different user 
+   contexts. 
+    
+    
+5. Functional Requirements 
+    
+   The goals stated above lead to the following functional 
+   requirements. 
+    
+   For receivers: 
+   o    Identify a message as belonging to a message class. 
+    
+   o    Incorrect or invalid message classification must not result in 
+        failure to transfer or inability to present a message. 
+    
+    
+   For senders: 
+   o    Specify message classes by the originating user's choice of 
+        authoring tool or simple user interaction. 
+    
+    
+   For both: 
+   o    Specify a well-defined set of message classes to make 
+        interoperability between mail user agents (UAs) possible. 
+    
+   o    Message classification information has to be interpretable in 
+        reasonable fashion by many different user agent systems. 
+    
+   o    The mechanism should be extensible to allow for the 
+        introduction of new kinds of messages. 
+    
+   NOTE: We specifically do not specify user agent behavior when the 
+   user agent forwards a message.  Clearly, the user agent, being 
+   message-context-aware, should provide a meaningful message-context.  
+   It is obvious what to do for the easy cases.  Messages that the user 
+   simply forwards will most likely keep the context unchanged.  
+   However, it is beyond the scope of this document to specify the user 
+   agent behavior for any other scenario. 
+    
+
+
+  
+Burger et. al.             Expires 10/16/01                   [Page 5] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+6. Determining the Message Context 
+    
+   One method of indicating the interpretation context of a message is 
+   to examine the media types in the message.  However, this requires 
+   the UA to scan the entire message before it can make this 
+   determination.  This approach is particularly burdensome for the 
+   multi-media mail situation, as voice and especially video mail 
+   objects are quite large. 
+    
+   We considered indicating the message context by registering a 
+   multipart/* MIME subtype (Content-Type).  For example, the VPIM Work 
+   Group has registered multipart/voice-message to indicate that a 
+   message is primarily voice mail [4].  However, multipart/voice-
+   message is identical in syntax to multipart/mixed.  The only 
+   difference is that VPIM mail transfer agents and user agents 
+   recognize that they can perform special handling of the message 
+   based on it being a voice mail message.  Moreover, Content-Type 
+   refers to a given MIME body part, not to the message as a whole. 
+    
+   We wish to avoid scanning the entire message.  In addition, we wish 
+   to avoid having to create multiple aliases for multipart/mixed every 
+   time someone identifies a new primary content type.  Multiple 
+   aliases for multipart/mixed are not desirable as they remove the 
+   possibility for specifying a message as multipart/alternate, 
+   multipart/parallel, or multipart/encrypted, for example. 
+    
+   Since the message context is an attribute of the entire message, it 
+   is logical to define a new top-level (RFC 822 [5]) message 
+   attribute.  To this end, this document introduces the message 
+   attribute "Message-Context". 
+    
+   Message-Context only serves to identify the message context.  It 
+   does not provide any indication of content that the UA must be 
+   capable of delivering.  It does not imply any message disposition or 
+   delivery notification.  There is a related effort to define Critical 
+   Content of Internet Mail [6] that one might use to perform these 
+   tasks. 
+    
+   Message-Context is only an indicator.  We do not intend for it to 
+   convey information that is critical for presentation of the message.  
+   One can conceive of goofy situations, such as a message marked 
+   "voice-message" but without an audio body part.  In this case, the 
+   fact that the contents of a message donÆt match its context does not 
+   mean the receiving system should generate an error report or fail to 
+   deliver or process the message.  
+    
+    
+
+
+
+
+
+  
+Burger et. al.             Expires 10/16/01                   [Page 6] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+7. Message-Context Reference Field 
+    
+   The Message-Context reference field is a top-level header inserted 
+   by the sending UA to indicate the context of the message. 
+    
+   A receiving user agent MUST NOT depend on the indicated message-
+   context value in a way that prevents proper presentation of the 
+   message.  If the value is incorrect or does not match the message 
+   content, the receiving user agent MUST still be capable of 
+   displaying the message content at least as meaningfully as it would 
+   if no Message-Context value were present. 
+    
+   One can envision situations where a well-formed message ends up not 
+   including a media type one would expect from the message-context. 
+   For example, consider a voice messaging system that records a voice 
+   message and also performs speech-to-text processing on the message.  
+   The message then passes through a content gateway, such as a 
+   firewall, that removes non-critical body parts over a certain 
+   length.  The receiving user agent will receive a message in the 
+   voice-message context that has only a text part and no audio.  Even 
+   though the message does not have audio, it is still in the voice 
+   message context. 
+    
+   Said differently, the receiving UA can use the message-context to 
+   determine whether, when, and possibly where to display a message.  
+   However, the message-context should not affect the actual rendering 
+   or presentation.  For example, if the message is in the voice-
+   message context, then don't try to send it to a fax terminal.  
+   Conversely, consider the case of a message in the voice-message 
+   context that gets delivered to a multimedia voice terminal with a 
+   printer.  However, this message only has fax content.  In this 
+   situation, the "voice-message" context should not stop the terminal 
+   from being properly rendering the message. 
+    
+ 
+7.1. Message-Context Syntax 
+    
+   The syntax of the Message-Context field, described using the ABNF 
+   [7] is as follows.  Note that the Message-Context header field name 
+   and message-context-class values are not case sensitive. 
+    
+        "Message-Context" ":" message-context-class CRLF 
+    
+7.2. message-context-class Syntax 
+    
+   The message-context-class indicates the context of the message.  
+   This is an IANA registered value.  Current values for message-
+   context-class are as follows. 
+    
+
+
+
+  
+Burger et. al.             Expires 10/16/01                   [Page 7] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+        message-context-class =  (   "voice-message" 
+                                   | "fax-message" 
+                                   | "pager-message" 
+                                   | "multimedia-message" 
+                                   | "text-message" 
+                                   | "none" 
+                                   | extension-type ) 
+    
+        extension-type = token  ; Defined and registered per Section 8 
+                       / vnd.token ; Experimental, private use 
+    
+        token = <syntax as defined by [8],  
+                 but not starting with the characters "vnd."> 
+    
+        vnd.token = <Vendor-specific, private token> 
+    
+   Note: The values for Message-Context must be either IANA registered 
+   values or experimental, vendor tokens.  This ensures that user 
+   agents from different vendors will interoperate and perform in a 
+   uniform manner without an undue burden on the vendors. 
+    
+7.2.1. voice-message 
+    
+   The voice-message class states the message is a voice mail message. 
+    
+7.2.2. fax-message 
+    
+   The fax-message class states the message is a facsimile mail 
+   message. 
+    
+7.2.3. pager-message 
+    
+   The pager-message class states the message is a page, such as a text 
+   or numeric pager message or a traditional short text message service 
+   (SMS) message. 
+    
+7.2.4. multimedia-message 
+    
+   The multimedia-message class states the message is an aggregate 
+   multimedia message, such as a message specified by [9].  This helps 
+   identify a message in a multimedia context.  For example, a MIME 
+   multipart/related [10] data part and resource part looks the same as 
+   a multimedia MHTML multipart/related.  However, the semantics are 
+   quite different. 
+    
+7.2.5. text-message 
+    
+   The text-message class states the message is a traditional internet 
+   mail message.  Such a message consists of text, possibly richly 
+   formatted, with or without attachments. 
+    
+
+  
+Burger et. al.             Expires 10/16/01                   [Page 8] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+7.2.6. none 
+    
+   The none class states there is no context information for this 
+   message. 
+    
+   If a message has no Message-Context reference field, a receiving 
+   user agent MUST treat it the same as it would if the message has a 
+   "none" value. 
+    
+    
+8. Security Considerations 
+   The intention for this header is to be an indicator only of message 
+   context.  One can imagine someone creating an "Application" Message-
+   Context.  A poorly designed user agent could blindly execute a 
+   mailed program based on the Message-Context.  Don't do that! 
+    
+   One can envision a denial of service attack by bombing a receiver 
+   with a message that has a Message-Context that doesn't fit the 
+   profile of the actual body parts.  This is why the receiver 
+   considers the Message-Context to be a hint only. 
+    
+    
+9. IANA Considerations 
+    
+   Following the policies outlined in [11] as "Specification Required", 
+   IANA assigns values for Message-Context. 
+    
+   We would expect new registrations to reflect sensible message 
+   contexts that will arise in the future. 
+    
+    
+9.1. Message-Context Registration 
+    
+   To: iana@iana.org 
+   Subject: Registration of new Content-Disposition parameter 
+    
+   Content-Disposition parameter name: 
+   Message-Context 
+    
+   Allowable values for this parameter: 
+   <See Primary Context Class IANA Registrations> 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+
+
+
+
+
+
+  
+Burger et. al.             Expires 10/16/01                   [Page 9] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+9.2. Primary Context Class Registrations 
+    
+9.2.1. Registration Template 
+    
+   In the following template, a pipe symbol, "|", precedes instructions 
+   or other helpful material.  Be sure to replace "<classname>" with 
+   the class name you are defining. 
+    
+    
+   To: iana@iana.org 
+   Subject: Registration of New Message-Context class <classname> 
+    
+   Message-Context class name: 
+   <classname> 
+    
+   Summary of the message class: 
+       | Include a short (no longer than 4 lines) description or summary 
+       | Examples: 
+       |   "Palmtop devices have a 320x160 pixel display, so we can..." 
+       |   "Color fax is so different than black & white that..." 
+    
+   Security considerations: 
+       | Describe issues related to security.  Examples include privacy 
+       | concerns, denial of service concerns, malicious behavior, etc. 
+    
+   Interoperability considerations: 
+       | Describe issues with existing RFC's or BCP's, if any. 
+    
+   Additional information: 
+       | Any other relevant information that might be useful, such 
+       | as related class definitions, reference to specific 
+       | applications and specifications to which this class 
+       | relates, etc. 
+    
+   Person & email address to contact for further information: 
+       | Name & e-mail! 
+    
+    
+9.2.2. voice-message 
+    
+   To: iana@iana.org 
+   Subject: Registration of New Message-Context class voice-message 
+    
+   Message-Context class name: 
+   voice-message 
+    
+   Summary of the message class: 
+   "voice-message" indicates a message whose primary content is a voice 
+   mail message.  The primary content is audio data.  The context is 
+   usually a message recorded from a voice telephone call. 
+    
+   Security considerations: 
+  
+Burger et. al.             Expires 10/16/01                  [Page 10] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+   none 
+    
+   Interoperability considerations: 
+   None. 
+    
+   Additional information: 
+   RFC 2421, Voice Profile for Internet Mail - version 2 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+    
+9.2.3. fax-message 
+    
+   To: iana@iana.org 
+   Subject: Registration of New Message-Context class fax-message 
+    
+   Message-Context class name: 
+   fax-message 
+    
+   Summary of the message class: 
+   "fax-message" indicates a message whose primary content is a fax 
+   mail message.  The primary content is image data.  The context is 
+   usually a message recorded from a facsimile telephone call. 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   none 
+ 
+   Additional information: 
+   RFC 2305, A Simple Mode of Facsimile Using Internet Mail 
+   RFC 2421, Voice Profile for Internet Mail - version 2 
+   RFC 2532, Extended Facsimile Using Internet Mail 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+    
+9.2.4. pager-message 
+    
+   To: iana@iana.org 
+   Subject: Registration of New Message-Context class pager-message 
+    
+   Message-Context class name: 
+   pager-message 
+    
+   Summary of the message class: 
+
+  
+Burger et. al.             Expires 10/16/01                  [Page 11] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+   "pager-message" indicates a message whose primary content is a page.  
+   The primary content is text data.  The context is an urgent message 
+   usually of a limited length. 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   none 
+    
+   Additional information: 
+   none 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+ 
+9.2.5. multimedia-message 
+    
+   To: iana@iana.org 
+   Subject: Registration of New Message-Context class multimedia-
+   message 
+    
+   Message-Context class name: 
+   multimedia-message 
+    
+   Summary of the message class: 
+   "multimedia-message" indicates a message whose primary content is 
+   multimedia message.  The primary content is multimedia, most likely 
+   MHTML.  The context is often spam or newsletters. 
+    
+   Security considerations: 
+   None beyond the usual issues with rendering HTML, if present. 
+    
+   Interoperability considerations: 
+   none 
+    
+   Additional information: 
+   none 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+ 
+9.2.6. text-message 
+    
+   To: iana@iana.org 
+   Subject: Registration of New Message-Context class text-message 
+    
+   Message-Context class name: 
+  
+Burger et. al.             Expires 10/16/01                  [Page 12] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+   text-message 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   none 
+    
+   Published specification: 
+   draft-ietf-vpim-hint-05.txt 
+    
+   Additional information: 
+   none 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+    
+9.2.7. none 
+    
+   To: ietf-types@iana.org 
+   Subject: Registration of New Message-Context class none 
+    
+   Message-Context class name: 
+   none 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   none 
+    
+   Published specification: 
+   draft-ietf-vpim-hint-05.txt 
+    
+   Additional information: 
+   none 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+ 
+10. APPENDIX: Some messaging scenarios 
+    
+   This section is not a normative part of this document.  We include 
+   it here as a historical perspective on the issue of multimedia 
+   message types. 
+    
+   These scenarios are neither comprehensive nor fixed.  For example, 
+   e-mails being typically text-based do not mean that they cannot 
+  
+Burger et. al.             Expires 10/16/01                  [Page 13] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+   convey a voice-message.  This very mutability serves to underline 
+   the desirability of providing some explicit message context hint. 
+    
+10.1. Internet e-mail 
+    
+   Internet e-mail carries textual information.  Sometimes it conveys 
+   computer application data of arbitrary size. 
+    
+   Typically, one uses e-mail for non-urgent messages, which the 
+   recipient will retrieve and process at a time convenient to her. 
+    
+   The normal device for receiving and processing e-mail messages is 
+   some kind of personal computer.  Modern personal computers usually 
+   come with a reasonably large display and an alphanumeric keyboard.  
+   Audio, video, and printing capabilities are not necessarily 
+   available. 
+    
+   One can use E-mail for communication between two parties (one-to-
+   one), a small number of known parties (one-to-few) or, via an e-mail 
+   distribution list, between larger numbers of unknown parties (one-
+   to-many). 
+    
+   One of the endearing characteristics of e-mail is the way that it 
+   allows the recipient to forward all or part of the message a to 
+   another party, with or without additional comments.  It is quite 
+   common for an e-mail to contain snippets of content from several 
+   previous messages. Similar features apply when replying to e-mail. 
+    
+10.2. Pager service 
+    
+   One uses a pager message to convey notifications and alerts.  For 
+   the most part, these notifications are textual information of 
+   limited size.  The typical limit is 160 characters.  People use 
+   pages for relatively urgent messages, which the sender wishes the 
+   receiver to see and possibly respond to within a short time period.  
+   Pager messages are often used as a way of alerting users to 
+   something needing their attention.  For example, a system can use a 
+   page to notify a subscriber there is a voicemail message requiring 
+   her attention.   
+    
+   Example devices for sending and receiving a pager message are a 
+   mobile telephone with a small character display or a text pager.  
+   Personal computers and personal digital assistants (PDAs) can also 
+   participate in pager messaging. 
+    
+   Currently, the most common use of pager messages are between just 
+   two parties (one-to-one). 
+    
+   One delivery method for pager messages is the short text messaging 
+   service (SMS).  SMS is a facility that has evolved for use with 
+   mobile telephones, and has an associated per-message transmission 
+   charge.  Note that the focus here is on the notification aspect of 
+  
+Burger et. al.             Expires 10/16/01                  [Page 14] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+   SMS.  From the beginning, SMS was envisioned to be more than a 
+   simple pager service.  Operators can use SMS to provision the phone, 
+   for example.  From the subscriber point of view, SMS has evolved 
+   considerably from its origins as a pure pager replacement service.  
+   For example, with mobile originate service, people can have two-way 
+   text chat sessions using SMS and a mobile phone.  In addition, there 
+   are SMS-enabled handsets that can display pictures.  However, for 
+   the purposes of this document, there is still a need to capture the 
+   essence of a "highly urgent, short-text, notification or alert" 
+   service. 
+    
+   Users often send pager messages in isolation, rather than as part of 
+   a longer exchange.  One use for them is as a prompt or invitation to 
+   communicate by some more convenient and content-rich method, such as 
+   a telephone call. 
+    
+10.3. Facsimile 
+    
+   People use facsimile to convey image information of moderate size, 
+   typically a small number of pages.  Sometimes people use facsimile 
+   for larger documents. 
+    
+   Facsimile is a facility that usually uses circuit-switched telephone 
+   circuits, with connection-time charges.  Message transfer takes 
+   place in real-time.  Thus, people often use facsimile for urgent 
+   communication. 
+    
+   The normal device for sending and receiving a facsimile is a self-
+   contained scanning and printing device connected to a telephone line 
+   or a desktop computer. 
+    
+   Most facsimiles are between just two parties (one-to-one).  However, 
+   a significant portion of facsimile service is broadcast between 
+   multiple parties (one-to-many). 
+    
+   Most facsimile exchanges are in isolation, rather than as part of a 
+   longer exchange.  Facsimile data is typically not suitable for 
+   further processing by computer. 
+    
+10.4. Voice mail 
+    
+   People use voice mail to convey audio information, almost 
+   exclusively human speech. 
+    
+   Voice mail is a facility that usually uses circuit-switched 
+   telephone circuits, with modest connection-time charges, often used 
+   for moderately urgent messages.  A common use for them is as a 
+   prompt or invitation to communicate by some more convenient method, 
+   such as a telephone call. In most, but not all cases, the sender of 
+   a voice message does not want to send a message at all.  Rather, 
+   they wished to engage in a real-time conversation. 
+    
+  
+Burger et. al.             Expires 10/16/01                  [Page 15] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+   The normal device for sending and receiving a voice mail is a 
+   telephone handset. 
+    
+   Voice messages are usually sent between just two parties (one-to-
+   one). 
+    
+   Voice mail data is not generally suitable for further processing by 
+   computer. 
+    
+10.5. Multimedia message 
+    
+   We define a multimedia message as a message containing more than one 
+   basic media type (text, image, audio, video, model, application). 
+    
+   The following are some characteristics of a multimedia message. 
+    
+   In some cases, a multimedia message is just e-mail with an 
+   attachment that a multimedia display application presents.  For 
+   example, I can send you an MP3 of something I recorded in my garage 
+   today. 
+    
+   In other cases, a multimedia message represents a convergence 
+   between two or more of the scenarios described above.  For example, 
+   a voice message with an accompanying diagram or a talking head video 
+   message is a multimedia message. 
+    
+   The characteristics will vary somewhat with the intent of the 
+   sender.  This in turn may affect the user agent or application used 
+   to render the message. 
+    
+    
+    
+11. References 
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Troost, R., Dorner, S., and Moore, K., "Communicating 
+      Presentation Information in Internet Messages: The Content-
+      Disposition Header Field", RFC 2183, New Century Systems, 
+      QUALCOMM Incorporated, and University of Tennessee, August 1997. 
+    
+   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   4  Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type 
+      Registration", RFC 2423, Lucent Technologies and Northern 
+      Telecom, September 1998. 
+    
+   5  Crocker, D., "Standard for the Format of ARPA Internet Text 
+      Messages", STD 11, RFC 822, August 1982. 
+ 
+  
+Burger et. al.             Expires 10/16/01                  [Page 16] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+ 
+    
+   6  Burger, E., "Critical Content of Internet Mail", draft-ietf-vpim-
+      cc-04.txt, Work in Progress. 
+    
+   7  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+   8  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   9  Palme, J., Hopmann, A., Shelness, N., "MIME Encapsulation of 
+      Aggregate Documents, such as HTML (MHTML)", RFC 2557, Stockholm 
+      University/KTH, Microsoft, and Lotus Development Corporation, 
+      March 1999. 
+    
+   10 Levinson, E., "The MIME Multipart/Related Content-type", RFC 
+      2387, August 1998. 
+    
+   11 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 
+      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 
+    
+    
+    
+12. Acknowledgments 
+    
+   Many of the ideas here arose originally from a discussion with Jutta 
+   Degener. 
+    
+   We'd also like to thank Keith Moore for helping us tighten-up our 
+   explanations. 
+    
+   In the last round, we got some rather good advise from Caleb Clausen 
+   and Dave Aronson.  
+    
+   Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae 
+   helped distil the essence of the pager service vis a vis SMS. 
+    
+   We offer an extra special thanks to Greg Vaudreuil for pulling RFC 
+   2557 out of his hat. 
+    
+    
+    
+
+
+
+
+
+
+
+  
+Burger et. al.             Expires 10/16/01                  [Page 17] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+13. Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks, Inc. 
+   285 Billerica Rd. 
+   Chelmsford, MA  01824-4120 
+   USA 
+    
+   Phone: +1 978 367 8403 
+   Fax:   +1 603 457 5944 
+   Email: e.burger@ieee.org 
+    
+    
+   Emily Candell 
+   Comverse Network Systems 
+   200 Quannapowitt Pkwy. 
+   Wakefield, MA  01880 
+   USA 
+    
+   Phone: +1 781 213 2324 
+   Email: emily@comversens.com 
+    
+    
+   Graham Klyne 
+   Baltimore Technologies Ltd. 
+   1310 Waterside 
+   Arlington Business Park 
+   Theale 
+   Reading, RG7 4SA 
+   United Kingdom 
+    
+   Telephone: +44 118 930 8000 
+   Facsimile: +44 118 930 9000 
+   E-mail:    GK@ACM.ORG 
+    
+    
+   Charles Eliot 
+   Microsoft Corporation 
+   One Microsoft Way  
+   Redmond WA 98052  
+   USA 
+    
+   Telephone: +1 425 936 9760 
+   E-Mail:    charle@Microsoft.com 
+
+
+
+
+
+
+
+
+  
+Burger et. al.             Expires 10/16/01                  [Page 18] 
+ 
+
+                  Message Context for Internet Mail        April 2001 
+ 
+ 
+14. Full Copyright Statement 
+ 
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to 
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2000, 2001 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+ 
+
+
+
+
+  
+Burger et. al.             Expires 10/16/01                  [Page 19] 
+ 
+
diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-06.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-06.txt
new file mode 100644
index 00000000..9f3dfaeb
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-hint-06.txt
@@ -0,0 +1,999 @@
+
+
+Network Working Group                                           E. Burger 
+Internet Draft                                         SnowShore Networks 
+Document: draft-ietf-vpim-hint-06.txt                          E. Candell 
+Category: Standards Track                                        Comverse 
+Expires November 2001                                            C. Eliot 
+                                                    Microsoft Corporation 
+                                                                 G. Klyne 
+                                                   Baltimore Technologies 
+                                                             June 1, 2001 
+ 
+ 
+                   Message Context for Internet Mail 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1].  
+    
+   Internet-Drafts are working documents of the Internet Engineering 
+   Task Force (IETF), its areas, and its working groups. Note that 
+   other groups may also distribute working documents as Internet-
+   Drafts. 
+    
+   Internet-Drafts are draft documents valid for a maximum of six 
+   months and may be updated, replaced, or obsoleted by other documents 
+   at any time. It is inappropriate to use Internet-Drafts as reference 
+   material or to cite them other than as "work in progress." 
+    
+   The list of current Internet-Drafts can be accessed at 
+   http://www.ietf.org/ietf/1id-abstracts.txt . 
+    
+   The list of Internet-Draft Shadow Directories can be accessed at 
+   http://www.ietf.org/shadow.html . 
+    
+   This document is a work product of the IETF Voice Profile for 
+   Internet Mail (VPIM) Work Group. 
+    
+    
+    
+1. Abstract 
+    
+   This memo describes a new RFC822 message header, "Message-Context".  
+   This header provides information about the context and presentation 
+   characteristics of a message. 
+    
+   A receiving user agent (UA) may use this information as a hint to 
+   optimally present the message. 
+    
+
+
+
+
+
+ 
+                           Expires 12/01/01                   [Page 1] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+Table of Contents 
+    
+1. Abstract...........................................................1 
+2. Introduction.......................................................3 
+3. Conventions used in this document..................................3 
+4. Motivation.........................................................4 
+5. Functional Requirements............................................5 
+6. Determining the Message Context....................................6 
+7. Message-Context Reference Field....................................7 
+7.1. Message-Context Syntax...........................................7 
+7.2. message-context-class Syntax.....................................7 
+7.2.1. voice-message..................................................8 
+7.2.2. fax-message....................................................8 
+7.2.3. pager-message..................................................8 
+7.2.4. multimedia-message.............................................8 
+7.2.5. text-message...................................................8 
+7.2.6. none...........................................................9 
+8. Security Considerations............................................9 
+9. IANA Considerations................................................9 
+9.1. Primary Context Class Registrations.............................10 
+9.2. Registration Template...........................................10 
+9.3. Message-Context Registration....................................11 
+10. APPENDIX: Some messaging scenarios...............................11 
+10.1. Internet e-mail................................................11 
+10.2. Pager service..................................................12 
+10.3. Facsimile......................................................12 
+10.4. Voice mail.....................................................13 
+10.5. Multimedia message.............................................13 
+11. References.......................................................14 
+12. Acknowledgments..................................................15 
+13. Author's Addresses...............................................15 
+14. Full Copyright Statement.........................................17 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger et. al.             Expires 12/01/01                   [Page 2] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+2. Introduction 
+    
+   This document describes a mechanism to allow senders of an Internet 
+   mail message to convey the message's contextual information.  Taking 
+   account of this information, the receiving user agent (UA) can make 
+   decisions that improve message presentation for the user in the 
+   context the sender and receiver expects. 
+    
+   In this document, the "message context" conveys information about 
+   the way the user expects to interact with the message.  For example, 
+   a message may be e-mail, voice mail, fax mail, etc.  A smart UA may 
+   have specialized behavior based on the context of the message. 
+    
+   This document specifies a RFC 822 header called "Message-Context".  
+   The mechanism is in some ways similar to the use of the Content-
+   Disposition MIME entity described in [2].  Content-Disposition gives 
+   clues to the receiving User Agent (UA) for how to display a given 
+   body part.  Message-Context can give clues to the receiving UA for 
+   the presentation of the message.  This allows the receiving UA to 
+   present the message in a meaningful and helpful way to the 
+   recipient. 
+    
+   Typical uses for this mechanism include: 
+   o    Selecting a special viewer for a given message. 
+   o    Selecting an icon indicating the kind of message in a displayed 
+        list of messages. 
+   o    Arranging messages in an inbox display. 
+   o    Filtering messages the UA presents when the user has limited 
+        access. 
+ 
+ 
+3. Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [3]. 
+    
+   FORMATTING NOTE: Notes, such at this one, provide additional 
+   nonessential information that the reader may skip without missing 
+   anything essential.  The primary purpose of these non-essential 
+   notes is to convey information about the rationale of this document, 
+   or to place this document in the proper historical or evolutionary 
+   context.  Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+  
+Burger et. al.             Expires 12/01/01                   [Page 3] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+    
+4. Motivation 
+    
+   Multimedia messaging systems receive messages that a UA may present 
+   in variety of ways.  For example, traditional e-mail uses simple 
+   text messages that the recipient displays and edits.  One UA may 
+   automatically print Fax images.  Another UA may play voice messages 
+   through a telephone handset.  Likewise, a receiving desktop computer 
+   may process or present documents transferred over e-mail using a 
+   local application.  Emerging and future developments may deliver 
+   other forms of information that have their own characteristics for 
+   user presentation, such as video messages and pager messages. 
+    
+   An often-requested characteristic for multimedia messaging systems 
+   is to collect received messages in a "universal inbox", and to offer 
+   them to the user as a combined list. 
+    
+   In the context of "unified messaging", different message contexts 
+   may have different implied semantics.  For example, some users may 
+   perceive voicemail to have an implicit assumption of urgency.  Thus 
+   they may wish to gather them together and process them before other 
+   messages.  This results in the end-user receiving agent needing to 
+   be able to identify voicemail and distinguish it from other 
+   messages. 
+    
+   The uses of this kind of presentation characteristic for each 
+   message is multi-fold: 
+    
+   o    Display an indication to the user (e.g., by a suitably 
+        evocative icon along with other summary fields), 
+    
+   o    Auto-forward a given message type into another messaging 
+        environment (e.g., a page to a mobile short message service), 
+    
+   o    Prioritize and group messages in an inbox display list, 
+    
+   o    Suggest appropriate default handling for presentation, 
+    
+   o    Suggest appropriate default handling for reply, forward, etc., 
+        and 
+    
+   A problem faced by multimedia messaging systems is that it is not 
+   always easy to decide the context of a received message.  For 
+   example, consider the following scenarios. 
+    
+   o    A message that contains audio and image data:  Is this a fax 
+        message that happens to have some voice commentary?  Is it a 
+        voice message that is accompanied by some supplementary 
+        diagrams?  Is it a fully multimedia message, in which all parts 
+        are expected to carry equal significance? 
+    
+
+  
+Burger et. al.             Expires 12/01/01                   [Page 4] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+   o    A message containing text and audio data:  Is this e-mail with 
+        an MP3 music attachment?  Is it a voice message that happens to 
+        have been generated with an initial text header for the benefit 
+        of non-voice-enabled e-mail receivers? 
+    
+   The message context does relate to the message media content.  
+   However, it is not the same thing.  As shown above, the media type 
+   used in a message is not sufficient to indicate the message context.  
+   One cannot determine a priori which media types to use in 
+   alternative (gateway) message.  Also, what if the user cares about 
+   distinguishing traditional e-mail text from SMS messages?  They are 
+   both the same media type, text, but they have different user 
+   contexts. 
+    
+    
+5. Functional Requirements 
+    
+   The goals stated above lead to the following functional 
+   requirements. 
+    
+   For receivers: 
+   o    Identify a message as belonging to a message class. 
+    
+   o    Incorrect or invalid message classification must not result in 
+        failure to transfer or inability to present a message. 
+    
+    
+   For senders: 
+   o    Specify message classes by the originating user's choice of 
+        authoring tool or simple user interaction. 
+    
+    
+   For both: 
+   o    Specify a well-defined set of message classes to make 
+        interoperability between mail user agents (UAs) possible. 
+    
+   o    Message classification information has to be interpretable in 
+        reasonable fashion by many different user agent systems. 
+    
+   o    The mechanism should be extensible to allow for the 
+        introduction of new kinds of messages. 
+    
+   NOTE: We specifically do not specify user agent behavior when the 
+   user agent forwards a message.  Clearly, the user agent, being 
+   message-context-aware, should provide a meaningful message-context.  
+   It is obvious what to do for the easy cases.  Messages that the user 
+   simply forwards will most likely keep the context unchanged.  
+   However, it is beyond the scope of this document to specify the user 
+   agent behavior for any other scenario. 
+    
+
+
+  
+Burger et. al.             Expires 12/01/01                   [Page 5] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+6. Determining the Message Context 
+    
+   One method of indicating the interpretation context of a message is 
+   to examine the media types in the message.  However, this requires 
+   the UA to scan the entire message before it can make this 
+   determination.  This approach is particularly burdensome for the 
+   multi-media mail situation, as voice and especially video mail 
+   objects are quite large. 
+    
+   We considered indicating the message context by registering a 
+   multipart/* MIME subtype (Content-Type).  For example, the VPIM Work 
+   Group has registered multipart/voice-message to indicate that a 
+   message is primarily voice mail [4].  However, multipart/voice-
+   message is identical in syntax to multipart/mixed.  The only 
+   difference is that VPIM mail transfer agents and user agents 
+   recognize that they can perform special handling of the message 
+   based on it being a voice mail message.  Moreover, Content-Type 
+   refers to a given MIME body part, not to the message as a whole. 
+    
+   We wish to avoid scanning the entire message.  In addition, we wish 
+   to avoid having to create multiple aliases for multipart/mixed every 
+   time someone identifies a new primary content type.  Multiple 
+   aliases for multipart/mixed are not desirable as they remove the 
+   possibility for specifying a message as multipart/alternate, 
+   multipart/parallel, or multipart/encrypted, for example. 
+    
+   Since the message context is an attribute of the entire message, it 
+   is logical to define a new top-level (RFC 822 [5]) message 
+   attribute.  To this end, this document introduces the message 
+   attribute "Message-Context". 
+    
+   Message-Context only serves to identify the message context.  It 
+   does not provide any indication of content that the UA must be 
+   capable of delivering.  It does not imply any message disposition or 
+   delivery notification.  There is a related effort to define Critical 
+   Content of Internet Mail [6] that one might use to perform these 
+   tasks. 
+    
+   Message-Context is only an indicator.  We do not intend for it to 
+   convey information that is critical for presentation of the message.  
+   One can conceive of goofy situations, such as a message marked 
+   "voice-message" but without an audio body part.  In this case, the 
+   fact that the contents of a message donÆt match its context does not 
+   mean the receiving system should generate an error report or fail to 
+   deliver or process the message.  
+    
+    
+
+
+
+
+
+  
+Burger et. al.             Expires 12/01/01                   [Page 6] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+7. Message-Context Reference Field 
+    
+   The Message-Context reference field is a top-level header inserted 
+   by the sending UA to indicate the context of the message. 
+    
+   A receiving user agent MUST NOT depend on the indicated message-
+   context value in a way that prevents proper presentation of the 
+   message.  If the value is incorrect or does not match the message 
+   content, the receiving user agent MUST still be capable of 
+   displaying the message content at least as meaningfully as it would 
+   if no Message-Context value were present. 
+    
+   One can envision situations where a well-formed message ends up not 
+   including a media type one would expect from the message-context. 
+   For example, consider a voice messaging system that records a voice 
+   message and also performs speech-to-text processing on the message.  
+   The message then passes through a content gateway, such as a 
+   firewall, that removes non-critical body parts over a certain 
+   length.  The receiving user agent will receive a message in the 
+   voice-message context that has only a text part and no audio.  Even 
+   though the message does not have audio, it is still in the voice 
+   message context. 
+    
+   Said differently, the receiving UA can use the message-context to 
+   determine whether, when, and possibly where to display a message.  
+   However, the message-context should not affect the actual rendering 
+   or presentation.  For example, if the message is in the voice-
+   message context, then don't try to send it to a fax terminal.  
+   Conversely, consider the case of a message in the voice-message 
+   context that gets delivered to a multimedia voice terminal with a 
+   printer.  However, this message only has fax content.  In this 
+   situation, the "voice-message" context should not stop the terminal 
+   from being properly rendering the message. 
+    
+ 
+7.1. Message-Context Syntax 
+    
+   The syntax of the Message-Context field, described using the ABNF 
+   [7] is as follows.  Note that the Message-Context header field name 
+   and message-context-class values are not case sensitive. 
+    
+        "Message-Context" ":" message-context-class CRLF 
+    
+7.2. message-context-class Syntax 
+    
+   The message-context-class indicates the context of the message.  
+   This is an IANA registered value.  Current values for message-
+   context-class are as follows. 
+    
+
+
+
+  
+Burger et. al.             Expires 12/01/01                   [Page 7] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+        message-context-class =  (   "voice-message" 
+                                   | "fax-message" 
+                                   | "pager-message" 
+                                   | "multimedia-message" 
+                                   | "text-message" 
+                                   | "none" 
+                                   | extension-type ) 
+    
+        extension-type = token  ; Defined and registered per Section 8 
+                       / vnd.token ; Experimental, private use 
+    
+        token = <syntax as defined by [8],  
+                 but not starting with the characters "vnd."> 
+    
+        vnd.token = <Vendor-specific, private token> 
+    
+   Note: The values for Message-Context must be either IANA registered 
+   values or experimental, vendor tokens.  This ensures that user 
+   agents from different vendors will interoperate and perform in a 
+   uniform manner without an undue burden on the vendors. 
+    
+7.2.1. voice-message 
+    
+   The voice-message class states the message is a voice mail message. 
+    
+7.2.2. fax-message 
+    
+   The fax-message class states the message is a facsimile mail 
+   message. 
+    
+7.2.3. pager-message 
+    
+   The pager-message class states the message is a page, such as a text 
+   or numeric pager message or a traditional short text message service 
+   (SMS) message. 
+    
+7.2.4. multimedia-message 
+    
+   The multimedia-message class states the message is an aggregate 
+   multimedia message, such as a message specified by [9].  This helps 
+   identify a message in a multimedia context.  For example, a MIME 
+   multipart/related [10] data part and resource part looks the same as 
+   a multimedia MHTML multipart/related.  However, the semantics are 
+   quite different. 
+    
+7.2.5. text-message 
+    
+   The text-message class states the message is a traditional internet 
+   mail message.  Such a message consists of text, possibly richly 
+   formatted, with or without attachments. 
+    
+
+  
+Burger et. al.             Expires 12/01/01                   [Page 8] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+7.2.6. none 
+    
+   The none class states there is no context information for this 
+   message. 
+    
+   If a message has no Message-Context reference field, a receiving 
+   user agent MUST treat it the same as it would if the message has a 
+   "none" value. 
+    
+    
+8. Security Considerations 
+   The intention for this header is to be an indicator only of message 
+   context.  One can imagine someone creating an "Application" Message-
+   Context.  A poorly designed user agent could blindly execute a 
+   mailed program based on the Message-Context.  Don't do that! 
+    
+   One can envision a denial of service attack by bombing a receiver 
+   with a message that has a Message-Context that doesn't fit the 
+   profile of the actual body parts.  This is why the receiver 
+   considers the Message-Context to be a hint only. 
+    
+    
+9. IANA Considerations 
+    
+   Section 9.3 is a registration for a new Content-Disposition 
+   parameter, "Message-Context".  The registration follows the 
+   requirements for Content-Disposition registrations as described in 
+   Section 9 of [2]. 
+    
+   This document creates an extensible set of context types.  To 
+   promote interoperability and coherent interpretations of different 
+   types, we need a central repository for well-known context types. 
+    
+   IANA will create a repository for context types called "Internet 
+   Message Context Types".  Following the policies outlined in [11], 
+   this repository is "Specification Required" by RFC.  Section 9.1 
+   describes the initial values for this registry. 
+    
+   To create a new message context type, you MUST publish an RFC to 
+   document the type.  In the RFC, include a copy of the registration 
+   template found in Section 9.2 of this document.  Put the template in 
+   your IANA Considerations section, filling-in the appropriate fields.  
+   You MUST describe any interoperability and security issues in your 
+   draft. 
+    
+    
+    
+
+
+
+
+
+  
+Burger et. al.             Expires 12/01/01                   [Page 9] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+9.1. Primary Context Class Registrations 
+    
+   Internet Message Content Types 
+   ============================== 
+ 
+   Value              Description                           Reference 
+   -----              -----------                           --------- 
+   voice-message      Indicates a message whose primary     This RFC 
+                      content is a voice mail message.  The 
+                      primary content is audio data.  The 
+                      context is usually a message recorded 
+                      from a voice telephone call. 
+                                                             
+   fax-message        Indicates a message whose primary     This RFC 
+                      content is a fax mail message.  The 
+                      primary content is image data.  The 
+                      context is usually a message recorded 
+                      from a facsimile telephone call. 
+                                                             
+   pager-message      Indicates a message whose primary     This RFC 
+                      content is a page.  The primary 
+                      content is text data.  The context is 
+                      an urgent message usually of a 
+                      limited length. 
+                                                             
+   multimedia-message Indicates a message whose primary     This RFC 
+                      content is a multimedia message.  The 
+                      primary content is multimedia, most 
+                      likely MHTML.  The context is often 
+                      spam or newsletters. 
+                                                             
+   text-message       Indicates a classic, text-based,      This RFC 
+                      Internet message. 
+                                                             
+   None               Indicates an unknown message context. This RFC 
+    
+    
+9.2. Registration Template 
+    
+   In the following template, a pipe symbol, "|", precedes instructions 
+   or other helpful material.  Be sure to replace "<classname>" with 
+   the class name you are defining. 
+    
+    
+   Message-Context class name: 
+   <classname> 
+    
+   Summary of the message class: 
+       | Include a short (no longer than 4 lines) description or summary 
+       | Examples: 
+       |   "Palmtop devices have a 320x160 pixel display, so we can..." 
+       |   "Color fax is so different than black & white that..." 
+  
+Burger et. al.             Expires 12/01/01                  [Page 10] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+ 
+   Person & email address to contact for further information: 
+       | Name & e-mail 
+    
+    
+9.3. Message-Context Registration 
+    
+   To: iana@iana.org 
+   Subject: Registration of new Content-Disposition parameter 
+    
+   Content-Disposition parameter name: 
+   Message-Context 
+    
+   Allowable values for this parameter: 
+   Please create a new registry for Primary Context Class 
+   registrations.  See section 9.1 of this document for the initial 
+   values. 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org                                           
+    
+10. APPENDIX: Some messaging scenarios 
+    
+   This section is not a normative part of this document.  We include 
+   it here as a historical perspective on the issue of multimedia 
+   message types. 
+    
+   These scenarios are neither comprehensive nor fixed.  For example, 
+   e-mails being typically text-based do not mean that they cannot 
+   convey a voice-message.  This very mutability serves to underline 
+   the desirability of providing some explicit message context hint. 
+    
+10.1. Internet e-mail 
+    
+   Internet e-mail carries textual information.  Sometimes it conveys 
+   computer application data of arbitrary size. 
+    
+   Typically, one uses e-mail for non-urgent messages, which the 
+   recipient will retrieve and process at a time convenient to her. 
+    
+   The normal device for receiving and processing e-mail messages is 
+   some kind of personal computer.  Modern personal computers usually 
+   come with a reasonably large display and an alphanumeric keyboard.  
+   Audio, video, and printing capabilities are not necessarily 
+   available. 
+    
+   One can use E-mail for communication between two parties (one-to-
+   one), a small number of known parties (one-to-few) or, via an e-mail 
+   distribution list, between larger numbers of unknown parties (one-
+   to-many). 
+    
+  
+Burger et. al.             Expires 12/01/01                  [Page 11] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+   One of the endearing characteristics of e-mail is the way that it 
+   allows the recipient to forward all or part of the message a to 
+   another party, with or without additional comments.  It is quite 
+   common for an e-mail to contain snippets of content from several 
+   previous messages. Similar features apply when replying to e-mail. 
+    
+10.2. Pager service 
+    
+   One uses a pager message to convey notifications and alerts.  For 
+   the most part, these notifications are textual information of 
+   limited size.  The typical limit is 160 characters.  People use 
+   pages for relatively urgent messages, which the sender wishes the 
+   receiver to see and possibly respond to within a short time period.  
+   Pager messages are often used as a way of alerting users to 
+   something needing their attention.  For example, a system can use a 
+   page to notify a subscriber there is a voicemail message requiring 
+   her attention.   
+    
+   Example devices for sending and receiving a pager message are a 
+   mobile telephone with a small character display or a text pager.  
+   Personal computers and personal digital assistants (PDAs) can also 
+   participate in pager messaging. 
+    
+   Currently, the most common use of pager messages are between just 
+   two parties (one-to-one). 
+    
+   One delivery method for pager messages is the short text messaging 
+   service (SMS).  SMS is a facility that has evolved for use with 
+   mobile telephones, and has an associated per-message transmission 
+   charge.  Note that the focus here is on the notification aspect of 
+   SMS.  From the beginning, SMS was envisioned to be more than a 
+   simple pager service.  Operators can use SMS to provision the phone, 
+   for example.  From the subscriber point of view, SMS has evolved 
+   considerably from its origins as a pure pager replacement service.  
+   For example, with mobile originate service, people can have two-way 
+   text chat sessions using SMS and a mobile phone.  In addition, there 
+   are SMS-enabled handsets that can display pictures.  However, for 
+   the purposes of this document, there is still a need to capture the 
+   essence of a "highly urgent, short-text, notification or alert" 
+   service. 
+    
+   Users often send pager messages in isolation, rather than as part of 
+   a longer exchange.  One use for them is as a prompt or invitation to 
+   communicate by some more convenient and content-rich method, such as 
+   a telephone call. 
+    
+10.3. Facsimile 
+    
+   People use facsimile to convey image information of moderate size, 
+   typically a small number of pages.  Sometimes people use facsimile 
+   for larger documents. 
+    
+  
+Burger et. al.             Expires 12/01/01                  [Page 12] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+   Facsimile is a facility that usually uses circuit-switched telephone 
+   circuits, with connection-time charges.  Message transfer takes 
+   place in real-time.  Thus, people often use facsimile for urgent 
+   communication. 
+    
+   The normal device for sending and receiving a facsimile is a self-
+   contained scanning and printing device connected to a telephone line 
+   or a desktop computer. 
+    
+   Most facsimiles are between just two parties (one-to-one).  However, 
+   a significant portion of facsimile service is broadcast between 
+   multiple parties (one-to-many). 
+    
+   Most facsimile exchanges are in isolation, rather than as part of a 
+   longer exchange.  Facsimile data is typically not suitable for 
+   further processing by computer. 
+    
+10.4. Voice mail 
+    
+   People use voice mail to convey audio information, almost 
+   exclusively human speech. 
+    
+   Voice mail is a facility that usually uses circuit-switched 
+   telephone circuits, with modest connection-time charges, often used 
+   for moderately urgent messages.  A common use for them is as a 
+   prompt or invitation to communicate by some more convenient method, 
+   such as a telephone call. In most, but not all cases, the sender of 
+   a voice message does not want to send a message at all.  Rather, 
+   they wished to engage in a real-time conversation. 
+    
+   The normal device for sending and receiving a voice mail is a 
+   telephone handset. 
+    
+   Voice messages are usually sent between just two parties (one-to-
+   one). 
+    
+   Voice mail data is not generally suitable for further processing by 
+   computer. 
+    
+10.5. Multimedia message 
+    
+   We define a multimedia message as a message containing more than one 
+   basic media type (text, image, audio, video, model, application). 
+    
+   The following are some characteristics of a multimedia message. 
+    
+   In some cases, a multimedia message is just e-mail with an 
+   attachment that a multimedia display application presents.  For 
+   example, I can send you an MP3 of something I recorded in my garage 
+   today. 
+    
+
+  
+Burger et. al.             Expires 12/01/01                  [Page 13] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+   In other cases, a multimedia message represents a convergence 
+   between two or more of the scenarios described above.  For example, 
+   a voice message with an accompanying diagram or a talking head video 
+   message is a multimedia message. 
+    
+   The characteristics will vary somewhat with the intent of the 
+   sender.  This in turn may affect the user agent or application used 
+   to render the message. 
+    
+    
+    
+11. References 
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Troost, R., Dorner, S., and Moore, K., "Communicating 
+      Presentation Information in Internet Messages: The Content-
+      Disposition Header Field", RFC 2183, New Century Systems, 
+      QUALCOMM Incorporated, and University of Tennessee, August 1997. 
+    
+   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   4  Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type 
+      Registration", RFC 2423, Lucent Technologies and Northern 
+      Telecom, September 1998. 
+    
+   5  Crocker, D., "Standard for the Format of ARPA Internet Text 
+      Messages", STD 11, RFC 822, August 1982. 
+    
+   6  Burger, E., "Critical Content of Internet Mail", draft-ietf-vpim-
+      cc-04.txt, Work in Progress. 
+    
+   7  Crocker, D. and Overell, P. (Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+   8  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   9  Palme, J., Hopmann, A., Shelness, N., "MIME Encapsulation of 
+      Aggregate Documents, such as HTML (MHTML)", RFC 2557, Stockholm 
+      University/KTH, Microsoft, and Lotus Development Corporation, 
+      March 1999. 
+    
+   10 Levinson, E., "The MIME Multipart/Related Content-type", RFC 
+      2387, August 1998. 
+    
+ 
+
+  
+Burger et. al.             Expires 12/01/01                  [Page 14] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+ 
+   11 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 
+      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 
+    
+    
+    
+12. Acknowledgments 
+    
+   Many of the ideas here arose originally from a discussion with Jutta 
+   Degener. 
+    
+   We'd also like to thank Keith Moore for helping us tighten-up our 
+   explanations. 
+    
+   In the last round, we got some rather good advise from Caleb Clausen 
+   and Dave Aronson.  
+    
+   Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae 
+   helped distil the essence of the pager service vis a vis SMS. 
+    
+   We offer an extra special thanks to Greg Vaudreuil for pulling RFC 
+   2557 out of his hat. 
+    
+    
+    
+13. Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks, Inc. 
+   285 Billerica Rd. 
+   Chelmsford, MA  01824-4120 
+   USA 
+    
+   Phone: +1 978 367 8403 
+   Fax:   +1 603 457 5944 
+   Email: e.burger@ieee.org 
+    
+    
+   Emily Candell 
+   Comverse Network Systems 
+   200 Quannapowitt Pkwy. 
+   Wakefield, MA  01880 
+   USA 
+    
+   Phone: +1 781 213 2324 
+   Email: emily.candell@comverse.com 
+    
+    
+
+
+
+
+  
+Burger et. al.             Expires 12/01/01                  [Page 15] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+   Graham Klyne 
+   Baltimore Technologies Ltd. 
+   1310 Waterside 
+   Arlington Business Park 
+   Theale 
+   Reading, RG7 4SA 
+   United Kingdom 
+    
+   Telephone: +44 118 930 8000 
+   Facsimile: +44 118 930 9000 
+   E-mail:    GK@ACM.ORG 
+    
+    
+   Charles Eliot 
+   Microsoft Corporation 
+   One Microsoft Way  
+   Redmond WA 98052  
+   USA 
+    
+   Telephone: +1 425 936 9760 
+   E-Mail:    charle@Microsoft.com 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger et. al.             Expires 12/01/01                  [Page 16] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+14. Full Copyright Statement 
+ 
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to 
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2001 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+ 
+
+
+
+
+  
+Burger et. al.             Expires 12/01/01                  [Page 17] 
+ 
+
diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt
new file mode 100644
index 00000000..9b6ea071
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt
@@ -0,0 +1,999 @@
+
+
+Network Working Group                                           E. Burger 
+Internet Draft                                         SnowShore Networks 
+Document: draft-ietf-vpim-hint-07.txt                          E. Candell 
+Category: Standards Track                                        Comverse 
+Expires December 2001                                            C. Eliot 
+                                                    Microsoft Corporation 
+                                                                 G. Klyne 
+                                                   Baltimore Technologies 
+                                                             June 5, 2001 
+ 
+ 
+                   Message Context for Internet Mail 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1].  
+    
+   Internet-Drafts are working documents of the Internet Engineering 
+   Task Force (IETF), its areas, and its working groups. Note that 
+   other groups may also distribute working documents as Internet-
+   Drafts. 
+    
+   Internet-Drafts are draft documents valid for a maximum of six 
+   months and may be updated, replaced, or obsoleted by other documents 
+   at any time. It is inappropriate to use Internet-Drafts as reference 
+   material or to cite them other than as "work in progress." 
+    
+   The list of current Internet-Drafts can be accessed at 
+   http://www.ietf.org/ietf/1id-abstracts.txt . 
+    
+   The list of Internet-Draft Shadow Directories can be accessed at 
+   http://www.ietf.org/shadow.html . 
+    
+   This document is a work product of the IETF Voice Profile for 
+   Internet Mail (VPIM) Work Group. 
+    
+    
+    
+1. Abstract 
+    
+   This memo describes a new RFC2822 message header, "Message-Context".  
+   This header provides information about the context and presentation 
+   characteristics of a message. 
+    
+   A receiving user agent (UA) may use this information as a hint to 
+   optimally present the message. 
+    
+
+
+
+
+
+ 
+                           Expires 12/05/01                   [Page 1] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+Table of Contents 
+    
+1. Abstract...........................................................1 
+2. Introduction.......................................................3 
+3. Conventions used in this document..................................3 
+4. Motivation.........................................................4 
+5. Functional Requirements............................................5 
+6. Determining the Message Context....................................6 
+7. Message-Context Reference Field....................................7 
+7.1. Message-Context Syntax...........................................7 
+7.2. message-context-class Syntax.....................................7 
+7.2.1. voice-message..................................................8 
+7.2.2. fax-message....................................................8 
+7.2.3. pager-message..................................................8 
+7.2.4. multimedia-message.............................................8 
+7.2.5. text-message...................................................8 
+7.2.6. none...........................................................9 
+8. Security Considerations............................................9 
+9. IANA Considerations................................................9 
+9.1. Message Content Type Registrations..............................10 
+9.2. Registration Template...........................................10 
+9.3. Message-Context Registration....................................11 
+10. APPENDIX: Some messaging scenarios...............................11 
+10.1. Internet e-mail................................................11 
+10.2. Pager service..................................................12 
+10.3. Facsimile......................................................13 
+10.4. Voice mail.....................................................13 
+10.5. Multimedia message.............................................13 
+11. References.......................................................14 
+12. Acknowledgments..................................................15 
+13. Author's Addresses...............................................15 
+14. Full Copyright Statement.........................................17 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger et. al.             Expires 12/05/01                   [Page 2] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+2. Introduction 
+    
+   This document describes a mechanism to allow senders of an Internet 
+   mail message to convey the message's contextual information.  Taking 
+   account of this information, the receiving user agent (UA) can make 
+   decisions that improve message presentation for the user in the 
+   context the sender and receiver expects. 
+    
+   In this document, the "message context" conveys information about 
+   the way the user expects to interact with the message.  For example, 
+   a message may be e-mail, voice mail, fax mail, etc.  A smart UA may 
+   have specialized behavior based on the context of the message. 
+    
+   This document specifies a RFC2822 header called "Message-Context".  
+   The mechanism is in some ways similar to the use of the Content-
+   Disposition MIME entity described in [2].  Content-Disposition gives 
+   clues to the receiving User Agent (UA) for how to display a given 
+   body part.  Message-Context can give clues to the receiving UA for 
+   the presentation of the message.  This allows the receiving UA to 
+   present the message in a meaningful and helpful way to the 
+   recipient. 
+    
+   Typical uses for this mechanism include: 
+   o    Selecting a special viewer for a given message. 
+   o    Selecting an icon indicating the kind of message in a displayed 
+        list of messages. 
+   o    Arranging messages in an inbox display. 
+   o    Filtering messages the UA presents when the user has limited 
+        access. 
+ 
+ 
+3. Conventions used in this document 
+    
+   This document refers generically to the sender of a message in the 
+   masculine (he/him/his) and the recipient of the message in the 
+   feminine (she/her/hers).  This convention is purely for convenience 
+   and makes no assumption about the gender of a message sender or 
+   recipient. 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [3]. 
+    
+   FORMATTING NOTE: Notes, such at this one, provide additional 
+   nonessential information that the reader may skip without missing 
+   anything essential.  The primary purpose of these non-essential 
+   notes is to convey information about the rationale of this document, 
+   or to place this document in the proper historical or evolutionary 
+   context.  Readers whose sole purpose is to construct a conformant 
+   implementation may skip such information.  However, it may be of use 
+   to those who wish to understand why we made certain design choices. 
+    
+  
+Burger et. al.             Expires 12/05/01                   [Page 3] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+    
+4. Motivation 
+    
+   Multimedia messaging systems receive messages that a UA may present 
+   in variety of ways.  For example, traditional e-mail uses simple 
+   text messages that the recipient displays and edits.  One UA may 
+   automatically print Fax images.  Another UA may play voice messages 
+   through a telephone handset.  Likewise, a receiving desktop computer 
+   may process or present documents transferred over e-mail using a 
+   local application.  Emerging and future developments may deliver 
+   other forms of information that have their own characteristics for 
+   user presentation, such as video messages and pager messages. 
+    
+   An often-requested characteristic for multimedia messaging systems 
+   is to collect received messages in a "universal inbox", and to offer 
+   them to the user as a combined list. 
+    
+   In the context of "unified messaging", different message contexts 
+   may have different implied semantics.  For example, some users may 
+   perceive voicemail to have an implicit assumption of urgency.  Thus 
+   they may wish to gather them together and process them before other 
+   messages.  This results in the end-user receiving agent needing to 
+   be able to identify voicemail and distinguish it from other 
+   messages. 
+    
+   The uses of this kind of presentation characteristic for each 
+   message is multi-fold: 
+    
+   o    Display an indication to the user (e.g., by a suitably 
+        evocative icon along with other summary fields), 
+    
+   o    Auto-forward a given message type into another messaging 
+        environment (e.g., a page to a mobile short message service), 
+    
+   o    Prioritize and group messages in an inbox display list, 
+    
+   o    Suggest appropriate default handling for presentation, 
+    
+   o    Suggest appropriate default handling for reply, forward, etc., 
+        and 
+    
+   A problem faced by multimedia messaging systems is that it is not 
+   always easy to decide the context of a received message.  For 
+   example, consider the following scenarios. 
+    
+   o    A message that contains audio and image data:  Is this a fax 
+        message that happens to have some voice commentary?  Is it a 
+        voice message that is accompanied by some supplementary 
+        diagrams?  Is it a fully multimedia message, in which all parts 
+        are expected to carry equal significance? 
+    
+
+  
+Burger et. al.             Expires 12/05/01                   [Page 4] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+   o    A message containing text and audio data:  Is this e-mail with 
+        an MP3 music attachment?  Is it a voice message that happens to 
+        have been generated with an initial text header for the benefit 
+        of non-voice-enabled e-mail receivers? 
+    
+   The message context does relate to the message media content.  
+   However, it is not the same thing.  As shown above, the media type 
+   used in a message is not sufficient to indicate the message context.  
+   One cannot determine a priori which media types to use in 
+   alternative (gateway) message.  Also, what if the user cares about 
+   distinguishing traditional e-mail text from SMS messages?  They are 
+   both the same media type, text, but they have different user 
+   contexts. 
+    
+    
+5. Functional Requirements 
+    
+   The goals stated above lead to the following functional 
+   requirements. 
+    
+   For receivers: 
+   o    Identify a message as belonging to a message class. 
+    
+   o    Incorrect or invalid message classification must not result in 
+        failure to transfer or inability to present a message. 
+    
+    
+   For senders: 
+   o    Specify message classes by the originating user's choice of 
+        authoring tool or simple user interaction. 
+    
+    
+   For both: 
+   o    Specify a well-defined set of message classes to make 
+        interoperability between mail user agents (UAs) possible. 
+    
+   o    Message classification information has to be interpretable in 
+        reasonable fashion by many different user agent systems. 
+    
+   o    The mechanism should be extensible to allow for the 
+        introduction of new kinds of messages. 
+    
+   NOTE: We specifically do not specify user agent behavior when the 
+   user agent forwards a message.  Clearly, the user agent, being 
+   message-context-aware, should provide a meaningful message-context.  
+   It is obvious what to do for the easy cases.  Messages that the user 
+   simply forwards will most likely keep the context unchanged.  
+   However, it is beyond the scope of this document to specify the user 
+   agent behavior for any other scenario. 
+    
+
+
+  
+Burger et. al.             Expires 12/05/01                   [Page 5] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+6. Determining the Message Context 
+    
+   One method of indicating the interpretation context of a message is 
+   to examine the media types in the message.  However, this requires 
+   the UA to scan the entire message before it can make this 
+   determination.  This approach is particularly burdensome for the 
+   multi-media mail situation, as voice and especially video mail 
+   objects are quite large. 
+    
+   We considered indicating the message context by registering a 
+   multipart/* MIME subtype (Content-Type).  For example, the VPIM Work 
+   Group has registered multipart/voice-message to indicate that a 
+   message is primarily voice mail [4].  However, multipart/voice-
+   message is identical in syntax to multipart/mixed.  The only 
+   difference is that VPIM mail transfer agents and user agents 
+   recognize that they can perform special handling of the message 
+   based on it being a voice mail message.  Moreover, Content-Type 
+   refers to a given MIME body part, not to the message as a whole. 
+    
+   We wish to avoid scanning the entire message.  In addition, we wish 
+   to avoid having to create multiple aliases for multipart/mixed every 
+   time someone identifies a new primary content type.  Multiple 
+   aliases for multipart/mixed are not desirable as they remove the 
+   possibility for specifying a message as multipart/alternate, 
+   multipart/parallel, or multipart/encrypted, for example. 
+    
+   Since the message context is an attribute of the entire message, it 
+   is logical to define a new top-level (RFC2822 [5]) message 
+   attribute.  To this end, this document introduces the message 
+   attribute "Message-Context". 
+    
+   Message-Context only serves to identify the message context.  It 
+   does not provide any indication of content that the UA must be 
+   capable of delivering.  It does not imply any message disposition or 
+   delivery notification.  There is a related effort to define Critical 
+   Content of Internet Mail [6] that one might use to perform these 
+   tasks. 
+    
+   Message-Context is only an indicator.  We do not intend for it to 
+   convey information that is critical for presentation of the message.  
+   One can conceive of goofy situations, such as a message marked 
+   "voice-message" but without an audio body part.  In this case, the 
+   fact that the contents of a message donÆt match its context does not 
+   mean the receiving system should generate an error report or fail to 
+   deliver or process the message.  
+    
+    
+
+
+
+
+
+  
+Burger et. al.             Expires 12/05/01                   [Page 6] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+7. Message-Context Reference Field 
+    
+   The Message-Context reference field is a top-level header inserted 
+   by the sending UA to indicate the context of the message. 
+    
+   A receiving user agent MUST NOT depend on the indicated message-
+   context value in a way that prevents proper presentation of the 
+   message.  If the value is incorrect or does not match the message 
+   content, the receiving user agent MUST still be capable of 
+   displaying the message content at least as meaningfully as it would 
+   if no Message-Context value were present. 
+    
+   One can envision situations where a well-formed message ends up not 
+   including a media type one would expect from the message-context. 
+   For example, consider a voice messaging system that records a voice 
+   message and also performs speech-to-text processing on the message.  
+   The message then passes through a content gateway, such as a 
+   firewall, that removes non-critical body parts over a certain 
+   length.  The receiving user agent will receive a message in the 
+   voice-message context that has only a text part and no audio.  Even 
+   though the message does not have audio, it is still in the voice 
+   message context. 
+    
+   Said differently, the receiving UA can use the message-context to 
+   determine whether, when, and possibly where to display a message.  
+   However, the message-context should not affect the actual rendering 
+   or presentation.  For example, if the message is in the voice-
+   message context, then don't try to send it to a fax terminal.  
+   Conversely, consider the case of a message in the voice-message 
+   context that gets delivered to a multimedia voice terminal with a 
+   printer.  However, this message only has fax content.  In this 
+   situation, the "voice-message" context should not stop the terminal 
+   from being properly rendering the message. 
+    
+ 
+7.1. Message-Context Syntax 
+    
+   The syntax of the Message-Context field, described using the ABNF 
+   [7] is as follows.  Note that the Message-Context header field name 
+   and message-context-class values are not case sensitive. 
+    
+        "Message-Context" ":" message-context-class CRLF 
+    
+7.2. message-context-class Syntax 
+    
+   The message-context-class indicates the context of the message.  
+   This is an IANA registered value.  Current values for message-
+   context-class are as follows. 
+    
+
+
+
+  
+Burger et. al.             Expires 12/05/01                   [Page 7] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+        message-context-class =  (   "voice-message" 
+                                   | "fax-message" 
+                                   | "pager-message" 
+                                   | "multimedia-message" 
+                                   | "text-message" 
+                                   | "none" 
+                                   | extension-type ) 
+    
+        extension-type = token  ; Defined and registered per Section 8 
+                       / vnd.token ; Experimental, private use 
+    
+        token = <syntax as defined by [8],  
+                 but not starting with the characters "vnd."> 
+    
+        vnd.token = <Vendor-specific, private token> 
+    
+   Note: The values for Message-Context must be either IANA registered 
+   values or experimental, vendor tokens.  This ensures that user 
+   agents from different vendors will interoperate and perform in a 
+   uniform manner without an undue burden on the vendors. 
+    
+7.2.1. voice-message 
+    
+   The voice-message class states the message is a voice mail message. 
+    
+7.2.2. fax-message 
+    
+   The fax-message class states the message is a facsimile mail 
+   message. 
+    
+7.2.3. pager-message 
+    
+   The pager-message class states the message is a page, such as a text 
+   or numeric pager message or a traditional short text message service 
+   (SMS) message. 
+    
+7.2.4. multimedia-message 
+    
+   The multimedia-message class states the message is an aggregate 
+   multimedia message, such as a message specified by [9].  This helps 
+   identify a message in a multimedia context.  For example, a MIME 
+   multipart/related [10] data part and resource part looks the same as 
+   a multimedia MHTML multipart/related.  However, the semantics are 
+   quite different. 
+    
+7.2.5. text-message 
+    
+   The text-message class states the message is a traditional internet 
+   mail message.  Such a message consists of text, possibly richly 
+   formatted, with or without attachments. 
+    
+
+  
+Burger et. al.             Expires 12/05/01                   [Page 8] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+7.2.6. none 
+    
+   The none class states there is no context information for this 
+   message. 
+    
+   If a message has no Message-Context reference field, a receiving 
+   user agent MUST treat it the same as it would if the message has a 
+   "none" value. 
+    
+    
+8. Security Considerations 
+   The intention for this header is to be an indicator only of message 
+   context.  One can imagine someone creating an "Application" Message-
+   Context.  A poorly designed user agent could blindly execute a 
+   mailed program based on the Message-Context.  Don't do that! 
+    
+   One can envision a denial of service attack by bombing a receiver 
+   with a message that has a Message-Context that doesn't fit the 
+   profile of the actual body parts.  This is why the receiver 
+   considers the Message-Context to be a hint only. 
+    
+    
+9. IANA Considerations 
+    
+   Section 9.3 is a registration for a new top-level RFC2822 [5] 
+   message header, "Message-Context".   
+    
+   This document creates an extensible set of context types.  To 
+   promote interoperability and coherent interpretations of different 
+   types, we need a central repository for well-known context types. 
+    
+   IANA will create a repository for context types called "Internet 
+   Message Context Types".  Following the policies outlined in [11], 
+   this repository is "Specification Required" by RFC.  Section 9.1 
+   describes the initial values for this registry. 
+    
+   To create a new message context type, you MUST publish an RFC to 
+   document the type.  In the RFC, include a copy of the registration 
+   template found in Section 9.2 of this document.  Put the template in 
+   your IANA Considerations section, filling-in the appropriate fields.  
+   You MUST describe any interoperability and security issues in your 
+   draft. 
+    
+    
+    
+
+
+
+
+
+
+
+  
+Burger et. al.             Expires 12/05/01                   [Page 9] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+9.1. Message Content Type Registrations 
+    
+   Internet Message Content Types 
+   ============================== 
+ 
+   Value              Description                           Reference 
+   -----              -----------                           --------- 
+   voice-message      Indicates a message whose primary     This RFC 
+                      content is a voice mail message.  The 
+                      primary content is audio data.  The 
+                      context is usually a message recorded 
+                      from a voice telephone call. 
+                                                             
+   fax-message        Indicates a message whose primary     This RFC 
+                      content is a fax mail message.  The 
+                      primary content is image data.  The 
+                      context is usually a message recorded 
+                      from a facsimile telephone call. 
+                                                             
+   pager-message      Indicates a message whose primary     This RFC 
+                      content is a page.  The primary 
+                      content is text data.  The context is 
+                      an urgent message usually of a 
+                      limited length. 
+                                                             
+   multimedia-message Indicates a message whose primary     This RFC 
+                      content is a multimedia message.  The 
+                      primary content is multimedia, most 
+                      likely MHTML.  The context is often 
+                      spam or newsletters. 
+                                                             
+   text-message       Indicates a classic, text-based,      This RFC 
+                      Internet message. 
+                                                             
+   None               Indicates an unknown message context. This RFC 
+    
+    
+9.2. Registration Template 
+    
+   In the following template, a pipe symbol, "|", precedes instructions 
+   or other helpful material.  Be sure to replace "<classname>" with 
+   the class name you are defining. 
+    
+    
+   Message-Context class name: 
+   <classname> 
+    
+   Summary of the message class: 
+       | Include a short (no longer than 4 lines) description or summary 
+       | Examples: 
+       |   "Palmtop devices have a 320x160 pixel display, so we can..." 
+       |   "Color fax is so different than black & white that..." 
+  
+Burger et. al.             Expires 12/05/01                  [Page 10] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+ 
+   Person & email address to contact for further information: 
+       | Name & e-mail 
+    
+    
+9.3. Message-Context Registration 
+    
+   To: iana@iana.org 
+   Subject: Registration of New RFC 2822 Header 
+    
+   RFC 2822 Header Name: 
+   Message-Context 
+    
+   Allowable values for this parameter: 
+   Please create a new registry for Primary Context Class 
+   registrations.  See section 9.1 of this document for the initial 
+   values. 
+    
+   RFC 2822 Section 3.6 Repeat Value: 
+   Field             Min Number   Max Number   Notes 
+   Message-Context       0            1         
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org                                           
+    
+    
+10. APPENDIX: Some messaging scenarios 
+    
+   This section is not a normative part of this document.  We include 
+   it here as a historical perspective on the issue of multimedia 
+   message types. 
+    
+   These scenarios are neither comprehensive nor fixed.  For example, 
+   e-mails being typically text-based do not mean that they cannot 
+   convey a voice-message.  This very mutability serves to underline 
+   the desirability of providing some explicit message context hint. 
+    
+10.1. Internet e-mail 
+    
+   Internet e-mail carries textual information.  Sometimes it conveys 
+   computer application data of arbitrary size. 
+    
+   Typically, one uses e-mail for non-urgent messages, which the 
+   recipient will retrieve and process at a time convenient to her. 
+    
+   The normal device for receiving and processing e-mail messages is 
+   some kind of personal computer.  Modern personal computers usually 
+   come with a reasonably large display and an alphanumeric keyboard.  
+   Audio, video, and printing capabilities are not necessarily 
+   available. 
+    
+  
+Burger et. al.             Expires 12/05/01                  [Page 11] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+   One can use E-mail for communication between two parties (one-to-
+   one), a small number of known parties (one-to-few) or, via an e-mail 
+   distribution list, between larger numbers of unknown parties (one-
+   to-many). 
+    
+   One of the endearing characteristics of e-mail is the way that it 
+   allows the recipient to forward all or part of the message a to 
+   another party, with or without additional comments.  It is quite 
+   common for an e-mail to contain snippets of content from several 
+   previous messages. Similar features apply when replying to e-mail. 
+    
+10.2. Pager service 
+    
+   One uses a pager message to convey notifications and alerts.  For 
+   the most part, these notifications are textual information of 
+   limited size.  The typical limit is 160 characters.  People use 
+   pages for relatively urgent messages, which the sender wishes the 
+   receiver to see and possibly respond to within a short time period.  
+   Pager messages are often used as a way of alerting users to 
+   something needing their attention.  For example, a system can use a 
+   page to notify a subscriber there is a voicemail message requiring 
+   her attention.   
+    
+   Example devices for sending and receiving a pager message are a 
+   mobile telephone with a small character display or a text pager.  
+   Personal computers and personal digital assistants (PDAs) can also 
+   participate in pager messaging. 
+    
+   Currently, the most common use of pager messages are between just 
+   two parties (one-to-one). 
+    
+   One delivery method for pager messages is the short text messaging 
+   service (SMS).  SMS is a facility that has evolved for use with 
+   mobile telephones, and has an associated per-message transmission 
+   charge.  Note that the focus here is on the notification aspect of 
+   SMS.  From the beginning, SMS was envisioned to be more than a 
+   simple pager service.  Operators can use SMS to provision the phone, 
+   for example.  From the subscriber point of view, SMS has evolved 
+   considerably from its origins as a pure pager replacement service.  
+   For example, with mobile originate service, people can have two-way 
+   text chat sessions using SMS and a mobile phone.  In addition, there 
+   are SMS-enabled handsets that can display pictures.  However, for 
+   the purposes of this document, there is still a need to capture the 
+   essence of a "highly urgent, short-text, notification or alert" 
+   service. 
+    
+   Users often send pager messages in isolation, rather than as part of 
+   a longer exchange.  One use for them is as a prompt or invitation to 
+   communicate by some more convenient and content-rich method, such as 
+   a telephone call. 
+    
+
+  
+Burger et. al.             Expires 12/05/01                  [Page 12] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+10.3. Facsimile 
+    
+   People use facsimile to convey image information of moderate size, 
+   typically a small number of pages.  Sometimes people use facsimile 
+   for larger documents. 
+    
+   Facsimile is a facility that usually uses circuit-switched telephone 
+   circuits, with connection-time charges.  Message transfer takes 
+   place in real-time.  Thus, people often use facsimile for urgent 
+   communication. 
+    
+   The normal device for sending and receiving a facsimile is a self-
+   contained scanning and printing device connected to a telephone line 
+   or a desktop computer. 
+    
+   Most facsimiles are between just two parties (one-to-one).  However, 
+   a significant portion of facsimile service is broadcast between 
+   multiple parties (one-to-many). 
+    
+   Most facsimile exchanges are in isolation, rather than as part of a 
+   longer exchange.  Facsimile data is typically not suitable for 
+   further processing by computer. 
+    
+10.4. Voice mail 
+    
+   People use voice mail to convey audio information, almost 
+   exclusively human speech. 
+    
+   Voice mail is a facility that usually uses circuit-switched 
+   telephone circuits, with modest connection-time charges, often used 
+   for moderately urgent messages.  A common use for them is as a 
+   prompt or invitation to communicate by some more convenient method, 
+   such as a telephone call. In most, but not all cases, the sender of 
+   a voice message does not want to send a message at all.  Rather, 
+   they wished to engage in a real-time conversation. 
+    
+   The normal device for sending and receiving a voice mail is a 
+   telephone handset. 
+    
+   Voice messages are usually sent between just two parties (one-to-
+   one). 
+    
+   Voice mail data is not generally suitable for further processing by 
+   computer. 
+    
+10.5. Multimedia message 
+    
+   We define a multimedia message as a message containing more than one 
+   basic media type (text, image, audio, video, model, application). 
+    
+   The following are some characteristics of a multimedia message. 
+    
+  
+Burger et. al.             Expires 12/05/01                  [Page 13] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+   In some cases, a multimedia message is just e-mail with an 
+   attachment that a multimedia display application presents.  For 
+   example, I can send you an MP3 of something I recorded in my garage 
+   today. 
+    
+   In other cases, a multimedia message represents a convergence 
+   between two or more of the scenarios described above.  For example, 
+   a voice message with an accompanying diagram or a talking head video 
+   message is a multimedia message. 
+    
+   The characteristics will vary somewhat with the intent of the 
+   sender.  This in turn may affect the user agent or application used 
+   to render the message. 
+    
+    
+    
+11. References 
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Troost, R., Dorner, S., and Moore, K., "Communicating 
+      Presentation Information in Internet Messages: The Content-
+      Disposition Header Field", RFC 2183, New Century Systems, 
+      QUALCOMM Incorporated, and University of Tennessee, August 1997. 
+    
+   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997. 
+    
+   4  Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type 
+      Registration", RFC 2423, Lucent Technologies and Northern 
+      Telecom, September 1998. 
+    
+   5  Resnick, P., "Internet Message Format", RFC 2822, Qualcomm, April 
+      2001. 
+    
+   6  Burger, E., "Critical Content of Internet Mail", draft-ietf-vpim-
+      cc-04.txt, Work in Progress. 
+    
+   7  Crocker, D. and Overell, P. (Editors), "Augmented BNF for Syntax 
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
+      Demon Internet Ltd., November 1997. 
+    
+   8  Freed, N. and Borenstein, N., "Multipurpose Internet Mail 
+      Extensions (MIME) Part One: Format of Internet Message Bodies", 
+      RFC 2045, Innosoft and First Virtual, November 1996. 
+    
+   9  Palme, J., Hopmann, A., Shelness, N., "MIME Encapsulation of 
+      Aggregate Documents, such as HTML (MHTML)", RFC 2557, Stockholm 
+      University/KTH, Microsoft, and Lotus Development Corporation, 
+      March 1999. 
+ 
+  
+Burger et. al.             Expires 12/05/01                  [Page 14] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+ 
+    
+   10 Levinson, E., "The MIME Multipart/Related Content-type", RFC 
+      2387, August 1998. 
+    
+   11 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 
+      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 
+    
+    
+    
+12. Acknowledgments 
+    
+   Many of the ideas here arose originally from a discussion with Jutta 
+   Degener. 
+    
+   We'd also like to thank Keith Moore for helping us tighten-up our 
+   explanations. 
+    
+   In the last round, we got some rather good advise from Caleb Clausen 
+   and Dave Aronson.  
+    
+   Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae 
+   helped distil the essence of the pager service vis a vis SMS. 
+    
+   We offer an extra special thanks to Greg Vaudreuil for pulling RFC 
+   2557 out of his hat. 
+    
+    
+    
+13. Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks, Inc. 
+   285 Billerica Rd. 
+   Chelmsford, MA  01824-4120 
+   USA 
+    
+   Phone: +1 978 367 8403 
+   Fax:   +1 603 457 5944 
+   Email: e.burger@ieee.org 
+    
+    
+   Emily Candell 
+   Comverse Network Systems 
+   200 Quannapowitt Pkwy. 
+   Wakefield, MA  01880 
+   USA 
+    
+   Phone: +1 781 213 2324 
+   Email: emily.candell@comverse.com 
+    
+    
+  
+Burger et. al.             Expires 12/05/01                  [Page 15] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+   Graham Klyne 
+   Baltimore Technologies Ltd. 
+   1310 Waterside 
+   Arlington Business Park 
+   Theale 
+   Reading, RG7 4SA 
+   United Kingdom 
+    
+   Telephone: +44 118 930 8000 
+   Facsimile: +44 118 930 9000 
+   E-mail:    GK@ACM.ORG 
+    
+    
+   Charles Eliot 
+   Microsoft Corporation 
+   One Microsoft Way  
+   Redmond WA 98052  
+   USA 
+    
+   Telephone: +1 425 936 9760 
+   E-Mail:    charle@Microsoft.com 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Burger et. al.             Expires 12/05/01                  [Page 16] 
+ 
+
+                  Message Context for Internet Mail         June 2001 
+ 
+ 
+14. Full Copyright Statement 
+ 
+   The IETF takes no position regarding the validity or scope of any 
+   intellectual property or other rights that might be claimed to 
+   pertain to the implementation or use of the technology described in 
+   this document or the extent to which any license under such rights 
+   might or might not be available; neither does it represent that it 
+   has made any effort to identify any such rights.  Information on the 
+   IETF's procedures with respect to rights in standards-track and 
+   standards-related documentation can be found in BCP-11.  Copies of 
+   claims of rights made available for publication and any assurances 
+   of licenses to be made available, or the result of an attempt made 
+   to obtain a general license or permission for the use of such 
+   proprietary rights by implementers or users of this specification 
+   can be obtained from the IETF Secretariat. 
+    
+   The IETF invites any interested party to bring to its attention any 
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to practice 
+   this standard.  Please address the information to the IETF Executive 
+   Director. 
+    
+   Copyright (C) 2001 The Internet Society.  All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works.  However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+ 
+
+
+
+
+  
+Burger et. al.             Expires 12/05/01                  [Page 17] 
+ 
+
diff --git a/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt b/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt
new file mode 100644
index 00000000..123bea1d
--- /dev/null
+++ b/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

+K. Khanna: gauravkhanna@mailandnews.com                                            

+

+

diff --git a/Documentation/en/I-D/draft-melnikov-smtp-lang-04.txt b/Documentation/en/I-D/draft-melnikov-smtp-lang-04.txt
new file mode 100644
index 00000000..9c04ae58
--- /dev/null
+++ b/Documentation/en/I-D/draft-melnikov-smtp-lang-04.txt
@@ -0,0 +1,574 @@
+Network Working Group                            Mike Gahrns, Microsoft 
+Internet Draft           Alexey Melnikov, ACI WorldWide/MessagingDirect
+Document: draft-melnikov-smtp-lang-04.txt                     July 2001
+
+
+                          SMTP Language Extension
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.  Internet-Drafts are
+   working documents of the Internet Engineering Task Force (IETF), its
+   areas, and its working groups.  Note that other groups may also
+   distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six
+   months and may be updated, replaced, or obsoleted by other documents
+   at any time.  It is inappropriate to use Internet- Drafts as
+   reference material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+   This document  suggests  a  proposed  protocol  for  the   Internet
+   community, and requests discussion and suggestions for improvements.
+   Distribution of this draft is unlimited.
+
+   The protocol discussed in this document is experimental and subject to
+   change.  Persons planning on either implementing or using this protocol
+   are STRONGLY URGED to get in touch with the author before embarking on
+   such a project.
+
+
+0. Meta Information on this draft 
+    
+   This information is intended to facilitate discussion.  It will be
+   removed when this document leaves the Internet-Draft stage.
+    
+
+   Changes since -00 
+    
+1). Corrected grammar error in LANG command description section
+
+2). Included Mark Crispin's suggestion of allowing the server to substitute
+    a primary language if the sublanguage asked for is not available.
+
+3). Added section 5 that describes extended LANG reply
+
+4). Corrected example, more examples
+
+5). Added extension mechanism
+
+6). Specified interaction with RFC-2034 ("SMTP Service Extension for
+    Returning Enhanced Error Codes")
+
+7). LANG command must always have language-tag as a parameter. Only EHLO
+    response could be used to examine list of supported languages.
+
+
+   Changes since -01 
+    
+1). Corrected ABNF for CR
+
+2). Updated Copyright section
+
+3). Other minor bugfixes
+
+
+   Changes since -02 
+    
+1). Extended DSN format to include language tag
+
+2). Fixed few typos.
+
+
+   Changes since -03 
+    
+1). Changed DSN format to include language tag and translation of text part of
+    diagnostic-code-field. Don't use diagnostic-code-field for a non English text.
+
+2). Added LANG parameter to MAIL FROM.
+
+
+   Open issues
+
+1). What a server should send in LANGUAGE EHLO response if it can't
+    enumerate all of the supported languages but only some of them?
+
+
+1. Abstract
+
+   The Simple Mail Transfer Protocol [RFC-821] allows server responses to
+   include human-readable text that in many cases needs to be presented to
+   the user.  This document specifies a way for a client to negotiate which
+   language the server should use when sending human-readable text. It also
+   extends DSN format to include language field for the human-readable text.
+
+
+2. Conventions used in this document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and server
+   respectively.  If such lines are wrapped without a new "C:" or "S:"
+   label, then the wrapping is for editorial clarity and is not part of the
+   command.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KEYWORDS].
+
+
+3. Framework for the Language SMTP service extension
+
+   The Language SMTP service extension uses the SMTP service extension
+   mechanism described in [ESMTP]. The following SMTP service extension is
+   therefore defined:
+
+  (1) The name of the SMTP service extension is "Language".
+
+  (2) The EHLO keyword value associated with this service extension is
+      "LANGUAGE".
+
+  (3) The LANGUAGE EHLO keyword contains as a parameter a space separated
+      list of the names of supported language tags. This list is optional. 
+      If the language tag argument is omitted, this means that server is
+      unable to enumerate the list of languages it supports.
+
+  (4) A new SMTP verb "LANG" is defined by this document.
+
+  (5) One optional parameter is added to the MAIL command:
+
+      An optional parameter for the MAIL command, using the esmtp-keyword
+      "LANG", (used to propagate a language that should be used in human
+      readable part and/or localized-diagnostic-text-field field of
+      "message/delivery-status" part (see section 8.) of a delivery status
+      notification for the message), is defined in section 7.
+
+  An additional document may define an extension to LANGUAGE ESMTP
+  extension.  Any such extension MUST use ESMTP extension name that starts
+  with LANGUAGE prefix. This document doesn't specify any LANG command
+  extension.
+
+
+4. Requirements
+
+   Any server that supports this extension MUST support the language
+   "i-default".  It SHOULD use the language "i-default" as described in
+   [CHARSET-POLICY] as its default language until another supported language
+   is negotiated by the client.  If a server is able to enumerate supported
+   languages it MUST include "i-default" in EHLO response. Otherwise it MUST
+   NOT return any language in LANGUAGE EHLO response.
+
+
+5. LANG Command
+
+   LANG language-tag [*extension]
+
+     Arguments:
+         language tag as defined by [RFC-1766].
+         optional extension specific parameters 
+
+     Restrictions:
+         The LANG command is permitted throughout a mail connection.
+
+     Reply Codes:
+         Success:
+            250 LANG command completed successfully
+         Error: 
+            504 Language is not supported
+            421 <domain> Service not available, closing transmission channel
+
+     Discussion: 
+         The LANG command requests that human-readable text emitted by the
+         server be localized to the language specified in the language tag
+         argument.
+
+         If a sublanguage was asked for and not available but the primary
+         language is available, the server SHOULD switch to the primary
+         language and MUST use an extended LANG reply containing the
+         identifier of the primary language it switched to as described in
+         section 5.
+
+         It is also recommended that server recognizes languages that have
+         multiple different tags (for example "ru" and "rus").
+
+         Note 1. Client MUST NOT use MUL (Multiple languages) and UND
+         (Undetermined) language tags and server MUST return error code 504
+         to the LANG command that is used with such parameter.
+
+         Note 2. [RFC-1766] warns that there is no guaranteed relationship
+         between languages whose tags start out with the same series of
+         subtags. However it is believed that for the purpose of this
+         document it is safe to treat all languages, whose tags starts with
+         primary language described in ISO 639-1 and ISO 639-2 (i.e. all 2
+         or 3 letters primary languages) as hierarchical.  For all languages
+         with other primary tags described fallback rule MUST NOT be used.
+         In particular, language tags starting with 'i-' and 'x-' SHOULD NOT
+         be treated as hierarchical.
+
+         If the command succeeds, the server will return human-readable
+         responses in the specified language starting with the successful
+         250 response to the LANG command.  These responses will be in UTF-8
+         [RFC-2044]. In particular, LANG command MAY affect the result of a
+         HELP command.
+
+         If the command fails, the server will continue to return human-
+         readable responses in the language it was previously using.
+
+         An additional document may define an extension to LANGUAGE ESMTP
+         extension.  Any such extension MUST use ESMTP extension name that
+         starts with LANGUAGE prefix. This document doesn't specify any
+         LANGUAGE extension.
+
+         LANGUAGE extension document may define additional parameters to LANG
+         command.  Client MUST NOT issue the optional extension parameters
+         unless a server has indicated in its EHLO response that it supports
+         that extension. In case when server doesn't support requested
+         parameter(s) or any parameters, it MUST respond with 504 code.
+
+     Example 1:
+
+        < The server defaults to using responses in "i-default" language
+          until the user explicitly changes the language. >
+
+         S: 220 smtp.example.com ESMTP server ready
+         C: EHLO main.example.com
+         S: 250-smtp.example.com
+         S: 250-AUTH CRAM-MD5 DIGEST-MD5
+         S: 250 LANGUAGE EN FR RU i-default
+         C: HELP
+         S: 214-This is Sendmail version X.X.X
+         S: 214-Topics:
+         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
+         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
+         S: 214-    EXPN    VERB    ETRN    DSN
+         S: 214-For more info use "HELP <topic>".
+         S: 214 End of HELP info
+
+        < Once the client changes the language, all responses will be in
+          that language starting with 250 response to the LANG command. >
+
+         C: LANG FR
+         S: 250 La Language commande a ete execute avec success
+
+         C: HELP
+         S: 214-C'est le programme Sendmail version X.X.X
+         S: 214-Topics:
+         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
+         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
+         S: 214-    EXPN    VERB    ETRN    DSN
+         S: 214-Pour obtenir l'information supplementaire utilisez "HELP <topic>".
+         S: 214 La fin de l'information 
+
+        < If a server does not support the requested language, responses
+          will continue to be returned in the current language the server is
+          using. >
+
+         C: LANG DE
+         S: 504 Ce Language n'est pas supporte
+
+     Example 2:
+
+        < The client tries to select MUL language that couldn't be used with
+          described extension>
+
+         C: LANG MUL
+         S: 504 It is not allowed to use MUL language.
+
+     Example 3:
+
+        < The client tries to use LANG extension not supported by server>
+
+         C: LANG i-default (blah blah)
+         S: 504 LANG extension blah is not recognized.
+
+
+6. "LANG" extended reply
+
+   Extended reply is the reply that contains additional information in the
+   text part. Extended reply allows to pass additional information from
+   server to client.  Client may choose to ignore additional information in
+   an extended reply. Thus client that doesn't recognize an extended reply
+   would treat it as a regular SMTP reply.
+
+     Example 4:
+
+        < The client tries to select the language, but it is unavailable. 
+          However primary language is available>
+
+         C: LANG FR-ca
+         S: 250 [LANG FR]La Language commande a ete execute avec success
+
+   Client that supports LANGUAGE extension must recognize Enhanced Error
+   Codes defined in [RFC-2034]. When server supports both LANGUAGE and
+   ENHANCEDSTATUSCODES extensions, Extended reply data MUST follow Enhanced
+   Error Code in reply.
+
+     Example 5:
+
+        < The server supports both LANGUAGE and ENHANCEDSTATUSCODES>
+
+         S: 220 smtp.example.com ESMTP server ready
+         C: EHLO main.example.com
+         S: 250-smtp.example.com
+         S: 250-LANGUAGE EN FR RU i-default
+         S: 250 ENHANCEDSTATUSCODES
+         C: LANG FR-ca
+         S: 250 2.0.0 [LANG FR]La Language commande a ete execute avec success
+
+
+7. The LANG parameter of the ESMTP MAIL command
+
+   Then LANG esmtp-keyword on the extended MAIL command specifies what
+   language should be used in human readable part and/or
+   localized-diagnostic-text-field field of "message/delivery-status" part
+   (see section 8.) of a delivery status notification for the message.
+
+   If the LANG esmtp-keyword is used, it MUST have an associated
+   esmtp-value. The ABNF for the LANG parameter is:
+
+     lang-parameter = "LANG=" language-tag
+
+   If the message is relayed to another SMTP server that supports LANGUAGE
+   ESMTP extension, the MTA acting as the client MUST check if the receiving
+   MTA lists the language specified in lang-param ("requested language") in
+   the list of supported language tags in LANGUAGE EHLO response.  If the
+   receiving MTA either lists the requested language or doesn't list any
+   language tag (i.e. the receiving MTA is unable to list languages it
+   supports) the sender MUST issue LANG command for the requested language.
+   After that, regardless of the result of LANG command, the client MTA MUST
+   specify LANG parameter in MAIL command.
+
+   The receiving MTA SHOULD use the language specified in LANG parameter if
+   it has to generates a DSN for the message. Human readable part in
+   generated DSN SHOULD contain the description of the event in both English
+   and requested language. If the server MTA doesn't support the requested
+   language, it MUST act as if the client didn't specify LANG parameter in
+   MAIL command.
+
+     Example 6:
+
+        < Relaying of the message >
+
+         S: 220 smtp.example.com ESMTP server ready
+         C: EHLO main.example.com
+         S: 250-smtp.example.com
+         S: 250-DSN
+         S: 250-8BITMIME
+         S: 250 LANGUAGE
+         C: LANG RU
+         S: 504 Unsupported language
+         C: MAIL FROM:<Katerina@example.ru> LANG=ru
+         S: 250 <Katerina@example.ru> sender ok
+         C: DATA
+         S: 354 okay, send message
+         C: (message goes here)
+         C: .
+         S: 250 message accepted
+         C: QUIT
+         S: 221 goodbye
+
+
+8. Delivery status notifications and extension
+
+   The format of delivery status notifications (DSNs) is specified in [DSN]. 
+   This memo extends the per-recipient-fields of [DSN] to include two new
+   DSN fields, Localized-Diagnostic-Text, that is equivalent to text part of
+   Diagnostic-Code but contains text in any language other than English, and
+   Language, indicating the language tag for Localized-Diagnostic-Text
+   field. In the augmented BNF of RFC 822 [ABNF], per-recipient-fields is
+   therefore extended as follows:
+
+     per-recipient-fields =
+          [ original-recipient-field CRLF ]
+          final-recipient-field CRLF
+          action-field CRLF
+          status-field CRLF
+          [ remote-mta-field CRLF ]
+          [ [language-field CRLF
+            localized-diagnostic-text-field CRLF ]
+            diagnostic-code-field CRLF ]
+          [ last-attempt-date-field CRLF ]
+          [ will-retry-until-field CRLF ]
+          *( extension-field CRLF )
+
+    language-field = "Language" ":" language
+
+    localized-diagnostic-text-field = "Localized-Diagnostic-Text" ":" *text
+
+   where language is a language tag as described in [RFC-1766].
+
+   An SMTP server that supports both DSN and LANGUAGE extensions SHOULD
+   include localized-diagnostic-text-field. If
+   localized-diagnostic-text-field is present, language-field MUST be
+   present too. diagnostic-code-field MUST NOT contain text in any language
+   other than English.
+
+
+8. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur Form
+   (BNF) as described in [ABNF].
+
+   Except as noted otherwise, all alphabetic characters are
+   case-insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST accept
+   these strings in a case-insensitive fashion.
+
+   CR              = %x0D     ;; ASCII CR, carriage return
+
+   CRLF            = CR LF
+
+   LF              = %x0A     ;; ASCII LF, line feed
+
+   SPACE           = %x20     ;; ASCII SP, space
+
+   LANG_Command = "LANG" SPACE language_tag [*extension] CRLF
+      ; A client MUST NOT issue the optional extension parameter 
+      ; unless a server has indicated in its EHLO response that it 
+      ; supports that extension 
+
+   extension = SP "(" lang-ext-name SP lang-ext-values ")" 
+
+   lang-ext-name = text
+      ; Name of LANG extension
+
+   lang-ext-values = "(" lang-ext-value *(SP lang-ext-value)")"
+      ; List of LANG extension specific values 
+
+   lang-ext-value = text
+
+   LANGUAGE_List = "LANGUAGE" *(SPACE <language_tag>) CRLF
+      ; Note 1: the server is required to support the language i-default and
+      ; as such i-default MUST appear in the language response.  When
+      ; "i-default" is used, all responses MUST contain only ASCII text.
+      ;
+      ; Note 2: Language tags MUL (Multiple languages) and UND
+      ; (Undetermined) MUST NOT be used.
+
+
+   language_tag =  <language_tag> as defined in [RFC-1766]
+
+   Reply-line |= Lang-Reply-line
+      ; Reply-line is defined in [SMTP-UPD]
+      ; See section 6 for description of Lang-Reply-line
+
+   Lang-Reply-line = Reply-code [ SP ext-text ] CRLF
+      ; Reply line for LANG command
+
+   ext-text = ext-data text
+
+   ext-data = "[" ext-name SP ext-value "]"
+      ; Note 1: In the case of multiline response the same ext-data SHOULD
+      ; appear on every line.
+      ;
+      ; Note 2: In case when server also supports "SMTP Service Extension
+      ; for Returning Enhanced Error Codes" [RFC-2034], ext-data MUST follow
+      ; Enhanced Error Code.
+
+   ext-name = "LANG"
+
+   ext-value = Primary-tag
+      ; Primary tag as defined by [RFC-1766]  
+
+
+9. Security Considerations
+
+   This extension allows the negotiation of a language for the human-
+   readable text returned by a server.  A user is able to query the
+   languages that a server supports.
+
+
+10. References
+
+   [RFC-821], Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+   821, August 1982, <ftp://ftp.isi.edu/in-notes/rfc821.txt>
+
+   [SMTP-UPD], Klensin, J., "Simple Mail Transfer Protocol",
+   draft-ietf-drums-smtpupd-10.txt (work in progress), February 1999. 
+
+   [RFC-1766], Alvestrand, H., "Tags for the Identification of
+   Languages", RFC 1766, UNINETT, March 1995,
+   <ftp://ftp.isi.edu/in-notes/rfc1766.txt>
+
+   [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 
+   Languages", RFC 2277, January 1998, <ftp://ftp.isi.edu/in-notes/rfc2277.txt>
+
+   [RFC-2044], Yergeau, F., "UTF-8, a transformation format of Unicode
+   and ISO 10646, RFC 2044, Alis Technologies, October 1996,
+   <ftp://ftp.isi.edu/in-notes/rfc2044.txt>
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, March 1997,
+   <ftp://ftp.isi.edu/in-notes/rfc2119.txt>
+
+   [IMAP-LANGUAGE], Gahrns, M., Melnikov, A., "IMAP4 Language Extension", 
+   draft-gahrns-imap-language-xx.txt (work in progress), Microsoft, 
+   ACI WorldWide/MessagingDirect
+
+   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
+   ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd.,
+   November 1997, <ftp://ftp.isi.edu/in-notes/rfc2234.txt>
+
+   [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced
+   Error Codes", RFC 2034, Innosoft, October 1996
+
+   [DSN]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
+   Delivery Status Notifications", RFC 1894, January 1996.
+
+11.  Acknowledgments
+
+   This document is based on the early version of [IMAP-LANGUAGE]. 
+   Thus the work of Andrew McCown is appreciated.
+
+   Many thanks to the following people who gave feedback on the document:
+   Brad Knowles and Paul Hoffman.
+
+
+12.  Copyright
+
+   Copyright (C) The Internet Society 1999-2001. All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph
+   are included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+13. Author's Address
+
+    Mike Gahrns
+    Microsoft
+    One Microsoft Way
+    Redmond, WA, 98072
+
+    Phone: (425) 936-9833
+    Email: mikega@microsoft.com 
+
+    Alexey Melnikov
+    ACI WorldWide/MessagingDirect
+    #900, 10117 Jasper Avenue,
+    Edmonton, Alberta, T5J 1W8
+
+    Phone: (780) 424-4922 Ext 357
+    Email: mel@messagingdirect.com
+
diff --git a/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-01.txt b/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-01.txt
new file mode 100644
index 00000000..92e7aad6
--- /dev/null
+++ b/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-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):

+

+M. Nakamura: motonori@econ.kyoto-u.ac.jp                                             

+J. Hagino: itojun@jilab.net                                                        

+

+

diff --git a/Documentation/en/I-D/draft-newman-datetime-02.txt b/Documentation/en/I-D/draft-newman-datetime-02.txt
new file mode 100644
index 00000000..f818256a
--- /dev/null
+++ b/Documentation/en/I-D/draft-newman-datetime-02.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

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

+

+

diff --git a/Documentation/en/I-D/draft-palme-autosub-07.txt b/Documentation/en/I-D/draft-palme-autosub-07.txt
new file mode 100644
index 00000000..2cc38fc0
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-autosub-07.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

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

+

+

diff --git a/Documentation/en/I-D/draft-palme-e-mail-translation-01.txt b/Documentation/en/I-D/draft-palme-e-mail-translation-01.txt
new file mode 100644
index 00000000..a84423c5
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-e-mail-translation-01.txt
@@ -0,0 +1,1011 @@
+Network Working Group                                     Jacob Palme
+Internet Draft                               Stockholm University/KTH
+draft-palme-e-mail-translation-01.txt                          Sweden
+Category-to-be: Proposed standard                 Date: November 2000
+                                                     Expires: May 2001
+
+                    Support for Language Translation
+                        in E-Mail and Netnews
+
+                         Status of this Memo
+
+
+This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright (C) The Internet Society 1999, 2000. All Rights
+Reserved.
+
+1.1   Abstract
+
+This memo specifies extensions to e-mail and netnews standards, to
+allow for the submission of translation of messages, not only at
+initial submission time, but also at later time, and made by other
+translators than the original author of the message. three new e-
+mail/netnews header fields are proposed, "Content-Translation-Of,
+"Content-Translator" and "Translation-Request" and a new content-type
+"Multipart/translations" is specified.
+
+This memo does not specify any change to the already existing
+proposed standard for the Content-Language header (RFC 1766).
+
+
+1.2   Mailing list
+
+Further discussion of this memo can take place in the mailing list WG-
+I18N@TERENA.NL.
+
+Mailing List Information
+
+To write contributions
+
+  Further discussion on this document should be done through the
+  mailing list WG-I18N@TERENA.NL.
+
+  Comments on less important details may also be sent to the editor,
+  Jacob Palme <jpalme@dsv.su.se>.
+
+To subscribe
+
+  To subscribe to this mailing list, send a message to
+  LISTSERV@TERENA.NL
+  which contains the text
+  SUB[SCRIBE] WG-I18N <your name (not your email address)>
+
+To unsubscribe
+
+  To unsubscribe from this list, send a message to
+  LISTSERV@TERENA.NL
+  which contains the text
+  UNS[UBSCRIBE] WG-I18N
+
+To access mailing list archives
+
+  The archives are available for browsing from
+  http://www.terena.nl/working-groups/wg-i18n/hypermail/
+
+The archives are also available by email. Send a message to
+  LISTSERV@TERENA.NL with the text "INDEX WG-I18N" to get a list
+  of the archive files, and then a new message "GET <file name>" to
+  retrieve archive files.
+
+
+Table of Contents
+
+      1.1  Abstract                                                    1
+      1.2  Mailing list                                                2
+2    Language Support in Existing Standards                            3
+3    Multi-Language Scenario                                           4
+4    The Content-Translation-Of Header Field                           4
+5    The Content-Translator Header Field                               5
+6    The Multipart/Translations MIME Content Type                      5
+7    The Translation-Request Header                                    6
+8    Examples                                                          7
+      8.1  Separate Original and Translated Messages                   7
+      8.2  Sending a Message to a Translator for Translation           8
+      8.3  Resending of the Message in 8.2 After Translation           8
+9    For Further Study                                                 9
+10   Security Considerations                                           10
+11   Copyright and Disclaimer                                          10
+12   Acknowledgments                                                   11
+13   References                                                        11
+14   Author's Address                                                  12
+Appendix 1: An Investigation of Handling of
+Multipart/Alternative in some Common Mailers in November 2000          12
+
+
+
+2     Language Support in Existing Standards
+
+The "Content-Language:" e-mail content header specified in RFC 1766 [6]
+can be used to specify one or a list of natural languages used in that
+message body.
+
+The "Content-Type: Multipart/alternative" defined in MIME [4] might be
+used to send the same text in more than one language. Each part would
+then be marked with the "Content-Language:" header to indicate its
+language, and the recipient might choose the body part according to his
+or her language preferences. The combination of Multipart/alternative
+with Content-Language is however not commonly supported and gives
+disastrous results with most mailers (November 2000), so this solution
+is not recommended in this specification.
+
+In HTTP [7], a request operation can indicate a list of preferred
+languages, and the server can then deliver the resource in the
+preferred language. The request operation can also indicate how good
+each language is for a particular user, in the format:
+
+           Accept-Content-Language: da, en-gb;q=0.8, en;q=0.7
+
+HTTP also has facilities for the server to tell the client which
+alternatives are available in different languages, letting the client
+choose between them. It is also possible, with HTTP, to deliver a
+resource in the "Multipart/alternative" format, if the recipient wants
+to store the resource in all available language versions. These HTTP
+features are however not commonly supported (November 2000).
+
+All of these methods of transmitting information is based on the
+assumption that all language versions are ready and available when a
+message is sent.
+
+
+3     Multi-Language Scenario
+
+John Smith writes a message in English and submits it to a mailing list
+or to a Usenet newsgroup. The mailing list expander sends this message
+to an automatic translation agent which translates it into other
+languages and returns the translations to the mailing list expander.
+The mailing list expander might then either forward all translations to
+each member of the list, or forward to each member only the translation
+preferred by this member. Ernst D’rrenmatt has requested the mailing
+list to send him all language versions, but reads this message in
+English, because he has indicated that he prefers English original
+documents to automatic German translations. Hilda Schmidt reads the
+message in both English and German, decides that the automatic German
+translation is not very good, and cleans it up, submitting a new better
+translation to German. Ernst D’rrenmatt checks this translation, makes
+some corrections, and submits a final corrected version of the German
+translation of the original message.
+
+
+4     The Content-Translation-Of Header Field
+
+The "Content-Translation-Of" header field is used when submitting a
+translation to a message, which earlier has been sent in another
+language. The syntax for this header field is similar to the syntax for
+the "In-Reply-To" header, but only one value is allowed, since every
+translation can only be the translation of one previous message. The
+value contains the Message-ID of the original message before
+translation. If a message is available in more than one language,
+"Content-Translation-Of" should always reference the original message,
+even if the translation was actually based on a translated version. If
+the original message is available in more than one version, with
+"Supersedes" or "Replaces" references between the versions, then the
+"Content-Translation-Of" should reference the version which was the
+basis of this translation.
+
+Translation is applied to the body content, and to the content of the
+"Subject:" header, but not to any other header contents. When a
+"Subject:" is translated, the language code enclosed in parenthesis"
+can be added to the beginning of the "Subject".
+
+If more than one translation is available of the same original message,
+the "Supersedes" or "Replaces" header field should not be used between
+them. "Supersedes" or "Replaces" are only to be used when the original
+message is revised.
+
+
+5     The Content-Translator Header Field
+
+The "Content-Translator" header field indicates who made the
+translation. When a translation is submitted, the "From" header field
+should still indicate the original author, but the "Content-Translator"
+header field can indicate who made the translation.
+
+The syntax of the "Content-Translator" header field is:
+
+Content-Translator           = "Content-Translator:" ( CFWS mailbox-
+list / Phrase )
+                        *(";" translator-parameter) CFWS CRLF
+
+translator-parameter = art / fluency / future-extension
+
+art                  = "Human" / "Machine" / "Original"
+
+fluency              = "Expert" / "Native" / "Other"
+
+The meaning of these parameters are:
+
+Human    = Translation was made or revised/approved by a human
+            translator.
+
+Machine  = Translation was entirely automatic, with no human checking
+            of the translation. In this case, the "Auto-Submitted" [8]
+            header should also be added to the message heading.
+
+Original = This is the original before translation. Absence of a
+            "Content-Translator" also indicates that the message is not
+            translated, but "Content-Translator: None; Original" can be
+            used to explicitly specify that this is not translated.
+
+Expert   = Translation was made by an expert translator.
+
+Native   = Translation was made by a native speaker of the target
+            language.
+
+
+Other    = Translation was made by someone who is not an expert nor
+            a native speaker of the target language.
+
+
+6     The Multipart/Translations MIME Content Type
+
+It might seem natural to use the Multipart/alternative content type
+[5], with different language versions in the different bodies. This
+should, however be avoided, because it downgrades disastrously to older
+mailers. Instead, a new content-type Multipart/translations is to be
+used. This will according to the Mime standard downgrade to
+Multipart/mixed, which downgrades much better for older mailers than
+Multipart/alternative does.
+
+The Multipart/translations header is to be used when the different body
+parts contain the same information translated to different human
+languages. Each body part of Multipart/translations must contain a
+Content-Language header. Even if the body part itself is a multipart,
+such as a Multipart/mixed or Multipart/related. Content-Language is
+required both in the embedded multipart heading and in textual body
+parts within the embedded multipart.
+
+If translation is desired also of the "Subject" header, then the
+translated body parts has to be of content-type Message/rfc822, since
+only that content-type allows different subject in different body
+parts.
+
+It is recommended to add information about translation at the top of
+each body part (example, see section 8.3 below), because some mailers
+display multiple body parts in sequence inline with no indication of
+the Differences between them. This recommendation may be lifted at some
+future time when most mailers have support for Multipart/translations.
+
+It is also recommended to add a blank line at the end of each
+translation, since this will show up neater on some old mailers, which
+display all body parts in sequence to the recipient.
+
+
+7     The Translation-Request Header
+
+The Translation-Request header is used when sending a message for
+translation to a human or machine translator. Its value is a list of
+the languages to which translation is requested. The languages are
+specified according to [6]. The language of the original can be
+included in the Translation-Request header, this tells the translator
+to include the original of the message when it is forwarded after
+translation, together with the translations to other languages.
+
+When the Translation-Request header is used, the content-type should
+always be "Message/rfc822" [5] and the content should be the message to
+be translated. When the translation is ready, the translator is
+instructed to send the translation to the recipients in the "To:",
+"Cc:" and "Bcc:" headers and to leave non-translated headers of the
+message/rfc822 body as they were before the translation. When the
+translator resends the translation, Resent-From" is added with the name
+of the translator, and "Resent-Date" with the date of the translation.
+If translation to multiple languages is requested, the result is sent
+using the content-type multipart/translations.
+
+Syntax: "Translation-Request:" CFWS language 1*(, CFWS language)
+         CFWS CRLF
+
+
+8     Examples
+
+8.1   Separate Original and Translated Messages
+
+     Message-ID: A@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+     Content-Translator: None; Original
+     Content-Language: en
+
+     Message-ID: B@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+     Content-Translation-Of: A
+     Content-Translator: Erika Ernst <eernst@foo.bar.de>; human; native
+     Content-Language: de
+
+     Message-ID: C@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+     Content-Translation-Of: A
+     Content-Translator: Tomas D’rrenmatt <tdurrenmatt@foo.bar.de>;
+     expert
+     Content-Language: de
+
+     Message-ID: D@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+     Content-Language: en
+     Supersedes: A
+
+     Message-ID: E@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+     Content-Translation-Of: D
+     Content-Translator: Supertrans Translation Engine
+     <supertrans@foo.bar>; machine
+     Auto-Submitted: Auto-generated
+     Content-Language: de
+     Supersedes: A
+
+
+8.2   Sending a Message to a Translator for Translation
+
+     Message-ID: Z@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     Translation-Request: en, fr, de
+     Content-Type: Message/rfc822
+
+     Message-ID: A@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+     Content-Translator: None; Original
+     Content-Language: en
+     Subject: Orchids
+
+     Orchids are beautiful.
+
+
+8.3   Resending of the Message in 8.2 After Translation
+
+     Resent-From: Supertrans Translation Engine <supertrans@foo.bar>
+     Message-ID: Z@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     Content-Type: Multipart/translations; boundary="boundary 1"
+     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+     Subject: (en) Orchids
+
+     --boundary 1
+     Message-ID: Y@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     Translation-Request: en, fr, de
+     Content-Type: Message/rfc822
+
+     Message-ID: A@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+     Content-Translator: None; Original
+     Content-Language: en
+     Subject: (en) Orchids
+
+     Original English Text
+     ---------------------
+
+     Orchids are beautiful.
+
+     --boundary 1
+     Content-Type: Message/rfc822
+
+     Message-ID: B@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     Content-Translation-Of: A
+     Content-Translator: Supertrans Translation
+                         Engine <supertrans@foo.bar>; machine
+     Content-Language: de
+     Subject: (de) Orchideen
+
+     Deutsche ›bersetzung
+     --------------------
+
+     Orchideen sind sch÷n.
+
+     --boundary 1
+     Content-Type: Message/rfc822
+
+     Message-ID: C@foo.bar.net
+     Content-Translation-Of: A
+     Content-Translator: Supertrans Translation Engine
+                         <supertrans@foo.bar>; machine
+     Content-Language: fr
+     Subject: (fr) Orchid‰e
+
+     Traduction fran‡ais
+     -------------------
+
+     Orchid‰e sont beau.
+
+     --boundary 1--
+
+
+9     For Further Study
+
+The following is not yet resolved in this draft:
+
+-  How a user can register its language preferences with a mail
+    server or a mailing list expander.
+
+-  Whether POP/IMAP should be extended with commands to request
+    messages in only a certain language.
+
+-  How to handle translation in Usenet News. One might for example
+    have a set of co-ordinated newsgroups, with the same articles in
+    different languages. A newsgroup "alt.cultures.multiple" might be
+    provided with English in "alt.cultures.multiple.en", German in
+    "alt.cultures.multiple.de", etc., with automatic or manual
+    translation of the messages between these newsgroups.
+
+-  Handling of signatures and seals.
+
+
+10    Security Considerations
+
+Translations made by other people than the original author of
+a message will of course entail the risk of intentional or
+unintentional incorrectness of the translation. But this is a
+risk we must accept if we want to have translations, and if
+everyone is not fluent in every language.
+
+Some people claim that machine translation technology is so
+bad, that it should not be used at all. I do not agree,
+machine translation will often give a good understanding of
+the intent of the original text even if the translation is not
+perfect. And if the recipient has a choice of either not
+understanding a message at all, or getting a machine
+translation, the recipient may still prefer the automatic
+translation. Based on this, the recipient might decide whether
+the message is of enough interest to be willing to pay for a
+human to make a better translation.
+
+The risk can be reduced, if the receiving user agent clearly
+shows that a message is a translator, who made the
+translation, and allows the user to check the original text
+and compare it with the translation.
+
+A translation will invalidate any digital signatures or seals,
+but the translator might add its own signature and seals to
+ensure that the translation is not corrupted when sent from
+translator to readers. These signatures and seals will not
+promise any correspondence with the original text, except the
+promise which a translator might give of the correctness of
+its translations.
+
+
+11    Copyright and Disclaimer
+
+The IETF takes no position regarding the validity or scope of
+any intellectual property or other rights that might be
+claimed to pertain to the implementation or use of the
+technology described in this document or the extent to which
+any license under such rights might or might not be available;
+neither does it represent that it has made any effort to
+identify any such rights. Information on the IETF's procedures
+with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims
+of rights made available for publication and any assurances of
+licenses to be made available, or the result of an attempt
+made to obtain a general license or permission for the use of
+such proprietary rights by implementors or users of this
+specification can be obtained from the IETF Secretariat."
+
+The IETF invites any interested party to bring to its
+attention any copyrights, patents or patent applications, or
+other proprietary rights which may cover technology that may
+be required to practice this standard. Please address the
+information to the IETF Executive Director.
+
+Copyright (C) The Internet Society (2000). All Rights
+Reserved.
+
+This document and translations of it may be copied and
+furnished to others, and derivative works that comment on or
+otherwise explain it or assist in its implementation may be
+prepared, copied, published and distributed, in whole or in
+part, without restriction of any kind, provided that the above
+copyright notice and this paragraph are included on all such
+copies and derivative works. However, this document itself may
+not be modified in any way, such as by removing the copyright
+notice or references to the Internet Society or other Internet
+organizations, except as needed for the purpose of developing
+Internet standards in which case the procedures for copyrights
+defined in the Internet Standards process must be followed, or
+as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will
+not be revoked by the Internet Society or its successors or
+assigns.
+
+
+12    Acknowledgments
+
+Suggestions during the development of this memo has been given by
+Harald Alvestrand, Bill Jansson, Larry Masinter, Keith Moore and Henry
+Spencer.
+
+13    References
+
+Ref.    Author, title                                    IETF status
+                                                          (July 1996)
+-----   ---------------------------------------------    -----------
+[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
+         STD 10, RFC 821, August 1982.                    Recommended
+
+[2]     D. Crocker: "Standard for the format of ARPA     Standard,
+         Internet text messages." STD 11, RFC 822,        Recommended
+         August 1982.
+
+[3]     M.R. Horton, R. Adams: "Standard for             Not an
+         interchange of USENET messages", RFC 1036,       official
+         December 1987.                                   IETF
+                                                          standard,
+                                                          but in
+                                                          reality a de-
+                                                          facto
+                                                          standard for
+                                                          Usenet News
+
+[4]     N. Freed & N. Borenstein: "Multipurpose          Draft
+         Internet Mail Extensions (MIME) Part One:        Standard,
+         Format of Internet Message Bodies." RFC 2045.    elective
+         November 1996.
+
+[5]     N. Freed & N. Borenstein: "Multipurpose          Draft
+         Internet Mail Extensions (MIME) Part Two:        Standard,
+         Media Types." RFC 2046. November 1996.           elective
+
+[6]     H. Alvestrand: "Tags for the Identification      Proposed
+         of Languages", RFC 1766, February 1995.          standard,
+                                                          elective
+
+[7]     R. Fielding, J. Gettys, J. Mogul, H. Frystyk,    Draft
+         T. Berners-Lee: Hypertext Transfer Protocol -    standard
+         - HTTP/1.1, RFC 2616, June 1999.
+
+[8]     J. Palme: The Auto-Submitted, Supersedes and     Work in
+         Expires Headers in E-mail and Netnews, draft-    progress
+         ietf-mailext-new-fields-14.txt, November
+         1998.
+
+
+14    Author's Address
+
+Jacob Palme                     Phone: +46-8-16 16 67
+Stockholm University/KTH        Fax: +46-8-783 08 29
+Skeppargatan 73                 E-mail: jpalme@dsv.su.se
+S-115 30 Stockholm, Sweden
+
+
+Appendix 1: An Investigation of Handling of Multipart/Alternative in
+some Common Mailers in November 2000
+
+As a basis for possible work on developing standards for language-
+translation in e-mail, I tested how some common mailers handled
+multipart/alternative with different Content-Language in the body parts
+in November 2000.
+
+I used the following test messages:
+
+Test message 1: First part English, second part German
+
+Test message 2: Same as test message 1, but first part German, second
+part English
+
+Test message 3: Same as test message 2, but multipart/mixed instead of
+multipart/alternative.
+
+Test message 4: Same as test message 3, but with Content-Disposition:
+Attachment on all but the first body part.
+
+Test message 5: Multipart/mixed on an outer level, with the first part
+a directory of attachments, and the second part a multipart/alternative
+with the German and English parts as the two alternatives.
+
+Test message 6: Multipart/alternative with the first part containing
+all the translations in one body part, and the second part a
+multipart/alternative with one translation in each alternative.
+
+I tested this with the following mailers:
+Eudora 5 Macintosh, Pine 4.21 on Unix, Netscape 4.7 Macintosh, Outlook
+Express 5 Macintosh, First Class 5.611 Macintosh, KOM 2000 (our own
+system), and Hotmail.
+
+Result: None of the mailers seemed to test on the Content-Language
+value, and make a selection based on this.
+
+Eudora, Outlook Express, KOM 2000 and Hotmail only showed the first
+body part. Netscape only showed the second body part. Pine only showed
+the second body part, but provided a user command to see also the first
+body part. First Class displayed both body parts in sequence, i.e. i
+treated multipart/alternative as identical to multipart/mixed.
+
+The conclusion of this is that if IETF makes a standard, specifying
+that different translations of the same message should be sent with
+multipart/alternative with different Content-Language on the different
+body parts, then most mailers will not show a user the version in the
+preferred language of that user.
+
+Since backwards compatibility with existing mailers is very important,
+this seems to indicate that an IETF standard for handling of language
+translation in e-mail has to use some other format than
+multipart/alternative to indicate translations.
+
+I also tested some more complex messages. In test message 4, I used
+multipart/mixed with three body parts, the first a list of the rest of
+the body parts, which contained the message in different languages.
+This format was not ideal either with the existing mailers. Most of
+them showed all three body parts in sequence inline (even though all
+except the first were marked as Content-Disposition: Attachment) and
+some of them without any visible marker between the body parts.
+
+In test message 5, on the top level is a multipart/mixed with two body
+parts, the first a list of the body parts, the second a
+multipart/alternative with the different language parts. This had the
+same problem as all the other multipart/alternative test examples: Many
+of the mailers arbitrarily chooses one of the multipart/alternatives
+and only shows this, some mailers choose the first alternative, some
+the second.
+
+In test message 6, I had on the top level a multipart/alternative where
+the first body part was a text/plain with all the language versions in
+one text. The second body part was another multipart/alternative with
+the different language parts as body parts. A mailer which cannot
+discriminate between languages, should for this message only display
+body part 1. Only Outlook Express and KOM 2000 did this. Pine, Netscape
+and Hotmail arbitrarily showed only one language version.
+
+In test message 7, I tested the format proposed in this ietf-draft, as
+shown in section 8.3 above.
+
+
+Test message 1:
+---------------
+
+       Message-ID: <language-test-1@dsv.su.se>
+       Date: Wed, 12 Nov 2000 18:12:00 +0100
+       From: Jacob Palme <jpalme@dsv.su.se>
+       MIME-Version: 1.0
+       To: jpalme@dsv.su.se, jptest@dsv.su.se
+       Subject: Language test message no. 1 v1
+       Content-Type: multipart/alternative; boundary="==boundary-2"
+
+       Text displayed only to non-MIME-compliant mailers
+
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: en
+
+       Message in English.
+
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: de
+
+       Nachricht auf deutsch.
+       --==boundary-2--
+
+
+Test message 2:
+---------------
+
+       Message-ID: <language-test-2@dsv.su.se>
+       Date: Wed, 12 Nov 2000 18:12:00 +0100
+       From: Jacob Palme <jpalme@dsv.su.se>
+       MIME-Version: 1.0
+       To: jpalme@dsv.su.se, jptest@dsv.su.se
+       Subject: Language test message no. 1 v1
+       Content-Type: multipart/alternative; boundary="==boundary-2"
+
+       Text displayed only to non-MIME-compliant mailers
+
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: de
+
+       Nachricht auf deutsch.
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: en
+
+       Message in English.
+       --==boundary-2--
+
+
+Test message 3:
+---------------
+
+       Message-ID: <language-test-3@dsv.su.se>
+       Date: Wed, 12 Nov 2000 18:12:00 +0100
+       From: Jacob Palme <jpalme@dsv.su.se>
+       MIME-Version: 1.0
+       To: jpalme@dsv.su.se,jptest@dsv.su.se
+       Subject: Language test message no. 3 v1
+       Content-Type: multipart/mixed; boundary="==boundary-2"
+
+       Text displayed only to non-MIME-compliant mailers
+
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: de
+
+       Nachricht auf deutsch.
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: en
+
+       Message in English.
+       --==boundary-2--
+
+
+Test message 4:
+---------------
+
+       Message-ID: <language-test-4@dsv.su.se>
+       Date: Wed, 12 Nov 2000 18:12:00 +0100
+       From: Jacob Palme <jpalme@dsv.su.se>
+       MIME-Version: 1.0
+       To: jpalme@dsv.su.se,jptest@dsv.su.se
+       Subject: Language test message no. 4 v1
+       Content-Type: multipart/mixed; boundary="==boundary-2"
+
+       Text displayed only to non-MIME-compliant mailers
+
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+
+       Attachment 1: Deutsch
+       Attachment 2: English
+
+       Nachricht auf deutsch.
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Disposition: Attachment
+       Content-Language: de
+
+       Nachricht auf deutsch.
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Disposition: Attachment
+       Content-Language: en
+
+       Message in English.
+       --==boundary-2--
+
+
+Test message 5:
+---------------
+
+       Message-ID: <language-test-5@dsv.su.se>
+       Date: Mon, 13 Nov 2000 12:12:00 +0100
+       From: Jacob Palme <jpalme@dsv.su.se>
+       MIME-Version: 1.0
+       To: jpalme@dsv.su.se,jptest@dsv.su.se
+       Subject: Language test message no. 5 v1
+       Content-Type: multipart/mixed; boundary="==boundary-2"
+
+       Text displayed only to non-MIME-compliant mailers
+
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+
+       Attachment 1: Deutsch
+       Attachment 2: English
+
+       --==boundary-2
+       Content-Type: Multipart/alternative; boundary="==boundary-1"
+
+       --==boundary-1
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: de
+
+       Nachricht auf deutsch.
+       --==boundary-1
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: en
+
+       Message in English.
+       --==boundary-1--
+       --==boundary-2--
+
+
+Test message 6:
+---------------
+
+       Message-ID: <language-test-6@dsv.su.se>
+       Date: Wed, 12 Nov 2000 18:12:00 +0100
+       From: Jacob Palme <jpalme@dsv.su.se>
+       MIME-Version: 1.0
+       To: jpalme@dsv.su.se,jptest@dsv.su.se
+       Subject: Language test message no. 6 v1
+       Content-Type: multipart/alternative; boundary="==boundary-1"
+
+       Text displayed only to non-MIME-compliant mailers
+
+       --==boundary-1
+       Content-Type: text/plain; charset=iso-8859-1
+
+       **** This message in English ***
+
+       Message in English.
+
+       **** Diese Nachricht auf deutsch
+
+       Nachricht auf deutsch.
+       --==boundary-1
+       Content-Type: multipart/alternative; boundary="==boundary-2"
+
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: en
+
+       Message in English.
+
+       --==boundary-2
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: 8bit
+       Content-Language: de
+
+       Nachricht auf deutsch.
+       --==boundary-2--
+       --==boundary-1--
+
+Test message 7:
+--------------
+
+Same as in section 8.3 above.
+
+Mailer          Test message 1&2        Test message 3
+------          -----------------       ---------------
+
+Eudora 5        Only displayed the      Both shown in
+Macintosh       first alternative,      sequence, Content-
+version         did not even indicate   headers shown, but
+                 that there was any      not Content-Language!
+                 other alternative.      No indication that
+                                         the different
+                                         language of the two
+                                         body parts.
+
+Pine 4.21 on a  Only the second         Both versions are
+Unix platform   alternative is shown    listed in sequence
+                 directly, but the       with a divider
+                 user can ask to see     indication in-
+                 the first alternative   between, no
+                 with the VIEW           indication that the
+                 command. Nothing is     different language of
+                 said to indicate that   the two body parts.
+                 the two alternatives
+                 contain the same text
+                 in two languages.
+
+Netscape 4.7    Only the second         Both versions are
+on a Macintosh  alternative is shown,   listed in sequence
+                 did not even indicate   with a horizontal
+                 that there was any      rule in-between, no
+                 other alternative.      indication that the
+                                         different language of
+                                         the two body parts.
+
+Outlook         Only displayed the      Both shown in
+Express 5,      first alternative,      sequence, no divider
+Macintosh       did not even indicate   and no indication
+edition         that there was any      that the different
+                 other alternative.      language of the two
+                                         body parts.
+
+First Class     Both versions are       Both versions are
+5.611,          listed in sequence      listed in sequence
+Macintosh       with no divider in-     with no divider in-
+client          between, no             between, no
+                 indication that the     indication that the
+                 different language of   different language of
+                 the two body parts.     the two body parts.
+
+KOM 2000        Only displayed the      Both versions are
+                 first alternative,      listed in sequence
+                 did not even indicate   with a blank line in-
+                 that there was any      between, no
+                 other alternative.      indication that the
+                                         different language of
+                                         the two body parts.
+
+Hotmail         Only displayed the      Both shown in
+                 first alternative,      sequence, blank line
+                 did not even indicate   in-between.
+                 that there was any
+                 other alternative.
+
+
+Mailer          Test message 4          Test message 5
+------          ---------------         ---------------
+
+Eudora 5        All three body parts    First and second body
+Macintosh       in sequence.            part shown inline.
+version
+
+Pine 4.21 on a  First message shown     First message shown
+Unix platform   inline, the rest        inline, the rest
+                 available by commands   available by commands
+                 to retrieve             to retrieve
+                 attachments.            attachments.
+
+Netscape 4.7    All three body parts    Only first and third
+on a Macintosh  in sequence with a      body part shown in
+                 horizontal rule in-     sequence with two
+                 between.                horizontal rules in-
+                                         between.
+
+Outlook         All three body parts    First and third body
+Express 5,      in sequence.            parts in sequence.
+Macintosh
+edition
+
+First Class     All three body parts
+5.611,          listed in sequence.
+Macintosh
+client
+
+KOM 2000        All three body parts    First and third body
+                 in sequence,            part in sequence,
+                 horizontal rule in      horizontal rule in
+                 between.                between.
+
+Hotmail         All three body parts    First and third body
+                 in sequence.            part in sequence.
+
+
+Mailer          Test message 6          Test message 7
+------          ---------------         --------------
+
+Eudora 5        The first and the       All translations
+Macintosh       second, but not the     inline in sequence
+version         third body part is      with all headers,
+                 shown.                  including translation-
+                                         headers shown on each
+                                         body part.
+
+Pine 4.21 on a  Last body part (the     All translations
+Unix platform   German variant) shown   listed as
+                 inline, the other       attachments.
+                 body parts available
+                 as attachments.
+
+Netscape 4.7    Only the last body      All translations
+on a Macintosh  part (the German        inline with some
+                 variant shown,          headers shown on each
+                 nothing indicates to    body parts.
+                 the reader that
+                 anything more is
+                 available.)
+
+Outlook         Only the first body     All translations
+Express 5,      part shown, with both   inline with some
+Macintosh       language text within    headers shown on each
+edition         a single body part!     body parts.
+
+First Class                             All translations
+5.611,                                  inline in sequence
+Macintosh                               with all headers,
+client                                  including translation-
+                                         headers shown on each
+                                         body part.
+
+KOM 2000        Only the first body     All translations
+                 part is shown,          inline with some
+                 containing both         headers shown on each
+                 language versions in    body parts.
+                 one body part.
+
+Hotmail         Only the second body    All translations
+                 part is shown, no       inline with some
+                 indication that any     headers shown on each
+                 more text is            body parts.
+                 available.
diff --git a/Documentation/en/I-D/draft-palme-e-mail-translation-02.txt b/Documentation/en/I-D/draft-palme-e-mail-translation-02.txt
new file mode 100644
index 00000000..e4a45e3b
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-e-mail-translation-02.txt
@@ -0,0 +1,991 @@
+Network Working Group                                     Jacob Palme
+Internet Draft                               Stockholm University/KTH
+draft-palme-e-mail-translation-02.txt                          Sweden
+Category-to-be: Proposed standard                 Date: December 2000
+                                                   Expires: June 2001
+
+
+
+                  Support for Language Translation
+                       in E-Mail and Netnews
+
+                        Status of this Memo
+
+
+This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright (C) The Internet Society 1999, 2000. All Rights
+Reserved.
+
+
+1.1   Abstract
+
+This memo specifies extensions to e-mail and netnews standards, to
+allow for the submission of translations of messages, not only at
+initial submission time, but also at later time, and made by other
+translators than the original author of the message. three new e-
+mail/netnews header fields are proposed, "Content-Translation-Of,
+"Content-Translator" and "Translation-Request".
+
+
+1.2   Mailing list
+
+To write
+
+ Further discussion of this memo can take place in the mailing list WG-
+ LANGTRANS@SU.SE.
+
+ Comments on less important details may also be sent to the editor,
+ Jacob Palme <jpalme@dsv.su.se>.
+
+To subscribe
+
+ To subscribe to this mailing list, send a message to
+ LISTSERV@SU.SE
+ which contains the text
+ SUB[SCRIBE] LANGTRANS <your name (not your email address)>
+
+To unsubscribe
+
+ To unsubscribe from this list, send a message to
+ LISTSERV@SU.SE
+ which contains the text
+ UNS[UBSCRIBE] LANGTRANS
+
+To access mailing list archives
+
+ The archives are available for browsing from
+ http://salut.nu/forum/uno/6/1/
+ Use the browsing command "All messages" to get everything written on a
+ single web page.
+
+
+Table of Contents
+
+2    Language Support in Existing Standards
+3    Multi-Language Scenario
+4    The Content-Translation-Of Header Field
+5    The Content-Translator Header Field
+6    USE of The Multipart/Choices MIME Content Type
+7    The Translation-Request Header
+8    Examples
+     8.1  Separate Original and Translated Messages
+     8.2  Sending a Message to a Translator for Translation
+     8.3  Resending of the Message in 8.2 After Translation
+9    For Further Study
+10   Security Considerations
+11   Copyright and Disclaimer
+12   Acknowledgments
+13   References
+14   Author's Address
+Appendix 1: An Investigation of Handling of
+Multipart/Alternative in some Common Mailers in November 2000
+
+
+2     Language Support in Existing Standards
+
+The "Content-Language:" e-mail content header specified in RFC 1766 [6]
+can be used to specify one or a list of natural languages used in that
+message body.
+
+The "Content-Type: Multipart/alternative" defined in MIME [4] might be
+used to send the same text in more than one language. Each part would
+then be marked with the "Content-Language:" header to indicate its
+language, and the recipient might choose the body part according to his
+or her language preferences. The combination of Multipart/alternative
+with Content-Language is however not commonly supported and gives
+disastrous results with most mailers (November 2000), so this solution
+is not recommended in this specification.
+
+In HTTP [7], a request operation can indicate a list of preferred
+languages, and the server can then deliver the resource in the
+preferred language. The request operation can also indicate how good
+each language is for a particular user, in the format:
+
+          Accept-Content-Language: da, en-gb;q=0.8, en;q=0.7
+
+HTTP also has facilities for the server to tell the client which
+alternatives are available in different languages, letting the client
+choose between them. It is also possible, with HTTP, to deliver a
+resource in the "Multipart/alternative" format, if the recipient wants
+to store the resource in all available language versions. These HTTP
+features are however not commonly supported (November 2000).
+
+All of these methods of transmitting information is based on the
+assumption that all language versions are ready and available when a
+message is sent.
+
+
+3     Multi-Language Scenario
+
+John Smith writes a message in English and submits it to a mailing list
+or to a Usenet newsgroup. The mailing list expander sends this message
+to an automatic translation agent which translates it into other
+languages and returns the translations to the mailing list expander.
+The mailing list expander might then either forward all translations to
+each member of the list, or forward to each member only the translation
+preferred by this member. Ernst D’rrenmatt has requested the mailing
+list to send him all language versions, but reads this message in
+English, because he has indicated that he prefers English original
+documents to automatic German translations. Hilda Schmidt reads the
+message in both English and German, decides that the automatic German
+translation is not very good, and cleans it up, submitting a new better
+translation to German. Ernst D’rrenmatt checks this translation, makes
+some corrections, and submits a final corrected version of the German
+translation of the original message.
+
+
+4     The Content-Translation-Of Header Field
+
+The "Content-Translation-Of" header field is used when submitting a
+translation to a message, which earlier has been sent in another
+language. The syntax for this header field is similar to the syntax for
+the "In-Reply-To" header, but only one value is allowed, since every
+translation can only be the translation of one previous message. The
+value contains the Message-ID of the original message before
+translation. If a message is available in more than one language,
+"Content-Translation-Of" should always reference the original message,
+even if the translation was actually based on a translated version. If
+the original message is available in more than one version, with
+"Supersedes" or "Replaces" references between the versions, then the
+"Content-Translation-Of" should reference the version which was the
+basis of this translation.
+
+Translation is applied to the body content, and to the content of the
+"Subject:" header, but not to any other header contents. When a
+"Subject:" is translated, the language code enclosed in parenthesis"
+can be added to the beginning of the "Subject".
+
+If more than one translation is available of the same original message,
+the "Supersedes" or "Replaces" header field should not be used between
+them. "Supersedes" or "Replaces" are only to be used when the original
+message is revised.
+
+
+5     The Content-Translator Header Field
+
+The "Content-Translator" header field indicates who made the
+translation. When a translation is submitted, the "From" header field
+should still indicate the original author, but the "Content-Translator"
+header field can indicate who made the translation.
+
+The syntax of the "Content-Translator" header field is:
+
+Content-Translator           = "Content-Translator:" ( CFWS mailbox-
+list / Phrase )
+                       *(";" translator-parameter) CFWS CRLF
+
+translator-parameter = art / fluency / future-extension
+
+art                  = "Human" / "Machine" / "Original"
+
+fluency              = "Expert" / "Native" / "Other"
+
+The meaning of these parameters are:
+
+Human    = Translation was made or revised/approved by a human
+           translator.
+
+Machine  = Translation was entirely automatic, with no human checking
+           of the translation. In this case, the "Auto-Submitted" [8]
+           header should also be added to the message heading.
+
+Original = This is the original before translation. Absence of a
+           "Content-Translator" also indicates that the message is not
+           translated, but "Content-Translator: None; Original" can be
+           used to explicitly specify that this is not translated.
+
+Expert   = Translation was made by an expert translator.
+
+Native   = Translation was made by a native speaker of the target
+           language.
+
+
+Other    = Translation was made by someone who is not an expert nor
+           a native speaker of the target language.
+
+
+6     USE of The Multipart/Choices MIME Content Type
+
+When several translations of the same message are sent in the same
+message, the content-type multipart/choices, as defined in [9].
+
+If translation is desired also of the "Subject" header, then the
+translated body parts have to be of content-type Message/rfc822, since
+only that content-type allows different subject in different body
+parts.
+
+It is recommended to add information about translation at the top of
+each body part (example, see section 8.3 below), because some mailers
+display multiple body parts in sequence inline with no indication of
+the Differences between them. This recommendation may be lifted at some
+future time when most mailers have support for Multipart/choices.
+
+It is also recommended to add a blank line at the end of each
+translation, since this will show up neater on some old mailers, which
+display all body parts in sequence to the recipient.
+
+
+7     The Translation-Request Header
+
+The Translation-Request header is used when sending a message for
+translation to a human or machine translator. Its value is a list of
+the languages to which translation is requested. The languages are
+specified according to [6]. The language of the original can be
+included in the Translation-Request header, this tells the translator
+to include the original of the message when it is forwarded after
+translation, together with the translations to other languages.
+
+When the Translation-Request header is used, the content-type should
+always be "Message/rfc822" [5] and the content should be the message to
+be translated. When the translation is ready, the translator is
+instructed to send the translation to the recipients in the "To:",
+"Cc:" and "Bcc:" headers and to leave non-translated headers of the
+message/rfc822 body as they were before the translation. When the
+translator resends the translation, Resent-From" is added with the name
+of the translator, and "Resent-Date" with the date of the translation.
+If translation to multiple languages is requested, the result is sent
+using the content-type multipart/choices.
+
+Syntax: "Translation-Request:" CFWS language 1*(, CFWS language)
+        CFWS CRLF
+
+
+8     Examples
+
+8.1   Separate Original and Translated Messages
+
+    Message-ID: A@foo.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+    Content-Translator: None; Original
+    Content-Language: en
+
+    Message-ID: B@foo.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+    Content-Translation-Of: A
+    Content-Translator: Erika Ernst <eernst@foo.bar.de>; human; native
+    Content-Language: de
+
+    Message-ID: C@foo.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+    Content-Translation-Of: A
+    Content-Translator: Tomas D’rrenmatt <tdurrenmatt@foo.bar.de>;
+                         expert
+    Content-Language: de
+
+    Message-ID: D@foo.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+    Content-Language: en
+    Supersedes: A
+
+    Message-ID: E@foo.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+    Content-Translation-Of: D
+    Content-Translator: Supertrans Translation Engine
+                        <supertrans@foo.bar>; machine
+    Auto-Submitted: Auto-generated
+    Content-Language: de
+    Supersedes: A
+
+
+8.2   Sending a Message to a Translator for Translation
+
+    Message-ID: Z@foo.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    Translation-Request: en, fr, de
+    Content-Type: Message/rfc822
+
+    Message-ID: Z-en@foo.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+    Content-Translator: None; Original
+    Content-Language: en
+    Subject: Orchids
+
+    Orchids are beautiful.
+
+
+8.3   Resending of the Message in 8.2 After Translation
+
+    Resent-From: Supertrans Translation Engine <supertrans@foo.bar>
+    Message-ID: Z@supertrans.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    Content-Type: Multipart/choices; boundary="boundary 1"
+    To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+    Subject: (en) Orchids
+
+    --boundary 1
+    Message-ID: Z-@foo.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    Translation-Request: en, fr, de
+    Content-Type: Message/rfc822
+
+    Message-ID: Z-en@foo.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
+    Content-Translator: None; Original
+    Content-Language: en
+    Subject: (en) Orchids
+
+    Original English Text
+    ---------------------
+
+    Orchids are beautiful.
+
+    --boundary 1
+    Content-Type: Message/rfc822
+
+    Message-ID: Z-de@supertrans.bar.net
+    From: John Smith <jsmit@foo.bar.net>
+    Content-Translation-Of: A
+    Content-Translator: Supertrans Translation
+                        Engine <supertrans@foo.bar>; machine
+    Content-Language: de
+    Subject: (de) Orchideen
+
+    Deutsche ›bersetzung
+    --------------------
+
+    Orchideen sind sch÷n.
+
+    --boundary 1
+    Content-Type: Message/rfc822
+
+    Message-ID: Z-fr@supertrans.bar.net
+    Content-Translation-Of: A
+    Content-Translator: Supertrans Translation Engine
+                        <supertrans@foo.bar>; machine
+    Content-Language: fr
+    Subject: (fr) Orchid‰e
+
+    Traduction fran‡ais
+    -------------------
+
+    Orchid‰e sont beau.
+
+    --boundary 1--
+
+
+9     For Further Study
+
+The following is not yet resolved in this draft:
+
+-  How a user can register its language preferences with a mail
+   server or a mailing list expander.
+
+-  Whether POP/IMAP should be extended with commands to request
+   messages in only a certain language.
+
+-  How to handle translation in Usenet News. One might for example
+   have a set of co-ordinated newsgroups, with the same articles in
+   different languages. A newsgroup "alt.cultures.multiple" might be
+   provided with English in "alt.cultures.multiple.en", German in
+   "alt.cultures.multiple.de", etc., with automatic or manual
+   translation of the messages between these newsgroups.
+
+-  Handling of signatures and seals.
+
+
+10    Security Considerations
+
+Translations made by other people than the original author of
+a message will of course entail the risk of intentional or
+unintentional incorrectness of the translation. But this is a
+risk we must accept if we want to have translations, and if
+everyone is not fluent in every language.
+
+Some people claim that machine translation technology is so
+bad, that it should not be used at all. I do not agree,
+machine translation will often give a good understanding of
+the intent of the original text even if the translation is not
+perfect. And if the recipient has a choice of either not
+understanding a message at all, or getting a machine
+translation, the recipient may still prefer the automatic
+translation. Based on this, the recipient might decide whether
+the message is of enough interest to be willing to pay for a
+human to make a better translation.
+
+The risk can be reduced, if the receiving user agent clearly
+shows that a message is a translator, who made the
+translation, and allows the user to check the original text
+and compare it with the translation.
+
+A translation will invalidate any digital signatures or seals,
+but the translator might add its own signature and seals to
+ensure that the translation is not corrupted when sent from
+translator to readers. These signatures and seals will not
+promise any correspondence with the original text, except the
+promise which a translator might give of the correctness of
+its translations.
+
+
+11    Copyright and Disclaimer
+
+The IETF takes no position regarding the validity or scope of
+any intellectual property or other rights that might be
+claimed to pertain to the implementation or use of the
+technology described in this document or the extent to which
+any license under such rights might or might not be available;
+neither does it represent that it has made any effort to
+identify any such rights. Information on the IETF's procedures
+with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims
+of rights made available for publication and any assurances of
+licenses to be made available, or the result of an attempt
+made to obtain a general license or permission for the use of
+such proprietary rights by implementors or users of this
+specification can be obtained from the IETF Secretariat."
+
+The IETF invites any interested party to bring to its
+attention any copyrights, patents or patent applications, or
+other proprietary rights which may cover technology that may
+be required to practice this standard. Please address the
+information to the IETF Executive Director.
+
+Copyright (C) The Internet Society (2000). All Rights
+Reserved.
+
+This document and translations of it may be copied and
+furnished to others, and derivative works that comment on or
+otherwise explain it or assist in its implementation may be
+prepared, copied, published and distributed, in whole or in
+part, without restriction of any kind, provided that the above
+copyright notice and this paragraph are included on all such
+copies and derivative works. However, this document itself may
+not be modified in any way, such as by removing the copyright
+notice or references to the Internet Society or other Internet
+organizations, except as needed for the purpose of developing
+Internet standards in which case the procedures for copyrights
+defined in the Internet Standards process must be followed, or
+as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will
+not be revoked by the Internet Society or its successors or
+assigns.
+
+
+12    Acknowledgments
+
+Suggestions during the development of this memo has been given by
+Harald Alvestrand, Bill Jansson, Larry Masinter, Keith Moore and Henry
+Spencer.
+
+13    References
+
+Ref.    Author, title                                    IETF status
+                                                         (July 1996)
+-----   ---------------------------------------------    -----------
+[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
+        STD 10, RFC 821, August 1982.                    Recommended
+
+[2]     D. Crocker: "Standard for the format of ARPA     Standard,
+        Internet text messages." STD 11, RFC 822,        Recommended
+        August 1982.
+
+[3]     M.R. Horton, R. Adams: "Standard for             Not an
+        interchange of USENET messages", RFC 1036,       official
+        December 1987.                                   IETF
+                                                         standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[4]     N. Freed & N. Borenstein: "Multipurpose          Draft
+        Internet Mail Extensions (MIME) Part One:        Standard,
+        Format of Internet Message Bodies." RFC 2045.    elective
+        November 1996.
+
+[5]     N. Freed & N. Borenstein: "Multipurpose          Draft
+        Internet Mail Extensions (MIME) Part Two:        Standard,
+        Media Types." RFC 2046. November 1996.           elective
+
+[6]     H. Alvestrand: "Tags for the Identification      Proposed
+        of Languages", RFC 1766, February 1995.          standard,
+                                                         elective
+
+[7]     R. Fielding, J. Gettys, J. Mogul, H. Frystyk,    Draft
+        T. Berners-Lee: Hypertext Transfer Protocol -    standard
+        - HTTP/1.1, RFC 2616, June 1999.
+
+[8]     J. Palme: The Auto-Submitted, Supersedes and     Work in
+        Expires Headers in E-mail and Netnews, draft-    progress
+        ietf-mailext-new-fields-14.txt, November
+        1998.
+
+[9]     J. Palme: The multipart/choices Content-Type.    Work in
+        draft-palme-multipart-choices-00.txt,            progress
+        December 2000.
+
+
+14    Author's Address
+
+Jacob Palme                     Phone: +46-8-16 16 67
+Stockholm University/KTH        Fax: +46-8-783 08 29
+Skeppargatan 73                 E-mail: jpalme@dsv.su.se
+S-115 30 Stockholm, Sweden
+
+
+Appendix 1: An Investigation of Handling of Multipart/Alternative in
+some Common Mailers in November 2000
+
+As a basis for possible work on developing standards for language-
+translation in e-mail, I tested how some common mailers handled
+multipart/alternative with different Content-Language in the body parts
+in November 2000.
+
+I used the following test messages:
+
+Test message 1: First part English, second part German
+
+Test message 2: Same as test message 1, but first part German, second
+part English
+
+Test message 3: Same as test message 2, but multipart/mixed instead of
+multipart/alternative.
+
+Test message 4: Same as test message 3, but with Content-Disposition:
+Attachment on all but the first body part.
+
+Test message 5: Multipart/mixed on an outer level, with the first part
+a directory of attachments, and the second part a multipart/alternative
+with the German and English parts as the two alternatives.
+
+Test message 6: Multipart/alternative with the first part containing
+all the translations in one body part, and the second part a
+multipart/alternative with one translation in each alternative.
+
+I tested this with the following mailers:
+Eudora 5 Macintosh, Pine 4.21 on Unix, Netscape 4.7 Macintosh, Outlook
+Express 5 Macintosh, First Class 5.611 Macintosh, KOM 2000 (our own
+system), and Hotmail.
+
+Result: None of the mailers seemed to test on the Content-Language
+value, and make a selection based on this.
+
+Eudora, Outlook Express, KOM 2000 and Hotmail only showed the first
+body part. Netscape only showed the second body part. Pine only showed
+the second body part, but provided a user command to see also the first
+body part. First Class displayed both body parts in sequence, i.e. i
+treated multipart/alternative as identical to multipart/mixed.
+
+The conclusion of this is that if IETF makes a standard, specifying
+that different translations of the same message should be sent with
+multipart/alternative with different Content-Language on the different
+body parts, then most mailers will not show a user the version in the
+preferred language of that user.
+
+Since backwards compatibility with existing mailers is very important,
+this seems to indicate that an IETF standard for handling of language
+translation in e-mail has to use some other format than
+multipart/alternative to indicate translations.
+
+I also tested some more complex messages. In test message 4, I used
+multipart/mixed with three body parts, the first a list of the rest of
+the body parts, which contained the message in different languages.
+This format was not ideal either with the existing mailers. Most of
+them showed all three body parts in sequence inline (even though all
+except the first were marked as Content-Disposition: Attachment) and
+some of them without any visible marker between the body parts.
+
+In test message 5, on the top level is a multipart/mixed with two body
+parts, the first a list of the body parts, the second a
+multipart/alternative with the different language parts. This had the
+same problem as all the other multipart/alternative test examples: Many
+of the mailers arbitrarily chooses one of the multipart/alternatives
+and only shows this, some mailers choose the first alternative, some
+the second.
+
+In test message 6, I had on the top level a multipart/alternative where
+the first body part was a text/plain with all the language versions in
+one text. The second body part was another multipart/alternative with
+the different language parts as body parts. A mailer which cannot
+discriminate between languages, should for this message only display
+body part 1. Only Outlook Express and KOM 2000 did this. Pine, Netscape
+and Hotmail arbitrarily showed only one language version.
+
+In test message 7, I tested the format proposed in this ietf-draft, as
+shown in section 8.3 above.
+
+
+Test message 1:
+---------------
+
+      Message-ID: <language-test-1@dsv.su.se>
+      Date: Wed, 12 Nov 2000 18:12:00 +0100
+      From: Jacob Palme <jpalme@dsv.su.se>
+      MIME-Version: 1.0
+      To: jpalme@dsv.su.se, jptest@dsv.su.se
+      Subject: Language test message no. 1 v1
+      Content-Type: multipart/alternative; boundary="==boundary-2"
+
+      Text displayed only to non-MIME-compliant mailers
+
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: en
+
+      Message in English.
+
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: de
+
+      Nachricht auf deutsch.
+      --==boundary-2--
+
+
+Test message 2:
+---------------
+
+      Message-ID: <language-test-2@dsv.su.se>
+      Date: Wed, 12 Nov 2000 18:12:00 +0100
+      From: Jacob Palme <jpalme@dsv.su.se>
+      MIME-Version: 1.0
+      To: jpalme@dsv.su.se, jptest@dsv.su.se
+      Subject: Language test message no. 1 v1
+      Content-Type: multipart/alternative; boundary="==boundary-2"
+
+      Text displayed only to non-MIME-compliant mailers
+
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: de
+
+      Nachricht auf deutsch.
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: en
+
+      Message in English.
+      --==boundary-2--
+
+
+Test message 3:
+---------------
+
+      Message-ID: <language-test-3@dsv.su.se>
+      Date: Wed, 12 Nov 2000 18:12:00 +0100
+      From: Jacob Palme <jpalme@dsv.su.se>
+      MIME-Version: 1.0
+      To: jpalme@dsv.su.se,jptest@dsv.su.se
+      Subject: Language test message no. 3 v1
+      Content-Type: multipart/mixed; boundary="==boundary-2"
+
+      Text displayed only to non-MIME-compliant mailers
+
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: de
+
+      Nachricht auf deutsch.
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: en
+
+      Message in English.
+      --==boundary-2--
+
+
+Test message 4:
+---------------
+
+      Message-ID: <language-test-4@dsv.su.se>
+      Date: Wed, 12 Nov 2000 18:12:00 +0100
+      From: Jacob Palme <jpalme@dsv.su.se>
+      MIME-Version: 1.0
+      To: jpalme@dsv.su.se,jptest@dsv.su.se
+      Subject: Language test message no. 4 v1
+      Content-Type: multipart/mixed; boundary="==boundary-2"
+
+      Text displayed only to non-MIME-compliant mailers
+
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+
+      Attachment 1: Deutsch
+      Attachment 2: English
+
+      Nachricht auf deutsch.
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Disposition: Attachment
+      Content-Language: de
+
+      Nachricht auf deutsch.
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Disposition: Attachment
+      Content-Language: en
+
+      Message in English.
+      --==boundary-2--
+
+
+Test message 5:
+---------------
+
+      Message-ID: <language-test-5@dsv.su.se>
+      Date: Mon, 13 Nov 2000 12:12:00 +0100
+      From: Jacob Palme <jpalme@dsv.su.se>
+      MIME-Version: 1.0
+      To: jpalme@dsv.su.se,jptest@dsv.su.se
+      Subject: Language test message no. 5 v1
+      Content-Type: multipart/mixed; boundary="==boundary-2"
+
+      Text displayed only to non-MIME-compliant mailers
+
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+
+      Attachment 1: Deutsch
+      Attachment 2: English
+
+      --==boundary-2
+      Content-Type: Multipart/alternative; boundary="==boundary-1"
+
+      --==boundary-1
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: de
+
+      Nachricht auf deutsch.
+      --==boundary-1
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: en
+
+      Message in English.
+      --==boundary-1--
+      --==boundary-2--
+
+
+Test message 6:
+---------------
+
+      Message-ID: <language-test-6@dsv.su.se>
+      Date: Wed, 12 Nov 2000 18:12:00 +0100
+      From: Jacob Palme <jpalme@dsv.su.se>
+      MIME-Version: 1.0
+      To: jpalme@dsv.su.se,jptest@dsv.su.se
+      Subject: Language test message no. 6 v1
+      Content-Type: multipart/alternative; boundary="==boundary-1"
+
+      Text displayed only to non-MIME-compliant mailers
+
+      --==boundary-1
+      Content-Type: text/plain; charset=iso-8859-1
+
+      **** This message in English ***
+
+      Message in English.
+
+      **** Diese Nachricht auf deutsch
+
+      Nachricht auf deutsch.
+      --==boundary-1
+      Content-Type: multipart/alternative; boundary="==boundary-2"
+
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: en
+
+      Message in English.
+
+      --==boundary-2
+      Content-Type: text/plain; charset=iso-8859-1
+      Content-Transfer-Encoding: 8bit
+      Content-Language: de
+
+      Nachricht auf deutsch.
+      --==boundary-2--
+      --==boundary-1--
+
+Test message 7:
+--------------
+
+Same as in section 8.3 above.
+
+Mailer          Test message 1&2        Test message 3
+------          -----------------       ---------------
+
+Eudora 5        Only displayed the      Both shown in
+Macintosh       first alternative,      sequence, Content-
+version         did not even indicate   headers shown, but
+                that there was any      not Content-Language!
+                other alternative.      No indication that
+                                        the different
+                                        language of the two
+                                        body parts.
+
+Pine 4.21 on a  Only the second         Both versions are
+Unix platform   alternative is shown    listed in sequence
+                directly, but the       with a divider
+                user can ask to see     indication in-
+                the first alternative   between, no
+                with the VIEW           indication that the
+                command. Nothing is     different language of
+                said to indicate that   the two body parts.
+                the two alternatives
+                contain the same text
+                in two languages.
+
+Netscape 4.7    Only the second         Both versions are
+on a Macintosh  alternative is shown,   listed in sequence
+                did not even indicate   with a horizontal
+                that there was any      rule in-between, no
+                other alternative.      indication that the
+                                        different language of
+                                        the two body parts.
+
+Outlook         Only displayed the      Both shown in
+Express 5,      first alternative,      sequence, no divider
+Macintosh       did not even indicate   and no indication
+edition         that there was any      that the different
+                other alternative.      language of the two
+                                        body parts.
+
+First Class     Both versions are       Both versions are
+5.611,          listed in sequence      listed in sequence
+Macintosh       with no divider in-     with no divider in-
+client          between, no             between, no
+                indication that the     indication that the
+                different language of   different language of
+                the two body parts.     the two body parts.
+
+KOM 2000        Only displayed the      Both versions are
+                first alternative,      listed in sequence
+                did not even indicate   with a blank line in-
+                that there was any      between, no
+                other alternative.      indication that the
+                                        different language of
+                                        the two body parts.
+
+Hotmail         Only displayed the      Both shown in
+                first alternative,      sequence, blank line
+                did not even indicate   in-between.
+                that there was any
+                other alternative.
+
+
+Mailer          Test message 4          Test message 5
+------          ---------------         ---------------
+
+Eudora 5        All three body parts    First and second body
+Macintosh       in sequence.            part shown inline.
+version
+
+Pine 4.21 on a  First message shown     First message shown
+Unix platform   inline, the rest        inline, the rest
+                available by commands   available by commands
+                to retrieve             to retrieve
+                attachments.            attachments.
+
+Netscape 4.7    All three body parts    Only first and third
+on a Macintosh  in sequence with a      body part shown in
+                horizontal rule in-     sequence with two
+                between.                horizontal rules in-
+                                        between.
+
+Outlook         All three body parts    First and third body
+Express 5,      in sequence.            parts in sequence.
+Macintosh
+edition
+
+First Class     All three body parts
+5.611,          listed in sequence.
+Macintosh
+client
+
+KOM 2000        All three body parts    First and third body
+                in sequence,            part in sequence,
+                horizontal rule in      horizontal rule in
+                between.                between.
+
+Hotmail         All three body parts    First and third body
+                in sequence.            part in sequence.
+
+
+Mailer          Test message 6          Test message 7
+------          ---------------         --------------
+
+Eudora 5        The first and the       All translations
+Macintosh       second, but not the     inline in sequence
+version         third body part is      with all headers,
+                shown.                  including translation-
+                                        headers shown on each
+                                        body part.
+
+Pine 4.21 on a  Last body part (the     All translations
+Unix platform   German variant) shown   listed as
+                inline, the other       attachments.
+                body parts available
+                as attachments.
+
+Netscape 4.7    Only the last body      All translations
+on a Macintosh  part (the German        inline with some
+                variant shown,          headers shown on each
+                nothing indicates to    body parts.
+                the reader that
+                anything more is
+                available.)
+
+Outlook         Only the first body     All translations
+Express 5,      part shown, with both   inline with some
+Macintosh       language text within    headers shown on each
+edition         a single body part!     body parts.
+
+First Class                             All translations
+5.611,                                  inline in sequence
+Macintosh                               with all headers,
+client                                  including translation-
+                                        headers shown on each
+                                        body part.
+
+KOM 2000        Only the first body     All translations
+                part is shown,          inline with some
+                containing both         headers shown on each
+                language versions in    body parts.
+                one body part.
+
+Hotmail         Only the second body    All translations
+                part is shown, no       inline with some
+                indication that any     headers shown on each
+                more text is            body parts.
+                available.
+
diff --git a/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt b/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
new file mode 100644
index 00000000..2cc38fc0
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

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

+

+

diff --git a/Documentation/en/I-D/draft-palme-int-print-03.txt b/Documentation/en/I-D/draft-palme-int-print-03.txt
new file mode 100644
index 00000000..3104d3c7
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-int-print-03.txt
@@ -0,0 +1,227 @@
+Network Working Group                                       Jacob Palme
+Internet Draft                                 Stockholm University/KTH
+draft-palme-int-print-03.txt                                     Sweden
+Category-to-be: Informational
+Expires: September 1998                                      March 1998
+
+
+
+
+Making Postscript and PDF International
+
+
+
+Status of this Memo
+
+
+This document is an Internet-Draft. Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its areas, and
+its working groups. Note that other groups may also distribute working
+documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as ``work in progress.''
+
+To learn the current status of any Internet-Draft, please check the
+``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ftp.isi.edu (US West Coast).
+
+This memo provides information for the Internet community. This memo
+does not specify an Internet standard of any kind. Distribution of this
+memo is unlimited.
+
+Copyright (C) The Internet Society 1998. All Rights Reserved.
+
+
+Differences between version 02 and 03 of this document
+
+Made the dimensions more consistent, rounded inch dimensions to 1/10
+(still within ISO 216 tolerances), fixed some typos and editorial
+things, added requirement for min. 20 mm left/right margin for filing
+holes, added recommendation for PDF over Postscript, replaced
+'Acrobat' (name of an Adobe software product) by PDF (file format
+standard name), added some references, etc.
+
+
+Abstract
+
+Certain text formats, for example Postscript (MIME-Type:
+application/postscript; file extension .ps) and Portable Document Format
+(MIME-Type: application/pdf;  file extension .pdf) specify exactly the
+page layout of the printed document. The commonly used paper format is
+different in North America and the rest of the world. North America uses
+the 'Letter' format, while the rest of the world mostly uses the ISO-
+standard 'A4' format. This means that documents formatted on one
+continent may not be easily printable on another continent. This memo
+gives advice on how to produce documents which are equally well
+printable with the Letter and the A4 formats. By using the advice in
+this document, you can put up a document on the Internet, which
+recipients can print without problem both in and outside North America.
+
+A very short summary of the advice in this document: If you are using
+U.S. Letter paper format, ensure that both the left and right margins
+are at least 21 mm (0.8 in). If you are using A4 paper format, ensure
+that both the top and bottom margins are at least 33 mm (1.3 in).
+
+Table of contents
+
+1. Introduction
+2. Two methods for printing on different paper formats
+   2.1 Method 1: Use wider margins
+   2.2 Method 2: Print with reduced size
+3. References
+4. Author's Address
+
+
+1.    Introduction
+
+Certain text formats, for example Postscript (MIME-Type:
+application/postscript; file extension .ps) and Portable Document Format
+(MIME-Type: application/pdf;  file extension .pdf) specify exactly the
+page layout of the printed document. The commonly used paper format is
+different in North America and the rest of the world. North America uses
+the 'Letter' format, while the rest of the world uses the 'A4' format.
+
+The North American Letter format is 216 x 279 mm (8.5 x 11 in) while the
+ISO standardised A4 format is 210 x 297 mm (8.3 x 11.7 in). The Letter
+format is thus 6 mm (0.2 inches) wider, while the A4 format is 18 mm
+(0.7 inches) taller.
+
+This means that documents formatted on one continent may not be
+printable on another continent. It is oboviously desirable that
+documents on the Internet are printable on all continents. This paper
+gives advice on how to achieve this.
+
+This memo is not intended for HTML documents, but the advice may be of
+value also for HTML developers in case they are using fixed-size
+graphics and fixed WIDTH sizes of objects in HTML documents.
+
+
+2.    Three methods for printing on different paper formats
+
+2.1   Method 1: Use wider margins
+
+Paper format
+you use when
+converting
+the document                                 Suggested minimal margins
+to Postscript Paper
+or PDF        orien-      Suggested change   Left   Right  Top    Bot-
+             tation      of margins                              tom
+------------  -----------  -----------------  -----  -----  -----  -----
+A4           Portrait     Add 18 mm (0.7     20 mm  20 mm  33 mm  33 mm
+             (upright,    inches) to the top 0.8"   0.8"   1.3"   1.3"
+             vertical)    of page and bottom
+                          of page margins
+
+A4           Landscape    Add 18 mm (0.7     33 mm  33 mm  15 mm  15 mm
+             (lying,      inches) to the     1.3"   1.3"   0.6"   0.6"
+             horizontal)  left and right
+                         margins
+
+Letter       Portrait     Add 6 mm (0.2      20 mm  26 mm  15 mm  15 mm
+             (upright,    inches) to the     0.8"   1.0"   0.6"   0.6"
+             vertical)    right margins
+
+Letter       Landscape    Add 6 mm (0.2      15 mm  15 mm  21 mm  21 mm
+             (lying,      inches) to the top 0.6"   0.6"   0.8"   0.8"
+             horizontal)  of page and bottom
+                          of page margins
+
+The reason why you have to add 18 respectively 6 mm to both the top and
+the bottom margin is that you do not know what kind of printer the
+recipient uses, and different printers feed paper in different ways,
+requiring the margin to be added either at the top or the bottom of the
+paper. Left and right margins on any paper format should be at least 20
+mm wide to accomodate filing with ISO 838 hole punches.
+
+Note: Ensure that also headers, footers, and page numbers are within the
+suggested minimal margins. Many word processors put headers, footers and
+page numbers outside the specified text margins.
+
+
+2.2   Method 2: Print with reduced size
+
+This is a method useful for the recipient of a document with the wrong
+paper size: The recipient sets the printer to print with reduced size.
+When the sender produces the PDF or Postscript files, the sender should
+'print' with 100 % size, but when the recipient prints the PDF or
+Postscript files, and if the program for printing PDF or Postscript
+files allows this, the recipient should print the document with 94 % or
+less of full size. Many programs for printing Postscript files do not
+allow this. In that case, the recipient can convert a Postscript
+document to PDF format and then print it with the PDF printing program.
+This requires, however, that the recipient has the Adobe Acrobat
+Distiller program, which is not freeware. Recent versions of the
+freeware ghostscript can also convert to PDF format. The user may also
+have to specify the paper size as the actual paper size loaded in the
+printer, not the paper size specified when the document was converted to
+PDF or Postscript format.
+
+It is also possible to edit the Postscript file, and add a scale command
+to it, before sending it to the printer.
+
+Method 2 can be more difficult for the recipient, who has to manage
+these settings himself. However, manufacturers of printing software may
+in the future make method 2 easier by making this service automatic,
+perhaps controlled by a 'shrink to fit paper size' checkbox in the
+printing window and a 'default shrink to fit paper size' preference
+setting.
+
+In general, the authors of this RFC recommend PDF as the prefered
+formatted document distribution format over Postscript, not only because
+PDF printing programs typically feature a 'shrink to fit' option to
+handle different paper sizes elegantly, but also because PDF has built-
+in per page data compression, PDF files can be displayed without being
+fully downloaded, PDF is more portable, PDF has a better method of
+rendering fonts not available in the printer and PDF allows to embed
+URLs.
+
+2.3   Method 3: Buy paper in the A4 size
+
+People in North America who often need to print international documents
+might choose to buy paper in the A4 size. It is available in the U.S.
+from many large paper distribution companies, and almost all laser
+printers support it.
+
+
+3.    Acknowledgements
+
+Markus Kuhn has provided many helpful suggestions on this document.
+
+
+4.    References
+
+Writing paper and certain classes of printed matter - Trimmed sizes - A
+and B series, International Standard ISO 216, International Organization
+for Standardization, Geneva, 1975.
+
+Bond Papers and Index Bristols - Common Sheet Sizes, North American
+National Standard ANSI X3.151, North American National Standards
+Institute, 1987
+
+Paper - Holes for general filing purposes - Specifications,
+International Standard ISO 838, International Organization for
+Standardization, Geneva, 1974.
+
+Markus Kuhn: International Standard Paper Sizes. <URL:http://www.ft.uni-
+erlangen.de/~mskuhn/iso-paper.html>.
+
+Tim Bienz, Richard Cohn, James R. Mechan: Portable Document Format
+Reference Manual, Version 1.2, Adobe Systems Incorporated,
+<URL:http://www.adobe.com/supportservice/devrelations/PDFS/TN/PDFSPEC.PD
+F>.
+
+
+5.    Author's Address
+
+Jacob Palme                          Phone: +46-8-16 16 67
+Stockholm University and KTH         Fax: +46-8-783 08 29
+Electrum 230                         E-mail: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
+
diff --git a/Documentation/en/I-D/draft-palme-mailext-headers-00.txt b/Documentation/en/I-D/draft-palme-mailext-headers-00.txt
new file mode 100644
index 00000000..e346cf6f
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-mailext-headers-00.txt
@@ -0,0 +1,1499 @@
+Network Working Group                                       Jacob Palme
+Internet Draft                                 Stockholm University/KTH
+                                                                 Sweden
+Category: Informational                              Date: January 1998
+Revision of: RFC 2076                                Expires: July 1998
+
+
+
+
+
+                  Common Internet Message Header Fields
+
+                        Status of this Memo
+
+                  <draft-palme-mailext-headers-00.txt>
+
+
+  This document is an Internet-Draft.  Internet-Drafts are working
+  documents of the Internet Engineering Task Force (IETF), its
+  areas, and its working groups.  Note that other groups may also
+  distribute working documents as Internet-Drafts.
+
+  Internet-Drafts are draft documents valid for a maximum of six
+  months and may be updated, replaced, or obsoleted by other
+  documents at any time.  It is inappropriate to use Internet-
+  Drafts as reference material or to cite them other than as
+  ``work in progress.''
+
+  To learn the current status of any Internet-Draft, please check
+  the ``1id-abstracts.txt'' listing contained in the Internet-
+  Drafts Shadow Directories on ftp.is.co.za (Africa),
+  nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
+  ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
+
+  This memo provides information for the Internet community. This
+  memo does not specify an Internet standard of any kind, since
+  this document is mainly a compilation of information taken from
+  other RFCs.. Distribution of this memo is unlimited.
+
+  Copyright (C) The Internet Society 1998. All Rights Reserved.
+
+
+
+                            Abstract
+
+This memo contains a table of commonly occurring header fields in
+headings of e-mail messages. The document compiles information from
+other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC
+2045, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly
+occurring header fields which are not defined in RFCs are also
+included. For each header field, the memo gives a short description and
+a reference to the RFC in which the header field is defined.
+
+This document is a revision of RFC 2076. The following new header
+fields, not included in RFC 2076, have been added: Content-Alias,
+Disposition-Notification-Options, Disposition-Notification-To, Expiry-
+Date, For-Approval, List-Archive, List-Help, List-ID, List-Owner, List-
+Post, List-Software, List-Subscribe, List-Unsubscribe, Original-
+Recipient, PICS-Label, X-Envelope-From, X-Envelope-To, X-List-Host, X-
+Listserver, X-MIME-Autoconverted, X-No-Archive, X-Priority, X-UIDL.
+
+
+                         Table of contents
+
+1. Introduction
+2. Use of gatewaying header fields
+3. Table of header fields
+     3.1 Phrases used in the tables
+     3.2 Trace information
+     3.3 Format and control information
+     3.4 Sender and recipient indication
+     3.5 Response control
+     3.6 Message identification and referral header fields
+     3.7 Other textual header fields
+     3.8 Header fields containing dates and times
+     3.9 Quality information
+     3.10 Language information
+     3.11 Size information
+     3.12 Conversion control
+     3.13 Encoding information
+     3.14 Resent-header fields
+     3.15 Security and reliability
+     3.16 Mailing list control
+     3.17 Miscellaneous
+4. Acknowledgments
+5. References
+6. Author's address
+Appendix A: Header fields sorted by Internet RFC document in
+which they appear.
+Appendix B: Alphabetical index
+
+
+
+                         1. Introduction
+
+Many different Internet standards and RFCs define header fields which
+may occur on Internet Mail Messages and Usenet News Articles. The
+intention of this document is to list all such header fields in one
+document as an aid to people developing message systems or interested
+in Internet Mail standards.
+
+The document contains all header fields which the author has
+found in the following Internet standards: RFC 822 [2],
+RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 2045 [11],
+RFC 1766 [12], RFC 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in
+particular that heading attributes defined in PEM (RFC 1421-1424) and
+MOSS (RFC 1848 [16]) are not included. PEM and MOSS header fields only
+appear inside the body of a message, and thus are not header fields in
+the RFC 822 sense. Mail attributes in envelopes, i.e. attributes
+controlling the message transport mechanism between mail and news
+servers, are not included. This means that attributes from SMTP [1],
+UUCP [18] and NNTP [15] are mainly not covered either. Headings used
+only in HTTP [19] are not included yet, but may be included in future
+version of this memo. Some additional header fields which often can be
+found in e-mail headings but are not part of any Internet standard are
+also included.
+
+For each header field, the document gives a short description and
+a reference to the Internet standard or RFC, in which they are defined.
+
+The header field names given here are spelled the same way as when they
+are actually used. This is usually American but sometimes English
+spelling.  One header field in particular, "Organisation/Organization",
+occurs in e-mail header fields sometimes with the English and other
+times with the American spelling.
+
+The following words are used in this memo with the meaning specified
+below:
+
+heading           Formatted text at the top of a message, ended by a
+                  blank line
+
+header field      One field in the heading, beginning with a field
+                  name, colon, and followed by the field value(s). The
+                  words "heading field" and "header" are also
+                  sometimes used with this meaning.
+
+It is my intention to continue updating this document after its
+publication as an RFC. The latest version, which may be more up-to-date
+(but also less fully checked out) will be kept available for
+downloading from URL
+http://www.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html.
+
+Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
+header fields which should be included in this memo but are not.
+
+
+                 2. Use of gatewaying header fields
+
+RFC 1327 defines a number of new header fields in Internet mail, which
+are defined to map header fields which X.400 has but which were
+previously not standardized in Internet mail. The fact that a header
+field occurs in RFC 1327 indicates that it is recommended for use in
+gatewaying messages between X.400 and Internet mail, but does not mean
+that the header field is recommended for messages wholly within
+Internet mail. Some of these header fields may eventually see
+widespread implementation and use in Internet mail, but at the time of
+this writing (1996) they are not widely implemented or used.
+
+Header fields defined only in RFC 1036 for use in Usenet News sometimes
+appear in mail messages, either because the messages have been
+gatewayed from Usenet News to e-mail, or because the messages were
+written in combined clients supporting both e-mail and Usenet News in
+the same client. These header fields are not standardized for use in
+Internet e-mail and should be handled with caution by e-mail agents.
+
+
+
+                      3. Table of header fields
+
+3.1 Phrases used in the tables
+
+
+"not for general        Used to mark header fields which are defined
+usage"                  in RFC 1327 for use in messages from or to
+                        Internet mail/X.400 gateways. These header
+                        fields have not been standardized for general
+                        usage in the exchange of messages between
+                        Internet mail-based systems.
+
+"not standardized       Used to mark header fields defined only in RFC
+for use in e-mail"      1036 for use in Usenet News. These header
+                        fields have no standard meaning when appearing
+                        in e-mail, some of them may even be used in
+                        different ways by different software. When
+                        appearing in e-mail, they should be handled
+                        with caution. Note that RFC 1036, although
+                        generally used as a de-facto standard for
+                        Usenet News, is not an official IETF standard
+                        or even on the IETF standards track.
+
+"non-standard"          This header field is not specified in any of
+                        referenced RFCs which define Internet
+                        protocols, including Internet Standards, draft
+                        standards or proposed standards. The header
+                        field appears here because it often appears in
+                        e-mail or Usenet News. Usage of these header
+                        fields is not in general recommended. Some
+                        header field proposed in ongoing IETF
+                        standards development work, but not yet
+                        accepted, are also marked in this way.
+
+"discouraged"           This header field, which is non-standard, is
+                        known to create problems and should not be
+                        generated. Handling of such header fields in
+                        incoming mail should be done with great
+                        caution.
+
+"controversial"         The meaning and usage of this header field is
+                        controversial, i.e. different implementors
+                        have chosen to implement the header field in
+                        different ways. Because of this, such header
+                        fields should be handled with caution and
+                        understanding of the different possible
+                        interpretations.
+
+"experimental"          This header field is used for newly defined
+                        header fields, which are to be tried out
+                        before entering the IETF standards track.
+                        These should only be used if both
+                        communicating parties agree on using them. In
+                        practice, some experimental protocols become
+                        de-facto-standards before they are made into
+                        IETF standards.
+
+
+
+3.2 Trace information
+
+
+Used to convey the information       Return-Path:    RFC 821,
+from the MAIL FROM envelope                          RFC 1123: 5.2.13.
+attribute in final delivery, when
+the message leaves the SMTP
+environment in which "MAIL FROM"
+is used.
+
+Trace of MTAs which a message has    Received:       RFC 822: 4.3.2,
+passed.                                              RFC 1123: 5.2.8.
+
+List of MTAs passed.                 Path:           RFC 1036: 2.1.6,
+                                                     only in Usenet
+                                                     News, not in e-
+                                                     mail.
+
+Trace of distribution lists          DL-Expansion-   RFC 1327, not for
+passed.                              History-        general usage.
+                                     Indication:
+
+3.3 Format and control information
+
+An indicator that this message is    MIME-Version:   RFC 2045: 4.
+formatted according to the MIME
+standard, and an indication of
+which version of MIME is
+utilized.
+
+Only in Usenet News, contains        Control:        RFC 1036: 2.1.6,
+commands to be performed by News                     only in Usenet
+agents.                                              News, not in e-
+                                                     mail.
+
+Special Usenet News commands and     Also-Control:   son-of-RFC1036
+a normal article at the same                         [21], non-
+time.                                                standard, only in
+                                                     Usenet News, not
+                                                     in e-mail
+
+Which body part types occur in       Original-       RFC 1327, not for
+this message.                        Encoded-        general usage.
+                                     Information-
+                                     Types:
+
+Controls whether this message may    Alternate-      RFC 1327, not for
+be forwarded to alternate            Recipient:      general usage.
+recipients such as a postmaster
+if delivery is not possible to
+the intended recipient. Default:
+Allowed.
+
+Whether recipients are to be told    Disclose-       RFC 1327, not for
+the names of other recipients of     Recipients:     general usage.
+the same message. This is
+primarily an X.400 facility. In
+X.400, this is an envelope
+attribute and refers to
+disclosure of the envelope
+recipient list. Disclosure of
+other recipients is in Internet
+mail done via the To:, cc: and
+bcc: header fields.
+
+Whether a MIME body part is to be    Content-        RFC 1806,
+shown inline or is an attachment;    Disposition:    experimental
+can also indicate a suggested
+filename for use when saving an
+attachment to a file.
+
+3.4 Sender and recipient indication
+
+Authors or persons taking            From:           RFC 822: 4.4.1,
+responsibility for the message.                      RFC 1123: 5.2.15-
+                                                     16, 5.3.7,
+Note difference from the "From "                     RFC 1036 2.1.1
+header field (not followed by
+":") below.
+
+
+(1) This header field should         From (not       not standardized
+never appear in e-mail being         followed by a   for use in e-mail
+sent, and should thus not appear     colon)
+in this memo. It is however
+included, since people often ask
+about it.
+
+This header field is used in the
+so-called Unix mailbox format,
+also known as Berkely mailbox
+format or the MBOX format. This
+is a format for storing a set of
+messages in a file. A line
+beginning with "From " is used to
+separate successive messages in
+such files.
+
+This header field will thus
+appear when you use a text editor
+to look at a file in the Unix
+mailbox format. Some mailers also
+use this format when printing
+messages on paper.
+
+The information in this header
+field should NOT be used to find
+an address to which replies to a
+message are to be sent.
+
+(2) Used in Usenet News mail         From            RFC 976: 2.4 for
+transport, to indicate the path      or              use in Usenet News
+through which an article has gone    >From
+when transferred to a new host.      (not followed
+                                     by a colon)
+Sometimes called "From_" header
+field.
+
+Name of the moderator of the         Approved:       RFC 1036: 2.2.11,
+newsgroup to which this article                      not standardized
+is sent; necessary on an article                     for use in e-mail.
+sent to a moderated newsgroup to
+allow its distribution to the
+newsgroup members. Also used on
+certain control messages, which
+are only performed if they are
+marked as Approved.
+
+The person or agent submitting       Sender:         RFC 822: 4.4.2,
+the message to the network, if                       RFC 1123: 5.2.15-
+other than shown by the From:                        16, 5.3.7.
+header field. Should be
+authenticated,
+according to RFC 822, but what
+kind of authentication is not
+clear. Some implementations
+expect that the e-mail address
+used in this field can be used to
+reach the sender, others do not.
+See also "X-Sender".
+
+Some mail software expect            X-Sender:       Non-standard
+"Sender:" to be an e-mail address
+which you can send mail to.
+However, some mail software has
+as the best authenticated sender
+a POP or IMAP account, which you
+might not be able to send to.
+Because of this, some mail
+software put the POP or IMAP
+account into an X-sender header
+field instead of a Sender header
+field, to indicate that you may
+not be able to send e-mail to
+this address. See also "X-X-
+Sender".
+
+Another use of" X-Sender:" is
+that some e-mail software, which
+wants to insert a "Sender:"
+header, will first change an
+existing "Sender:" header to "X-
+Sender". This use is actually
+often the same as that described
+in the previous paragraph, since
+the new "Sender:" is added
+because it is better
+authenticated than the old value.
+
+Even though some systems put the     X-X-Sender:     Non-standard
+POP or IMAP account name into the
+"X-Sender:" instead of the Sender
+header field, some mail software
+tries to send to the "X-Sender:"
+too. To stop this, some systems
+have begun to use "X-X-Sender:"
+to indicate an authentication of
+the sender which might not be
+useable to send e-mail to. See
+also "Originator-Info:"
+
+Contains information about the       Originator-     Non-standard [25]
+authentication of the originator     Info:
+in a format which is not easily
+used to send email to, to avoid
+the problems with "Sender" and "X-
+Sender".
+
+Primary recipients.                  To:             RFC 822: 4.5.1,
+                                                     RFC 1123: 5.2.15-
+                                                     16, 5.3.7.
+
+Secondary, informational             cc:             RFC 822: 4.5.2,
+recipients. (cc = Carbon Copy)                       RFC 1123. 5.2.15-
+                                                     16, 5.3.7.
+
+Recipients not to be disclosed to    bcc:            RFC 822: 4.5.3,
+other recipients. (bcc = Blind                       RFC 1123: 5.2.15-
+Carbon Copy).                                        16, 5.3.7.
+
+Primary recipients, who are          For-Handling:   Non-standard
+requested to handle the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Comment:    Non-standard
+requested to comment on the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Approval:   Non-standard
+requested to approve the
+information in this message or
+its attachments.
+
+In Usenet News: group(s) to which    Newsgroups:     RFC 1036: 2.1.3,
+this article was posted.                             not standardized
+Some systems provide this header                     and controversial
+field also in e-mail although it                     for use in e-mail.
+is not standardized there.
+
+Unfortunately, the header field
+can appear in e-mail with two
+different and contradictory
+meanings:
+
+(a) Indicating the newsgroup
+recipient of an article/message
+sent to both e-mail and Usenet
+News recipients.
+
+(b) In a personally addressed
+reply to an article in a news-
+group, indicating the newsgroup
+in which this discussion
+originated.
+
+Inserted by Sendmail when there      Apparently-     Non-standard,
+is no "To:" recipient in the         To:             discouraged,
+original message, listing                            mentioned in
+recipients derived from the                          RFC 1211.
+envelope into the message
+heading. This behavior is not
+quite proper, MTAs should not
+modify headings (except inserting
+Received lines), and it can in
+some cases cause Bcc recipients
+to be wrongly divulged to non-Bcc
+recipients.
+
+Geographical or organizational       Distribution:   RFC 1036: 2.2.7,
+limitation on where this article                     not standardized
+can be distributed. Value can be                     for use in e-mail.
+a compete or incomplete domain
+names, also various special
+values are accepted like "world",
+"usenet", "USA", etc.
+
+Fax number of the originator.        Fax:,           Non-standard.
+                                     Telefax:
+
+Phone number of the originator.      Phone:          Non-standard.
+
+If the recipient in the envelope     X-Envelope-To   Non-standard.
+(SMTP "MAIL FROM") is not
+included in the CC list, some
+mail servers add this to the
+RFC822 header field as an aid to
+clients which would otherwise not
+be able to display the envelope
+recipients.
+
+If the sender in the envelope        X-Envelope-     Non-standard.
+(SMTP "RCTP TO") is not the same     From
+as the senders in the "From" or
+"Sender" RFC822 header fields,
+some mail servers add this to the
+RFC822 header fields as an aid to
+clients which would otherwise not
+be able to display this
+information.
+
+Information about the client         Mail-System-    Non-standard.
+software of the originator.          Version:,
+                                     Mailer:,
+                                     Originating-
+                                     Client:, X-
+                                     Mailer, X-
+                                     Newsreader
+
+3.5 Response control
+
+This header field is meant to        Reply-To:       RFC 822: 4.4.3,
+indicate where the sender wants                      RFC 1036: 2.2.1
+replies to go. Unfortunately,                        controversial.
+this is ambiguous, since there
+are different kinds of replies,
+which the sender may wish to go
+to different addresses. In
+particular, there are personal
+replies intended for only one
+person, and group replies,
+intended for the whole group of
+people who read the replied-to
+message (often a mailing list,
+anewsgroup name cannot appear
+here because of different syntax,
+see "Followup-To" below.).
+
+Some mail systems use this header
+field to indicate a better form
+of the e-mail address of the
+sender. Some mailing list
+expanders puts the name of the
+list in this header field. These
+practices are controversial. The
+personal opinion of the author of
+this RFC is that this header
+field should be avoided except in
+special cases, but this is a
+personal opinion not shared by
+all specialists in the area.
+
+Used in Usenet News to indicate      Followup-To:    RFC 1036: 2.2.3,
+that future discussions (=follow-                    not standardized
+up) on an article should go to a                     for use in e-mail.
+different set of newsgroups than
+the replied-to article. The most
+common usage is when an article
+is posted to several newsgroups,
+and further discussions is to
+take place in only one of them.
+
+In e-mail, this header field may
+occur in a message which is sent
+to both e-mail and Usenet News,
+to show where follow-up in Usenet
+news is wanted. The header field
+does not say anything about where
+follow-up in e-mail is to be
+sent.
+
+Note that the value of this
+header field must always be one
+or more newsgroup names, never e-
+mail addresses.
+
+Address to which notifications       Errors-To:,     Non-standard,
+are to be sent and a request to      Return-         discouraged.
+get delivery notifications.          Receipt-To:
+Internet standards recommend,
+however, the use of RCPT TO and
+Return-Path, not Errors-To, for
+where delivery notifications are
+to be sent.
+
+Whether non-delivery report is       Prevent-        RFC 1327, not for
+wanted at delivery error. Default    NonDelivery-    general usage.
+is to want such a report.            Report:
+
+Whether a delivery report is         Generate-       RFC 1327, not for
+wanted at successful delivery.       Delivery-       general usage.
+Default is not to generate such a    Report:
+report.
+
+Indicates whether the content of     Content-        RFC 1327, not for
+a message is to be returned with     Return:         general usage.
+non-delivery notifications.
+
+Possible future change of name       X400-Content-   non-standard
+for "Content-Return:"                Return:
+
+Indicate that the sender wants a     Disposition-    draft-ietf-receipt-
+dispoisition notification when       Notification-   03.txt (standard
+this message is received (read,      To              to be)
+processed, etc.) by its
+receipents.
+
+For future options on disposition    Disposition-    draft-ietf-receipt-
+notifications.                       Notification-   03.txt (standard
+                                     Options         to be)
+
+
+Original Recipient information       Original-       draft-ietf-receipt-
+for inclusion in disposition         Recipient       03.txt (standard
+notifications.                                       to be)
+
+
+3.6 Message identification and referral header fields
+
+Unique ID of this message.           Message-ID:     RFC 822: 4.6.1
+                                                     RFC 1036: 2.1.5.
+
+Unique ID of one body part of the    Content-ID:     RFC 2045: 7.
+content of a message.
+
+Base to be used for resolving        Content-Base:   RFC 2110
+relative URIs within this content
+part.
+
+URI with which the content of        Content-        RFC 2110
+this content part might be           Location:
+retrievable.
+
+Used in addition to Content-         Content-        Internet draft
+Location if this content part can    Alias:
+be retrieved through more than
+one URI. Only one of them is
+allowed in the Content-Location,
+the other can be specified in
+Content-Alias.
+
+Sometimes used with the same         X-URL:          Non-standard
+meaning as "Content-Location:",
+sometimes to indicate the web
+home page of the sender or of his
+organisation.
+
+Reference to message which this      In-Reply-To:    RFC 822: 4.6.2.
+message is a reply to.
+
+In e-mail: reference to other        References:     RFC 822: 4.6.3
+related messages, in Usenet News:                    RFC 1036: 2.1.5.
+reference to replied-to-articles.
+
+References to other related          See-Also:       Son-of-RFC1036
+articles in Usenet News.                             [21], non-standard
+
+Reference to previous message        Obsoletes:      RFC 1327, not for
+being corrected and replaced.                        general usage.
+Compare to "Supersedes:" below.
+This field may in the future be
+replaced with "Supersedes:".
+
+Commonly used in Usenet News in      Supersedes:     son-of-RFC1036
+similar ways to the "Obsoletes"                      [21], non-standard
+header field described above. In
+Usenet News, however, Supersedes
+causes a full deletion of the
+replaced article in the server,
+while "Supersedes" and
+"Obsoletes" in e-mail is
+implemented in the client and
+often does not remove the old
+version of the text.
+
+Unique identifier for a message,     X-UIDL:         non-standard
+local to a particular local
+mailbox store. The UIDL
+identifier is defined in the POP3
+standard, but not the "X-UIDL:"
+header.
+
+Only in Usenet News, similar to      Article-        son-of-RFC1036
+"Supersedes:" but does not cause     Updates:        [21], non-standard
+the referenced article to be
+physically deleted.
+
+Reference to specially important     Article-        son-of-RFC1036
+articles for a particular Usenet     Names:          [21], non-standard
+Newsgroup.
+
+3.7 Other textual header fields
+
+Search keys for data base            Keywords:       RFC 822: 4.7.1
+retrieval.                                           RFC 1036: 2.2.9.
+
+Title, heading, subject. Often       Subject:        RFC 822: 4.7.1
+used as thread indicator for                         RFC 1036: 2.1.4.
+messages replying to or
+commenting on other messages.
+
+Comments on a message.               Comments:       RFC 822: 4.7.2.
+
+Description of a particular body     Content-        RFC 2045: 8.
+part of a message, for example a     Description:
+caption for an image body part.
+
+Organization to which the sender     Organization:   RFC 1036: 2.2.8,
+of this article belongs.                             not standardized
+                                                     for use in e-mail.
+
+See Organization above.              Organisation:   Non-standard.
+
+Short text describing a longer       Summary:        RFC 1036: 2.2.10,
+article. Warning: Some mail                          not standardized
+systems will not display this                        for use in e-mail,
+text to the recipient. Because of                    discouraged.
+this, do not use this header
+field for text which you want to
+ensure that the recipient gets.
+
+A text string which identifies       Content-        RFC 1327, not for
+the content of a message.            Identifier:     general usage.
+
+3.8 Header fields containing dates and times
+
+The time when a message was          Delivery-       RFC 1327, not for
+delivered to its recipient.          Date:           general usage.
+
+In Internet, the date when a         Date:           RFC 822: 5.1,
+message was written, in X.400,                       RFC 1123: 5.2.14
+the time a message was submitted.                    RFC 1036: 2.1.2.
+Some Internet mail systems also
+use the date when the message was
+submitted.
+
+A suggested expiration date. Can     Expires:        RFC 1036: 2.2.4,
+be used both to limit the time of                    not standardized
+an article which is not                              for use in e-mail.
+meaningful after a certain date,
+and to extend the storage of
+important articles.
+
+Time at which a message loses its    Expiry-Date:    RFC 1327, not for
+validity. This field may in the                      general usage.
+future be replaced by "Expires:".
+
+Latest time at which a reply is      Reply-By:       RFC 1327, not for
+requested (not demanded).                            general usage.
+
+3.9 Quality information
+
+Can be "normal", "urgent" or "non-   Priority:       RFC 1327, not for
+urgent" and can influence                            general usage.
+transmission speed and delivery.
+
+Values: 1 (Highest), 2 (High), 3     X-Priority:     Non-standard [24]
+(Normal), 4 (Low), 5 (Lowest). 3
+(Normal) is default if the field
+is omitted.
+
+Sometimes used as a priority         Precedence:     Non-standard,
+value which can influence                            controversial.
+transmission speed and delivery.
+Common values are "bulk" and
+"first-class". Other uses is to
+control automatic replies and to
+control return-of-content
+facilities, and to stop mailing
+list loops.
+
+A hint from the originator to the    Importance:     RFC 1327 and
+recipients about how important a                     RFC 1911,
+message is. Values: High, normal                     experimental
+or low. Not used to control
+transmission speed.
+
+How sensitive it is to disclose      Sensitivity:    RFC 1327 and
+this message to other people than                    RFC 1911,
+the specified recipients. Values:                    experimental
+Personal, private, company
+confidential. The absence of this
+header field in messages
+gatewayed from X.400 indicates
+that the message is not
+sensitive.
+
+Body parts are missing.              Incomplete-     RFC 1327, not for
+                                     Copy:           general usage.
+
+Ratings label to control             PICS-Label:     REC-PICS-labels,
+selection (filtering) of messages                    W3C document [23].
+according to the PICS protocol.
+
+3.10 Language information
+
+Can include a code for the           Language:       RFC 1327, not for
+natural language used in a                           general usage.
+message, e.g. "en" for English.
+
+Can include a code for the           Content-        RFC 1766, proposed
+natural language used in a           Language:       standard.
+message, e.g. "en" for English.
+
+3.11 Size information
+
+Inserted by certain mailers to       Content-        Non-standard,
+indicate the size in bytes of the    Length:         discouraged.
+message text. This is part of a
+format some mailers use when
+showing a message to its users,
+and this header field should not
+be used when sending a message
+through the net. The use of this
+header field in transmission of a
+message can cause several
+robustness and interoperability
+problems.
+
+Size of the message.                 Lines:          RFC 1036: 2.2.12,
+                                                     not standardized
+                                                     for use in e-mail.
+
+3.12 Conversion control
+
+The body of this message may not     Conversion:     RFC 1327, not for
+be converted from one character                      general usage.
+set to another. Values:
+Prohibited and allowed.
+
+Non-standard variant of              Content-        Non-standard.
+Conversion: with the same values.    Conversion:
+
+The body of this message may not     Conversion-     RFC 1327, not for
+be converted from one character      With-Loss:      general usage.
+set to another if information
+will be lost. Values: Prohibited
+and allowed.
+
+3.13 Encoding information
+
+Format of content (character set     Content-Type:   RFC 1049,
+etc.) Note that the values for                       RFC 1123: 5.2.13,
+this header field are defined in                     RFC 2045: 5.
+different ways in RFC 1049 and in                    RFC 1766: 4.1
+MIME (RFC 2045), look for the
+"MIME-version" header field to
+understand if Content-Type is to
+be interpreted according to RFC
+1049 or according to MIME. The
+MIME definition should be used in
+generating mail.
+
+RFC 1766 defines a parameter
+"difference" to this header
+field.
+
+Information from the SGML entity     Content-SGML-   non-standard
+declaration corresponding to the     Entity:
+entity contained in the body of
+the body part.
+
+Coding method used in a MIME         Content-        RFC 2045: 6.
+message body.                        Transfer-
+                                     Encoding:
+
+Only used with the value             Message-Type:   RFC 1327, not for
+"Delivery Report" to indicates                       general usage.
+that this is a delivery report
+gatewayed from X.400.
+
+Used in several different ways by    Encoding:       RFC 1154,
+different mail systems. Some use                     RFC 1505,
+it for a kind of content-type                        experimental.
+information, some for encoding
+and length information, some for
+a kind of boundary information,
+some in other ways.
+
+Information about conversion of      X-MIME-         non-standard
+this message on the path from        Autoconverted:
+sender to recipient, like
+conversion between MIME encoding
+formats. Note: Auto-conversion
+may invalidate digital seals and
+signatures.
+
+3.14 Resent-header fields
+
+When manually forwarding a           Resent-Reply-   RFC 822: C.3.3.
+message, header fields referring     To:,
+to the forwarding, not to the        Resent-From:,
+original message.  Note: MIME        Resent-
+specifies another way of             Sender:,
+resending messages, using the        Resent-From:,
+"Message" Content-Type.              Resent-Date:,
+                                     Resent-To:,
+                                     Resent-cc:,
+                                     Resent-bcc:,
+                                     Resent-
+                                     Message-ID:
+
+3.15 Security and reliability
+
+Checksum of content to ensure        Content-MD5:    RFC 1864, proposed
+that it has not been modified.                       standard.
+
+Used in Usenet News to store         Xref:           RFC 1036: 2.2.13,
+information to avoid showing a                       only in Usenet
+reader the same article twice if                     News, not in e-
+it was sent to more than one                         mail.
+newsgroup. Only for local usage
+within one Usenet News server,
+should not be sent between
+servers.
+
+3.16 Mailing list control
+Contains URL to use to get a         List-           Non-standard [26]
+subscription to the mailing list     Subscribe
+from which this message was
+relayed.
+
+Contains URL to use to               List-           Non-standard [26]
+unsubscribe the mailing list from    Unsubscribe
+which this message was relayed.
+
+Contains URL to send e-mail to       List-Owner      Non-standard [26]
+the owner of the mailing list
+from which this message was
+relayed.
+
+Contains URL to use to get a         List-Help       Non-standard [26]
+information about the mailing
+list from which this message was
+relayed.
+
+Contains URL to use to send          List-Post       Non-standard [26]
+contributions to the mailing list
+from which this message was
+relayed.
+
+Contains URL to use to browse the    List-Archive    Non-standard [26]
+archives of the mailing list from
+which this message was relayed.
+
+Information about the software       List-Software   Non-standard, has
+used in a mailing list expander                      been considered
+through which this message has                       for inclusion in
+passed.                                              [26].
+
+Stores the URN of the mailing        List-ID         Non-standard, has
+list, through which this message                     been considered
+was distributed.                                     for inclusion in
+                                                     [26].
+
+Information about the software       X-Listserver    Non-standard.
+used in a mailing list expander
+through which this message has
+passed. Warning: "Listserv" is a
+trademark and should not be used
+for other than the "Listserv"
+product. Use, instead the "List-
+Software" header field.
+
+3.17 Miscellaneous
+
+Name of file in which a copy of      Fcc:            Non-standard.
+this message is stored.
+
+Has been automatically forwarded.    Auto-           RFC 1327, not for
+                                     Forwarded:      general usage.
+
+Can be used in Internet mail to      Discarded-      RFC 1327, not for
+indicate X.400 IPM extensions        X400-IPMS-      general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+
+Can be used in Internet mail to      Discarded-      RFC 1327, not for
+indicate X.400 MTS extensions        X400-MTS-       general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+
+This field is used by some mail      Status:         Non-standard,
+delivery systems to indicate the                     should never
+status of delivery for this                          appear in mail in
+message when stored. Common                          transit.
+values of this field are:
+
+U    message is not downloaded
+     and not deleted.
+
+R    message is read or
+     downloaded.
+
+O    message is old but not
+     deleted.
+
+D    to be deleted.
+
+N    new (a new message also
+     sometimes is distinguished
+     by not having any "Status:"
+     header field.
+
+Combinations of these characters
+can occur, such as "Status: OR"
+to indicate that a message is
+downloaded but not deleted.
+
+Do not archive this message in       X-No-Archive:   Non-standard
+publicly available archives.         Yes
+
+
+
+                          4. Acknowledgments
+
+Harald Tveit Alvestrand, Ned Freed, Olle Järnefors, Keith Moore, Nick
+Smith and several other people have helped me with compiling this list.
+I especially thank Ned Freed and Olle Järnefors for their thorough
+review and many helpful suggestions for improvements. I alone take
+responsibility for any errors which may still be in the list.
+
+An earlier version of this list has been published as part of [13].
+
+
+
+                            5. References
+
+Ref.    Author, title                                    IETF status
+                                                         (July 1996)
+-----   ---------------------------------------------    -----------
+[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
+        STD 10, RFC 821, August 1982.                    Recommended
+
+[2]     D. Crocker: "Standard for the format of ARPA     Standard,
+        Internet text messages." STD 11, RFC 822,        Recommended
+        August 1982.
+
+[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
+        interchange of USENET messages", RFC 1036,       cial IETF
+        December 1987.                                   standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[4]     M. Sirbu: "A Content-Type header field header    Standard,
+        field for internet messages", RFC 1049, March    Recommended,
+        1988.                                            but can in
+                                                         the future
+                                                         be expected
+                                                         to be
+                                                         replaced by
+                                                         MIME
+
+[5]     R. Braden (editor): "Requirements for            Standard,
+        Internet Hosts -- Application and Support",      Required
+        STD-3, RFC 1123, October 1989.
+
+[6]     D. Robinson, R. Ullman: "Encoding Header         Non-standard
+        field Header field for Internet Messages",
+        RFC 1154, April 1990.
+
+[7]     S. Hardcastle-Kille: "Mapping between            Proposed
+        X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
+        1327 May 1992.                                   elective
+
+[8]     H. Alvestrand & J. Romaguera: "Rules for         Proposed
+        Downgrading Messages from X.400/88 to            standard,
+        X.400/84 When MIME Content-Types are Present     elective
+        in the Messages", RFC 1496, August 1993.
+
+[9]     A. Costanzo: "Encoding Header field Header       Non-standard
+        field for Internet Messages", RFC 1154, April
+        1990.
+
+[10]    A. Costanzo, D. Robinson: "Encoding Header       Experimental
+        field Header field for Internet Messages",
+        RFC 1505, August 1993.
+
+[11]    N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
+        Internet Mail Extensions) Part One: Format of    Standard,
+        Internet Message Bodies. RFC 2945. November      elective
+        1996.
+
+[12]    H. Alvestrand: "Tags for the Identification      Proposed
+        of Languages", RFC 1766, February 1995.          standard,
+                                                         elective
+
+[13]    J. Palme: "Electronic Mail", Artech House        Non-standard
+        publishers, London-Boston January 1995.
+
+[14]    R. Troost, S. Dorner: "Communicating             Experimental
+        Presentation Information in Internet
+        Messages: The Content-Disposition Header
+        field", RFC 1806, June 1995.
+
+[15]    B. Kantor, P. Lapsley, "Network News Transfer    Proposed
+        Protocol: "A Proposed Standard for the Stream-   standard
+        Based Transmission of News", RFC 977, January
+        1986.
+[16]    1848  PS   S. Crocker, N. Freed, J. Galvin,      Proposed
+        S. Murphy, "MIME Object Security Services",      standard
+        RFC 1848, March 1995.
+
+[17]    J. Myers, M. Rose: The Content-MD5 Header        Draft
+        field Header field, RFC 1864, October 1995.      standard
+
+[18]    M. Horton, UUCP mail interchange format          Not an offi-
+        standard, RFC 976, Januari 1986.                 cial IETF
+                                                         standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[19]    T. Berners-Lee, R. Header fielding, H.           IETF draft
+        Frystyk: Hypertext Transfer Protocol --
+        HTTP/1.0, draft-ietf-http-v10-spec-04.txt.
+
+[20]    G. Vaudreuil: Voice Profile for Internet         Experimental
+        Mail, RFC 1911, February 1996.
+
+[21]    H. Spencer: News Article Format and              Not even an
+        Transmission, June 1994,                         RFC, but
+        FTP://zoo.toronto.edu/pub/news.ps.Z              still widely
+        FTP://zoo.toronto.edu/pub/news.txt.Z             used and
+                                                         partly
+        This document is often referenced under the      almost a de-
+        name "son-of-RFC1036".                           facto
+                                                         standard for
+                                                         Usenet News
+
+[23]    PICS Label Distribution Label Syntax and         Other
+        Communication Protocols, World Wide Web          standard
+        Consortium, October 1996.
+
+[24]    Eudora Pro Macintosh User Manual, Qualcomm       Non-standard
+        Inc., 1988-1995.
+
+[25]    C. Newman: Originator-Info Message Header        Non-standard
+        field. draft-newman-msgheader field-originfo-
+        01.txt, July 1997.
+
+[26]    Grant Neufeld and Joshua D. Baer: The Use of     IETF draft
+        URLs as Meta-Syntax for Core Mail List
+        Commands and their Transport through Message
+        Header fields, draft-baer-listspec-01.txt,
+        September 1997.
+
+
+                          6. Author's address
+
+Jacob Palme                          Phone: +46-8-16 16 67
+Stockholm University/KTH             Fax: +46-8-783 08 29
+Electrum 230                         E-mail: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
+
+
+
+                             Appendix A:
+Header fields sorted by Internet RFC document in which they appear.
+
+
+RFC 822
+-------
+
+bcc
+cc
+Comments
+Date
+From
+In-Reply-To
+Keywords
+Message-ID
+Received
+References
+Reply-To
+Resent-
+Resent-bcc
+Resent-cc
+Resent-Date
+Resent-From
+Resent-From
+Resent-Message-ID
+Resent-Reply-To
+Resent-To
+Return-Path
+Sender
+Sender
+Subject
+To
+
+RFC 976
+-------
+
+"From " (followed by space, not colon (:")
+
+RFC 1036
+--------
+
+Approved
+Control
+Distribution
+Expires
+Followup-To
+Lines
+Newsgroups
+Organization
+Path
+Summary
+Xref
+
+RFC 1049
+--------
+
+Content-Type
+
+RFC 1327
+--------
+
+Alternate-recipient
+Auto-Forwarded
+Autoforwarded
+Content-Identifier
+Content-Return
+Conversion
+Conversion-With-Loss
+Delivery-Date
+Discarded-X400-IPMS-Extensions
+Discarded-X400-MTS-Extensions
+Disclose-Recipients
+DL-Expansion-History
+Expiry-Date
+Generate-Delivery-Report
+Importance
+Incomplete-Copy
+Language
+Message-Type Delivery
+Obsoletes
+Original-Encoded-Information-Types
+Prevent-NonDelivery-Report
+Priority
+Reply-By
+Report
+Sensitivity
+
+RFC 1505
+--------
+
+Encoding
+
+RFC 2045
+--------
+
+Content-Description
+Content-ID
+Content-Transfer-Encoding
+Content-Type
+MIME-Version
+
+RFC 1806
+--------
+
+Content-Disposition
+
+RFC 1864
+--------
+
+Content-MD5
+
+RFC 1911
+--------
+
+Importance
+Sensitivity
+
+RFC 2110
+--------
+
+Content-Base
+Content-Location
+
+son-of-RFC1036 [21]
+-------------------
+
+Also-Control
+Article-Names
+Article-Updates
+See-Also
+Supersedes
+
+draft-ietf-receipt
+------------------
+Disposition-Notification-To
+Disposition-Notification-Options
+Original-Recipient
+
+World Wide Web Consortium (W3C) Recommendations
+-----------------------------------------------
+
+Pics-Label
+
+Not Internet standard
+---------------------
+
+"From " (not followed by ":")
+Apparently-to
+Content-Alias
+Content-Length
+Content-SGML-Entity
+Encoding
+Errors-To
+Fax
+Fcc
+For-Approval
+For-Comment
+For-Handling
+List-Archive
+List-Help
+List-ID
+List-Owner
+List-Post
+List-Software
+List-Subscribe
+List-Unsubscribe
+Mail-System-Version
+Mailer
+Organisation
+Originating-Client
+Originator-Info
+Phone
+Return-Receipt-To
+Status
+Supersedes
+Telefax
+X-Envelope-From
+X-Envelope-To
+X-Mailer
+X-MIME-Autoconverted
+X-Newsreader
+X-No-Archive
+X-Priority
+X-Sender
+X-UIDL
+X-URL
+X-X-Sender
+X400-Content-Return
+
+
+                   Appendix B: Alphabetical index
+
+Section Header field
+------- ------------
+
+3.3     Also-Control
+3.3     Alternate-Recipient
+3.4     Apparently-To
+3.4     Approved
+3.6     Article-Names
+3.6     Article-Updates
+3.17    Auto-Forwarded
+3.4     bcc
+3.4     cc
+        Client, see Originating-Client
+        Comment, see For-Comment
+3.7     Comments
+3.6     Content-Alias
+3.6     Content-Base
+3.12    Content-Conversion
+3.7     Content-Description
+3.3     Content-Disposition
+3.6     Content-ID
+3.7     Content-Identifier
+3.10    Content-Language see also Language
+3.11    Content-Length
+3.6     Content-Location
+3.15    Content-MD5
+3.4     Content-Return
+3.13    Content-SGML-Entity
+3.13    Content-Transfer-Encoding
+3.13    Content-Type
+3.3     Control
+3.12    Conversion
+3.12    Conversion-With-Loss
+        Copy, see Incomplete-Copy
+3.8     Date
+        Date, see also Delivery-Date, Received, Expires, Expiry-
+        Date
+3.8     Delivery-Date
+        Delivery-Report, see Generate-Delivery-Report, Prevent-
+        Delivery-Report, Non-Delivery-Report, Content-Type
+        Description, see Content-Description
+3.17    Discarded-X400-IPMS-Extensions
+3.17    Discarded-X400-MTS-Extensions
+3.3     Disclose-Recipients
+        Disposition, see also Content-Disposition
+3.5     Disposition-Notification-Options
+3.5     Disposition-Notification-To
+3.4     Distribution
+3.2     DL-Expansion-History-Indication
+3.13    Encoding see also Content-Transfer-Encoding
+3.4     Errors-To
+3.8     Expires
+3.8     Expiry-Date
+        Extension see Discarded-X400-IPMS-Extensions, Discarded-
+        X400-MTS-Extensions
+3.4     Fax
+3.17    Fcc
+3.4     Followup-To
+3.4     For-Approval
+3.4     For-Comment
+3.4     For-Handling
+        Forwarded, see Auto-Forwarded
+3.4     From
+3.4     Generate-Delivery-Report
+        Handling, see For-Handling
+        History, see DL-Expansion-History-Indication
+        ID, see Content-ID and Message-ID
+        Identifier, see Content-ID and Message-ID
+3.9     Importance
+3.6     In-Reply-To
+3.9     Incomplete-Copy
+3.7     Keywords
+        Label, see PICS-Label
+3.10    Language see also Content-Language
+        Length see Content-Length
+3.11    Lines
+3.16    List-Archive
+3.16    List-Help
+3.16    List-ID
+3.16    List-Owner
+3.16    List-Post
+3.16    List-Software
+3.16    List-Subscribe
+3.16    List-Unsubscribe
+        Loss, see Conversion-With-Loss
+3.4     Mail-System-Version see also X-mailer
+3.4     Mailer
+        MD5 see Content-MD5
+3.6     Message-ID
+3.13    Message-Type
+3.3     MIME-Version
+3.4     Newsgroups
+        Newsreader, see X-Newsreader
+3.6     Obsoletes
+3.7     Organisation
+3.7     Organization
+3.3     Original-Encoded-Information-Types
+3.6     Original-Recipient
+3.4     Originating-Client
+3.4     Originator-Info see also Sender
+3.2     Path
+3.4     Phone
+3.9     PICS-Label
+3.9     Precedence
+3.4     Prevent-NonDelivery-Report
+3.9     Priority
+3.2     Received
+        Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
+        Recipient
+3.6     References
+3.8     Reply-By
+3.4     Reply-To, see also In-Reply-To, References
+3.14    Resent-
+        Return see also Content-Return
+3.2     Return-Path
+3.5     Return-Receipt-To
+3.6     See-Also
+3.4     Sender
+3.9     Sensitivity
+3.17    Status
+3.7     Subject
+3.7     Summary
+3.6     Supersedes
+3.4     Telefax
+3.4     To
+        Transfer-Encoding see Content-Transfer-Encoding
+        Type see Content-Type, Message-Type, Original-Encoded-
+        Information-Types
+        Version, see MIME-Version, X-Mailer
+3.4     X-Envelope-From
+3.4     X-Envelope-To
+3.16    X-List-Host
+3.16    X-Listserver
+3.4     X-Mailer see also Mail-System-Version
+3.13    X-MIME-Autoconverted
+3.4     X-Newsreader
+3.17    X-No-Archive
+3.9     X-Priority
+3.4     X-Sender see also Originator-Info
+3.6     X-UIDL
+3.6     X-URL see also Content-Location
+3.4     X-X-Sender see also Originator-Info
+3.4     X400-Content-Return
+3.15    Xref
+
+
diff --git a/Documentation/en/I-D/draft-palme-mailext-headers-01.txt b/Documentation/en/I-D/draft-palme-mailext-headers-01.txt
new file mode 100644
index 00000000..4fb44682
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-mailext-headers-01.txt
@@ -0,0 +1,1612 @@
+Network Working Group                                     Jacob Palme
+Internet Draft                               Stockholm University/KTH
+draft-palme-mailext-headers-01.txt                     Sweden
+Category: Informational                                Date: May 1999
+Revision of: RFC 2076                          Expires: November 1999
+
+                  Common Internet Message Header Fields
+
+                        Status of this Memo
+
+This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright (C) The Internet Society 1998. All Rights Reserved.
+
+
+                            Abstract
+
+This memo contains a table of commonly occurring header fields in
+headings of e-mail messages. The document compiles information from
+other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC
+1766, RFC 1806, RFC 1864, RFC 1911 and RFC 2045. A few commonly
+occurring header fields which are not defined in RFCs are also
+included. For each header field, the memo gives a short description and
+a reference to the RFC in which the header field is defined.
+
+This document is a revision of RFC 2076. The following new header
+fields, not included in RFC 2076, have been added:
+Also-Control,  Content-Alias, Content-Conversion, Content-Features,
+Disposition-Notification-Options, Disposition-Notification-To, Expiry-
+Date, For-Approval, List-Archive, List-Help, List-ID, List-Owner, List-
+Post, List-Software, List-Subscribe, List-Unsubscribe, Original-
+Recipient, Originator, Originator-Info, Path, PICS-Label, Replaces,
+Speech-Act, Translated-By. Translation-Of, X-Envelope-From, X-Envelope-
+To, X-List-Host, X-Listserver, X-MIME-Autoconverted, X-No-Archive, X-
+Priority, X-Sender, X-X-Sender, X-UIDL, X-URL, X-URI.
+
+The latest, revised version of this document is available in plain
+text, HTML and Adobe Acrobat format at URL
+http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#anchor1003783
+
+
+                         Table of contents
+
+     Abstract                                                         1
+1. Introduction                                                        3
+2. Use of gatewaying header fields                                     6
+3. Table of header fields                                              6
+     3.1 Phrases used in the tables                                   6
+     3.2 Trace information                                            8
+     3.3 Format and control information                               8
+     3.4 Sender and recipient indication                              9
+     3.5 Response control                                             14
+     3.6 Message identification and referral header fields            17
+     3.7 Other textual header fields                                  19
+     3.8 Header fields containing dates and times                     20
+     3.9 Quality information                                          20
+     3.10 Language information                                        21
+     3.11 Size information                                            22
+     3.12 Conversion control                                          22
+     3.13 Encoding information                                        22
+     3.14 Resent-header fields                                        24
+     3.15 Security and reliability                                    24
+     3.16 Mailing list control                                        25
+     3.17 Miscellaneous                                               26
+4. Acknowledgments                                                     27
+Copyright and disclaimer                                               28
+5. References                                                          28
+6. Author's address                                                    31
+Appendix A: Header fields sorted by Internet RFC document in
+which they appear.                                                     31
+     RFC 822                                                          31
+     RFC 976                                                          32
+     RFC 1036                                                         32
+     RFC 1049                                                         33
+     RFC 1327                                                         33
+     RFC 1505                                                         33
+     RFC 2045                                                         33
+     RFC 1806                                                         34
+     RFC 1911                                                         34
+     RFC 2110                                                         34
+     RFC 2369                                                         34
+     son-of-RFC1036 [21]                                              34
+     draft-ietf-receipt                                               35
+     World Wide Web Consortium (W3C) Recommendations                  35
+     Not Internet standard                                            35
+Appendix B: Alphabetical index                                         36
+
+
+                         1. Introduction
+
+Many different Internet standards and RFCs define header fields which
+may occur on Internet Mail Messages and Usenet News Articles. The
+intention of this document is to list all such header fields in one
+document as an aid to people developing message systems or interested
+in Internet Mail standards.
+
+The document contains all header fields which the author has
+found in the following Internet standards: RFC 822 [2],
+RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 2045 [11],
+RFC 1766 [12], RFC 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in
+particular that heading attributes defined in PEM (RFC 1421-1424) and
+MOSS (RFC 1848 [16]) are not included. PEM and MOSS header fields only
+appear inside the body of a message, and thus are not header fields in
+the RFC 822 sense. Mail attributes in envelopes, i.e. attributes
+controlling the message transport mechanism between mail and news
+servers, are not included. This means that attributes from SMTP [1],
+UUCP [18] and NNTP [15] are mainly not covered either. Headings used
+only in HTTP [19] are not included yet, but may be included in future
+version of this memo. Some additional header fields which often can be
+found in e-mail headings but are not part of any Internet standard are
+also included.
+
+For each header field, the document gives a short description and a
+reference to the Internet standard or RFC, in which they are defined.
+
+The header field names given here are spelled the same way as when they
+are actually used. This is usually American but sometimes English
+spelling.  One header field in particular, "Organisation/Organization",
+occurs in e-mail header fields sometimes with the English and other
+times with the American spelling.
+
+The following words are used in this memo with the meaning specified
+below:
+
+heading           Formatted text at the top of a message, ended by a
+                  blank line
+
+header field      One field in the heading, beginning with a field
+                  name, colon, and followed by the field value(s). The
+                  words "heading field" and "header" are also
+                  sometimes used with this meaning.
+
+It is my intention to continue updating this document after its
+publication as an RFC. The latest version, which may be more up-to-date
+(but also less fully checked out) will be kept available for
+downloading from URL
+http://www.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html
+http://www.dsv.su.se/~jpalme/ietf/mail-attributes.html and
+http://www.dsv.su.se/~jpalme/ietf/mail-attributes.pdf
+
+Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
+header fields which should be included in this memo but are not.
+
+
+                 2. Use of gatewaying header fields
+
+RFC 1327 defines a number of new header fields in Internet mail, which
+are defined to map header fields which X.400 has but which were
+previously not standardized in Internet mail. The fact that a header
+field occurs in RFC 1327 indicates that it is recommended for use in
+gatewaying messages between X.400 and Internet mail, but does not mean
+that the header field is recommended for messages wholly within
+Internet mail. Some of these header fields may eventually see
+widespread implementation and use in Internet mail, but at the time of
+this writing (1996) they are not widely implemented or used.
+
+Header fields defined only in RFC 1036 for use in Usenet News sometimes
+appear in mail messages, either because the messages have been
+gatewayed from Usenet News to e-mail, or because the messages were
+written in combined clients supporting both e-mail and Usenet News in
+the same client. These header fields are not standardized for use in
+Internet e-mail and should be handled with caution by e-mail agents.
+
+
+                      3. Table of header fields
+
+3.1 Phrases used in the tables
+
+"not for general        Used to mark header fields which are defined
+usage"                  in RFC 1327 for use in messages from or to
+                        Internet mail/X.400 gateways. These header
+                        fields have not been standardized for general
+                        usage in the exchange of messages between
+                        Internet mail-based systems.
+
+"not standardized       Used to mark header fields defined only in RFC
+for use in e-mail"      1036 for use in Usenet News. These header
+                        fields have no standard meaning when appearing
+                        in e-mail, some of them may even be used in
+                        different ways by different software. When
+                        appearing in e-mail, they should be handled
+                        with caution. Note that RFC 1036, although
+                        generally used as a de-facto standard for
+                        Usenet News, is not an official IETF standard
+                        or even on the IETF standards track.
+
+"non-standard"          This header field is not specified in any of
+                        referenced RFCs which define Internet
+                        protocols, including Internet Standards, draft
+                        standards or proposed standards. The header
+                        field appears here because it often appears in
+                        e-mail or Usenet News. Usage of these header
+                        fields is not in general recommended. Some
+                        header field proposed in ongoing IETF
+                        standards development work, but not yet
+                        accepted, are also marked in this way.
+
+"discouraged"           This header field, which is non-standard, is
+                        known to create problems and should not be
+                        generated. Handling of such header fields in
+                        incoming mail should be done with great
+                        caution.
+
+"controversial"         The meaning and usage of this header field is
+                        controversial, i.e. different implementors
+                        have chosen to implement the header field in
+                        different ways. Because of this, such header
+                        fields should be handled with caution and
+                        understanding of the different possible
+                        interpretations.
+
+"experimental"          This header field is used for newly defined
+                        header fields, which are to be tried out
+                        before entering the IETF standards track.
+                        These should only be used if both
+                        communicating parties agree on using them. In
+                        practice, some experimental protocols become
+                        de-facto-standards before they are made into
+                        IETF standards.
+
+3.2 Trace information
+
+Used to convey the information       Return-Path:    RFC 821,
+from the MAIL FROM envelope                          RFC 1123: 5.2.13.
+attribute in final delivery, when
+the message leaves the SMTP
+environment in which "MAIL FROM"
+is used.
+
+Trace of MTAs which a message has    Received:       RFC 822: 4.3.2,
+passed.                                              RFC 1123: 5.2.8.
+
+List of MTAs passed.                 Path:           RFC 1036: 2.1.6,
+                                                     only in Usenet
+                                                     News, not in e-
+                                                     mail.
+
+Trace of distribution lists          DL-Expansion-   RFC 1327, not for
+passed.                              History-        general usage.
+                                     Indication:
+
+3.3 Format and control information
+
+An indicator that this message is    MIME-Version:   RFC 2045: 4.
+formatted according to the MIME
+standard, and an indication of
+which version of MIME is
+utilized.
+
+Only in Usenet News, contains        Control:        RFC 1036: 2.1.6,
+commands to be performed by News                     only in Usenet
+agents.                                              News, not in e-
+                                                     mail.
+
+Special Usenet News commands and     Also-Control:   son-of-RFC1036
+a normal article at the same                         [21], non-
+time.                                                standard, only in
+                                                     Usenet News, not
+                                                     in e-mail
+
+Which body part types occur in       Original-       RFC 1327, not for
+this message.                        Encoded-        general usage.
+                                     Information-
+                                     Types:
+
+Controls whether this message may    Alternate-      RFC 1327, not for
+be forwarded to alternate            Recipient:      general usage.
+recipients such as a postmaster
+if delivery is not possible to
+the intended recipient. Default:
+Allowed.
+
+Whether recipients are to be told    Disclose-       RFC 1327, not for
+the names of other recipients of     Recipients:     general usage.
+the same message. This is
+primarily an X.400 facility. In
+X.400, this is an envelope
+attribute and refers to
+disclosure of the envelope
+recipient list. Disclosure of
+other recipients is in Internet
+mail done via the To:, cc: and
+bcc: header fields.
+
+Whether a MIME body part is to be    Content-        RFC 1806,
+shown inline or is an attachment;    Disposition:    experimental
+can also indicate a suggested
+filename for use when saving an
+attachment to a file.
+
+
+3.4 Sender and recipient indication
+
+Authors or persons taking            From:           RFC 822: 4.4.1,
+responsibility for the message.                      RFC 1123: 5.2.15-
+                                                     16, 5.3.7,
+Note difference from the "From "                     RFC 1036 2.1.1
+header field (not followed by
+":") below.
+
+
+(1) This header field should         From (not       not standardized
+never appear in e-mail being         followed by a   for use in e-mail
+sent, and should thus not appear     colon)
+in this memo. It is however
+included, since people often ask
+about it.
+
+This header field is used in the
+so-called Unix mailbox format,
+also known as Berkely mailbox
+format or the MBOX format. This
+is a format for storing a set of
+messages in a file. A line
+beginning with "From " is used to
+separate successive messages in
+such files.
+
+This header field will thus
+appear when you use a text editor
+to look at a file in the Unix
+mailbox format. Some mailers also
+use this format when printing
+messages on paper.
+
+The information in this header
+field should NOT be used to find
+an address to which replies to a
+message are to be sent.
+
+(2) Used in Usenet News mail         From            RFC 976: 2.4 for
+transport, to indicate the path      or              use in Usenet News
+through which an article has gone    >From
+when transferred to a new host.      (not followed
+                                     by a colon)
+Sometimes called "From_" header
+field.
+
+Name of the moderator of the         Approved:       RFC 1036: 2.2.11,
+newsgroup to which this article                      not standardized
+is sent; necessary on an article                     for use in e-mail.
+sent to a moderated newsgroup to
+allow its distribution to the
+newsgroup members. Also used on
+certain control messages, which
+are only performed if they are
+marked as Approved.
+
+The person or agent submitting       Sender:         RFC 822: 4.4.2,
+the message to the network, if                       RFC 1123: 5.2.15-
+other than shown by the From:                        16, 5.3.7, RFC
+header field. Should be                              1036.
+authenticated,
+according to RFC 822, but what
+kind of authentication is not
+clear. Some implementations
+expect that the e-mail address
+used in this field can be used to
+reach the sender, others do not.
+See also "X-Sender".
+
+Sometimes used in Usenet News in     Originator:     Non-standard
+similar ways to "Sender:"
+
+Some mail software expect            X-Sender:       Non-standard
+"Sender:" to be an e-mail address
+which you can send mail to.
+However, some mail software has
+as the best authenticated sender
+a POP or IMAP account, which you
+might not be able to send to.
+Because of this, some mail
+software put the POP or IMAP
+account into an X-sender header
+field instead of a Sender header
+field, to indicate that you may
+not be able to send e-mail to
+this address. See also "X-X-
+Sender".
+
+Another use of" X-Sender:" is
+that some e-mail software, which
+wants to insert a "Sender:"
+header, will first change an
+existing "Sender:" header to "X-
+Sender". This use is actually
+often the same as that described
+in the previous paragraph, since
+the new "Sender:" is added
+because it is better
+authenticated than the old value.
+
+Even though some systems put the     X-X-Sender:     Non-standard
+POP or IMAP account name into the
+"X-Sender:" instead of the Sender
+header field, some mail software
+tries to send to the "X-Sender:"
+too. To stop this, some systems
+have begun to use "X-X-Sender:"
+to indicate an authentication of
+the sender which might not be
+useable to send e-mail to. See
+also "Originator-Info:"
+
+Contains information about the       Originator-     Non-standard [25]
+authentication of the originator     Info:
+in a format which is not easily
+used to send email to, to avoid
+the problems with "Sender" and "X-
+Sender".
+
+Primary recipients.                  To:             RFC 822: 4.5.1,
+                                                     RFC 1123: 5.2.15-
+                                                     16, 5.3.7.
+
+Secondary, informational             cc:             RFC 822: 4.5.2,
+recipients. (cc = Carbon Copy)                       RFC 1123. 5.2.15-
+                                                     16, 5.3.7.
+
+Recipients not to be disclosed to    bcc:            RFC 822: 4.5.3,
+other recipients. (bcc = Blind                       RFC 1123: 5.2.15-
+Carbon Copy).                                        16, 5.3.7.
+
+Primary recipients, who are          For-Handling:   Non-standard
+requested to handle the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Comment:    Non-standard
+requested to comment on the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Approval:   Non-standard
+requested to approve the
+information in this message or
+its attachments.
+
+In Usenet News: group(s) to which    Newsgroups:     RFC 1036: 2.1.3,
+this article was posted.                             not standardized
+Some systems provide this header                     and controversial
+field also in e-mail although it                     for use in e-mail.
+is not standardized there.
+Unfortunately, the header field
+can appear in e-mail with three
+different and contradictory
+meanings:
+
+(a) Indicating the newsgroup
+recipient of an article/message
+sent to both e-mail and Usenet
+News recipients.
+
+(b) In a message adressed to some
+mail to news gateways, indicates
+the newsgroup(s) that the message
+is to be posted to.
+
+(c) In a personally addressed
+reply to an article in a news-
+group, indicating the newsgroup
+in which this discussion
+originated.
+
+Inserted by Sendmail when there      Apparently-     Non-standard,
+is no "To:" recipient in the         To:             discouraged,
+original message, listing                            mentioned in
+recipients derived from the                          RFC 1211.
+envelope into the message
+heading. This behavior is not
+quite proper, MTAs should not
+modify headings (except inserting
+Received lines), and it can in
+some cases cause Bcc recipients
+to be wrongly divulged to non-Bcc
+recipients.
+
+Geographical or organizational       Distribution:   RFC 1036: 2.2.7,
+limitation on where this article                     not standardized
+can be distributed. Value can be                     for use in e-mail.
+a compete or incomplete domain
+names, also various special
+values are accepted like "world",
+"usenet", "USA", etc.
+
+Fax number of the originator.        Fax:,           Non-standard.
+                                     Telefax:
+
+Phone number of the originator.      Phone:          Non-standard.
+
+If the recipient in the envelope     X-Envelope-To   Non-standard.
+(SMTP "MAIL FROM") is not
+included in the CC list, some
+mail servers add this to the
+RFC822 header field as an aid to
+clients which would otherwise not
+be able to display the envelope
+recipients.
+
+If the sender in the envelope        X-Envelope-     Non-standard.
+(SMTP "RCTP TO") is not the same     From
+as the senders in the "From" or
+"Sender" RFC822 header fields,
+some mail servers add this to the
+RFC822 header fields as an aid to
+clients which would otherwise not
+be able to display this
+information.
+
+Information about the client         Mail-System-    Non-standard.
+software of the originator.          Version:,
+                                     Mailer:,
+                                     Originating-
+                                     Client:, X-
+                                     Mailer, X-
+                                     Newsreader
+
+3.5 Response control
+
+This header field is meant to        Reply-To:       RFC 822: 4.4.3,
+indicate where the sender wants                      RFC 1036: 2.2.1
+replies to go. Unfortunately,                        controversial.
+this is ambiguous, since there
+are different kinds of replies,
+which the sender may wish to go
+to different addresses. In
+particular, there are personal
+replies intended for only one
+person, and group replies,
+intended for the whole group of
+people who read the replied-to
+message (often a mailing list,
+anewsgroup name cannot appear
+here because of different syntax,
+see "Followup-To" below.).
+
+Some mail systems use this header
+field to indicate a better form
+of the e-mail address of the
+sender. Some mailing list
+expanders puts the name of the
+list in this header field. These
+practices are controversial. The
+personal opinion of the author of
+this RFC is that this header
+field should be avoided except in
+special cases, but this is a
+personal opinion not shared by
+all specialists in the area.
+
+Used in Usenet News to indicate      Followup-To:    RFC 1036: 2.2.3,
+that future discussions (=follow-                    not standardized
+up) on an article should go to a                     for use in e-mail.
+different set of newsgroups than
+the replied-to article. The most
+common usage is when an article
+is posted to several newsgroups,
+and further discussions is to
+take place in only one of them.
+
+In e-mail, this header field may
+occur in a message which is sent
+to both e-mail and Usenet News,
+to show where follow-up in Usenet
+news is wanted. The header field
+does not say anything about where
+follow-up in e-mail is to be
+sent.
+
+Note that the value of this
+header field must always be one
+or more newsgroup names, never e-
+mail addresses.
+
+Address to which notifications       Errors-To:,     Non-standard,
+are to be sent and a request to      Return-         discouraged.
+get delivery notifications.          Receipt-To:
+Internet standards recommend,
+however, the use of MAIL FROM and
+Return-Path, not Errors-To, for
+where delivery notifications are
+to be sent.
+
+Whether non-delivery report is       Prevent-        RFC 1327, not for
+wanted at delivery error. Default    NonDelivery-    general usage.
+is to want such a report.            Report:
+
+Whether a delivery report is         Generate-       RFC 1327, not for
+wanted at successful delivery.       Delivery-       general usage.
+Default is not to generate such a    Report:
+report.
+Indicates whether the content of     Content-        RFC 1327, not for
+a message is to be returned with     Return:         general usage.
+non-delivery notifications.
+Possible future change of name       X400-Content-   non-standard
+for "Content-Return:"                Return:
+
+Indicate that the sender wants a     Disposition-    RFC 2298
+dispoisition notification when       Notification-
+this message is received (read,      To
+processed, etc.) by its
+receipents.
+
+For future options on disposition    Disposition-    RFC 2298
+notifications.                       Notification-
+                                     Options
+
+
+Original Recipient information       Original-       RFC 2298
+for inclusion in disposition         Recipient
+notifications.
+
+
+3.6 Message identification and referral header fields
+
+Unique ID of this message.           Message-ID:     RFC 822: 4.6.1
+                                                     RFC 1036: 2.1.5.
+
+Unique ID of one body part of the    Content-ID:     RFC 2045: 7.
+content of a message.
+Base to be used for resolving        Content-Base:   RFC 2110
+relative URIs within this content
+part.
+
+URI with which the content of        Content-        RFC 2110
+this content part might be           Location:
+retrievable.
+Used in addition to Content-         Content-        Work in progress
+Location if this content part can    Alias:
+be retrieved through more than
+one URI. Only one of them is
+allowed in the Content-Location,
+the other can be specified in
+Content-Alias.
+
+Sometimes used with the same         X-URL:          Non-standard
+meaning as "Content-Location:",
+sometimes to indicate the web
+home page of the sender or of his
+organisation.
+
+Similar usage as "X-URL". The URI    X-URI:          Non-standard
+can be either a URL or a URN.
+URNs are meant to become more
+persistent references to
+resources than URLs.
+
+Reference to message which this      In-Reply-To:    RFC 822: 4.6.2.
+message is a reply to.
+In e-mail: reference to other        References:     RFC 822: 4.6.3
+related messages, in Usenet News:                    RFC 1036: 2.1.5.
+reference to replied-to-articles.
+References to other related          See-Also:       Son-of-RFC1036
+articles in Usenet News.                             [21], non-standard
+
+Reference to previous message        Obsoletes:      RFC 1327, not for
+being corrected and replaced.                        general usage.
+Compare to "Supersedes:" below.
+This field may in the future be
+replaced with "Supersedes:".
+
+Commonly used in Usenet News in      Supersedes:     son-of-RFC1036
+similar ways to the "Obsoletes"                      [21], non-standard
+header field described above. In
+Usenet News, however, Supersedes
+causes a full deletion of the
+replaced article in the server,
+while "Supersedes" and
+"Obsoletes" in e-mail is
+implemented in the client and
+often does not remove the old
+version of the text.
+
+Still another name for similar       Replaces:       non-standard,
+functionality as for "Obsoletes:"                    proposed in IETF
+and "Supersedes:". This may                          USEFOR working
+become the most recommended                          group
+header in the future, but is
+still under discussion in IETF
+standards development work.
+
+Unique identifier for a message,     X-UIDL:         non-standard
+local to a particular local
+mailbox store. The UIDL
+identifier is defined in the POP3
+standard, but not the "X-UIDL:"
+header.
+
+Only in Usenet News, similar to      Article-        son-of-RFC1036
+"Supersedes:" but does not cause     Updates:        [21], non-standard
+the referenced article to be
+physically deleted.
+
+Reference to specially important     Article-        son-of-RFC1036
+articles for a particular Usenet     Names:          [21], non-standard
+Newsgroup.
+Reference to the Message-ID of a     Translation-    non-standard
+message, which the current           Of:
+message is a translation of.
+
+Mailbox of the person who made       Translated-     non-standard
+the translation.                     By:
+
+
+3.7 Other textual header fields
+
+Search keys for data base            Keywords:       RFC 822: 4.7.1
+retrieval.                                           RFC 1036: 2.2.9.
+
+Title, heading, subject. Often       Subject:        RFC 822: 4.7.1
+used as thread indicator for                         RFC 1036: 2.1.4.
+messages replying to or
+commenting on other messages.
+
+Comments on a message.               Comments:       RFC 822: 4.7.2.
+
+Description of a particular body     Content-        RFC 2045: 8.
+part of a message, for example a     Description:
+caption for an image body part.
+Organization to which the sender     Organization:   RFC 1036: 2.2.8,
+of this article belongs.                             not standardized
+                                                     for use in e-mail.
+
+See Organization above.              Organisation:   Non-standard.
+
+Short text describing a longer       Summary:        RFC 1036: 2.2.10,
+article. Warning: Some mail                          not standardized
+systems will not display this                        for use in e-mail,
+text to the recipient. Because of                    discouraged.
+this, do not use this header
+field for text which you want to
+ensure that the recipient gets.
+
+A text string which identifies       Content-        RFC 1327, not for
+the content of a message.            Identifier:     general usage.
+
+3.8 Header fields containing dates and times
+
+The time when a message was          Delivery-       RFC 1327, not for
+delivered to its recipient.          Date:           general usage.
+
+In Internet, the date when a         Date:           RFC 822: 5.1,
+message was written, in X.400,                       RFC 1123: 5.2.14
+the time a message was submitted.                    RFC 1036: 2.1.2.
+Some Internet mail systems also
+use the date when the message was
+submitted.
+
+A suggested expiration date. Can     Expires:        RFC 1036: 2.2.4,
+be used both to limit the time of                    not standardized
+an article which is not                              for use in e-mail.
+meaningful after a certain date,
+and to extend the storage of
+important articles.
+
+Time at which a message loses its    Expiry-Date:    RFC 1327, not for
+validity. This field may in the                      general usage.
+future be replaced by "Expires:".
+Latest time at which a reply is      Reply-By:       RFC 1327, not for
+requested (not demanded).                            general usage.
+
+3.9 Quality information
+
+Can be "normal", "urgent" or "non-   Priority:       RFC 1327, not for
+urgent" and can influence                            general usage.
+transmission speed and delivery.
+Values: 1 (Highest), 2 (High), 3     X-Priority:     Non-standard [24]
+(Normal), 4 (Low), 5 (Lowest). 3
+(Normal) is default if the field
+is omitted.
+
+Sometimes used as a priority         Precedence:     Non-standard,
+value which can influence                            controversial.
+transmission speed and delivery.
+Common values are "bulk" and
+"first-class". Other uses is to
+control automatic replies and to
+control return-of-content
+facilities, and to stop mailing
+list loops.
+
+A hint from the originator to the    Importance:     RFC 1327 and
+recipients about how important a                     RFC 1911,
+message is. Values: High, normal                     experimental
+or low. Not used to control
+transmission speed.
+
+How sensitive it is to disclose      Sensitivity:    RFC 1327 and
+this message to other people than                    RFC 1911,
+the specified recipients. Values:                    experimental
+Personal, private, company
+confidential. The absence of this
+header field in messages
+gatewayed from X.400 indicates
+that the message is not
+sensitive.
+
+Body parts are missing.              Incomplete-     RFC 1327, not for
+                                     Copy:           general usage.
+
+Ratings label to control             PICS-Label:     REC-PICS-labels,
+selection (filtering) of messages                    W3C document [23].
+according to the PICS protocol.
+
+3.10 Language information
+
+Can include a code for the           Language:       RFC 1327, not for
+natural language used in a                           general usage.
+message, e.g. "en" for English.
+Can include a code for the           Content-        RFC 1766, proposed
+natural language used in a           Language:       standard.
+message, e.g. "en" for English.
+
+3.11 Size information
+
+Inserted by certain mailers to       Content-        Non-standard,
+indicate the size in bytes of the    Length:         discouraged.
+message text. This is part of a
+format some mailers use when
+showing a message to its users,
+and this header field should not
+be used when sending a message
+through the net. The use of this
+header field in transmission of a
+message can cause several
+robustness and interoperability
+problems.
+
+Size of the message.                 Lines:          RFC 1036: 2.2.12,
+                                                     not standardized
+                                                     for use in e-mail.
+
+3.12 Conversion control
+
+The body of this message may not     Conversion:     RFC 1327, not for
+be converted from one character                      general usage.
+set to another. Values:
+Prohibited and allowed.
+
+Non-standard variant of              Content-        Non-standard.
+Conversion: with the same values.    Conversion:
+
+The body of this message may not     Conversion-     RFC 1327, not for
+be converted from one character      With-Loss:      general usage.
+set to another if information
+will be lost. Values: Prohibited
+and allowed.
+
+
+3.13 Encoding information
+
+Format of content (character set     Content-Type:   RFC 1049,
+etc.) Note that the values for                       RFC 1123: 5.2.13,
+this header field are defined in                     RFC 2045: 5.
+different ways in RFC 1049 and in                    RFC 1766: 4.1
+MIME (RFC 2045), look for the
+"MIME-version" header field to
+understand if Content-Type is to
+be interpreted according to RFC
+1049 or according to MIME. The
+MIME definition should be used in
+generating mail.
+
+RFC 1766 defines a parameter
+"difference" to this header
+field.
+
+Various other Content-Type define
+various additional parameters.
+For example, the parameter
+"charset" is mandatory for all
+textual Content-Types.
+
+Can give more detailed               Content-        non-standard
+information about the Content-       Features:
+Type. Example:
+
+(&  (color=binary)
+    (image-file-structure=TIFF-S)
+    (dpi=200)
+    (paper-size=A4)
+    (image-coding=MH)
+    (MRC-mode=0)
+    (ua-media=stationery) )
+
+This header is meant to be used
+when you can choose between
+different versions of a resource,
+such as when using
+multipart/atlernative.
+
+Information from the SGML entity     Content-SGML-   non-standard
+declaration corresponding to the     Entity:
+entity contained in the body of
+the body part.
+
+Coding method used in a MIME         Content-        RFC 2045: 6.
+message body.                        Transfer-
+                                     Encoding:
+
+Only used with the value             Message-Type:   RFC 1327, not for
+"Delivery Report" to indicates                       general usage.
+that this is a delivery report
+gatewayed from X.400.
+
+Used in several different ways by    Encoding:       RFC 1154,
+different mail systems. Some use                     RFC 1505,
+it for a kind of content-type                        experimental.
+information, some for encoding
+and length information, some for
+a kind of boundary information,
+some in other ways.
+
+Information about conversion of      X-MIME-         non-standard
+this message on the path from        Autoconverted:
+sender to recipient, like
+conversion between MIME encoding
+formats. Note: Auto-conversion
+may invalidate digital seals and
+signatures.
+
+
+3.14 Resent-header fields
+
+When manually forwarding a           Resent-Reply-   RFC 822: C.3.3.
+message, header fields referring     To:,
+to the forwarding, not to the        Resent-From:,
+original message.  Note: MIME        Resent-
+specifies another way of             Sender:,
+resending messages, using the        Resent-From:,
+"Message" Content-Type.              Resent-Date:,
+                                     Resent-To:,
+                                     Resent-cc:,
+                                     Resent-bcc:,
+                                     Resent-
+                                     Message-ID:
+
+3.15 Security and reliability
+
+Checksum of content to ensure        Content-MD5:    RFC 1864, proposed
+that it has not been modified.                       standard.
+
+Used in Usenet News to store         Xref:           RFC 1036: 2.2.13,
+information to avoid showing a                       only in Usenet
+reader the same article twice if                     News, not in e-
+it was sent to more than one                         mail.
+newsgroup. Only for local usage
+within one Usenet News server,
+should not be sent between
+servers.
+
+
+3.16 Mailing list control
+
+Contains URL to use to get a         List-           RFC 2369 [26]
+subscription to the mailing list     Subscribe
+from which this message was
+relayed.
+
+Contains URL to use to               List-           RFC 2369 [26]
+unsubscribe the mailing list from    Unsubscribe
+which this message was relayed.
+
+Contains URL to send e-mail to       List-Owner      RFC 2369 [26]
+the owner of the mailing list
+from which this message was
+relayed.
+
+Contains URL to use to get a         List-Help       RFC 2369 [26]
+information about the mailing
+list from which this message was
+relayed.
+
+Contains URL to use to send          List-Post       RFC 2369 [26]
+contributions to the mailing list
+from which this message was
+relayed.
+
+Contains URL to use to browse the    List-Archive    RFC 2369 [26]
+archives of the mailing list from
+which this message was relayed.
+
+Information about the software       List-Software   Non-standard, has
+used in a mailing list expander                      been considered
+through which this message has                       for inclusion in
+passed.                                              [26].
+
+Stores the URN of the mailing        List-ID         Non-standard, has
+list, through which this message                     been considered
+was distributed.                                     for inclusion in
+                                                     [26].
+
+Information about the software       X-Listserver    Non-standard.
+used in a mailing list expander
+through which this message has
+passed. Warning: "Listserv" is a
+trademark and should not be used
+for other than the "Listserv"
+product. Use, instead the "List-
+Software" header field.
+
+
+3.17 Miscellaneous
+
+Name of file in which a copy of      Fcc:            Non-standard.
+this message is stored.
+Has been automatically forwarded.    Auto-           RFC 1327, not for
+                                     Forwarded:      general usage.
+
+Can be used in Internet mail to      Discarded-      RFC 1327, not for
+indicate X.400 IPM extensions        X400-IPMS-      general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+Can be used in Internet mail to      Discarded-      RFC 1327, not for
+indicate X.400 MTS extensions        X400-MTS-       general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+This field is used by some mail      Status:         Non-standard,
+delivery systems to indicate the                     should never
+status of delivery for this                          appear in mail in
+message when stored. Common                          transit.
+values of this field are:
+U    message is not downloaded
+     and not deleted.
+
+R    message is read or
+     downloaded.
+
+O    message is old but not
+     deleted.
+
+D    to be deleted.
+
+N    new (a new message also
+     sometimes is distinguished
+     by not having any "Status:"
+     header field.
+
+Combinations of these characters
+can occur, such as "Status: OR"
+to indicate that a message is
+downloaded but not deleted.
+
+Do not archive this message in       X-No-Archive:   Non-standard
+publicly available archives.         Yes
+
+Speech act categoriztion of a        Speech-Act:     Non-standard
+message, examples of speeach acts
+are Question, Idea, More,
+Promise, Sad, Happy, Angry,
+summary, Decision
+
+
+                          4. Acknowledgments
+
+Harald Tveit Alvestrand, Ned Freed, Olle J„rnefors, Keith Moore, Nick
+Smith and several other people have helped me with compiling this list.
+I especially thank Ned Freed and Olle J„rnefors for their thorough
+review and many helpful suggestions for improvements. I alone take
+responsibility for any errors which may still be in the list.
+
+An earlier version of this list has been published as part of [13].
+
+
+                 Copyright and disclaimer
+
+The IETF takes no position regarding the validity or scope of
+any intellectual property or other rights that might be
+claimed to pertain to the implementation or use of the
+technology described in this document or the extent to which
+any license under such rights might or might not be available;
+neither does it represent that it has made any effort to
+identify any such rights. Information on the IETF's procedures
+with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims
+of rights made available for publication and any assurances of
+licenses to be made available, or the result of an attempt
+made to obtain a general license or permission for the use of
+such proprietary rights by implementors or users of this
+specification can be obtained from the IETF Secretariat."
+
+The IETF invites any interested party to bring to its
+attention any copyrights, patents or patent applications, or
+other proprietary rights which may cover technology that may
+be required to practice this standard. Please address the
+information to the IETF Executive Director.
+
+Copyright (C) The Internet Society (date). All Rights
+Reserved.
+
+This document and translations of it may be copied and
+furnished to others, and derivative works that comment on or
+otherwise explain it or assist in its implmentation may be
+prepared, copied, published and distributed, in whole or in
+part, without restriction of any kind, provided that the above
+copyright notice and this paragraph are included on all such
+copies and derivative works. However, this document itself may
+not be modified in any way, such as by removing the copyright
+notice or references to the Internet Society or other Internet
+organizations, except as needed for the purpose of developing
+Internet standards in which case the procedures for copyrights
+defined in the Internet Standards process must be followed, or
+as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will
+not be revoked by the Internet Society or its successors or
+assigns.
+
+
+                            5. References
+
+Ref.    Author, title                                    IETF status
+                                                         (July 1996)
+-----   ---------------------------------------------    -----------
+[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
+        STD 10, RFC 821, August 1982.                    Recommended
+
+[2]     D. Crocker: "Standard for the format of ARPA     Standard,
+        Internet text messages." STD 11, RFC 822,        Recommended
+        August 1982.
+
+[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
+        interchange of USENET messages", RFC 1036,       cial IETF
+        December 1987.                                   standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[4]     M. Sirbu: "A Content-Type header field header    Standard,
+        field for internet messages", RFC 1049, March    Recommended,
+        1988.                                            but can in
+                                                         the future
+                                                         be expected
+                                                         to be
+                                                         replaced by
+                                                         MIME
+
+[5]     R. Braden (editor): "Requirements for            Standard,
+        Internet Hosts -- Application and Support",      Required
+        STD-3, RFC 1123, October 1989.
+
+[6]     D. Robinson, R. Ullman: "Encoding Header         Non-standard
+        field Header field for Internet Messages",
+        RFC 1154, April 1990.
+
+[7]     S. Hardcastle-Kille: "Mapping between            Proposed
+        X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
+        1327 May 1992.                                   elective
+
+[8]     H. Alvestrand & J. Romaguera: "Rules for         Proposed
+        Downgrading Messages from X.400/88 to            standard,
+        X.400/84 When MIME Content-Types are Present     elective
+        in the Messages", RFC 1496, August 1993.
+
+[9]     A. Costanzo: "Encoding Header field Header       Non-standard
+        field for Internet Messages", RFC 1154, April
+        1990.
+
+[10]    A. Costanzo, D. Robinson: "Encoding Header       Experimental
+        field Header field for Internet Messages",
+        RFC 1505, August 1993.
+
+[11]    N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
+        Internet Mail Extensions) Part One: Format of    Standard,
+        Internet Message Bodies. RFC 2945. November      elective
+        1996.
+
+[12]    H. Alvestrand: "Tags for the Identification      Proposed
+        of Languages", RFC 1766, February 1995.          standard,
+                                                         elective
+
+[13]    J. Palme: "Electronic Mail", Artech House        Non-standard
+        publishers, London-Boston January 1995.
+
+[14]    R. Troost, S. Dorner: "Communicating             Experimental
+        Presentation Information in Internet
+        Messages: The Content-Disposition Header
+        field", RFC 1806, June 1995.
+
+[15]    B. Kantor, P. Lapsley, "Network News Transfer    Proposed
+        Protocol: "A Proposed Standard for the Stream-   standard
+        Based Transmission of News", RFC 977, January
+        1986.
+[16]    1848  PS   S. Crocker, N. Freed, J. Galvin,      Proposed
+        S. Murphy, "MIME Object Security Services",      standard
+        RFC 1848, March 1995.
+
+[17]    J. Myers, M. Rose: The Content-MD5 Header        Draft
+        field Header field, RFC 1864, October 1995.      standard
+
+[18]    M. Horton, UUCP mail interchange format          Not an offi-
+        standard, RFC 976, Januari 1986.                 cial IETF
+                                                         standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[19]    T. Berners-Lee, R. Header fielding, H.           Informatio
+        Frystyk: Hypertext Transfer Protocol --          nal
+        HTTP/1.0, RFC 1945.
+
+[20]    G. Vaudreuil: Voice Profile for Internet         Experimental
+        Mail, RFC 1911, February 1996.
+
+[21]    H. Spencer: News Article Format and              Not even an
+        Transmission, June 1994,                         RFC, but
+        FTP://zoo.toronto.edu/pub/news.ps.Z              still widely
+        FTP://zoo.toronto.edu/pub/news.txt.Z             used and
+                                                         partly
+        This document is often referenced under the      almost a de-
+        name "son-of-RFC1036".                           facto
+                                                         standard for
+                                                         Usenet News
+
+[23]    PICS Label Distribution Label Syntax and         Other
+        Communication Protocols, World Wide Web          standard
+        Consortium, October 1996.
+
+[24]    Eudora Pro Macintosh User Manual, Qualcomm       Non-standard
+        Inc., 1988-1995.
+
+[25]    C. Newman: Originator-Info Message Header        Non-standard
+        field. work in progress, July 1997.
+
+[26]    Grant Neufeld and Joshua D. Baer: The Use of     Proposed
+        URLs as Meta-Syntax for Core Mail List           standard
+        Commands and their Transport through Message
+        Header fields, RFC 2369, July 1998..
+
+
+                          6. Author's address
+
+Jacob Palme                     Phone: +46-8-16 16 67
+Stockholm University/KTH        Fax: +46-8-783 08 29
+Electrum 230                    E-mail: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
+
+                             Appendix A:
+Header fields sorted by Internet RFC document in which they appear.
+
+RFC 822
+-------
+
+bcc
+cc
+Comments
+Date
+From
+In-Reply-To
+Keywords
+Message-ID
+Received
+References
+Reply-To
+Resent-
+Resent-bcc
+Resent-cc
+Resent-Date
+Resent-From
+Resent-From
+Resent-Message-ID
+Resent-Reply-To
+Resent-To
+Return-Path
+Sender
+Sender
+Subject
+To
+
+RFC 976
+-------
+
+"From " (followed by space, not colon (:")
+
+
+RFC 1036
+--------
+
+Approved
+Control
+Distribution
+Expires
+Followup-To
+Lines
+Newsgroups
+Organization
+Path
+Summary
+Xref
+
+RFC 1049
+--------
+
+Content-Type
+
+RFC 1327
+--------
+
+Alternate-recipient
+Auto-Forwarded
+Autoforwarded
+Content-Identifier
+Content-Return
+Conversion
+Conversion-With-Loss
+Delivery-Date
+Discarded-X400-IPMS-Extensions
+Discarded-X400-MTS-Extensions
+Disclose-Recipients
+DL-Expansion-History
+Expiry-Date
+Generate-Delivery-Report
+Importance
+Incomplete-Copy
+Language
+Message-Type Delivery
+Obsoletes
+Original-Encoded-Information-Types
+Prevent-NonDelivery-Report
+Priority
+Reply-By
+Report
+Sensitivity
+
+
+RFC 1505
+--------
+
+Encoding
+
+
+RFC 2045
+--------
+
+Content-Description
+Content-ID
+Content-Transfer-Encoding
+Content-Type
+MIME-Version
+
+RFC 1806
+--------
+
+Content-Disposition
+
+RFC 1864
+--------
+
+Content-MD5
+
+RFC 1911
+--------
+
+Importance
+Sensitivity
+
+RFC 2110
+--------
+
+Content-Base
+Content-Location
+
+RFC 2369
+--------
+
+List-Archive
+List-Help
+List-Owner
+List-Post
+List-Software
+List-Subscribe
+List-Unsubscribe
+
+son-of-RFC1036 [21]
+-------------------
+
+Also-Control
+Article-Names
+Article-Updates
+See-Also
+Supersedes
+
+draft-ietf-receipt
+------------------
+
+Disposition-Notification-To
+Disposition-Notification-Options
+Original-Recipient
+
+
+World Wide Web Consortium (W3C) Recommendations
+-----------------------------------------------
+
+Pics-Label
+
+Not Internet standard
+---------------------
+
+"From " (not followed by ":")
+Apparently-to
+Content-Alias
+Content-Length
+Content-SGML-Entity
+Encoding
+Errors-To
+Fax
+Fcc
+For-Approval
+For-Comment
+For-Handling
+List-ID
+Mail-System-Version
+Mailer
+Organisation
+Originating-Client
+Originator-Info
+Phone
+Return-Receipt-To
+Speech-Act
+Status
+Supersedes
+Telefax
+Translated-By
+Translation-Of
+X-Envelope-From
+X-Envelope-To
+X-Mailer
+X-MIME-Autoconverted
+X-Newsreader
+X-No-Archive
+X-Priority
+X-Sender
+X-UIDL
+X-URI
+X-URL
+X-X-Sender
+X400-Content-Return
+
+
+                   Appendix B: Alphabetical index
+
+Section Header field
+------- ------------
+
+3.3     Also-Control
+3.3     Alternate-Recipient
+3.4     Apparently-To
+3.4     Approved
+3.6     Article-Names
+3.6     Article-Updates
+3.17    Auto-Forwarded
+3.4     bcc
+3.4     cc
+        Client, see Originating-Client
+        Comment, see For-Comment
+3.7     Comments
+3.6     Content-Alias
+3.6     Content-Base
+3.12    Content-Conversion
+3.7     Content-Description
+3.3     Content-Disposition
+3.6     Content-ID
+3.7     Content-Identifier
+3.10    Content-Language see also Language
+3.11    Content-Length
+3.6     Content-Location
+3.15    Content-MD5
+3.4     Content-Return
+3.13    Content-SGML-Entity
+3.13    Content-Transfer-Encoding
+3.13    Content-Type
+3.3     Control
+3.12    Conversion
+3.12    Conversion-With-Loss
+        Copy, see Incomplete-Copy
+3.8     Date
+        Date, see also Delivery-Date, Received, Expires, Expiry-
+        Date
+3.8     Delivery-Date
+        Delivery-Report, see Generate-Delivery-Report, Prevent-
+        Delivery-Report, Non-Delivery-Report, Content-Type
+        Description, see Content-Description
+3.17    Discarded-X400-IPMS-Extensions
+3.17    Discarded-X400-MTS-Extensions
+3.3     Disclose-Recipients
+        Disposition, see also Content-Disposition
+3.5     Disposition-Notification-Options
+3.5     Disposition-Notification-To
+3.4     Distribution
+3.2     DL-Expansion-History-Indication
+3.13    Encoding see also Content-Transfer-Encoding
+3.4     Errors-To
+3.8     Expires
+3.8     Expiry-Date
+        Extension see Discarded-X400-IPMS-Extensions, Discarded-
+        X400-MTS-Extensions
+3.4     Fax
+3.17    Fcc
+3.4     Followup-To
+3.4     For-Approval
+3.4     For-Comment
+3.4     For-Handling
+        Forwarded, see Auto-Forwarded
+3.4     From
+3.4     Generate-Delivery-Report
+        Handling, see For-Handling
+        History, see DL-Expansion-History-Indication
+        ID, see Content-ID and Message-ID
+        Identifier, see Content-ID and Message-ID
+3.9     Importance
+3.6     In-Reply-To
+3.9     Incomplete-Copy
+3.7     Keywords
+        Label, see PICS-Label
+3.10    Language see also Content-Language
+        Length see Content-Length
+3.11    Lines
+3.16    List-Archive
+3.16    List-Help
+3.16    List-ID
+3.16    List-Owner
+3.16    List-Post
+3.16    List-Software
+3.16    List-Subscribe
+3.16    List-Unsubscribe
+        Loss, see Conversion-With-Loss
+3.4     Mail-System-Version see also X-mailer
+3.4     Mailer
+        MD5 see Content-MD5
+3.6     Message-ID
+3.13    Message-Type
+3.3     MIME-Version
+3.4     Newsgroups
+        Newsreader, see X-Newsreader
+3.6     Obsoletes
+3.7     Organisation
+3.7     Organization
+3.3     Original-Encoded-Information-Types
+3.6     Original-Recipient
+3.4     Originating-Client
+3.4     Originator-Info see also Sender
+3.2     Path
+3.4     Phone
+3.9     PICS-Label
+3.9     Precedence
+3.4     Prevent-NonDelivery-Report
+3.9     Priority
+3.2     Received
+        Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
+        Recipient
+3.6     References
+3.8     Reply-By
+3.4     Reply-To, see also In-Reply-To, References
+3.14    Resent-
+        Return see also Content-Return
+3.2     Return-Path
+3.5     Return-Receipt-To
+3.6     See-Also
+3.4     Sender
+3.9     Sensitivity
+3.17    Speech-Act
+3.17    Status
+3.7     Subject
+3.7     Summary
+3.6     Supersedes
+3.4     Telefax
+3.4     To
+        Transfer-Encoding see Content-Transfer-Encoding
+3.6     Translated-By
+3.6     Translation-Of
+        Type see Content-Type, Message-Type, Original-Encoded-
+        Information-Types
+        Version, see MIME-Version, X-Mailer
+3.4     X-Envelope-From
+3.4     X-Envelope-To
+3.16    X-List-Host
+3.16    X-Listserver
+3.4     X-Mailer see also Mail-System-Version
+3.13    X-MIME-Autoconverted
+3.4     X-Newsreader
+3.17    X-No-Archive
+3.9     X-Priority
+3.4     X-Sender see also Originator-Info
+3.6     X-UIDL
+3.6     X-URI
+3.6     X-URL see also Content-Location
+3.4     X-X-Sender see also Originator-Info
+3.4     X400-Content-Return
+3.15    Xref
diff --git a/Documentation/en/I-D/draft-palme-mailext-headers-02.txt b/Documentation/en/I-D/draft-palme-mailext-headers-02.txt
new file mode 100644
index 00000000..ee5d2448
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-mailext-headers-02.txt
@@ -0,0 +1,1699 @@
+Network Working Group                                     Jacob Palme
+Internet Draft                               Stockholm University/KTH
+draft-palme-mailext-headers-02.txt                             Sweden
+Category: Informational                            Date: October 1999
+Revision of: RFC 2076                             Expires: March 1999
+
+
+
+                  Common Internet Message Header Fields
+
+                        Status of this Memo
+
+This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright (C) The Internet Society 1998. All Rights Reserved.
+
+                            Abstract
+
+This memo contains tables of commonly occurring header fields in
+headings of e-mail messages. The document compiles information from
+other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC
+1766, RFC 1806, RFC 1864, RFC 1911 and RFC 2045. A few commonly
+occurring header fields which are not defined in RFCs are also
+included. For each header field, the memo gives a short description and
+a reference to the RFC in which the header field is defined.
+
+                  Changes since previous version
+
+This document is a revision of RFC 2076. The following new header
+fields, not included in RFC 2076, have been added:
+Also-Control,  Content-Alias, Content-Class, Content-Conversion,
+Content-Features, Disposition-Notification-Options, Disposition-
+Notification-To, Expiry-Date, For-Approval, List-Archive, List-Digest,
+List-Help, List-ID, List-Owner, List-Post, List-Software, List-
+Subscribe, List-Unsubscribe, List-URL, Original-Recipient, Originator,
+Originator-Info, Path, PICS-Label, Read-Receipt-To, Registered-Mail-
+Reply-Requested-By, Replaces, Retur-Receipt-Requested, Speech-Act,
+Translated-By. Translation-Of, X-Confirm-Reading-To, X-Envelope-From, X-
+Envelope-To, X-Face, X-List-Host, X-Listserver, X-MIME-Autoconverted, X-
+No-Archive, X-OriginalArrivalTime, X-Priority, X-Sender, X-X-Sender, X-
+UIDL, X-URL, X-URI.
+
+The latest, revised version of this document is available in plain
+text, HTML and Adobe Acrobat format at URL
+http://www.dsv.su.se/jpalme/ietf/jp-ietf-home.html#mail-headers
+
+
+
+                         Table of contents
+
+     Abstract
+1. Introduction
+2. Use of gatewaying header fields
+3. Table of header fields
+     3.1 Phrases used in the tables
+     3.2 Trace information
+     3.3 Format and control information
+     3.4 Sender and recipient indication
+     3.5 Response control
+     3.6 Message identification and referral header fields
+     3.7 Other textual header fields
+     3.8 Header fields containing dates and times
+     3.9 Quality information
+     3.10 Language information
+     3.11 Size information
+     3.12 Conversion control
+     3.13 Encoding information
+     3.14 Resent-header fields
+     3.15 Security and reliability
+     3.16 Mailing list control
+     3.17 Miscellaneous
+4. Acknowledgments
+Copyright and disclaimer
+5. References
+6. Author's address
+Appendix A: Header fields sorted by Internet RFC document in
+which they appear.
+     RFC 822
+     RFC 976
+     RFC 1036
+     RFC 1049
+     RFC 1327
+     RFC 1505
+     RFC 2045
+     RFC 1806
+     RFC 1911
+     RFC 2110
+     RFC 2369
+     son-of-RFC1036 [21]
+     draft-ietf-receipt
+     World Wide Web Consortium (W3C) Recommendations
+     Not Internet standard
+Appendix B: Alphabetical index
+
+
+                         1. Introduction
+
+Many different Internet standards and RFCs define header fields which
+may occur on Internet Mail Messages and Usenet News Articles. The
+intention of this document is to list all such header fields in one
+document as an aid to people developing message systems or interested
+in Internet Mail standards.
+
+The document contains all header fields which the author has found in
+the following Internet standards: RFC 822 [2], RFC 1036 [3], RFC 1123
+[5], RFC 1327 [7], RFC 1496 [8], RFC 2045 [11], RFC 1766 [12], RFC 1806
+[14], RFC 1864[17] and RFC 1911[20]. Note in particular that heading
+attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 [16]) are
+not included. PEM and MOSS header fields only appear inside the body of
+a message, and thus are not header fields in the RFC 822 sense. Mail
+attributes in envelopes, i.e. attributes controlling the message
+transport mechanism between mail and news servers, are not included.
+This means that attributes from SMTP [1], UUCP [18] and NNTP [15] are
+mainly not covered either. Headings used only in HTTP [19] are not
+included yet, but may be included in future version of this memo. Some
+additional header fields which often can be found in e-mail headings
+but are not part of any Internet standard are also included.
+
+For each header field, the document gives a short description and a
+reference to the Internet standard or RFC, in which they are defined.
+
+The header field names given here are spelled the same way as when they
+are actually used. This is usually American but sometimes English
+spelling.  One header field in particular, "Organisation/Organization",
+occurs in e-mail header fields sometimes with the English and other
+times with the American spelling.
+
+The following words are used in this memo with the meaning specified
+below:
+
+heading           Formatted text at the top of a message, ended by a
+                  blank line
+
+header field      One field in the heading, beginning with a field
+                  name, colon, and followed by the field value(s). The
+                  words "heading field" and "header" are also
+                  sometimes used with this meaning.
+
+It is my intention to continue updating this document after its
+publication as an RFC. The latest version, which may be more up-to-date
+(but also less fully checked out) will be kept available for
+downloading from URL
+http://www.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html
+http://www.dsv.su.se/~jpalme/ietf/mail-attributes.html and
+http://www.dsv.su.se/~jpalme/ietf/mail-attributes.pdf
+
+Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
+header fields which should be included in this memo but are not.
+
+
+                 2. Use of gatewaying header fields
+
+RFC 1327 defines a number of new header fields in Internet mail, which
+are defined to map header fields which X.400 has but which were
+previously not standardized in Internet mail. The fact that a header
+field occurs in RFC 1327 indicates that it is recommended for use in
+gatewaying messages between X.400 and Internet mail, but does not mean
+that the header field is recommended for messages wholly within
+Internet mail. Some of these header fields may eventually see
+widespread implementation and use in Internet mail, but at the time of
+this writing (1996) they are not widely implemented or used.
+
+Header fields defined only in RFC 1036 for use in Usenet News sometimes
+appear in mail messages, either because the messages have been
+gatewayed from Usenet News to e-mail, or because the messages were
+written in combined clients supporting both e-mail and Usenet News in
+the same client. These header fields are not standardized for use in
+Internet e-mail and should be handled with caution by e-mail agents.
+
+
+                      3. Table of header fields
+
+3.1 Phrases used in the tables
+
+"not for general        Used to mark header fields which are defined
+usage"                  in RFC 1327 for use in messages from or to
+                        Internet mail/X.400 gateways. These header
+                        fields have not been standardized for general
+                        usage in the exchange of messages between
+                        Internet mail-based systems.
+
+"not standardized       Used to mark header fields defined only in RFC
+for use in e-mail"      1036 for use in Usenet News. These header
+                        fields have no standard meaning when appearing
+                        in e-mail, some of them may even be used in
+                        different ways by different software. When
+                        appearing in e-mail, they should be handled
+                        with caution. Note that RFC 1036, although
+                        generally used as a de-facto standard for
+                        Usenet News, is not an official IETF standard
+                        or even on the IETF standards track.
+
+"non-standard"          This header field is not specified in any of
+                        referenced RFCs which define Internet
+                        protocols, including Internet Standards, draft
+                        standards or proposed standards. The header
+                        field appears here because it often appears in
+                        e-mail or Usenet News. Usage of these header
+                        fields is not in general recommended. Some
+                        header field proposed in ongoing IETF
+                        standards development work, but not yet
+                        accepted, are also marked in this way.
+
+"discouraged"           This header field, which is non-standard, is
+                        known to create problems and should not be
+                        generated. Handling of such header fields in
+                        incoming mail should be done with great
+                        caution.
+
+"controversial"         The meaning and usage of this header field is
+                        controversial, i.e. different implementors
+                        have chosen to implement the header field in
+                        different ways. Because of this, such header
+                        fields should be handled with caution and
+                        understanding of the different possible
+                        interpretations.
+
+"experimental"          This header field is used for newly defined
+                        header fields, which are to be tried out
+                        before entering the IETF standards track.
+                        These should only be used if both
+                        communicating parties agree on using them. In
+                        practice, some experimental protocols become
+                        de-facto-standards before they are made into
+                        IETF standards.
+
+3.2 Trace information
+
+Used to convey the information       Return-Path:    RFC 821,
+from the MAIL FROM envelope                          RFC 1123: 5.2.13.
+attribute in final delivery, when
+the message leaves the SMTP
+environment in which "MAIL FROM"
+is used.
+
+Trace of MTAs which a message has    Received:       RFC 822: 4.3.2,
+passed.                                              RFC 1123: 5.2.8.
+
+List of MTAs passed.                 Path:           RFC 1036: 2.1.6,
+                                                     only in Usenet
+                                                     News, not in e-
+                                                     mail.
+
+Trace of distribution lists          DL-Expansion-   RFC 1327, not for
+passed.                              History:        general usage.
+
+3.3 Format and control information
+
+An indicator that this message is    MIME-Version:   RFC 2045: 4.
+formatted according to the MIME
+standard, and an indication of
+which version of MIME is
+utilized.
+
+Only in Usenet News, contains        Control:        RFC 1036: 2.1.6,
+commands to be performed by News                     only in Usenet
+agents.                                              News, not in e-
+                                                     mail.
+
+Special Usenet News commands and     Also-Control:   son-of-RFC1036
+a normal article at the same                         [21], non-
+time.                                                standard, only in
+                                                     Usenet News, not
+                                                     in e-mail
+
+Which body part types occur in       Original-       RFC 1327, not for
+this message.                        Encoded-        general usage.
+                                     Information-
+                                     Types:
+
+Controls whether this message may    Alternate-      RFC 1327, not for
+be forwarded to alternate            Recipient:      general usage.
+recipients such as a postmaster
+if delivery is not possible to
+the intended recipient. Default:
+Allowed.
+
+Whether recipients are to be told    Disclose-       RFC 1327, not for
+the names of other recipients of     Recipients:     general usage.
+the same message. This is
+primarily an X.400 facility. In
+X.400, this is an envelope
+attribute and refers to
+disclosure of the envelope
+recipient list. Disclosure of
+other recipients is in Internet
+mail done via the To:, cc: and
+bcc: header fields.
+
+Whether a MIME body part is to be    Content-        RFC 1806,
+shown inline or is an attachment;    Disposition:    experimental
+can also indicate a suggested
+filename for use when saving an
+attachment to a file.
+
+3.4 Sender and recipient indication
+
+Authors or persons taking            From:           RFC 822: 4.4.1,
+responsibility for the message.                      RFC 1123: 5.2.15-
+                                                     16, 5.3.7,
+Note difference from the "From "                     RFC 1036 2.1.1
+header field (not followed by
+":") below.
+
+
+(1) This header field should         From (not       not standardized
+never appear in e-mail being         followed by a   for use in e-mail
+sent, and should thus not appear     colon)
+in this memo. It is however
+included, since people often ask
+about it.
+
+This header field is used in the
+so-called Unix mailbox format,
+also known as Berkely mailbox
+format or the MBOX format. This
+is a format for storing a set of
+messages in a file. A line
+beginning with "From " is used to
+separate successive messages in
+such files.
+
+This header field will thus
+appear when you use a text editor
+to look at a file in the Unix
+mailbox format. Some mailers also
+use this format when printing
+messages on paper.
+
+The information in this header
+field should NOT be used to find
+an address to which replies to a
+message are to be sent.
+
+(2) Used in Usenet News mail         From            RFC 976: 2.4 for
+transport, to indicate the path      or              use in Usenet News
+through which an article has gone    >From
+when transferred to a new host.      (not followed
+                                     by a colon)
+Sometimes called "From_" header
+field.
+
+Name of the moderator of the         Approved:       RFC 1036: 2.2.11,
+newsgroup to which this article                      not standardized
+is sent; necessary on an article                     for use in e-mail.
+sent to a moderated newsgroup to
+allow its distribution to the
+newsgroup members. Also used on
+certain control messages, which
+are only performed if they are
+marked as Approved.
+
+The person or agent submitting       Sender:         RFC 822: 4.4.2,
+the message to the network, if                       RFC 1123: 5.2.15-
+other than shown by the From:                        16, 5.3.7, RFC
+header field. Should be                              1036.
+authenticated,
+according to RFC 822, but what
+kind of authentication is not
+clear. Some implementations
+expect that the e-mail address
+used in this field can be used to
+reach the sender, others do not.
+See also "X-Sender".
+
+Sometimes used in Usenet News in     Originator:     Non-standard
+similar ways to "Sender:"
+
+Some mail software expect            X-Sender:       Non-standard
+"Sender:" to be an e-mail address
+which you can send mail to.
+However, some mail software has
+as the best authenticated sender
+a POP or IMAP account, which you
+might not be able to send to.
+Because of this, some mail
+software put the POP or IMAP
+account into an X-sender header
+field instead of a Sender header
+field, to indicate that you may
+not be able to send e-mail to
+this address. See also "X-X-
+Sender".
+
+Another use of" X-Sender:" is
+that some e-mail software, which
+wants to insert a "Sender:"
+header, will first change an
+existing "Sender:" header to "X-
+Sender". This use is actually
+often the same as that described
+in the previous paragraph, since
+the new "Sender:" is added
+because it is better
+authenticated than the old value.
+
+Even though some systems put the     X-X-Sender:     Non-standard
+POP or IMAP account name into the
+"X-Sender:" instead of the Sender
+header field, some mail software
+tries to send to the "X-Sender:"
+too. To stop this, some systems
+have begun to use "X-X-Sender:"
+to indicate an authentication of
+the sender which might not be
+useable to send e-mail to. See
+also "Originator-Info:"
+
+Contains information about the       Originator-     Non-standard [25]
+authentication of the originator     Info:
+in a format which is not easily
+used to send email to, to avoid
+the problems with "Sender" and "X-
+Sender".
+
+48x48 bitmap with picture of the     X-Face          Non-Standard
+sender of this message.
+
+Primary recipients.                  To:             RFC 822: 4.5.1,
+                                                     RFC 1123: 5.2.15-
+                                                     16, 5.3.7.
+
+Secondary, informational             cc:             RFC 822: 4.5.2,
+recipients. (cc = Carbon Copy)                       RFC 1123. 5.2.15-
+                                                     16, 5.3.7.
+
+Recipients not to be disclosed to    bcc:            RFC 822: 4.5.3,
+other recipients. (bcc = Blind                       RFC 1123: 5.2.15-
+Carbon Copy).                                        16, 5.3.7.
+
+Primary recipients, who are          For-Handling:   Non-standard
+requested to handle the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Comment:    Non-standard
+requested to comment on the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Approval:   Non-standard
+requested to approve the
+information in this message or
+its attachments.
+
+In Usenet News: group(s) to which    Newsgroups:     RFC 1036: 2.1.3,
+this article was posted.                             not standardized
+Some systems provide this header                     and controversial
+field also in e-mail although it                     for use in e-mail.
+is not standardized there.
+
+Unfortunately, the header field
+can appear in e-mail with three
+different and contradictory
+meanings:
+
+(a) Indicating the newsgroup
+recipient of an article/message
+sent to both e-mail and Usenet
+News recipients.
+
+(b) In a message adressed to some
+mail to news gateways, indicates
+the newsgroup(s) that the message
+is to be posted to.
+
+(c) In a personally addressed
+reply to an article in a news-
+group, indicating the newsgroup
+in which this discussion
+originated.
+
+Inserted by Sendmail when there      Apparently-     Non-standard,
+is no "To:" recipient in the         To:             discouraged,
+original message, listing                            mentioned in
+recipients derived from the                          RFC 1211.
+envelope into the message
+heading. This behavior is not
+quite proper, MTAs should not
+modify headings (except inserting
+Received lines), and it can in
+some cases cause Bcc recipients
+to be wrongly divulged to non-Bcc
+recipients.
+
+Geographical or organizational       Distribution:   RFC 1036: 2.2.7,
+limitation on where this article                     not standardized
+can be distributed. Value can be                     for use in e-mail.
+a compete or incomplete domain
+names, also various special
+values are accepted like "world",
+"usenet", "USA", etc.
+
+Fax number of the originator.        Fax:,           Non-standard.
+                                     Telefax:
+
+Phone number of the originator.      Phone:          Non-standard.
+
+If the recipient in the envelope     X-Envelope-To   Non-standard.
+(SMTP "MAIL FROM") is not
+included in the CC list, some
+mail servers add this to the
+RFC822 header field as an aid to
+clients which would otherwise not
+be able to display the envelope
+recipients.
+
+If the sender in the envelope        X-Envelope-     Non-standard.
+(SMTP "RCTP TO") is not the same     From
+as the senders in the "From" or
+"Sender" RFC822 header fields,
+some mail servers add this to the
+RFC822 header fields as an aid to
+clients which would otherwise not
+be able to display this
+information.
+
+Information about the client         Mail-System-    Non-standard.
+software of the originator.          Version:,
+                                     Mailer:,
+                                     Originating-
+                                     Client:, X-
+                                     Mailer, X-
+                                     Newsreader
+
+3.5 Response control
+
+This header field is meant to        Reply-To:       RFC 822: 4.4.3,
+indicate where the sender wants                      RFC 1036: 2.2.1
+replies to go. Unfortunately,                        controversial.
+this is ambiguous, since there
+are different kinds of replies,
+which the sender may wish to go
+to different addresses. In
+particular, there are personal
+replies intended for only one
+person, and group replies,
+intended for the whole group of
+people who read the replied-to
+message (often a mailing list,
+anewsgroup name cannot appear
+here because of different syntax,
+see "Followup-To" below.).
+
+Some mail systems use this header
+field to indicate a better form
+of the e-mail address of the
+sender. Some mailing list
+expanders puts the name of the
+list in this header field. These
+practices are controversial. The
+personal opinion of the author of
+this RFC is that this header
+field should be avoided except in
+special cases, but this is a
+personal opinion not shared by
+all specialists in the area.
+
+Used in Usenet News to indicate      Followup-To:    RFC 1036: 2.2.3,
+that future discussions (=follow-                    not standardized
+up) on an article should go to a                     for use in e-mail.
+different set of newsgroups than
+the replied-to article. The most
+common usage is when an article
+is posted to several newsgroups,
+and further discussions is to
+take place in only one of them.
+
+In e-mail, this header field may
+occur in a message which is sent
+to both e-mail and Usenet News,
+to show where follow-up in Usenet
+news is wanted. The header field
+does not say anything about where
+follow-up in e-mail is to be
+sent.
+
+The value of this header field
+should be one or more newsgroup
+names.
+
+The special value "poster" as in
+"Followup-To: poster" means that
+replies are to be sent as e-mail
+to the author only.
+
+Address to which notifications       Errors-To:,     Non-standard,
+are to be sent and a request to      Return-         discouraged.
+get delivery notifications.          Receipt-To:,
+Internet standards recommend,        Read-Receipt-
+however, the use of MAIL FROM and    To:, X-
+Return-Path, not Errors-To, for      Confirm-
+where delivery notifications are     reading-to:,
+to be sent.                          Return-
+                                     Receipt-
+                                     Requested,
+                                     Register-Mail-
+                                     Reply-
+                                     Requested-By:
+
+Whether non-delivery report is       Prevent-        RFC 1327, not for
+wanted at delivery error. Default    NonDelivery-    general usage.
+is to want such a report.            Report:
+
+Whether a delivery report is         Generate-       RFC 1327, not for
+wanted at successful delivery.       Delivery-       general usage.
+Default is not to generate such a    Report:
+report.
+
+Indicates whether the content of     Content-        RFC 1327, not for
+a message is to be returned with     Return:         general usage.
+non-delivery notifications.
+
+Possible future change of name       X400-Content-   non-standard
+for "Content-Return:"                Return:
+
+Indicate that the sender wants a     Disposition-    RFC 2298
+dispoisition notification when       Notification-
+this message is received (read,      To
+processed, etc.) by its
+receipents.
+
+For future options on disposition    Disposition-    RFC 2298
+notifications.                       Notification-
+                                     Options
+
+
+Original Recipient information       Original-       RFC 2298
+for inclusion in disposition         Recipient
+notifications.
+
+3.6 Message identification and referral header fields
+
+Unique ID of this message.           Message-ID:     RFC 822: 4.6.1
+                                                     RFC 1036: 2.1.5.
+
+Unique ID of one body part of the    Content-ID:     RFC 2045: 7.
+content of a message.
+
+Base to be used for resolving        Content-Base:   RFC 2110
+relative URIs within this content
+part.
+
+URI with which the content of        Content-        RFC 2110
+this content part might be           Location:
+retrievable.
+
+Used in addition to Content-         Content-        Work in progress
+Location if this content part can    Alias:
+be retrieved through more than
+one URI. Only one of them is
+allowed in the Content-Location,
+the other can be specified in
+Content-Alias.
+
+Sometimes used with the same         X-URL:          Non-standard
+meaning as "Content-Location:",
+sometimes to indicate the web
+home page of the sender or of his
+organisation.
+
+Similar usage as "X-URL". The URI    X-URI:          Non-standard
+can be either a URL or a URN.
+URNs are meant to become more
+persistent references to
+resources than URLs.
+
+Reference to message which this      In-Reply-To:    RFC 822: 4.6.2.
+message is a reply to.
+
+In e-mail: reference to other        References:     RFC 822: 4.6.3
+related messages, in Usenet News:                    RFC 1036: 2.1.5.
+reference to replied-to-articles.
+
+References to other related          See-Also:       Son-of-RFC1036
+articles in Usenet News.                             [21], non-standard
+
+Reference to previous message        Obsoletes:      RFC 1327, not for
+being corrected and replaced.                        general usage.
+Compare to "Supersedes:" below.
+This field may in the future be
+replaced with "Supersedes:".
+
+Commonly used in Usenet News in      Supersedes:     son-of-RFC1036
+similar ways to the "Obsoletes"                      [21], non-standard
+header field described above. In
+Usenet News, however, Supersedes
+causes a full deletion of the
+replaced article in the server,
+while "Supersedes" and
+"Obsoletes" in e-mail is
+implemented in the client and
+often does not remove the old
+version of the text.
+
+Still another name for similar       Replaces:       non-standard,
+functionality as for "Obsoletes:"                    proposed in IETF
+and "Supersedes:". This may                          USEFOR working
+become the most recommended                          group
+header in the future, but is
+still under discussion in IETF
+standards development work.
+
+Unique identifier for a message,     X-UIDL:         non-standard
+local to a particular local
+mailbox store. The UIDL
+identifier is defined in the POP3
+standard, but not the "X-UIDL:"
+header.
+
+Only in Usenet News, similar to      Article-        son-of-RFC1036
+"Supersedes:" but does not cause     Updates:        [21], non-standard
+the referenced article to be
+physically deleted.
+
+Reference to specially important     Article-        son-of-RFC1036
+articles for a particular Usenet     Names:          [21], non-standard
+Newsgroup.
+
+Reference to the Message-ID of a     Translation-    non-standard
+message, which the current           Of:
+message is a translation of.
+
+Mailbox of the person who made       Translated-     non-standard
+the translation.                     By:
+
+3.7 Other textual header fields
+
+Search keys for data base            Keywords:       RFC 822: 4.7.1
+retrieval.                                           RFC 1036: 2.2.9.
+
+Title, heading, subject. Often       Subject:        RFC 822: 4.7.1
+used as thread indicator for                         RFC 1036: 2.1.4.
+messages replying to or
+commenting on other messages.
+
+Comments on a message.               Comments:       RFC 822: 4.7.2.
+
+Description of a particular body     Content-        RFC 2045: 8.
+part of a message, for example a     Description:
+caption for an image body part.
+
+Organization to which the sender     Organization:   RFC 1036: 2.2.8,
+of this article belongs.                             not standardized
+                                                     for use in e-mail.
+
+See Organization above.              Organisation:   Non-standard.
+
+Short text describing a longer       Summary:        RFC 1036: 2.2.10,
+article. Warning: Some mail                          not standardized
+systems will not display this                        for use in e-mail,
+text to the recipient. Because of                    discouraged.
+this, do not use this header
+field for text which you want to
+ensure that the recipient gets.
+
+A text string which identifies       Content-        RFC 1327, not for
+the content of a message.            Identifier:     general usage.
+
+3.8 Header fields containing dates and times
+
+The time when a message was          Delivery-       RFC 1327, not for
+delivered to its recipient.          Date:           general usage.
+
+In Internet, the date when a         Date:           RFC 822: 5.1,
+message was written, in X.400,                       RFC 1123: 5.2.14
+the time a message was submitted.                    RFC 1036: 2.1.2.
+Some Internet mail systems also
+use the date when the message was
+submitted.
+
+A suggested expiration date. Can     Expires:        RFC 1036: 2.2.4,
+be used both to limit the time of                    not standardized
+an article which is not                              for use in e-mail.
+meaningful after a certain date,
+and to extend the storage of
+important articles.
+
+Time at which a message loses its    Expiry-Date:    RFC 1327, not for
+validity. This field may in the                      general usage.
+future be replaced by "Expires:".
+
+Latest time at which a reply is      Reply-By:       RFC 1327, not for
+requested (not demanded).                            general usage.
+
+Time when this message was           X-OriginalArr   Non-standard
+delivered into the message           ivalTime:
+transport system (usually the
+same time as in the last
+"Received:" header)
+
+3.9 Quality information
+
+Can be "normal", "urgent" or "non-   Priority:       RFC 1327, not for
+urgent" and can influence                            general usage.
+transmission speed and delivery.
+
+Values: 1 (Highest), 2 (High), 3     X-Priority:     Non-standard [24]
+(Normal), 4 (Low), 5 (Lowest). 3
+(Normal) is default if the field
+is omitted.
+
+Sometimes used as a priority         Precedence:     Non-standard,
+value which can influence                            controversial.
+transmission speed and delivery.
+Common values are "bulk" and
+"first-class". Other uses is to
+control automatic replies and to
+control return-of-content
+facilities, and to stop mailing
+list loops.
+
+A hint from the originator to the    Importance:     RFC 1327 and
+recipients about how important a                     RFC 1911,
+message is. Values: High, normal                     experimental
+or low. Not used to control
+transmission speed.
+
+How sensitive it is to disclose      Sensitivity:    RFC 1327 and
+this message to other people than                    RFC 1911,
+the specified recipients. Values:                    experimental
+Personal, private, company
+confidential. The absence of this
+header field in messages
+gatewayed from X.400 indicates
+that the message is not
+sensitive.
+
+Body parts are missing.              Incomplete-     RFC 1327, not for
+                                     Copy:           general usage.
+
+Ratings label to control             PICS-Label:     REC-PICS-labels,
+selection (filtering) of messages                    W3C document [23].
+according to the PICS protocol.
+
+3.10 Language information
+
+Can include a code for the           Language:       RFC 1327, not for
+natural language used in a                           general usage.
+message, e.g. "en" for English.
+
+Can include a code for the           Content-        RFC 1766, proposed
+natural language used in a           Language:       standard.
+message, e.g. "en" for English.
+
+3.11 Size information
+
+Inserted by certain mailers to       Content-        Non-standard,
+indicate the size in bytes of the    Length:         discouraged.
+message text. This is part of a
+format some mailers use when
+showing a message to its users,
+and this header field should not
+be used when sending a message
+through the net. The use of this
+header field in transmission of a
+message can cause several
+robustness and interoperability
+problems.
+
+Size of the message.                 Lines:          RFC 1036: 2.2.12,
+                                                     not standardized
+                                                     for use in e-mail.
+
+3.12 Conversion control
+
+The body of this message may not     Conversion:     RFC 1327, not for
+be converted from one character                      general usage.
+set to another. Values:
+Prohibited and allowed.
+
+Non-standard variant of              Content-        Non-standard.
+Conversion: with the same values.    Conversion:
+
+The body of this message may not     Conversion-     RFC 1327, not for
+be converted from one character      With-Loss:      general usage.
+set to another if information
+will be lost. Values: Prohibited
+and allowed.
+
+3.13 Encoding information
+
+Format of content (character set     Content-Type:   RFC 1049,
+etc.) Note that the values for                       RFC 1123: 5.2.13,
+this header field are defined in                     RFC 1766: 4.1
+different ways in RFC 1049 and in                    RFC 2045: 5.
+MIME (RFC 2045), look for the
+"MIME-version" header field to
+understand if Content-Type is to
+be interpreted according to RFC
+1049 or according to MIME. The
+MIME definition should be used in
+generating mail.
+
+RFC 1766 defines a parameter
+"difference" to this header
+field.
+
+Various other Content-Type define
+various additional parameters.
+For example, the parameter
+"charset" is mandatory for all
+textual Content-Types.
+
+Type information of the content      Content-        non-standard
+in some class hierarchy. Class       Class:
+hierarchies are commonly used to
+classify data structures in
+software development.
+
+Can give more detailed               Content-        non-standard
+information about the Content-       Features:
+Type. Example:
+
+(&  (color=binary)
+    (image-file-structure=TIFF-S)
+    (dpi=200)
+    (paper-size=A4)
+    (image-coding=MH)
+    (MRC-mode=0)
+    (ua-media=stationery) )
+
+This header is meant to be used
+when you can choose between
+different versions of a resource,
+such as when using
+multipart/atlernative.
+
+Information from the SGML entity     Content-SGML-   non-standard
+declaration corresponding to the     Entity:
+entity contained in the body of
+the body part.
+
+Coding method used in a MIME         Content-        RFC 2045: 6.
+message body.                        Transfer-
+                                     Encoding:
+
+Only used with the value             Message-Type:   RFC 1327, not for
+"Delivery Report" to indicates                       general usage.
+that this is a delivery report
+gatewayed from X.400.
+
+Used in several different ways by    Encoding:       RFC 1154,
+different mail systems. Some use                     RFC 1505,
+it for a kind of content-type                        experimental.
+information, some for encoding
+and length information, some for
+a kind of boundary information,
+some in other ways.
+
+Information about conversion of      X-MIME-         non-standard
+this message on the path from        Autoconverted:
+sender to recipient, like
+conversion between MIME encoding
+formats. Note: Auto-conversion
+may invalidate digital seals and
+signatures.
+
+3.14 Resent-header fields
+
+When manually forwarding a           Resent-Reply-   RFC 822: C.3.3.
+message, header fields referring     To:,
+to the forwarding, not to the        Resent-From:,
+original message.  Note: MIME        Resent-
+specifies another way of             Sender:,
+resending messages, using the        Resent-From:,
+"Message" Content-Type.              Resent-Date:,
+                                     Resent-To:,
+                                     Resent-cc:,
+                                     Resent-bcc:,
+                                     Resent-
+                                     Message-ID:
+
+3.15 Security and reliability
+
+Checksum of content to ensure        Content-MD5:    RFC 1864, proposed
+that it has not been modified.                       standard.
+
+Used in Usenet News to store         Xref:           RFC 1036: 2.2.13,
+information to avoid showing a                       only in Usenet
+reader the same article twice if                     News, not in e-
+it was sent to more than one                         mail.
+newsgroup. Only for local usage
+within one Usenet News server,
+should not be sent between
+servers.
+
+3.16 Mailing list control
+
+Contains URL to use to get a         List-           RFC 2369 [26]
+subscription to the mailing list     Subscribe
+from which this message was
+relayed.
+
+URL to use to get a subscription     List-Digest     Non-standard
+to the digest version of the
+mailing list from which this
+message was relayed.
+
+Contains URL to use to               List-           RFC 2369 [26]
+unsubscribe the mailing list from    Unsubscribe
+which this message was relayed.
+
+Contains URL to send e-mail to       List-Owner      RFC 2369 [26]
+the owner of the mailing list
+from which this message was
+relayed.
+
+Contains URL to use to get a         List-Help       RFC 2369 [26]
+information about the mailing
+list from which this message was
+relayed.
+
+Contains URL where information of    List-URL        Non-standard
+various kinds about the mailing
+list from which this message was
+relayed.
+
+Contains URL to use to send          List-Post       RFC 2369 [26]
+contributions to the mailing list
+from which this message was
+relayed.
+
+Contains URL to use to browse the    List-Archive    RFC 2369 [26]
+archives of the mailing list from
+which this message was relayed.
+
+Information about the software       List-Software   Non-standard, has
+used in a mailing list expander                      been considered
+through which this message has                       for inclusion in
+passed.                                              [26].
+
+Stores the URN of the mailing        List-ID         Non-standard, has
+list, through which this message                     been considered
+was distributed.                                     for inclusion in
+                                                     [26].
+
+Information about the server and     X-Listserver,   Non-standard.
+software used in a mailing list      X-List-Host     Recommended to use
+expander through which this                          "List-Software"
+message has passed. Warning:                         instead.
+"Listserv" is a trademark and
+should not be used for other than
+the "Listserv" product. Use,
+instead the "List-Software"
+header field.
+
+3.17 Miscellaneous
+
+Name of file in which a copy of      Fcc:            Non-standard.
+this message is stored.
+
+Has been automatically forwarded.    Autoforwarded   RFC 1327, not for
+                                     :               general usage.
+
+Can be used in Internet mail to      Discarded-      RFC 1327, not for
+indicate X.400 IPM extensions        X400-IPMS-      general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+
+Can be used in Internet mail to      Discarded-      RFC 1327, not for
+indicate X.400 MTS extensions        X400-MTS-       general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+
+This field is used by some mail      Status:         Non-standard,
+delivery systems to indicate the                     should never
+status of delivery for this                          appear in mail in
+message when stored. Common                          transit.
+values of this field are:
+
+U    message is not downloaded
+     and not deleted.
+
+R    message is read or
+     downloaded.
+
+O    message is old but not
+     deleted.
+
+D    to be deleted.
+
+N    new (a new message also
+     sometimes is distinguished
+     by not having any "Status:"
+     header field.
+
+Combinations of these characters
+can occur, such as "Status: OR"
+to indicate that a message is
+downloaded but not deleted.
+
+Do not archive this message in       X-No-Archive:   Non-standard
+publicly available archives.         Yes
+
+Speech act categoriztion of a        Speech-Act:     Non-standard
+message, examples of speeach acts
+are Question, Idea, More,
+Promise, Sad, Happy, Angry,
+summary, Decision
+
+
+                          4. Acknowledgments
+
+Harald Tveit Alvestrand, Ned Freed, Olle J„rnefors, Keith Moore, Nick
+Smith and several other people have helped me with compiling this list.
+I especially thank Ned Freed and Olle J„rnefors for their thorough
+review and many helpful suggestions for improvements. I alone take
+responsibility for any errors which may still be in the list.
+
+An earlier version of this list has been published as part of [13].
+
+
+                 Copyright and disclaimer
+
+The IETF takes no position regarding the validity or scope of
+any intellectual property or other rights that might be
+claimed to pertain to the implementation or use of the
+technology described in this document or the extent to which
+any license under such rights might or might not be available;
+neither does it represent that it has made any effort to
+identify any such rights. Information on the IETF's procedures
+with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims
+of rights made available for publication and any assurances of
+licenses to be made available, or the result of an attempt
+made to obtain a general license or permission for the use of
+such proprietary rights by implementors or users of this
+specification can be obtained from the IETF Secretariat."
+
+The IETF invites any interested party to bring to its
+attention any copyrights, patents or patent applications, or
+other proprietary rights which may cover technology that may
+be required to practice this standard. Please address the
+information to the IETF Executive Director.
+
+Copyright (C) The Internet Society (date). All Rights
+Reserved.
+
+This document and translations of it may be copied and
+furnished to others, and derivative works that comment on or
+otherwise explain it or assist in its implmentation may be
+prepared, copied, published and distributed, in whole or in
+part, without restriction of any kind, provided that the above
+copyright notice and this paragraph are included on all such
+copies and derivative works. However, this document itself may
+not be modified in any way, such as by removing the copyright
+notice or references to the Internet Society or other Internet
+organizations, except as needed for the purpose of developing
+Internet standards in which case the procedures for copyrights
+defined in the Internet Standards process must be followed, or
+as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will
+not be revoked by the Internet Society or its successors or
+assigns.
+
+
+                            5. References
+
+Ref.    Author, title                                    IETF status
+                                                         (July 1996)
+-----   ---------------------------------------------    -----------
+[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
+        STD 10, RFC 821, August 1982.                    Recommended
+
+[2]     D. Crocker: "Standard for the format of ARPA     Standard,
+        Internet text messages." STD 11, RFC 822,        Recommended
+        August 1982.
+
+[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
+        interchange of USENET messages", RFC 1036,       cial IETF
+        December 1987.                                   standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[4]     M. Sirbu: "A Content-Type header field header    Standard,
+        field for internet messages", RFC 1049, March    Recommended,
+        1988.                                            but can in
+                                                         the future
+                                                         be expected
+                                                         to be
+                                                         replaced by
+                                                         MIME
+
+[5]     R. Braden (editor): "Requirements for            Standard,
+        Internet Hosts -- Application and Support",      Required
+        STD-3, RFC 1123, October 1989.
+
+[6]     D. Robinson, R. Ullman: "Encoding Header         Non-standard
+        field for Internet Messages",RFC 1154,
+        April 1990.
+
+[7]     S. Hardcastle-Kille: "Mapping between            Proposed
+        X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
+        1327 May 1992.                                   elective
+
+[8]     H. Alvestrand & J. Romaguera: "Rules for         Proposed
+        Downgrading Messages from X.400/88 to            standard,
+        X.400/84 When MIME Content-Types are Present     elective
+        in the Messages", RFC 1496, August 1993.
+
+[9]     A. Costanzo: "Encoding Header field Header       Non-standard
+        field for Internet Messages", RFC 1154, April
+        1990.
+
+[10]    A. Costanzo, D. Robinson: "Encoding Header       Experimental
+        field Header field for Internet Messages",
+        RFC 1505, August 1993.
+
+[11]    N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
+        Internet Mail Extensions) Part One: Format of    Standard,
+        Internet Message Bodies. RFC 2945. November      elective
+        1996.
+
+[12]    H. Alvestrand: "Tags for the Identification      Proposed
+        of Languages", RFC 1766, February 1995.          standard,
+                                                         elective
+
+[13]    J. Palme: "Electronic Mail", Artech House        Non-standard
+        publishers, London-Boston January 1995.
+
+[14]    R. Troost, S. Dorner: "Communicating             Experimental
+        Presentation Information in Internet
+        Messages: The Content-Disposition Header
+        field", RFC 1806, June 1995.
+
+[15]    B. Kantor, P. Lapsley, "Network News Transfer    Proposed
+        Protocol: "A Proposed Standard for the Stream-   standard
+        Based Transmission of News", RFC 977, January
+        1986.
+[16]    1848  PS   S. Crocker, N. Freed, J. Galvin,      Proposed
+        S. Murphy, "MIME Object Security Services",      standard
+        RFC 1848, March 1995.
+
+[17]    J. Myers, M. Rose: The Content-MD5 Header        Draft
+        field Header field, RFC 1864, October 1995.      standard
+
+[18]    M. Horton, UUCP mail interchange format          Not an offi-
+        standard, RFC 976, Januari 1986.                 cial IETF
+                                                         standard,
+                                                         but in
+                                                         reality a de-
+                                                         facto
+                                                         standard for
+                                                         Usenet News
+
+[19]    T. Berners-Lee, R. Header fielding, H.           Informatio
+        Frystyk: Hypertext Transfer Protocol --          nal
+        HTTP/1.0, RFC 1945.
+
+[20]    G. Vaudreuil: Voice Profile for Internet         Experimental
+        Mail, RFC 1911, February 1996.
+
+[21]    H. Spencer: News Article Format and              Not even an
+        Transmission, June 1994,                         RFC, but
+        FTP://zoo.toronto.edu/pub/news.ps.Z              still widely
+        FTP://zoo.toronto.edu/pub/news.txt.Z             used and
+                                                         partly
+        This document is often referenced under the      almost a de-
+        name "son-of-RFC1036".                           facto
+                                                         standard for
+                                                         Usenet News
+
+[23]    PICS Label Distribution Label Syntax and         Other
+        Communication Protocols, World Wide Web          standard
+        Consortium, October 1996.
+
+[24]    Eudora Pro Macintosh User Manual, Qualcomm       Non-standard
+        Inc., 1988-1995.
+
+[25]    C. Newman: Originator-Info Message Header        Non-standard
+        field. work in progress, July 1997.
+
+[26]    Grant Neufeld and Joshua D. Baer: The Use of     Proposed
+        URLs as Meta-Syntax for Core Mail List           standard
+        Commands and their Transport through Message
+        Header fields, RFC 2369, July 1998..
+
+
+                          6. Author's address
+
+Jacob Palme                     Phone: +46-8-16 16 67
+Stockholm University/KTH        Fax: +46-8-783 08 29
+Electrum 230                    E-mail: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
+
+                             Appendix A:
+Header fields sorted by Internet RFC document in which they appear.
+
+RFC 822
+-------
+
+bcc
+cc
+Comments
+Date
+From
+In-Reply-To
+Keywords
+Message-ID
+Received
+References
+Reply-To
+Resent-
+Resent-bcc
+Resent-cc
+Resent-Date
+Resent-From
+Resent-From
+Resent-Message-ID
+Resent-Reply-To
+Resent-Sender
+Resent-To
+Return-Path
+Sender
+Subject
+To
+
+RFC 976
+-------
+
+"From " (followed by space, not colon (:")
+
+RFC 1049
+--------
+
+Content-Type
+
+RFC 1036
+--------
+
+Approved
+Control
+Distribution
+Expires
+Followup-To
+Lines
+Newsgroups
+Organization
+Path
+Summary
+Xref
+
+RFC 1049
+--------
+
+Content-Type
+
+RFC 1123
+--------
+
+Content-Type
+
+RFC 1327
+--------
+
+Alternate-recipient
+Auto-forwarded see Autoforwarded
+Autoforwarded
+Content-Identifier
+Content-Return
+Conversion
+Conversion-With-Loss
+Delivery-Date
+Discarded-X400-IPMS-Extensions
+Discarded-X400-MTS-Extensions
+Disclose-Recipients
+DL-Expansion-History
+Expiry-Date
+Generate-Delivery-Report
+Importance
+Incomplete-Copy
+Language
+Message-Type
+Obsoletes
+Original-Encoded-Information-Types
+Prevent-NonDelivery-Report
+Priority
+Reply-By
+Sensitivity
+
+RFC 1505
+--------
+
+Encoding
+
+RFC 1766
+--------
+
+Content-Language
+
+RFC 1806
+--------
+
+Content-Disposition
+
+RFC 1864
+--------
+
+Content-MD5
+
+RFC 1911
+--------
+
+Importance
+Sensitivity
+
+RFC 2045
+--------
+
+Content-Description
+Content-ID
+Content-Transfer-Encoding
+Content-Type
+MIME-Version
+
+RFC 2110
+--------
+
+Content-Base
+Content-Location
+
+RFC 2369
+--------
+
+List-Archive
+List-Help
+List-Owner
+List-Post
+List-Software
+List-Subscribe
+List-Unsubscribe
+
+son-of-RFC1036 [21]
+-------------------
+
+Also-Control
+Article-Names
+Article-Updates
+See-Also
+Supersedes
+
+draft-ietf-receipt
+------------------
+
+Disposition-Notification-To
+Disposition-Notification-Options
+Original-Recipient
+
+World Wide Web Consortium (W3C) Recommendations
+-----------------------------------------------
+
+Pics-Label
+
+Not Internet standard (as of September 1999)
+--------------------------------------------
+
+"From " (not followed by ":")
+Apparently-to
+Content-Alias
+Content-Class
+Content-Conversion
+Content-Features
+Content-Length
+Content-SGML-Entity
+Encoding
+Errors-To
+Fax
+Fcc
+For-Approval
+For-Comment
+For-Handling
+List-Digest
+List-ID
+List-URL
+Mail-System-Version
+Mailer
+Organisation
+Originating-Client
+Originator
+Originator-Info
+Phone
+Precedence
+Registered-Mail-Reply-Requested-By
+Replaces
+Return-Receipt-Requested
+Return-Receipt-To
+Read-Receipt-To
+Speech-Act
+Status
+Supersedes
+Telefax
+Translated-By
+Translation-Of
+X-Confirm-Reading-To
+X-Envelope-From
+X-Envelope-To
+X-Face
+X-List-Host
+X-Listserver
+X-Mailer
+X-MIME-Autoconverted
+X-Newsreader
+X-No-Archive
+X-OriginalArrivalTime
+X-Priority
+X-Sender
+X-UIDL
+X-URI
+X-URL
+X-X-Sender
+X400-Content-Return
+
+                   Appendix B: Alphabetical index
+
+Section Header field
+------- ------------
+
+3.3     Also-Control
+3.3     Alternate-Recipient
+3.4     Apparently-To
+3.4     Approved
+3.6     Article-Names
+3.6     Article-Updates
+        Auto-Forwarded see Autoforwarded
+3.17    Autoforwarded
+3.4     bcc
+3.4     cc
+        Client, see Originating-Client
+        Comment, see For-Comment
+3.7     Comments
+3.6     Content-Alias
+3.6     Content-Base
+3.13    Content-Class
+3.12    Content-Conversion
+3.7     Content-Description
+3.3     Content-Disposition
+3.13    Content-Features
+3.6     Content-ID
+3.7     Content-Identifier
+3.10    Content-Language see also Language
+3.11    Content-Length
+3.6     Content-Location
+3.15    Content-MD5
+3.4     Content-Return
+3.13    Content-SGML-Entity
+3.13    Content-Transfer-Encoding
+3.13    Content-Type
+3.3     Control
+3.12    Conversion
+3.12    Conversion-With-Loss
+        Copy, see Incomplete-Copy
+3.8     Date, see also Delivery-Date, Received, Expires, Expiry-
+        Date
+3.8     Delivery-Date
+        Delivery-Report, see Generate-Delivery-Report, Prevent-
+        Delivery-Report, Non-Delivery-Report, Content-Type
+        Description, see Content-Description
+3.17    Discarded-X400-IPMS-Extensions
+3.17    Discarded-X400-MTS-Extensions
+3.3     Disclose-Recipients
+        Disposition, see also Content-Disposition
+3.5     Disposition-Notification-Options
+3.5     Disposition-Notification-To
+3.4     Distribution
+3.2     DL-Expansion-History
+3.13    Encoding see also Content-Transfer-Encoding
+3.4     Errors-To
+3.8     Expires
+3.8     Expiry-Date
+        Extension see Discarded-X400-IPMS-Extensions, Discarded-
+        X400-MTS-Extensions
+3.4     Fax see also Telefax
+3.17    Fcc
+3.4     Followup-To
+3.4     For-Approval
+3.4     For-Comment
+3.4     For-Handling
+        Forwarded, see Autoforwarded
+3.4     From (not followed by (":" or preceded by ">")
+3.4     From (followed by ":")
+3.4     Generate-Delivery-Report
+        Handling, see For-Handling
+        History, see DL-Expansion-History
+        ID, see Content-ID and Message-ID
+        Identifier, see Content-ID and Message-ID
+3.9     Importance
+3.6     In-Reply-To
+3.9     Incomplete-Copy
+3.7     Keywords
+        Label, see PICS-Label
+3.10    Language see also Content-Language
+        Length see Content-Length
+3.11    Lines
+3.16    List-Archive
+3.16    List-Digest
+3.16    List-Help
+3.16    List-ID
+3.16    List-Owner
+3.16    List-Post
+3.16    List-Software
+3.16    List-Subscribe
+3.16    List-URL
+3.16    List-Unsubscribe
+        Loss, see Conversion-With-Loss
+3.4     Mail-System-Version see also X-mailer
+3.4     Mailer
+        MD5 see Content-MD5
+3.6     Message-ID
+3.13    Message-Type
+3.3     MIME-Version
+3.4     Newsgroups
+        Newsreader, see X-Newsreader
+3.6     Obsoletes
+3.7     Organisation
+3.7     Organization
+3.3     Original-Encoded-Information-Types
+3.6     Original-Recipient
+3.4     Originating-Client
+3.4     Originator
+3.4     Originator-Info see also Sender
+3.2     Path
+3.4     Phone
+3.9     PICS-Label
+3.9     Precedence
+3.4     Prevent-NonDelivery-Report
+3.9     Priority
+3.5     Read-Reciept-To
+3.2     Received
+        Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
+        Recipient
+3.6     References
+3.5     Registered-Mail-Reply-Requested-By
+3.6     Replaces
+3.8     Reply-By
+3.4     Reply-To, see also In-Reply-To, References
+3.14    Resent-
+        Return see Content-Return
+3.2     Return-Path
+3.5     Return-Receipt-Requested
+3.5     Return-Receipt-To
+3.6     See-Also
+3.4     Sender
+3.9     Sensitivity
+3.17    Speech-Act
+3.17    Status
+3.7     Subject
+3.7     Summary
+3.6     Supersedes
+3.4     Telefax see also Fax
+3.4     To
+        Transfer-Encoding see Content-Transfer-Encoding
+3.6     Translated-By
+3.6     Translation-Of
+        Type see Content-Type, Message-Type, Original-Encoded-
+        Information-Types
+        Version, see MIME-Version, X-Mailer
+3.5     X-Confirm-Reading-To
+3.4     X-Envelope-From
+3.4     X-Envelope-To
+3.4     X-Face
+3.16    X-List-Host
+3.16    X-Listserver
+3.4     X-Mailer see also Mail-System-Version
+3.13    X-MIME-Autoconverted
+3.4     X-Newsreader
+3.17    X-No-Archive
+3.8     X-OriginalArrivaltime
+3.9     X-Priority
+3.4     X-Sender see also Originator-Info
+3.6     X-UIDL
+3.6     X-URI
+3.6     X-URL see also Content-Location
+3.4     X-X-Sender see also Originator-Info
+3.4     X400-Content-Return
+3.15    Xref
diff --git a/Documentation/en/I-D/draft-palme-mailext-headers-04.txt b/Documentation/en/I-D/draft-palme-mailext-headers-04.txt
new file mode 100644
index 00000000..8e4ecb58
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-mailext-headers-04.txt
@@ -0,0 +1,1813 @@
+Network Working Group                                     Jacob Palme
+Internet Draft                               Stockholm University/KTH
+draft-palme-mailext-headers-04.txt                             Sweden
+Category: Informational                           Date: December 2000
+Revision of: RFC 2076                              Expires: June 2001
+
+
+
+                   Common Internet Message Header Fields
+
+                         Status of this Memo
+
+This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright (C) The Internet Society 2000. All Rights
+Reserved.
+
+                             Abstract
+
+This memo contains tables of commonly occurring header fields in
+headings of e-mail messages. The document compiles information from
+other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 2156, RFC 1496,
+RFC 1766, RFC 2183, RFC 1864, RFC 2421 and RFC 2045. A few commonly
+occurring header fields which are not defined in RFCs are also
+included. For each header field, the memo gives a short description
+and a reference to the RFC in which the header field is defined.
+
+                   Changes since previous version
+
+This document is a revision of RFC 2076. The following new header
+fields, not included in RFC 2076, have been added:
+Abuse-Reports-To:, Also-Control, Approved-By, Content-Alias, Content-
+Alternative, Content-Class, Content-Conversion, Content-Features,
+Content-ID, Delivered-To, Disposition-Notification-Options,
+Disposition-Notification-To, Expiry-Date, For-Approval, List-Archive,
+List-Digest, List-Help, List-ID, List-Owner, List-Post, List-
+Software, List-Subscribe, List-Unsubscribe, List-URL, Mail-Copies-
+To:, Original-Recipient, Originator, Originator-Info, Path, PICS-
+Label, NNTP-Posting-Host, Posted-To:, Read-Receipt-To, Received,
+Registered-Mail-Reply-Requested-By, Replaces, Return-Receipt-
+Requested, Speech-Act, Translated-By. Translation-Of, User-Agent, X-
+Confirm-Reading-To, X-Complaints-To:, X-Envelope-From, X-Envelope-To,
+X-Face, X-List-Host, X-Listserver, X-Loop, X-MIME-Autoconverted, X-No-
+Archive, X-OriginalArrivalTime, X-Priority, X-Report-Abuse-To, X-
+Sender, X-X-Sender, X-UIDL, X-URL, X-URI.
+
+The latest, revised version of this document from URL
+http://www.dsv.su.se/jpalme/ietf/mail-headers/
+
+Another list of headers can be found at URL
+http://www.hut.fi/~jkorpela/headers.html
+
+
+                          Table of contents
+
+      Abstract                                                       2
+      Changes since previous version                                 2
+1. Introduction                                                     3
+2. Use of gatewaying header fields                                  5
+3. Table of header fields                                           5
+      3.1 Phrases used in the tables                                 5
+      3.2 Trace information                                          6
+      3.3 Format and control information                             7
+      3.4 Sender and recipient indication                            8
+      3.5 Response control                                          13
+      3.6 Message identification and referral header fields         16
+      3.7 Other textual header fields                               19
+      3.8 Header fields containing dates and times                  19
+      3.9 Quality information                                       20
+      3.10 Language information                                     21
+      3.11 Size information                                         21
+      3.12 Conversion control                                       22
+      3.13 Encoding information                                     22
+      3.14 Resent-header fields                                     24
+      3.15 Security and reliability                                 25
+      3.16 Mailing list control                                     25
+      3.17 Miscellaneous                                            26
+4. Acknowledgments                                                 28
+Copyright and disclaimer                                           28
+5. References                                                      29
+6. Author's address                                                31
+Appendix A:                                                        32
+Header fields sorted by Internet RFC document in which they
+appear.                                                            32
+      RFC 822                                                       32
+      RFC 976                                                       32
+      RFC 1049                                                      32
+      RFC 1036                                                      33
+      RFC 1123                                                      33
+      RFC 2156                                                      33
+      RFC 1505                                                      34
+      RFC 1766                                                      34
+      RFC 2183                                                      34
+      RFC 1864                                                      34
+      RFC 2421                                                      34
+      RFC 2045                                                      34
+      RFC 2110                                                      34
+      RFC 2369                                                      34
+      son-of-RFC1036 [21]                                           35
+      draft-ietf-receipt                                            35
+      World Wide Web Consortium (W3C) Recommendations               35
+      Not Internet standard (as of June 2000)                       35
+Appendix B: Alphabetical index                                     36
+
+
+                          1. Introduction
+
+Many different Internet standards and RFCs define header fields which
+may occur on Internet Mail Messages and Usenet News Articles. The
+intention of this document is to list all such header fields in one
+document as an aid to people developing message systems or interested
+in Internet Mail standards.
+
+The document contains all header fields which the author has found in
+the following Internet standards: RFC 822 [2], RFC 1036 [3], RFC 1123
+[5], RFC 2156 [7], RFC 1496 [8], RFC 2045 [11], RFC 1766 [12], RFC
+2183 [14], RFC 1864[17] and RFC 2421[20]. Note in particular that
+heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
+[16]) are not included. PEM and MOSS header fields only appear inside
+the body of a message, and thus are not header fields in the RFC 822
+sense. Mail attributes in envelopes, i.e. attributes controlling the
+message transport mechanism between mail and news servers, are not
+included. This means that attributes from SMTP [1], UUCP [18] and
+NNTP [15] are mainly not covered either. Headings used only in HTTP
+[19] are not included yet, but may be included in future version of
+this memo. Some additional header fields which often can be found in
+e-mail headings but are not part of any Internet standard are also
+included.
+
+The author does not promise that this document contains a complete
+list of all heading fields which are specified in any standard or
+used by any mailer.
+
+For each header field, the document gives a short description and a
+reference to the Internet standard or RFC, in which they are defined.
+
+The header field names given here are spelled the same way as when
+they are actually used. This is usually American but sometimes
+English spelling.  One header field in particular,
+"Organisation/Organization", occurs in e-mail header fields sometimes
+with the English and other times with the American spelling.
+
+The following words are used in this memo with the meaning specified
+below:
+
+heading           Formatted text at the top of a message, ended by a
+                   blank line
+
+header field      One field in the heading, beginning with a field
+                   name, colon, and followed by the field value(s). The
+                   words "heading field" and "header" are also
+                   sometimes used with this meaning.
+
+It is my intention to continue updating this document after its
+publication as an RFC. The latest version, which may be more up-to-
+date (but also less fully checked out) will be kept available for
+downloading from URL
+http://www.dsv.su.se/jpalme/ietf/mail-headers
+
+Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
+header fields which should be included in this memo but are not.
+
+
+                  2. Use of gatewaying header fields
+
+RFC 2156 defines a number of new header fields in Internet mail,
+which are defined to map header fields which X.400 has but which were
+previously not standardized in Internet mail. The fact that a header
+field occurs in RFC 2156 indicates that it is recommended for use in
+gatewaying messages between X.400 and Internet mail, but does not
+mean that the header field is recommended for messages wholly within
+Internet mail. Some of these header fields may eventually see
+widespread implementation and use in Internet mail, but at the time
+of this writing (2000) they are not widely implemented or used.
+
+Header fields defined only in RFC 1036 for use in Usenet News
+sometimes appear in mail messages, either because the messages have
+been gatewayed from Usenet News to e-mail, or because the messages
+were written in combined clients supporting both e-mail and Usenet
+News in the same client. These header fields are not standardized for
+use in Internet e-mail and should be handled with caution by e-mail
+agents.
+
+
+                       3. Table of header fields
+
+3.1 Phrases used in the tables
+
+"not for general        Used to mark header fields which are defined
+usage"                  in RFC 2156 for use in messages from or to
+                         Internet mail/X.400 gateways. These header
+                         fields have not been standardized for general
+                         usage in the exchange of messages between
+                         Internet mail-based systems.
+
+"not standardized       Used to mark header fields defined only in RFC
+for use in e-mail"      1036 for use in Usenet News. These header
+                         fields have no standard meaning when appearing
+                         in e-mail, some of them may even be used in
+                         different ways by different software. When
+                         appearing in e-mail, they should be handled
+                         with caution. Note that RFC 1036, although
+                         generally used as a de-facto standard for
+                         Usenet News, is not an official IETF standard
+                         or even on the IETF standards track.
+
+"non-standard"          This header field is not specified in any of
+                         referenced RFCs which define Internet
+                         protocols, including Internet Standards, draft
+                         standards or proposed standards. The header
+                         field appears here because it often appears in
+                         e-mail or Usenet News. Usage of these header
+                         fields is not in general recommended. Some
+                         header field proposed in ongoing IETF
+                         standards development work, but not yet
+                         accepted, are also marked in this way.
+
+"discouraged"           This header field, which is non-standard, is
+                         known to create problems and should not be
+                         generated. Handling of such header fields in
+                         incoming mail should be done with great
+                         caution.
+
+"controversial"         The meaning and usage of this header field is
+                         controversial, i.e. different implementors
+                         have chosen to implement the header field in
+                         different ways. Because of this, such header
+                         fields should be handled with caution and
+                         understanding of the different possible
+                         interpretations.
+
+"experimental"          This header field is used for newly defined
+                         header fields, which are to be tried out
+                         before entering the IETF standards track.
+                         These should only be used if both
+                         communicating parties agree on using them. In
+                         practice, some experimental protocols become
+                         de-facto-standards before they are made into
+                         IETF standards.
+
+3.2 Trace information
+
+Trace of distribution lists          DL-Expansion-   RFC 2156, not for
+passed.                              History:        general usage.
+
+List of MTAs passed.                 Path:           RFC 1036: 2.1.6,
+                                                      only in Usenet
+                                                      News, not in e-
+                                                      mail.
+
+Trace of MTAs which a message has    Received:       RFC 822: 4.3.2,
+passed.                                              RFC 1123: 5.2.8.
+
+Used to convey the information       Return-Path:    RFC 821,
+from the MAIL FROM envelope                          RFC 1123: 5.2.13.
+attribute in final delivery, when
+the message leaves the SMTP
+environment in which "MAIL FROM"
+is used.
+
+The netnews host, to which this      NNTP-Posting-   Non-standard,
+article was originally posted.       Host            common in netnews
+Useful for finding the sender of
+spams. Since this header is added
+by the news server, it is a
+little more difficult to forge
+than other header fields.
+
+3.3 Format and control information
+
+Special Usenet News commands and     Also-Control:   son-of-RFC1036
+a normal article at the same                         [21], non-
+time.                                                standard, only in
+                                                      Usenet News, not
+                                                      in e-mail
+
+Controls whether this message may    Alternate-      RFC 2156, not for
+be forwarded to alternate            Recipient:      general usage.
+recipients such as a postmaster
+if delivery is not possible to
+the intended recipient. Default:
+Allowed.
+
+Whether a MIME body part is to be    Content-        RFC 2183,
+shown inline or is an attachment;    Disposition:    experimental
+can also indicate a suggested
+filename for use when saving an
+attachment to a file.
+
+Only in Usenet News, contains        Control:        RFC 1036: 2.1.6,
+commands to be performed by News                     only in Usenet
+agents.                                              News, not in e-
+                                                      mail.
+
+Whether recipients are to be told    Disclose-       RFC 2156, not for
+the names of other recipients of     Recipients:     general usage.
+the same message. This is
+primarily an X.400 facility. In
+X.400, this is an envelope
+attribute and refers to
+disclosure of the envelope
+recipient list. Disclosure of
+other recipients is in Internet
+mail done via the To:, cc: and
+bcc: header fields.
+
+An indicator that this message is    MIME-Version:   RFC 2045: 4.
+formatted according to the MIME
+standard, and an indication of
+which version of MIME is
+utilized.
+
+Which body part types occur in       Original-       RFC 2156, not for
+this message.                        Encoded-        general usage.
+                                      Information-
+                                      Types:
+
+3.4 Sender and recipient indication
+
+Inserted by Sendmail when there      Apparently-     Non-standard,
+is no "To:" recipient in the         To:             discouraged,
+original message, listing                            mentioned in
+recipients derived from the                          RFC 1211.
+envelope into the message
+heading. This behavior is not
+quite proper, MTAs should not
+modify headings (except inserting
+Received lines), and it can in
+some cases cause Bcc recipients
+to be wrongly divulged to non-Bcc
+recipients.
+
+Name of the moderator of the         Approved:       RFC 1036: 2.2.11,
+newsgroup to which this article                      not standardized
+is sent; necessary on an article                     for use in e-mail.
+sent to a moderated newsgroup to
+allow its distribution to the
+newsgroup members. Also used on
+certain control messages, which
+are only performed if they are
+marked as Approved.
+
+Name of the moderator of a           Approved-By:    Non-standard, used
+mailing list, and who has                            by some mailing
+approved this message for                            list expansion
+distribution to the members of                       systems.
+the list.
+
+Recipients not to be disclosed to    bcc:            RFC 822: 4.5.3,
+other recipients. (bcc = Blind                       RFC 1123: 5.2.15-
+Carbon Copy).                                        16, 5.3.7.
+
+Secondary, informational             cc:             RFC 822: 4.5.2,
+recipients. (cc = Carbon Copy)                       RFC 1123. 5.2.15-
+                                                      16, 5.3.7.
+
+Geographical or organizational       Distribution:   RFC 1036: 2.2.7,
+limitation on where this article                     not standardized
+can be distributed. Value can be                     for use in e-mail.
+a compete or incomplete domain
+names, also various special
+values are accepted like "world",
+"usenet", "USA", etc.
+
+Fax number of the originator.        Fax:,           Non-standard.
+                                      Telefax:
+
+Primary recipients, who are          For-Approval:   Non-standard
+requested to approve the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Comment:    Non-standard
+requested to comment on the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Handling:   Non-standard
+requested to handle the
+information in this message or
+its attachments.
+
+(2) Used in Usenet News mail         From            RFC 976: 2.4 for
+transport, to indicate the path      or              use in Usenet News
+through which an article has gone    >From
+when transferred to a new host.      (not followed
+                                      by a colon)
+Sometimes called "From_" header
+field.
+
+(1) This header field should         From (not       not standardized
+never appear in e-mail being         followed by a   for use in e-mail
+sent, and should thus not appear     colon)
+in this memo. It is however
+included, since people often ask
+about it.
+
+This header field is used in the
+so-called Unix mailbox format,
+also known as Berkely mailbox
+format or the MBOX format. This
+is a format for storing a set of
+messages in a file. A line
+beginning with "From " is used to
+separate successive messages in
+such files.
+
+This header field will thus
+appear when you use a text editor
+to look at a file in the Unix
+mailbox format. Some mailers also
+use this format when printing
+messages on paper.
+
+The information in this header
+field should NOT be used to find
+an address to which replies to a
+message are to be sent.
+
+Authors or persons taking            From:           RFC 822: 4.4.1,
+responsibility for the message.                      RFC 1123: 5.2.15-
+                                                      16, 5.3.7,
+Note difference from the "From "                     RFC 1036 2.1.1
+header field (not followed by
+":") below.
+
+
+Information about the client         Mail-System-    Non-standard.
+software of the originator.          Version:,
+                                      Mailer:,
+                                      Originating-
+                                      Client:, X-
+                                      Mailer, X-
+                                      Newsreader, X-
+                                      MimeOLE:,
+                                      User-Agent:
+
+In Usenet News: group(s) to which    Newsgroups:     RFC 1036: 2.1.3,
+this article was posted.                             not standardized
+Some systems provide this header                     and controversial
+field also in e-mail although it                     for use in e-mail.
+is not standardized there.
+
+Unfortunately, the header field
+can appear in e-mail with three
+different and contradictory
+meanings:
+
+(a) Indicating the newsgroup
+recipient of an article/message
+sent to both e-mail and Usenet
+News recipients.
+
+(b) In a message adressed to some
+mail to news gateways, indicates
+the newsgroup(s) that the message
+is to be posted to.
+
+(c) In a personally addressed
+reply to an article in a news-
+group, indicating the newsgroup
+in which this discussion
+originated.
+
+See also: "Posted-To:".
+
+Sometimes used in Usenet News in     Originator:     Non-standard in
+similar ways to "Sender:"                            Usenet News,
+                                                      Experimental in
+Also used in printing protocols.                     RFC 1528.
+
+Contains information about the       Originator-     Non-standard [25]
+authentication of the originator     Info:
+in a format which is not easily
+used to send email to, to avoid
+the problems with "Sender" and "X-
+Sender".
+
+Phone number of the originator.      Phone:          Non-standard.
+
+The person or agent submitting       Sender:         RFC 822: 4.4.2,
+the message to the network, if                       RFC 1123: 5.2.15-
+other than shown by the From:                        16, 5.3.7, RFC
+header field. Should be                              1036.
+authenticated,
+according to RFC 822, but what
+kind of authentication is not
+clear. Some implementations
+expect that the e-mail address
+used in this field can be used to
+reach the sender, others do not.
+See also "X-Sender".
+
+Primary recipients.                  To:             RFC 822: 4.5.1,
+                                                      RFC 1123: 5.2.15-
+                                                      16, 5.3.7.
+
+If the sender in the envelope        X-Envelope-     Non-standard.
+(SMTP "RCTP TO") is not the same     From
+as the senders in the "From" or
+"Sender" RFC822 header fields,
+some mail servers add this to the
+RFC822 header fields as an aid to
+clients which would otherwise not
+be able to display this
+information.
+
+If the recipient in the envelope     X-Envelope-To   Non-standard.
+(SMTP "MAIL FROM") is not
+included in the CC list, some
+mail servers add this to the
+RFC822 header field as an aid to
+clients which would otherwise not
+be able to display the envelope
+recipients.
+
+48x48 bitmap with picture of the     X-Face          Non-Standard
+sender of this message.
+
+Indication in the mail header of     X-RCPT-TO:      Non-standard
+recipient on the SMTP envelope.
+
+Some mail software expect            X-Sender:       Non-standard
+"Sender:" to be an e-mail address
+which you can send mail to.
+However, some mail software has
+as the best authenticated sender
+a POP or IMAP account, which you
+might not be able to send to.
+Because of this, some mail
+software put the POP or IMAP
+account into an X-sender header
+field instead of a Sender header
+field, to indicate that you may
+not be able to send e-mail to
+this address. See also "X-X-
+Sender".
+
+Another use of" X-Sender:" is
+that some e-mail software, which
+wants to insert a "Sender:"
+header, will first change an
+existing "Sender:" header to "X-
+Sender". This use is actually
+often the same as that described
+in the previous paragraph, since
+the new "Sender:" is added
+because it is better
+authenticated than the old value.
+
+Even though some systems put the     X-X-Sender:     Non-standard
+POP or IMAP account name into the
+"X-Sender:" instead of the Sender
+header field, some mail software
+tries to send to the "X-Sender:"
+too. To stop this, some systems
+have begun to use "X-X-Sender:"
+to indicate an authentication of
+the sender which might not be
+useable to send e-mail to. See
+also "Originator-Info:"
+
+When a message is sent both to       Posted-To:      Non-standard
+netnews and e-mail, this header
+is used in the e-mail version of
+the message to indicate which
+newsgroup it was sent to. This
+header thus contains the same
+information as the "Newsgroups:"
+header in the netnews version of
+the message.
+
+E-mail address of administrator      X-Admin:        Non-standard
+of a server, through which this
+message was submitted.
+
+3.5 Response control
+
+Indicates whether the content of     Content-        RFC 2156, not for
+a message is to be returned with     Return:         general usage.
+non-delivery notifications.
+
+For future options on disposition    Disposition-    RFC 2298
+notifications.                       Notification-
+                                      Options:
+
+
+Indicate that the sender wants a     Disposition-    RFC 2298
+dispoisition notification when       Notification-
+this message is received (read,      To:
+processed, etc.) by its
+receipents.
+
+Address to which notifications       Errors-To:,     Non-standard,
+are to be sent and a request to      Return-         discouraged.
+get delivery notifications.          Receipt-To:,
+Internet standards recommend,        Read-Receipt-
+however, the use of MAIL FROM and    To:, X-
+Return-Path, not Errors-To, for      Confirm-
+where delivery notifications are     reading-to:,
+to be sent.                          Return-
+                                      Receipt-
+                                      Requested,
+                                      Register-Mail-
+                                      Reply-
+                                      Requested-By:
+
+Used in Usenet News to indicate      Followup-To:    RFC 1036: 2.2.3,
+that future discussions (=follow-                    not standardized
+up) on an article should go to a                     for use in e-mail.
+different set of newsgroups than
+the replied-to article. The most
+common usage is when an article
+is posted to several newsgroups,
+and further discussions is to
+take place in only one of them.
+
+In e-mail, this header field may
+occur in a message which is sent
+to both e-mail and Usenet News,
+to show where follow-up in Usenet
+news is wanted. The header field
+does not say anything about where
+follow-up in e-mail is to be
+sent.
+
+The value of this header field
+should be one or more newsgroup
+names.
+
+The special value "poster" as in
+"Followup-To: poster" means that
+replies are to be sent as e-mail
+to the author only.
+
+Whether a delivery report is         Generate-       RFC 2156, not for
+wanted at successful delivery.       Delivery-       general usage.
+Default is not to generate such a    Report:
+report.
+
+Original Recipient information       Original-       RFC 2298
+for inclusion in disposition         Recipient
+notifications.
+
+Whether non-delivery report is       Prevent-        RFC 2156, not for
+wanted at delivery error. Default    NonDelivery-    general usage.
+is to want such a report.            Report:
+
+This header field is meant to        Reply-To:       RFC 822: 4.4.3,
+indicate where the sender wants                      RFC 1036: 2.2.1
+replies to go. Unfortunately,                        controversial.
+this is ambiguous, since there
+are different kinds of replies,
+which the sender may wish to go
+to different addresses. In
+particular, there are personal
+replies intended for only one
+person, and group replies,
+intended for the whole group of
+people who read the replied-to
+message (often a mailing list,
+anewsgroup name cannot appear
+here because of different syntax,
+see "Followup-To" below.).
+
+Some mail systems use this header    Reply-To2
+field to indicate a better form
+of the e-mail address of the
+sender. Some mailing list
+expanders puts the name of the
+list in this header field. These
+practices are controversial. The
+personal opinion of the author of
+this RFC is that this header
+field should be avoided except in
+special cases, but this is a
+personal opinion not shared by
+all specialists in the area.
+
+Indicates where to send complains    Abuse-Reports-  non-standard
+if you get a message which you       To:, X-
+think is against the laws or         Complaints-
+rules.                               To:, X-Report-
+                                      Abuse-To:
+
+Used in netnews articles to          Mail-Copies-    non-standard, but
+indicate that followup (=replies)    To:             commonly supported
+should be sent to the indicated e-                   by newsreaders
+mail address.
+
+Possible future change of name       X400-Content-   non-standard
+for "Content-Return:"                Return:
+
+3.6 Message identification and referral header fields
+
+Reference to specially important     Article-        son-of-RFC1036
+articles for a particular Usenet     Names:          [21], non-standard
+Newsgroup.
+
+Only in Usenet News, similar to      Article-        son-of-RFC1036
+"Supersedes:" but does not cause     Updates:        [21], non-standard
+the referenced article to be
+physically deleted.
+
+Used in addition to Content-         Content-        Work in progress
+Location if this content part can    Alias:
+be retrieved through more than
+one URI. Only one of them is
+allowed in the Content-Location,
+the other can be specified in
+Content-Alias.
+
+Base to be used for resolving        Content-Base:   RFC 2110
+relative URIs within this content
+part.
+
+Unique ID of one body part of the    Content-ID:     RFC 2045: 7.
+content of a message.
+
+URI with which the content of        Content-        RFC 2110
+this content part might be           Location:
+retrievable.
+
+Used by some automatic services      Delivered-To:   non-standard
+(mainly MLMs and autoresponders)     or
+for the purpose of loop              X-Loop:
+detection. The service adds the
+Delivered-To header to outgoing
+messages, with its e-mail address
+as a value, and discards incoming
+messages which already have it.
+
+Reference to message which this      In-Reply-To:    RFC 822: 4.6.2.
+message is a reply to.
+
+Unique ID of this message.           Message-ID:     RFC 822: 4.6.1
+                                                      RFC 1036: 2.1.5.
+
+Reference to previous message        Obsoletes:      RFC 2156, not for
+being corrected and replaced.                        general usage.
+Compare to "Supersedes:" below.
+This field may in the future be
+replaced with "Supersedes:".
+
+In e-mail: reference to other        References:     RFC 822: 4.6.3
+related messages, in Usenet News:                    RFC 1036: 2.1.5.
+reference to replied-to-articles.
+
+Still another name for similar       Replaces:       non-standard,
+functionality as for "Obsoletes:"                    proposed in IETF
+and "Supersedes:". This may                          USEFOR working
+become the most recommended                          group
+header in the future, but is
+still under discussion in IETF
+standards development work.
+
+References to other related          See-Also:       Son-of-RFC1036
+articles in Usenet News.                             [21], non-standard
+
+Commonly used in Usenet News in      Supersedes:     son-of-RFC1036
+similar ways to the "Obsoletes"                      [21], non-standard
+header field described above. In
+Usenet News, however, Supersedes
+causes a full deletion of the
+replaced article in the server,
+while "Supersedes" and
+"Obsoletes" in e-mail is
+implemented in the client and
+often does not remove the old
+version of the text.
+
+Mailbox of the person who made       Translated-     non-standard
+the translation.                     By:
+
+Reference to the Message-ID of a     Translation-    non-standard
+message, which the current           Of:
+message is a translation of.
+
+Unique identifier for a message,     X-UIDL:         non-standard
+local to a particular local
+mailbox store. The UIDL
+identifier is defined in the POP3
+standard, but not the "X-UIDL:"
+header.
+
+Similar usage as "X-URL". The URI    X-URI:          Non-standard
+can be either a URL or a URN.
+URNs are meant to become more
+persistent references to
+resources than URLs.
+
+Sometimes used with the same         X-URL:          Non-standard
+meaning as "Content-Location:",
+sometimes to indicate the web
+home page of the sender or of his
+organisation.
+
+The UID, as defined in the IMAP      X-IMAP:         Non-standard
+standard. Only used in internal
+mailbox storage in some mail
+systems, should never be visible
+to a user.
+
+3.7 Other textual header fields
+
+Comments on a message.               Comments:       RFC 822: 4.7.2.
+
+Description of a particular body     Content-        RFC 2045: 8.
+part of a message, for example a     Description:
+caption for an image body part.
+
+A text string which identifies       Content-        RFC 2156, not for
+the content of a message.            Identifier:     general usage.
+
+Search keys for data base            Keywords:       RFC 822: 4.7.1
+retrieval.                                           RFC 1036: 2.2.9.
+
+See Organization above.              Organisation:   Non-standard.
+
+Organization to which the sender     Organization:   RFC 1036: 2.2.8,
+of this article belongs.                             not standardized
+                                                      for use in e-mail.
+
+Title, heading, subject. Often       Subject:        RFC 822: 4.7.1
+used as thread indicator for                         RFC 1036: 2.1.4.
+messages replying to or
+commenting on other messages.
+
+Short text describing a longer       Summary:        RFC 1036: 2.2.10,
+article. Warning: Some mail                          not standardized
+systems will not display this                        for use in e-mail,
+text to the recipient. Because of                    discouraged.
+this, do not use this header
+field for text which you want to
+ensure that the recipient gets.
+
+3.8 Header fields containing dates and times
+
+In Internet, the date when a         Date:           RFC 822: 5.1,
+message was written, in X.400,                       RFC 1123: 5.2.14
+the time a message was submitted.                    RFC 1036: 2.1.2.
+Some Internet mail systems also
+use the date when the message was
+submitted.
+
+The time when a message was          Delivery-       RFC 2156, not for
+delivered to its recipient.          Date:           general usage.
+
+A suggested expiration date. Can     Expires:        RFC 1036: 2.2.4,
+be used both to limit the time of                    not standardized
+an article which is not                              for use in e-mail.
+meaningful after a certain date,
+and to extend the storage of
+important articles.
+
+Time at which a message loses its    Expiry-Date:    RFC 2156, not for
+validity. This field may in the                      general usage.
+future be replaced by "Expires:".
+
+Latest time at which a reply is      Reply-By:       RFC 2156, not for
+requested (not demanded).                            general usage.
+
+Time when this message was           X-OriginalArr   Non-standard
+delivered into the message           ivalTime:
+transport system (usually the
+same time as in the last
+"Received:" header)
+
+3.9 Quality information
+
+A hint from the originator to the    Importance:     RFC 2156 and
+recipients about how important a                     RFC 2421, proposed
+message is. Values: High, normal
+or low. Not used to control
+transmission speed.
+
+Body parts are missing.              Incomplete-     RFC 2156, not for
+                                      Copy:           general usage.
+
+Ratings label to control             PICS-Label:     REC-PICS-labels,
+selection (filtering) of messages                    W3C document [23].
+according to the PICS protocol.
+
+Sometimes used as a priority         Precedence:     Non-standard,
+value which can influence                            controversial.
+transmission speed and delivery.
+Common values are "bulk" and
+"first-class". Other uses is to
+control automatic replies and to
+control return-of-content
+facilities, and to stop mailing
+list loops.
+
+Can be "normal", "urgent" or "non-   Priority:       RFC 2156, not for
+urgent" and can influence                            general usage.
+transmission speed and delivery.
+
+How sensitive it is to disclose      Sensitivity:    RFC 2156 and
+this message to other people than                    RFC 2421, proposed
+the specified recipients. Values:
+Personal, private, company
+confidential. The absence of this
+header field in messages
+gatewayed from X.400 indicates
+that the message is not
+sensitive.
+
+Yet another priority indication.     X-MSMail-       Non-standard
+                                      Priority:
+
+Values: 1 (Highest), 2 (High), 3     X-Priority:     Non-standard [24]
+(Normal), 4 (Low), 5 (Lowest). 3
+(Normal) is default if the field
+is omitted.
+
+3.10 Language information
+
+Can include a code for the           Content-        RFC 1766, proposed
+natural language used in a           Language:       standard.
+message, e.g. "en" for English.
+
+Can include a code for the           Language:       RFC 2156, not for
+natural language used in a                           general usage.
+message, e.g. "en" for English.
+
+3.11 Size information
+
+Inserted by certain mailers to       Content-        Non-standard,
+indicate the size in bytes of the    Length:         discouraged.
+message text. This is part of a
+format some mailers use when
+showing a message to its users,
+and this header field should not
+be used when sending a message
+through the net. The use of this
+header field in transmission of a
+message can cause several
+robustness and interoperability
+problems.
+
+Size of the message.                 Lines:          RFC 1036: 2.2.12,
+                                                      not standardized
+                                                      for use in e-mail.
+
+3.12 Conversion control
+
+Information on where an              Content-        Non-standard [27].
+alternative variant of this          Alternative:
+document might be found.
+
+Non-standard variant of              Content-        Non-standard.
+Conversion: with the same values.    Conversion:
+
+The body of this message may not     Conversion:     RFC 2156, not for
+be converted from one character                      general usage.
+set to another. Values:
+Prohibited and allowed.
+
+The body of this message may not     Conversion-     RFC 2156, not for
+be converted from one character      With-Loss:      general usage.
+set to another if information
+will be lost. Values: Prohibited
+and allowed.
+
+3.13 Encoding information
+
+Type information of the content      Content-        non-standard
+in some class hierarchy. Class       Class:
+hierarchies are commonly used to
+classify data structures in
+software development.
+
+Can give more detailed               Content-        non-standard
+information about the Content-       Features:
+Type. Example:
+
+(&  (color=binary)
+     (image-file-structure=TIFF-S)
+     (dpi=200)
+     (paper-size=A4)
+     (image-coding=MH)
+     (MRC-mode=0)
+     (ua-media=stationery) )
+
+This header is meant to be used
+when you can choose between
+different versions of a resource,
+such as when using
+multipart/atlernative.
+
+Information from the SGML entity     Content-SGML-   non-standard
+declaration corresponding to the     Entity:
+entity contained in the body of
+the body part.
+
+Coding method used in a MIME         Content-        RFC 2045: 6.
+message body.                        Transfer-
+                                      Encoding:
+
+Format of content (character set     Content-Type:   RFC 1049,
+etc.) Note that the values for                       RFC 1123: 5.2.13,
+this header field are defined in                     RFC 1766: 4.1
+different ways in RFC 1049 and in                    RFC 2045: 5.
+MIME (RFC 2045), look for the
+"MIME-version" header field to
+understand if Content-Type is to
+be interpreted according to RFC
+1049 or according to MIME. The
+MIME definition should be used in
+generating mail. RFC 1049 has
+"historic" status.
+
+RFC 1766 defines a parameter
+"difference" to this header
+field.
+
+Various other Content-Type define
+various additional parameters.
+For example, the parameter
+"charset" is mandatory for all
+textual Content-Types.
+
+Used in several different ways by    Encoding:       RFC 1154,
+different mail systems. Some use                     RFC 1505,
+it for a kind of content-type                        experimental.
+information, some for encoding
+and length information, some for
+a kind of boundary information,
+some in other ways.
+
+Only used with the value             Message-Type:   RFC 2156, not for
+"Delivery Report" to indicates                       general usage.
+that this is a delivery report
+gatewayed from X.400.
+
+Information about conversion of      X-MIME-         non-standard
+this message on the path from        Autoconverted:
+sender to recipient, like
+conversion between MIME encoding
+formats. Note: Auto-conversion
+may invalidate digital seals and
+signatures.
+
+3.14 Resent-header fields
+
+When manually forwarding a           Resent-Reply-   RFC 822: C.3.3.
+message, header fields referring     To:,
+to the forwarding, not to the        Resent-From:,
+original message.  Note: MIME        Resent-
+specifies another way of             Sender:,
+resending messages, using the        Resent-From:,
+"Message" Content-Type.              Resent-Date:,
+                                      Resent-To:,
+                                      Resent-cc:,
+                                      Resent-bcc:,
+                                      Resent-
+                                      Message-ID:
+
+3.15 Security and reliability
+
+Checksum of content to ensure        Content-MD5:    RFC 1864, proposed
+that it has not been modified.                       standard.
+
+Used in Usenet News to store         Xref:           RFC 1036: 2.2.13,
+information to avoid showing a                       only in Usenet
+reader the same article twice if                     News, not in e-
+it was sent to more than one                         mail.
+newsgroup. Only for local usage
+within one Usenet News server,
+should not be sent between
+servers.
+
+3.16 Mailing list control
+
+Contains URL to use to browse the    List-Archive    RFC 2369 [26]
+archives of the mailing list from
+which this message was relayed.
+
+URL to use to get a subscription     List-Digest     Non-standard
+to the digest version of the
+mailing list from which this
+message was relayed.
+
+Contains URL to use to get a         List-Help       RFC 2369 [26]
+information about the mailing
+list from which this message was
+relayed.
+
+Stores an identification of the      List-ID         Approved by the
+mailing list, through which this                     IESG for
+message was distributed.                             standardization.
+
+Contains URL to send e-mail to       List-Owner      RFC 2369 [26]
+the owner of the mailing list
+from which this message was
+relayed.
+
+Contains URL to use to send          List-Post       RFC 2369 [26]
+contributions to the mailing list
+from which this message was
+relayed.
+
+Information about the software       List-Software   Non-standard, has
+used in a mailing list expander                      been considered
+through which this message has                       for inclusion in
+passed.                                              [26].
+
+Contains URL to use to get a         List-           RFC 2369 [26]
+subscription to the mailing list     Subscribe
+from which this message was
+relayed.
+
+Contains URL to use to               List-           RFC 2369 [26]
+unsubscribe the mailing list from    Unsubscribe
+which this message was relayed.
+
+Contains URL where information of    List-URL        Non-standard
+various kinds about the mailing
+list from which this message was
+relayed.
+
+Information about the server and     X-Listserver,   Non-standard.
+software used in a mailing list      X-List-Host     Recommended to use
+expander through which this                          "List-Software"
+message has passed. Warning:                         instead.
+"Listserv" is a trademark and
+should not be used for other than
+the "Listserv" product. Use,
+instead the "List-Software"
+header field.
+
+3.17 Miscellaneous
+
+Has been automatically forwarded.    Autoforwarded   RFC 2156, not for
+                                      :               general usage.
+
+Can be used in Internet mail to      Discarded-      RFC 2156, not for
+indicate X.400 IPM extensions        X400-IPMS-      general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+
+Can be used in Internet mail to      Discarded-      RFC 2156, not for
+indicate X.400 MTS extensions        X400-MTS-       general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+
+Name of file in which a copy of      Fcc:            Non-standard.
+this message is stored.
+
+Speech act categoriztion of a        Speech-Act:     Non-standard
+message, examples of speeach acts
+are Question, Idea, More,
+Promise, Sad, Happy, Angry,
+summary, Decision
+This field is used by some mail      Status:         Non-standard,
+delivery systems to indicate the                     should never
+status of delivery for this                          appear in mail in
+message when stored. Common                          transit.
+values of this field are:
+
+U    message is not downloaded
+      and not deleted.
+
+R    message is read or
+      downloaded.
+
+O    message is old but not
+      deleted.
+
+D    to be deleted.
+
+N    new (a new message also
+      sometimes is distinguished
+      by not having any "Status:"
+      header field.
+
+Combinations of these characters
+can occur, such as "Status: OR"
+to indicate that a message is
+downloaded but not deleted.
+
+Do not archive this message in       X-No-Archive:   Non-standard
+publicly available archives.         Yes
+
+
+
+                           4. Acknowledgments
+
+Harald Tveit Alvestrand, Neil Carpenter, William C. Carpenter, Rob
+Chandhok, Ned Freed, Olle J„rnefors, Jukka Korpela, Usi Paz, Martin
+Platt, Keith Moore, Robert A. Rosenberg, Mark Symons, Nick Smith
+Michael C. Tiernan and several other people have helped me with
+compiling this list. I especially thank Ned Freed and Olle J„rnefors
+for their thorough review and many helpful suggestions for
+improvements. I alone take responsibility for any errors which may
+still be in the list.
+
+An earlier version of this list has been published as part of [13].
+
+
+                  Copyright and disclaimer
+
+The IETF takes no position regarding the validity or scope
+of any intellectual property or other rights that might be
+claimed to pertain to the implementation or use of the
+technology described in this document or the extent to
+which any license under such rights might or might not be
+available; neither does it represent that it has made any
+effort to identify any such rights. Information on the
+IETF's procedures with respect to rights in standards-track
+and standards-related documentation can be found in BCP-11.
+Copies of claims of rights made available for publication
+and any assurances of licenses to be made available, or the
+result of an attempt made to obtain a general license or
+permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained
+from the IETF Secretariat."
+
+The IETF invites any interested party to bring to its
+attention any copyrights, patents or patent applications,
+or other proprietary rights which may cover technology that
+may be required to practice this standard. Please address
+the information to the IETF Executive Director.
+
+Copyright (C) The Internet Society (date). All Rights
+Reserved.
+
+This document and translations of it may be copied and
+furnished to others, and derivative works that comment on
+or otherwise explain it or assist in its implmentation may
+be prepared, copied, published and distributed, in whole or
+in part, without restriction of any kind, provided that the
+above copyright notice and this paragraph are included on
+all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by
+removing the copyright notice or references to the Internet
+Society or other Internet organizations, except as needed
+for the purpose of developing Internet standards in which
+case the procedures for copyrights defined in the Internet
+Standards process must be followed, or as required to
+translate it into languages other than English.
+
+The limited permissions granted above are perpetual and
+will not be revoked by the Internet Society or its
+successors or assigns.
+
+
+                             5. References
+
+Ref.    Author, title                                    IETF status
+                                                          (Dec 2000)
+-----   ---------------------------------------------    -----------
+[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
+         STD 10, RFC 821, August 1982.                    Recommended
+
+[2]     D. Crocker: "Standard for the format of ARPA     Standard,
+         Internet text messages." STD 11, RFC 822,        Recommended
+         August 1982.
+
+[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
+         interchange of USENET messages", RFC 1036,       cial IETF
+         December 1987.                                   standard,
+                                                          but in
+                                                          reality a de-
+                                                          facto
+                                                          standard for
+                                                          Usenet News
+
+[4]     M. Sirbu: "A Content-Type header field header    Historic
+         field for internet messages", RFC 1049, March
+         1988.
+
+[5]     R. Braden (editor): "Requirements for            Standard,
+         Internet Hosts -- Application and Support",      Required
+         STD-3, RFC 1123, October 1989.
+
+[6]     D. Robinson, R. Ullman: "Encoding Header         Non-standard
+         field for Internet Messages", RFC 1505,
+         August 1993.
+
+[7]     S. Hardcastle-Kille: "Mapping between            Proposed
+         X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
+         2156 January 1998.                               elective
+
+[8]     H. Alvestrand & J. Romaguera: "Rules for         Proposed
+         Downgrading Messages from X.400/88 to            standard,
+         X.400/84 When MIME Content-Types are Present     elective
+         in the Messages", RFC 1496, August 1993.
+
+[9]     A. Costanzo: "Encoding Header field Header       Non-standard
+         field for Internet Messages", RFC 1154, April
+         1990.
+
+[10]    A. Costanzo, D. Robinson: "Encoding Header       Experimental
+         field Header field for Internet Messages",
+         RFC 1505, August 1993.
+
+[11]    N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
+         Internet Mail Extensions) Part One: Format of    Standard,
+         Internet Message Bodies. RFC 2045. November      elective
+         1996.
+
+[12]    H. Alvestrand: "Tags for the Identification      Proposed
+         of Languages", RFC 1766, February 1995.          standard,
+                                                          elective
+
+[13]    J. Palme: "Electronic Mail", Artech House        Non-standard
+         publishers, London-Boston January 1995.
+
+[14]    R. Troost, S. Dorner: "Communicating             Experimental
+         Presentation Information in Internet
+         Messages: The Content-Disposition Header
+         field", RFC 2183, June 1995.
+
+[15]    B. Kantor, P. Lapsley, "Network News Transfer    Proposed
+         Protocol: "A Proposed Standard for the Stream-   standard
+         Based Transmission of News", RFC 977, January
+         1986.
+[16]    1848  PS   S. Crocker, N. Freed, J. Galvin,      Proposed
+         S. Murphy, "MIME Object Security Services",      standard
+         RFC 1848, March 1995.
+
+[17]    J. Myers, M. Rose: The Content-MD5 Header        Draft
+         field Header field, RFC 1864, October 1995.      standard
+
+[18]    M. Horton, UUCP mail interchange format          Not an offi-
+         standard, RFC 976, Januari 1986.                 cial IETF
+                                                          standard,
+                                                          but in
+                                                          reality a de-
+                                                          facto
+                                                          standard for
+                                                          Usenet News
+
+[19]    T. Berners-Lee, R. Header fielding, H.           Informatio
+         Frystyk: Hypertext Transfer Protocol --          nal
+         HTTP/1.0, RFC 1945.
+
+[20]    G. Vaudreuil: Voice Profile for Internet         Proposed
+         Mail, RFC 2421 Feburary 1998.
+
+[21]    H. Spencer: News Article Format and              Not even an
+         Transmission, June 1994,                         RFC, but
+         FTP://zoo.toronto.edu/pub/news.ps.Z              still widely
+         FTP://zoo.toronto.edu/pub/news.txt.Z             used and
+                                                          partly almost
+         This document is often referenced under the      a de-facto
+         name "son-of-RFC1036".                           standard for
+                                                          Usenet News
+
+[23]    PICS Label Distribution Label Syntax and         Other
+         Communication Protocols, World Wide Web          standard
+         Consortium, October 1996.
+
+[24]    Eudora Pro Macintosh User Manual, Qualcomm       Non-standard
+         Inc., 1988-1995.
+
+[25]    C. Newman: Originator-Info Message Header        Non-standard
+         field. work in progress, July 1997.
+
+[26]    Grant Neufeld and Joshua D. Baer: The Use of     Proposed
+         URLs as Meta-Syntax for Core Mail List           standard
+         Commands and their Transport through Message
+         Header fields, RFC 2369, July 1998.
+
+[27]    G. Klyne (ed.): Content Negotiation for          Non-standard
+         Facsimile Using Internet Mail, Work in
+         progress, March 2000.
+
+
+                           6. Author's address
+
+Jacob Palme                     Phone: +46-8-16 16 67
+Stockholm University/KTH        Fax: +46-8-783 08 29
+Electrum 230                    E-mail: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
+
+                              Appendix A:
+Header fields sorted by Internet RFC document in which they appear.
+
+RFC 822
+-------
+
+bcc
+cc
+Comments
+Date
+From
+In-Reply-To
+Keywords
+Message-ID
+Received
+References
+Reply-To
+Resent-
+Resent-bcc
+Resent-cc
+Resent-Date
+Resent-From
+Resent-From
+Resent-Message-ID
+Resent-Reply-To
+Resent-Sender
+Resent-To
+Return-Path
+Sender
+Subject
+To
+
+RFC 976
+-------
+
+"From " (followed by space, not colon (:")
+
+RFC 1049
+--------
+
+Content-Type
+
+RFC 1036
+--------
+
+Approved
+Control
+Distribution
+Expires
+Followup-To
+Lines
+Newsgroups
+Organization
+Path
+Summary
+Xref
+
+RFC 1123
+--------
+
+Content-Type
+
+RFC 2156
+--------
+
+Alternate-recipient
+Auto-forwarded see Autoforwarded
+Autoforwarded
+Content-Identifier
+Content-Return
+Conversion
+Conversion-With-Loss
+Delivery-Date
+Discarded-X400-IPMS-Extensions
+Discarded-X400-MTS-Extensions
+Disclose-Recipients
+DL-Expansion-History
+Expiry-Date
+Generate-Delivery-Report
+Importance
+Incomplete-Copy
+Language
+Message-Type
+Obsoletes
+Original-Encoded-Information-Types
+Prevent-NonDelivery-Report
+Priority
+Reply-By
+Sensitivity
+
+RFC 1505
+--------
+
+Encoding
+
+RFC 1766
+--------
+
+Content-Language
+
+RFC 2183
+--------
+
+Content-Disposition
+
+RFC 1864
+--------
+
+Content-MD5
+
+RFC 2421
+--------
+
+Importance
+Sensitivity
+
+RFC 2045
+--------
+
+Content-Description
+Content-ID
+Content-Transfer-Encoding
+Content-Type
+MIME-Version
+
+RFC 2110
+--------
+
+Content-Base
+Content-Location
+
+RFC 2369
+--------
+
+List-Archive
+List-Help
+List-Owner
+List-Post
+List-Software
+List-Subscribe
+List-Unsubscribe
+
+son-of-RFC1036 [21]
+-------------------
+
+Also-Control
+Article-Names
+Article-Updates
+See-Also
+Supersedes
+
+RFC 2298
+--------
+
+Disposition-Notification-To
+Disposition-Notification-Options
+Original-Recipient
+
+World Wide Web Consortium (W3C) Recommendations
+-----------------------------------------------
+
+Pics-Label
+
+Not Internet standard (as of December 2000)
+-------------------------------------------
+
+"From " (not followed by ":")
+Abouse-Reports-To
+Apparently-To
+Approved-By
+Content-Alias
+Content-Alternative
+Content-Class
+Content-Conversion
+Content-Features
+Content-Length
+Content-SGML-Entity
+Delivered-To
+Encoding
+Errors-To
+Fax
+Fcc
+For-Approval
+For-Comment
+For-Handling
+List-Digest
+List-ID
+List-URL
+Mail-Copies-To
+Mail-System-Version
+Mailer
+NNTP-Posting-Host
+Organisation
+Originating-Client
+Originator
+Originator-Info
+Phone
+Posted-To
+Precedence
+Registered-Mail-Reply-Requested-By
+Replaces
+Return-Receipt-Requested
+Return-Receipt-To
+Read-Receipt-To
+Speech-Act
+Status
+Supersedes
+Telefax
+Translated-By
+Translation-Of
+User-Agent
+X-Admin
+X-Confirm-Reading-To
+X-Complaints-To
+X-Envelope-From
+X-Envelope-To
+X-Face
+X-IMAP
+X-Loop
+X-List-Host
+X-Listserver
+X-Mailer
+X-MIME-Autoconverted
+X-MIMEOLE
+X-MSMail-Priority
+X-Newsreader
+X-No-Archive
+X-OriginalArrivalTime
+X-Priority
+X-RCPT-TO
+X-Report-Abuse-To
+X-Sender
+X-UIDL
+X-URI
+X-URL
+X-X-Sender
+X400-Content-Return
+
+                    Appendix B: Alphabetical index
+
+Section Header field
+------- ------------
+
+3.5     Abuse-Reports-To
+3.3     Also-Control
+3.3     Alternate-Recipient
+3.4     Apparently-To
+3.4     Approved
+3.4     Approved-By
+3.6     Article-Names
+3.6     Article-Updates
+         Auto-Forwarded see Autoforwarded
+3.17    Autoforwarded
+3.4     bcc
+3.4     cc
+         Client, see Originating-Client
+         Comment, see For-Comment
+3.7     Comments
+3.6     Content-Alias
+3.12    Content-Alternative
+3.6     Content-Base
+3.13    Content-Class
+3.12    Content-Conversion
+3.7     Content-Description
+3.3     Content-Disposition
+3.13    Content-Features
+3.6     Content-ID
+3.7     Content-Identifier
+3.10    Content-Language see also Language
+3.11    Content-Length
+3.6     Content-Location
+3.15    Content-MD5
+3.4     Content-Return
+3.13    Content-SGML-Entity
+3.13    Content-Transfer-Encoding
+3.13    Content-Type
+3.3     Control
+3.12    Conversion
+3.12    Conversion-With-Loss
+         Copy, see Incomplete-Copy
+3.8     Date, see also Delivery-Date, Received, Expires, Expiry-
+         Date
+3.6     Delivered-To
+3.8     Delivery-Date
+         Delivery-Report, see Generate-Delivery-Report, Prevent-
+         Delivery-Report, Non-Delivery-Report, Content-Type
+         Description, see Content-Description
+3.17    Discarded-X400-IPMS-Extensions
+3.17    Discarded-X400-MTS-Extensions
+3.3     Disclose-Recipients
+         Disposition, see also Content-Disposition
+3.5     Disposition-Notification-Options
+3.5     Disposition-Notification-To
+3.4     Distribution
+3.2     DL-Expansion-History
+3.13    Encoding see also Content-Transfer-Encoding
+3.4     Errors-To
+3.8     Expires
+3.8     Expiry-Date
+         Extension see Discarded-X400-IPMS-Extensions, Discarded-
+         X400-MTS-Extensions
+3.4     Fax see also Telefax
+3.17    Fcc
+3.4     Followup-To
+3.4     For-Approval
+3.4     For-Comment
+3.4     For-Handling
+         Forwarded, see Autoforwarded
+3.4     From (not followed by (":" or preceded by ">")
+3.4     From (followed by ":")
+3.4     Generate-Delivery-Report
+         Handling, see For-Handling
+         History, see DL-Expansion-History
+         ID, see Content-ID and Message-ID
+         Identifier, see Content-ID and Message-ID
+3.9     Importance
+3.6     In-Reply-To
+3.9     Incomplete-Copy
+3.7     Keywords
+         Label, see PICS-Label
+3.10    Language see also Content-Language
+         Length see Content-Length
+3.11    Lines
+3.16    List-Archive
+3.16    List-Digest
+3.16    List-Help
+3.16    List-ID
+3.16    List-Owner
+3.16    List-Post
+3.16    List-Software
+3.16    List-Subscribe
+3.16    List-URL
+3.16    List-Unsubscribe
+         Loss, see Conversion-With-Loss
+3.5     Mail-Copies-To
+3.4     Mail-System-Version see also X-mailer
+3.4     Mailer
+         MD5 see Content-MD5
+3.6     Message-ID
+3.13    Message-Type
+3.3     MIME-Version
+3.4     Newsgroups
+         Newsreader, see X-Newsreader
+3.3     NNTP-Posting-Host
+3.6     Obsoletes
+3.7     Organisation
+3.7     Organization
+3.3     Original-Encoded-Information-Types
+3.6     Original-Recipient
+3.4     Originating-Client
+3.4     Originator
+3.4     Originator-Info see also Sender
+3.2     Path
+3.4     Phone
+3.9     PICS-Label
+3.4     Posted-To
+3.9     Precedence
+3.4     Prevent-NonDelivery-Report
+3.9     Priority
+3.5     Read-Reciept-To
+3.2     Received
+         Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
+         Recipient
+3.6     References
+3.5     Registered-Mail-Reply-Requested-By
+3.6     Replaces
+3.8     Reply-By
+3.4     Reply-To, see also In-Reply-To, References
+3.14    Resent-
+         Return see Content-Return
+3.2     Return-Path
+3.5     Return-Receipt-Requested
+3.5     Return-Receipt-To
+3.6     See-Also
+3.4     Sender
+3.9     Sensitivity
+3.17    Speech-Act
+3.17    Status
+3.7     Subject
+3.7     Summary
+3.6     Supersedes
+3.4     Telefax see also Fax
+3.4     To
+         Transfer-Encoding see Content-Transfer-Encoding
+3.6     Translated-By
+3.6     Translation-Of
+         Type see Content-Type, Message-Type, Original-Encoded-
+         Information-Types
+3.4     User-Agent
+         Version, see MIME-Version, X-Mailer
+3.4     X-Admin
+3.4     X-Complaints-To
+3.5     X-Confirm-Reading-To
+3.4     X-Envelope-From
+3.4     X-Envelope-To
+3.4     X-Face
+3.6     X-IMAP
+3.16    X-List-Host
+3.16    X-Listserver
+3.6     X-Loop
+3.4     X-Mailer see also Mail-System-Version
+3.13    X-MIME-Autoconverted
+3.4     X-MimeOLE
+3.9     X-MSMail-Priority
+3.4     X-Newsreader
+3.17    X-No-Archive
+3.8     X-OriginalArrivaltime
+3.9     X-Priority
+3.4     X-Report-Abuse-To
+3.4     X-RCPT-TO
+3.4     X-Sender see also Originator-Info
+3.6     X-UIDL
+3.6     X-URI
+3.6     X-URL see also Content-Location
+3.4     X-X-Sender see also Originator-Info
+3.4     X400-Content-Return
+3.15    Xref
diff --git a/Documentation/en/I-D/draft-palme-mailext-headers-05.txt b/Documentation/en/I-D/draft-palme-mailext-headers-05.txt
new file mode 100644
index 00000000..9901bb21
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-mailext-headers-05.txt
@@ -0,0 +1,1842 @@
+Network Working Group                                     Jacob Palme
+Internet Draft                               Stockholm University/KTH
+draft-palme-mailext-headers-05.txt                             Sweden
+Category: Informational                                Date: May 2001
+Revision of: RFC 2076                          Expires: November 2001
+
+
+
+                   Common Internet Message Header Fields
+
+                         Status of this Memo
+
+This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright (C) The Internet Society 2001. All Rights
+Reserved.
+
+
+                             Abstract
+
+This memo contains tables of commonly occurring header fields in
+headings of e-mail messages. The document compiles information from
+other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 2156, RFC 1496,
+RFC 1766, RFC 2183, RFC 1864, RFC 2421 and RFC 2045. A few commonly
+occurring header fields which are not defined in RFCs are also
+included. For each header field, the memo gives a short description
+and a reference to the RFC in which the header field is defined.
+
+The latest, revised version of this document can be found at URL
+http://www.dsv.su.se/jpalme/ietf/mail-headers/. The version at that
+URL may be more recent than the version published as an RFC.
+
+Another list of headers can be found at URL
+http://www.hut.fi/~jkorpela/headers.html
+
+
+                   Changes since previous version
+
+This document is a revision of RFC 2076. The following new header
+fields, not included in RFC 2076, have been added:
+Abuse-Reports-To:, Also-Control, Approved-By, Content-Alias, Content-
+Alternative, Content-Class, Content-Conversion, Content-Features,
+Content-ID, Delivered-To, Disposition-Notification-Options,
+Disposition-Notification-To, Expiry-Date, For-Approval, List-Archive,
+List-Digest, List-Help, List-ID, List-Owner, List-Post, List-
+Software, List-Subscribe, List-Unsubscribe, List-URL, Mail-Copies-
+To:, Original-Recipient, Originator, Originator-Info, Path, PICS-
+Label, NNTP-Posting-Host, Posted-To:, Read-Receipt-To, Received,
+Registered-Mail-Reply-Requested-By, Replaces, Return-Receipt-
+Requested, Speech-Act, Translated-By. Translation-Of, User-Agent, X-
+Confirm-Reading-To, X-Complaints-To:, X-Envelope-From, X-Envelope-To,
+X-Face, X-List-Host, X-Listserver, X-Loop, X-MIME-Autoconverted, X-No-
+Archive, X-OriginalArrivalTime, X-Priority, X-Report-Abuse-To, X-
+Sender, X-X-Sender, X-UIDL, X-URL, X-URI.
+
+
+                          Table of contents
+
+      Abstract                                                       2
+      Changes since previous version                                 2
+1. Introduction                                                     3
+2. Use of gatewaying header fields                                  5
+3. Table of header fields                                           5
+      3.1 Phrases used in the tables                                 5
+      3.2 Trace information                                          6
+      3.3 Format and control information                             7
+      3.4 Sender and recipient indication                            8
+      3.5 Response control                                          13
+      3.6 Message identification and referral header fields         16
+      3.7 Other textual header fields                               19
+      3.8 Header fields containing dates and times                  19
+      3.9 Quality information                                       20
+      3.10 Language information                                     21
+      3.11 Size information                                         21
+      3.12 Conversion control                                       22
+      3.13 Encoding information                                     22
+      3.14 Resent-header fields                                     24
+      3.15 Security and reliability                                 25
+      3.16 Mailing list control                                     25
+      3.17 Miscellaneous                                            26
+4. Acknowledgments                                                 28
+Copyright and disclaimer                                           28
+5. References                                                      29
+6. Author's address                                                31
+Appendix A:                                                        32
+Header fields sorted by Internet RFC document in which they
+appear.                                                            32
+      RFC 822                                                       32
+      RFC 976                                                       32
+      RFC 1049                                                      32
+      RFC 1036                                                      33
+      RFC 1123                                                      33
+      RFC 2156                                                      33
+      RFC 1505                                                      34
+      RFC 1766                                                      34
+      RFC 2183                                                      34
+      RFC 1864                                                      34
+      RFC 2421                                                      34
+      RFC 2045                                                      34
+      RFC 2110                                                      34
+      RFC 2369                                                      34
+      son-of-RFC1036 [21]                                           35
+      draft-ietf-receipt                                            35
+      World Wide Web Consortium (W3C) Recommendations               35
+      Not Internet standard (as of May 2001)                        35
+Appendix B: Alphabetical index                                     36
+
+
+                          1. Introduction
+
+Many different Internet standards and RFCs define header fields which
+may occur on Internet Mail Messages and Usenet News Articles. The
+intention of this document is to list all such header fields in one
+document as an aid to people developing message systems or interested
+in Internet Mail standards.
+
+The document contains all header fields which the author has found in
+the following Internet standards: RFC 822 [2], RFC 1036 [3], RFC 1123
+[5], RFC 2156 [7], RFC 1496 [8], RFC 2045 [11], RFC 1766 [12], RFC
+2183 [14], RFC 1864[17] and RFC 2421[20]. Note in particular that
+heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
+[16]) are not included. PEM and MOSS header fields only appear inside
+the body of a message, and thus are not header fields in the RFC 822
+sense. Mail attributes in envelopes, i.e. attributes controlling the
+message transport mechanism between mail and news servers, are not
+included. This means that attributes from SMTP [1], UUCP [18] and
+NNTP [15] are mainly not covered either. Headings used only in HTTP
+[19] are not included yet, but may be included in future version of
+this memo. Some additional header fields which often can be found in
+e-mail headings but are not part of any Internet standard are also
+included.
+
+The author does not promise that this document contains a complete
+list of all heading fields which are specified in any standard or
+used by any mailer.
+
+For each header field, the document gives a short description and a
+reference to the Internet standard or RFC, in which they are defined.
+
+The header field names given here are spelled the same way as when
+they are actually used. This is usually American but sometimes
+English spelling.  One header field in particular,
+"Organisation/Organization", occurs in e-mail header fields sometimes
+with the English and other times with the American spelling.
+
+The following words are used in this memo with the meaning specified
+below:
+
+heading         Formatted text at the top of a message, ended by a
+                 blank line
+
+header field    One field in the heading, beginning with a field
+                 name, colon, and followed by the field value(s). The
+                 words "heading field" and "header" are also
+                 sometimes used with this meaning.
+
+It is my intention to continue updating this document after its
+publication as an RFC. The latest version, which may be more up-to-
+date (but also less fully checked out) will be kept available for
+downloading from URL
+http://www.dsv.su.se/jpalme/ietf/mail-headers
+
+Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
+header fields which should be included in this memo but are not.
+
+
+                  2. Use of gatewaying header fields
+
+RFC 2156 defines a number of new header fields in Internet mail,
+which are defined to map header fields which X.400 has but which were
+previously not standardized in Internet mail. The fact that a header
+field occurs in RFC 2156 indicates that it is recommended for use in
+gatewaying messages between X.400 and Internet mail, but does not
+mean that the header field is recommended for messages wholly within
+Internet mail. Some of these header fields may eventually see
+widespread implementation and use in Internet mail, but at the time
+of this writing (2001) they are not widely implemented or used.
+
+Header fields defined only in RFC 1036 for use in Usenet News
+sometimes appear in mail messages, either because the messages have
+been gatewayed from Usenet News to e-mail, or because the messages
+were written in combined clients supporting both e-mail and Usenet
+News in the same client. These header fields are not standardized for
+use in Internet e-mail and should be handled with caution by e-mail
+agents.
+
+
+                       3. Table of header fields
+
+**** 3.1 Phrases used in the tables
+
+"not for general        Used to mark header fields which are defined
+usage"                  in RFC 2156 for use in messages from or to
+                         Internet mail/X.400 gateways. These header
+                         fields have not been standardized for general
+                         usage in the exchange of messages between
+                         Internet mail-based systems.
+
+"not standardized       Used to mark header fields defined only in RFC
+for use in e-mail"      1036 for use in Usenet News. These header
+                         fields have no standard meaning when appearing
+                         in e-mail, some of them may even be used in
+                         different ways by different software. When
+                         appearing in e-mail, they should be handled
+                         with caution. Note that RFC 1036, although
+                         generally used as a de-facto standard for
+                         Usenet News, is not an official IETF standard
+                         or even on the IETF standards track.
+
+"non-standard"          This header field is not specified in any of
+                         referenced RFCs which define Internet
+                         protocols, including Internet Standards, draft
+                         standards or proposed standards. The header
+                         field appears here because it often appears in
+                         e-mail or Usenet News. Usage of these header
+                         fields is not in general recommended. Some
+                         header field proposed in ongoing IETF
+                         standards development work, but not yet
+                         accepted, are also marked in this way.
+
+"discouraged"           This header field, which is non-standard, is
+                         known to create problems and should not be
+                         generated. Handling of such header fields in
+                         incoming mail should be done with great
+                         caution.
+
+"controversial"         The meaning and usage of this header field is
+                         controversial, i.e. different implementors
+                         have chosen to implement the header field in
+                         different ways. Because of this, such header
+                         fields should be handled with caution and
+                         understanding of the different possible
+                         interpretations.
+
+"experimental"          This header field is used for newly defined
+                         header fields, which are to be tried out
+                         before entering the IETF standards track.
+                         These should only be used if both
+                         communicating parties agree on using them. In
+                         practice, some experimental protocols become
+                         de-facto-standards before they are made into
+                         IETF standards.
+
+
+**** 3.2 Trace information
+
+Trace of distribution lists          DL-Expansion-   RFC 2156, not for
+passed.                              History:        general usage.
+
+List of MTAs passed.                 Path:           RFC 1036: 2.1.6,
+                                                      only in Usenet
+                                                      News, not in e-
+                                                      mail.
+
+Trace of MTAs which a message has    Received:       RFC 822: 4.3.2,
+passed.                                              RFC 1123: 5.2.8.
+
+Used to convey the information       Return-Path:    RFC 821,
+from the MAIL FROM envelope                          RFC 1123: 5.2.13.
+attribute in final delivery, when
+the message leaves the SMTP
+environment in which "MAIL FROM"
+is used.
+
+The netnews host, to which this      NNTP-Posting-   Non-standard,
+article was originally posted.       Host:           common in netnews
+Useful for finding the sender of
+spams. Since this header is added
+by the news server, it is a
+little more difficult to forge
+than other header fields.
+
+
+**** 3.3 Format and control information
+
+Special Usenet News commands and     Also-Control:   son-of-RFC1036
+a normal article at the same                         [21], non-
+time.                                                standard, only in
+                                                      Usenet News, not
+                                                      in e-mail
+
+Controls whether this message may    Alternate-      RFC 2156, not for
+be forwarded to alternate            Recipient:      general usage.
+recipients such as a postmaster
+if delivery is not possible to
+the intended recipient. Default:
+Allowed.
+
+Whether a MIME body part is to be    Content-        RFC 2183,
+shown inline or is an attachment;    Disposition:    experimental
+can also indicate a suggested
+filename for use when saving an
+attachment to a file.
+
+Can have the values "voice-          Message-        Non-standard
+message", "fax-message", "pager-     Context:
+message", "multimedia-message",
+"text-message", "none"
+
+Only in Usenet News, contains        Control:        RFC 1036: 2.1.6,
+commands to be performed by News                     only in Usenet
+agents.                                              News, not in e-
+                                                      mail.
+
+Whether recipients are to be told    Disclose-       RFC 2156, not for
+the names of other recipients of     Recipients:     general usage.
+the same message. This is
+primarily an X.400 facility. In
+X.400, this is an envelope
+attribute and refers to
+disclosure of the envelope
+recipient list. Disclosure of
+other recipients is in Internet
+mail done via the To:, cc: and
+bcc: header fields.
+
+An indicator that this message is    MIME-Version:   RFC 2045: 4.
+formatted according to the MIME
+standard, and an indication of
+which version of MIME is
+utilized.
+
+Which body part types occur in       Original-       RFC 2156, not for
+this message.                        Encoded-        general usage.
+                                      Information-
+                                      Types:
+
+
+**** 3.4 Sender and recipient indication
+
+Inserted by Sendmail when there      Apparently-     Non-standard,
+is no "To:" recipient in the         To:             discouraged,
+original message, listing                            mentioned in
+recipients derived from the                          RFC 1211.
+envelope into the message
+heading. This behavior is not
+quite proper, MTAs should not
+modify headings (except inserting
+Received lines), and it can in
+some cases cause Bcc recipients
+to be wrongly divulged to non-Bcc
+recipients.
+
+Name of the moderator of the         Approved:       RFC 1036: 2.2.11,
+newsgroup to which this article                      not standardized
+is sent; necessary on an article                     for use in e-mail.
+sent to a moderated newsgroup to
+allow its distribution to the
+newsgroup members. Also used on
+certain control messages, which
+are only performed if they are
+marked as Approved.
+
+Name of the moderator of a           Approved-By:    Non-standard, used
+mailing list, and who has                            by some mailing
+approved this message for                            list expansion
+distribution to the members of                       systems.
+the list.
+Recipients not to be disclosed to    bcc:            RFC 822: 4.5.3,
+other recipients. (bcc = Blind                       RFC 1123: 5.2.15-
+Carbon Copy).                                        16, 5.3.7.
+
+Secondary, informational             cc:             RFC 822: 4.5.2,
+recipients. (cc = Carbon Copy)                       RFC 1123. 5.2.15-
+                                                      16, 5.3.7.
+
+Geographical or organizational       Distribution:   RFC 1036: 2.2.7,
+limitation on where this article                     not standardized
+can be distributed. Value can be                     for use in e-mail.
+a compete or incomplete domain
+names, also various special
+values are accepted like "world",
+"usenet", "USA", etc.
+
+Fax number of the originator.        Fax:,           Non-standard.
+                                      Telefax:
+
+Primary recipients, who are          For-Approval:   Non-standard
+requested to approve the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Comment:    Non-standard
+requested to comment on the
+information in this message or
+its attachments.
+
+Primary recipients, who are          For-Handling:   Non-standard
+requested to handle the
+information in this message or
+its attachments.
+
+(2) Used in Usenet News mail         From            RFC 976: 2.4 for
+transport, to indicate the path      or              use in Usenet News
+through which an article has gone    >From
+when transferred to a new host.      (not followed
+                                      by a colon)
+Sometimes called "From_" header
+field.
+
+(1) This header field should         From (not       not standardized
+never appear in e-mail being         followed by a   for use in e-mail
+sent, and should thus not appear     colon)
+in this memo. It is however
+included, since people often ask
+about it.
+
+This header field is used in the
+so-called Unix mailbox format,
+also known as Berkely mailbox
+format or the MBOX format. This
+is a format for storing a set of
+messages in a file. A line
+beginning with "From " is used to
+separate successive messages in
+such files.
+
+This header field will thus
+appear when you use a text editor
+to look at a file in the Unix
+mailbox format. Some mailers also
+use this format when printing
+messages on paper.
+
+The information in this header
+field should NOT be used to find
+an address to which replies to a
+message are to be sent.
+
+Authors or persons taking            From:           RFC 822: 4.4.1,
+responsibility for the message.                      RFC 1123: 5.2.15-
+                                                      16, 5.3.7,
+Note difference from the "From "                     RFC 1036 2.1.1
+header field (not followed by
+":") below.
+
+
+Information about the client         Mail-System-    Non-standard.
+software of the originator.          Version:,
+                                      Mailer:,
+                                      Originating-
+                                      Client:, X-
+                                      Mailer, X-
+                                      Newsreader, X-
+                                      MimeOLE:,
+                                      User-Agent:
+
+In Usenet News: group(s) to which    Newsgroups:     RFC 1036: 2.1.3,
+this article was posted.                             not standardized
+Some systems provide this header                     and controversial
+field also in e-mail although it                     for use in e-mail.
+is not standardized there.
+Unfortunately, the header field
+can appear in e-mail with three
+different and contradictory
+meanings:
+
+(a) Indicating the newsgroup
+recipient of an article/message
+sent to both e-mail and Usenet
+News recipients.
+
+(b) In a message adressed to some
+mail to news gateways, indicates
+the newsgroup(s) that the message
+is to be posted to.
+
+(c) In a personally addressed
+reply to an article in a news-
+group, indicating the newsgroup
+in which this discussion
+originated.
+
+See also: "Posted-To:".
+
+Sometimes used in Usenet News in     Originator:     Non-standard in
+similar ways to "Sender:"                            Usenet News,
+                                                      Experimental in
+Also used in printing protocols.                     RFC 1528.
+
+Contains information about the       Originator-     Non-standard [25]
+authentication of the originator     Info:
+in a format which is not easily
+used to send email to, to avoid
+the problems with "Sender" and "X-
+Sender".
+
+Phone number of the originator.      Phone:          Non-standard.
+
+The person or agent submitting       Sender:         RFC 822: 4.4.2,
+the message to the network, if                       RFC 1123: 5.2.15-
+other than shown by the From:                        16, 5.3.7, RFC
+header field. Should be                              1036.
+authenticated,
+according to RFC 822, but what
+kind of authentication is not
+clear. Some implementations
+expect that the e-mail address
+used in this field can be used to
+reach the sender, others do not.
+See also "X-Sender".
+
+Primary recipients.                  To:             RFC 822: 4.5.1,
+                                                      RFC 1123: 5.2.15-
+                                                      16, 5.3.7.
+
+If the sender in the envelope        X-Envelope-     Non-standard.
+(SMTP "RCTP TO") is not the same     From:
+as the senders in the "From" or
+"Sender" RFC822 header fields,
+some mail servers add this to the
+RFC822 header fields as an aid to
+clients which would otherwise not
+be able to display this
+information.
+
+If the recipient in the envelope     X-Envelope-     Non-standard.
+(SMTP "MAIL FROM") is not            To:,
+included in the CC list, some        Envelope-To:
+mail servers add this to the
+RFC822 header field as an aid to
+clients which would otherwise not
+be able to display the envelope
+recipients.
+
+48x48 bitmap with picture of the     X-Face:         Non-Standard
+sender of this message.
+
+Indication in the mail header of     X-RCPT-TO:      Non-standard
+recipient on the SMTP envelope.
+
+Some mail software expect            X-Sender:       Non-standard
+"Sender:" to be an e-mail address
+which you can send mail to.
+However, some mail software has
+as the best authenticated sender
+a POP or IMAP account, which you
+might not be able to send to.
+Because of this, some mail
+software put the POP or IMAP
+account into an X-sender header
+field instead of a Sender header
+field, to indicate that you may
+not be able to send e-mail to
+this address. See also "X-X-
+Sender".
+
+Another use of" X-Sender:" is
+that some e-mail software, which
+wants to insert a "Sender:"
+header, will first change an
+existing "Sender:" header to "X-
+Sender". This use is actually
+often the same as that described
+in the previous paragraph, since
+the new "Sender:" is added
+because it is better
+authenticated than the old value.
+
+Even though some systems put the     X-X-Sender:     Non-standard
+POP or IMAP account name into the
+"X-Sender:" instead of the Sender
+header field, some mail software
+tries to send to the "X-Sender:"
+too. To stop this, some systems
+have begun to use "X-X-Sender:"
+to indicate an authentication of
+the sender which might not be
+useable to send e-mail to. See
+also "Originator-Info:"
+
+When a message is sent both to       Posted-To:      Non-standard
+netnews and e-mail, this header
+is used in the e-mail version of
+the message to indicate which
+newsgroup it was sent to. This
+header thus contains the same
+information as the "Newsgroups:"
+header in the netnews version of
+the message.
+
+E-mail address of administrator      X-Admin:        Non-standard
+of a server, through which this
+message was submitted.
+
+
+**** 3.5 Response control
+
+Indicates whether the content of     Content-        RFC 2156, not for
+a message is to be returned with     Return:         general usage.
+non-delivery notifications.
+For future options on disposition    Disposition-    RFC 2298
+notifications.                       Notification-
+                                      Options:
+
+
+Indicate that the sender wants a     Disposition-    RFC 2298
+dispoisition notification when       Notification-
+this message is received (read,      To:
+processed, etc.) by its
+receipents.
+
+Address to which notifications       Errors-To:,     Non-standard,
+are to be sent and a request to      Return-         discouraged, some
+get delivery notifications.          Receipt-To:,    of them widely
+Internet standards recommend,        Read-Receipt-   used.
+however, the use of MAIL FROM and    To:, X-
+Return-Path, not Errors-To, for      Confirm-
+where delivery notifications are     reading-to:,
+to be sent.                          Return-
+                                      Receipt-
+                                      Requested,
+                                      Register-Mail-
+                                      Reply-
+                                      Requested-By:
+
+Used in Usenet News to indicate      Followup-To:    RFC 1036: 2.2.3,
+that future discussions (=follow-                    not standardized
+up) on an article should go to a                     for use in e-mail.
+different set of newsgroups than
+the replied-to article. The most
+common usage is when an article
+is posted to several newsgroups,
+and further discussions is to
+take place in only one of them.
+
+In e-mail, this header field may
+occur in a message which is sent
+to both e-mail and Usenet News,
+to show where follow-up in Usenet
+news is wanted. The header field
+does not say anything about where
+follow-up in e-mail is to be
+sent.
+
+The value of this header field
+should be one or more newsgroup
+names.
+
+The special value "poster" as in
+"Followup-To: poster" means that
+replies are to be sent as e-mail
+to the author only.
+
+Whether a delivery report is         Generate-       RFC 2156, not for
+wanted at successful delivery.       Delivery-       general usage.
+Default is not to generate such a    Report:
+report.
+Original Recipient information       Original-       RFC 2298
+for inclusion in disposition         Recipient
+notifications.
+
+Whether non-delivery report is       Prevent-        RFC 2156, not for
+wanted at delivery error. Default    NonDelivery-    general usage.
+is to want such a report.            Report:
+
+This header field is meant to        Reply-To:       RFC 822: 4.4.3,
+indicate where the sender wants                      RFC 1036: 2.2.1
+replies to go. Unfortunately,                        controversial.
+this is ambiguous, since there
+are different kinds of replies,
+which the sender may wish to go
+to different addresses. In
+particular, there are personal
+replies intended for only one
+person, and group replies,
+intended for the whole group of
+people who read the replied-to
+message (often a mailing list,
+anewsgroup name cannot appear
+here because of different syntax,
+see "Followup-To" below.).
+
+Some mail systems use this header    Reply-To2
+field to indicate a better form
+of the e-mail address of the
+sender. Some mailing list
+expanders puts the name of the
+list in this header field. These
+practices are controversial. The
+personal opinion of the author of
+this RFC is that this header
+field should be avoided except in
+special cases, but this is a
+personal opinion not shared by
+all specialists in the area.
+
+Indicates where to send complains    Abuse-Reports-  non-standard
+if you get a message which you       To:, X-
+think is against the laws or         Complaints-
+rules.                               To:, X-Report-
+                                      Abuse-To:
+
+Used in netnews articles to          Mail-Copies-    non-standard, but
+indicate that followup (=replies)    To:             commonly supported
+should be sent to the indicated e-                   by newsreaders
+mail address.
+Possible future change of name       X400-Content-   non-standard
+for "Content-Return:"                Return:
+
+
+**** 3.6 Message identification and referral header fields
+
+Reference to specially important     Article-        son-of-RFC1036
+articles for a particular Usenet     Names:          [21], non-standard
+Newsgroup.
+Only in Usenet News, similar to      Article-        son-of-RFC1036
+"Supersedes:" but does not cause     Updates:        [21], non-standard
+the referenced article to be
+physically deleted.
+
+Used in addition to Content-         Content-        Work in progress
+Location if this content part can    Alias:
+be retrieved through more than
+one URI. Only one of them is
+allowed in the Content-Location,
+the other can be specified in
+Content-Alias.
+
+Base to be used for resolving        Content-Base:   RFC 2110
+relative URIs within this content
+part.
+
+Unique ID of one body part of the    Content-ID:     RFC 2045: 7.
+content of a message.
+URI with which the content of        Content-        RFC 2110
+this content part might be           Location:
+retrievable.
+Used by some automatic services      Delivered-To:   non-standard
+(mainly MLMs and autoresponders)     or
+for the purpose of loop              X-Loop:
+detection. The service adds the
+Delivered-To header to outgoing
+messages, with its e-mail address
+as a value, and discards incoming
+messages which already have it.
+
+Reference to message which this      In-Reply-To:    RFC 822: 4.6.2.
+message is a reply to.
+Unique ID of this message.           Message-ID:     RFC 822: 4.6.1
+                                                      RFC 1036: 2.1.5.
+
+Reference to previous message        Obsoletes:      RFC 2156, not for
+being corrected and replaced.                        general usage.
+Compare to "Supersedes:" below.
+This field may in the future be
+replaced with "Supersedes:".
+
+In e-mail: reference to other        References:     RFC 822: 4.6.3
+related messages, in Usenet News:                    RFC 1036: 2.1.5.
+reference to replied-to-articles.
+Still another name for similar       Replaces:       non-standard,
+functionality as for "Obsoletes:"                    proposed in IETF
+and "Supersedes:". This may                          USEFOR working
+become the most recommended                          group
+header in the future, but is
+still under discussion in IETF
+standards development work.
+
+References to other related          See-Also:       Son-of-RFC1036
+articles in Usenet News.                             [21], non-standard
+
+Commonly used in Usenet News in      Supersedes:     son-of-RFC1036
+similar ways to the "Obsoletes"                      [21], non-standard
+header field described above. In
+Usenet News, however, Supersedes
+causes a full deletion of the
+replaced article in the server,
+while "Supersedes" and
+"Obsoletes" in e-mail is
+implemented in the client and
+often does not remove the old
+version of the text.
+
+Mailbox of the person who made       Translated-     non-standard
+the translation.                     By:
+
+Reference to the Message-ID of a     Translation-    non-standard
+message, which the current           Of:
+message is a translation of.
+
+Unique identifier for a message,     X-UIDL:         non-standard
+local to a particular local
+mailbox store. The UIDL
+identifier is defined in the POP3
+standard, but not the "X-UIDL:"
+header.
+
+Similar usage as "X-URL". The URI    X-URI:          Non-standard
+can be either a URL or a URN.
+URNs are meant to become more
+persistent references to
+resources than URLs.
+
+Sometimes used with the same         X-URL:          Non-standard
+meaning as "Content-Location:",
+sometimes to indicate the web
+home page of the sender or of his
+organisation.
+
+The UID, as defined in the IMAP      X-IMAP:         Non-standard
+standard. Only used in internal
+mailbox storage in some mail
+systems, should never be visible
+to a user.
+
+
+**** 3.7 Other textual header fields
+
+Comments on a message.               Comments:       RFC 822: 4.7.2.
+
+Description of a particular body     Content-        RFC 2045: 8.
+part of a message, for example a     Description:
+caption for an image body part.
+A text string which identifies       Content-        RFC 2156, not for
+the content of a message.            Identifier:     general usage.
+
+Search keys for data base            Keywords:       RFC 822: 4.7.1
+retrieval.                                           RFC 1036: 2.2.9.
+
+See Organization above.              Organisation:   Non-standard.
+
+Organization to which the sender     Organization:   RFC 1036: 2.2.8,
+of this article belongs.                             not standardized
+                                                      for use in e-mail.
+
+Title, heading, subject. Often       Subject:        RFC 822: 4.7.1
+used as thread indicator for                         RFC 1036: 2.1.4.
+messages replying to or
+commenting on other messages.
+
+Short text describing a longer       Summary:        RFC 1036: 2.2.10,
+article. Warning: Some mail                          not standardized
+systems will not display this                        for use in e-mail,
+text to the recipient. Because of                    discouraged.
+this, do not use this header
+field for text which you want to
+ensure that the recipient gets.
+
+
+**** 3.8 Header fields containing dates and times
+
+In Internet, the date when a         Date:           RFC 822: 5.1,
+message was written, in X.400,                       RFC 1123: 5.2.14
+the time a message was submitted.                    RFC 1036: 2.1.2.
+Some Internet mail systems also
+use the date when the message was
+submitted.
+
+The time when a message was          Delivery-       RFC 2156, not for
+delivered to its recipient.          Date:           general usage.
+
+A suggested expiration date. Can     Expires:        RFC 1036: 2.2.4,
+be used both to limit the time of                    not standardized
+an article which is not                              for use in e-mail.
+meaningful after a certain date,
+and to extend the storage of
+important articles.
+
+Time at which a message loses its    Expiry-Date:    RFC 2156, not for
+validity. This field may in the                      general usage.
+future be replaced by "Expires:".
+Latest time at which a reply is      Reply-By:       RFC 2156, not for
+requested (not demanded).                            general usage.
+
+Time when this message was           X-OriginalArr   Non-standard
+delivered into the message           ivalTime:
+transport system (usually the
+same time as in the last
+"Received:" header)
+
+
+**** 3.9 Quality information
+
+A hint from the originator to the    Importance:     RFC 2156 and
+recipients about how important a                     RFC 2421, proposed
+message is. Values: High, normal
+or low. Not used to control
+transmission speed.
+
+Body parts are missing.              Incomplete-     RFC 2156, not for
+                                      Copy:           general usage.
+
+Ratings label to control             PICS-Label:     REC-PICS-labels,
+selection (filtering) of messages                    W3C document [23].
+according to the PICS protocol.
+Sometimes used as a priority         Precedence:     Non-standard,
+value which can influence                            controversial,
+transmission speed and delivery.                     widely used.
+Common values are "bulk" and
+"first-class". Other uses is to
+control automatic replies and to
+control return-of-content
+facilities, and to stop mailing
+list loops.
+
+Can be "normal", "urgent" or "non-   Priority:       RFC 2156, not for
+urgent" and can influence                            general usage.
+transmission speed and delivery.
+How sensitive it is to disclose      Sensitivity:    RFC 2156 and
+this message to other people than                    RFC 2421, proposed
+the specified recipients. Values:
+Personal, private, company
+confidential. The absence of this
+header field in messages
+gatewayed from X.400 indicates
+that the message is not
+sensitive.
+
+Yet another priority indication.     X-MSMail-       Non-standard
+                                      Priority:
+
+Values: 1 (Highest), 2 (High), 3     X-Priority:     Non-standard [24]
+(Normal), 4 (Low), 5 (Lowest). 3
+(Normal) is default if the field
+is omitted.
+
+
+**** 3.10 Language information
+
+Can include a code for the           Content-        RFC 1766, proposed
+natural language used in a           Language:       standard.
+message, e.g. "en" for English.
+Can include a code for the           Language:       RFC 2156, not for
+natural language used in a                           general usage.
+message, e.g. "en" for English.
+
+
+**** 3.11 Size information
+
+Inserted by certain mailers to       Content-        Non-standard,
+indicate the size in bytes of the    Length:         discouraged.
+message text. This is part of a
+format some mailers use when
+showing a message to its users,
+and this header field should not
+be used when sending a message
+through the net. The use of this
+header field in transmission of a
+message can cause several
+robustness and interoperability
+problems.
+
+Size of the message.                 Lines:          RFC 1036: 2.2.12,
+                                                      not standardized
+                                                      for use in e-mail.
+
+
+**** 3.12 Conversion control
+
+Information on where an              Content-        Non-standard [27].
+alternative variant of this          Alternative:
+document might be found.
+Non-standard variant of              Content-        Non-standard.
+Conversion: with the same values.    Conversion:
+
+The body of this message may not     Conversion:     RFC 2156, not for
+be converted from one character                      general usage.
+set to another. Values:
+Prohibited and allowed.
+
+The body of this message may not     Conversion-     RFC 2156, not for
+be converted from one character      With-Loss:      general usage.
+set to another if information
+will be lost. Values: Prohibited
+and allowed.
+
+
+**** 3.13 Encoding information
+
+Type information of the content      Content-        non-standard
+in some class hierarchy. Class       Class:
+hierarchies are commonly used to
+classify data structures in
+software development.
+
+Can give more detailed               Content-        Proposed Standard,
+information about the Content-       Features:       RFC 2912
+Type. Example:
+
+Content-features:
+   (& (Type="image/tiff")
+   (color=Binary)
+   (image-file-structure=TIFF-S)
+   (dpi=200)
+   (dpi-xyratio=200/100)
+   (paper-size=A4)
+   (image-coding=MH) (MRC-mode=0)
+   (ua-media=stationery) )
+
+This header is meant to be used
+when you can choose between
+different versions of a resource,
+such as when using
+multipart/atlernative.
+
+Information from the SGML entity     Content-SGML-   non-standard
+declaration corresponding to the     Entity:
+entity contained in the body of
+the body part.
+
+Coding method used in a MIME         Content-        RFC 2045: 6.
+message body.                        Transfer-
+                                      Encoding:
+
+Format of content (character set     Content-Type:   RFC 1049,
+etc.) Note that the values for                       RFC 1123: 5.2.13,
+this header field are defined in                     RFC 1766: 4.1
+different ways in RFC 1049 and in                    RFC 2045: 5.
+MIME (RFC 2045), look for the
+"MIME-version" header field to
+understand if Content-Type is to
+be interpreted according to RFC
+1049 or according to MIME. The
+MIME definition should be used in
+generating mail. RFC 1049 has
+"historic" status.
+
+RFC 1766 defines a parameter
+"difference" to this header
+field.
+
+Various other Content-Type define
+various additional parameters.
+For example, the parameter
+"charset" is mandatory for all
+textual Content-Types.
+
+Used in several different ways by    Encoding:       RFC 1154,
+different mail systems. Some use                     RFC 1505,
+it for a kind of content-type                        experimental.
+information, some for encoding
+and length information, some for
+a kind of boundary information,
+some in other ways.
+
+Only used with the value             Message-Type:   RFC 2156, not for
+"Delivery Report" to indicates                       general usage.
+that this is a delivery report
+gatewayed from X.400.
+
+Information about conversion of      X-MIME-         non-standard
+this message on the path from        Autoconverted:
+sender to recipient, like
+conversion between MIME encoding
+formats. Note: Auto-conversion
+may invalidate digital seals and
+signatures.
+
+
+**** 3.14 Resent-header fields
+
+When manually forwarding a           Resent-Reply-   RFC 822: C.3.3.
+message, header fields referring     To:,
+to the forwarding, not to the        Resent-From:,
+original message.  Note: MIME        Resent-
+specifies another way of             Sender:,
+resending messages, using the        Resent-From:,
+"Message" Content-Type.              Resent-Date:,
+                                      Resent-To:,
+                                      Resent-cc:,
+                                      Resent-bcc:,
+                                      Resent-
+                                      Message-ID:
+
+
+**** 3.15 Security and reliability
+
+Checksum of content to ensure        Content-MD5:    RFC 1864, proposed
+that it has not been modified.                       standard.
+
+Used in Usenet News to store         Xref:           RFC 1036: 2.2.13,
+information to avoid showing a                       only in Usenet
+reader the same article twice if                     News, not in e-
+it was sent to more than one                         mail.
+newsgroup. Only for local usage
+within one Usenet News server,
+should not be sent between
+servers.
+
+
+**** 3.16 Mailing list control
+
+Contains URL to use to browse the    List-Archive:   RFC 2369 [26]
+archives of the mailing list from
+which this message was relayed.
+
+URL to use to get a subscription     List-Digest:    Non-standard
+to the digest version of the
+mailing list from which this
+message was relayed.
+
+Contains URL to use to get a         List-Help:      RFC 2369 [26]
+information about the mailing
+list from which this message was
+relayed.
+
+Stores an identification of the      List-ID:        RFC 2919 [27].
+mailing list, through which this
+message was distributed.
+
+Non-standard precursors to List-     Mailing-        Non-standard
+ID and List-Post.                    List:, X-
+                                      Mailing-List:
+
+Contains URL to send e-mail to       List-Owner:     RFC 2369 [26]
+the owner of the mailing list
+from which this message was
+relayed.
+
+Contains URL to use to send          List-Post:      RFC 2369 [26]
+contributions to the mailing list
+from which this message was
+relayed.
+
+Information about the software       List-           Non-standard, has
+used in a mailing list expander      Software:       been considered
+through which this message has                       for inclusion in
+passed.                                              [26].
+
+Contains URL to use to get a         List-           RFC 2369 [26]
+subscription to the mailing list     Subscribe:
+from which this message was
+relayed.
+
+Contains URL to use to               List-           RFC 2369 [26]
+unsubscribe the mailing list from    Unsubscribe:
+which this message was relayed.
+
+Contains URL where information of    List-URL:       Non-standard
+various kinds about the mailing
+list from which this message was
+relayed.
+
+Information about the server and     X-              Non-standard.
+software used in a mailing list      Listserver:,    Recommended to use
+expander through which this          X-List-Host:    "List-Software"
+message has passed. Warning:                         instead.
+"Listserv" is a trademark and
+should not be used for other than
+the "Listserv" product. Use,
+instead the "List-Software"
+header field.
+
+
+**** 3.17 Miscellaneous
+
+Has been automatically forwarded.    Autoforwarded   RFC 2156, not for
+                                      :               general usage.
+
+Can be used in Internet mail to      Discarded-      RFC 2156, not for
+indicate X.400 IPM extensions        X400-IPMS-      general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+Can be used in Internet mail to      Discarded-      RFC 2156, not for
+indicate X.400 MTS extensions        X400-MTS-       general usage.
+which could not be mapped to         Extensions:
+Internet mail format.
+Name of file in which a copy of      Fcc:            Non-standard.
+this message is stored.
+Speech act categoriztion of a        Speech-Act:     Non-standard
+message, examples of speeach acts
+are Question, Idea, More,
+Promise, Sad, Happy, Angry,
+summary, Decision
+This field is used by some mail      Status:         Non-standard,
+delivery systems to indicate the                     should never
+status of delivery for this                          appear in mail in
+message when stored. Common                          transit.
+values of this field are:
+U    message is not downloaded
+      and not deleted.
+
+R    message is read or
+      downloaded.
+
+O    message is old but not
+      deleted.
+
+D    to be deleted.
+
+N    new (a new message also
+      sometimes is distinguished
+      by not having any "Status:"
+      header field.
+
+Combinations of these characters
+can occur, such as "Status: OR"
+to indicate that a message is
+downloaded but not deleted.
+
+Do not archive this message in       X-No-Archive:   Non-standard
+publicly available archives.         Yes
+
+
+
+                           4. Acknowledgments
+
+Harald Tveit Alvestrand, Neil Carpenter, William C. Carpenter, Rob
+Chandhok, Ned Freed, Olle J„rnefors, Jukka Korpela, Usi Paz, Martin
+Platt, Keith Moore, Robert A. Rosenberg, Mark Symons, Nick Smith
+Michael C. Tiernan and several other people have helped me with
+compiling this list. I especially thank Ned Freed and Olle J„rnefors
+for their thorough review and many helpful suggestions for
+improvements. I alone take responsibility for any errors which may
+still be in the list.
+
+An earlier version of this list has been published as part of [13].
+
+
+                  Copyright and disclaimer
+
+The IETF takes no position regarding the validity or scope
+of any intellectual property or other rights that might be
+claimed to pertain to the implementation or use of the
+technology described in this document or the extent to
+which any license under such rights might or might not be
+available; neither does it represent that it has made any
+effort to identify any such rights. Information on the
+IETF's procedures with respect to rights in standards-track
+and standards-related documentation can be found in BCP-11.
+Copies of claims of rights made available for publication
+and any assurances of licenses to be made available, or the
+result of an attempt made to obtain a general license or
+permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained
+from the IETF Secretariat."
+
+The IETF invites any interested party to bring to its
+attention any copyrights, patents or patent applications,
+or other proprietary rights which may cover technology that
+may be required to practice this standard. Please address
+the information to the IETF Executive Director.
+
+Copyright (C) The Internet Society (date). All Rights
+Reserved.
+
+This document and translations of it may be copied and
+furnished to others, and derivative works that comment on
+or otherwise explain it or assist in its implmentation may
+be prepared, copied, published and distributed, in whole or
+in part, without restriction of any kind, provided that the
+above copyright notice and this paragraph are included on
+all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by
+removing the copyright notice or references to the Internet
+Society or other Internet organizations, except as needed
+for the purpose of developing Internet standards in which
+case the procedures for copyrights defined in the Internet
+Standards process must be followed, or as required to
+translate it into languages other than English.
+
+The limited permissions granted above are perpetual and
+will not be revoked by the Internet Society or its
+successors or assigns.
+
+
+                             5. References
+
+Ref.    Author, title                                    IETF status
+                                                          (May 2001)
+-----   ---------------------------------------------    -----------
+[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
+         STD 10, RFC 821, August 1982.                    Recommended
+
+[2]     D. Crocker: "Standard for the format of ARPA     Standard,
+         Internet text messages." STD 11, RFC 822,        Recommended
+         August 1982.
+
+[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
+         interchange of USENET messages", RFC 1036,       cial IETF
+         December 1987.                                   standard,
+                                                          but in
+                                                          reality a de-
+                                                          facto
+                                                          standard for
+                                                          Usenet News
+
+[4]     M. Sirbu: "A Content-Type header field header    Historic
+         field for internet messages", RFC 1049, March
+         1988.
+
+[5]     R. Braden (editor): "Requirements for            Standard,
+         Internet Hosts -- Application and Support",      Required
+         STD-3, RFC 1123, October 1989.
+
+[6]     D. Robinson, R. Ullman: "Encoding Header         Non-standard
+         field for Internet Messages", RFC 1505,
+         August 1993.
+
+[7]     S. Hardcastle-Kille: "Mapping between            Proposed
+         X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
+         2156 January 1998.                               elective
+
+[8]     H. Alvestrand & J. Romaguera: "Rules for         Proposed
+         Downgrading Messages from X.400/88 to            standard,
+         X.400/84 When MIME Content-Types are Present     elective
+         in the Messages", RFC 1496, August 1993.
+
+[9]     A. Costanzo: "Encoding Header field Header       Non-standard
+         field for Internet Messages", RFC 1154, April
+         1990.
+
+[10]    A. Costanzo, D. Robinson: "Encoding Header       Experimental
+         field Header field for Internet Messages",
+         RFC 1505, August 1993.
+
+[11]    N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
+         Internet Mail Extensions) Part One: Format of    Standard,
+         Internet Message Bodies. RFC 2045. November      elective
+         1996.
+
+[12]    H. Alvestrand: "Tags for the Identification      Proposed
+         of Languages", RFC 1766, February 1995.          standard,
+                                                          elective
+
+[13]    J. Palme: "Electronic Mail", Artech House        Non-standard
+         publishers, London-Boston January 1995.
+
+[14]    R. Troost, S. Dorner: "Communicating             Experimental
+         Presentation Information in Internet
+         Messages: The Content-Disposition Header
+         field", RFC 2183, June 1995.
+
+[15]    B. Kantor, P. Lapsley, "Network News Transfer    Proposed
+         Protocol: "A Proposed Standard for the Stream-   standard
+         Based Transmission of News", RFC 977, January
+         1986.
+[16]    1848  PS   S. Crocker, N. Freed, J. Galvin,      Proposed
+         S. Murphy, "MIME Object Security Services",      standard
+         RFC 1848, March 1995.
+
+[17]    J. Myers, M. Rose: The Content-MD5 Header        Draft
+         field Header field, RFC 1864, October 1995.      standard
+
+[18]    M. Horton, UUCP mail interchange format          Not an offi-
+         standard, RFC 976, Januari 1986.                 cial IETF
+                                                          standard,
+                                                          but in
+                                                          reality a de-
+                                                          facto
+                                                          standard for
+                                                          Usenet News
+
+[19]    T. Berners-Lee, R. Header fielding, H.           Informatio
+         Frystyk: Hypertext Transfer Protocol --          nal
+         HTTP/1.0, RFC 1945.
+
+[20]    G. Vaudreuil: Voice Profile for Internet         Proposed
+         Mail, RFC 2421 Feburary 1998.
+
+[21]    H. Spencer: News Article Format and              Not even an
+         Transmission, June 1994,                         RFC, but
+         FTP://zoo.toronto.edu/pub/news.ps.Z              still widely
+         FTP://zoo.toronto.edu/pub/news.txt.Z             used and
+                                                          partly almost
+         This document is often referenced under the      a de-facto
+         name "son-of-RFC1036".                           standard for
+                                                          Usenet News
+
+[23]    PICS Label Distribution Label Syntax and         Other
+         Communication Protocols, World Wide Web          standard
+         Consortium, October 1996.
+
+[24]    Eudora Pro Macintosh User Manual, Qualcomm       Non-standard
+         Inc., 1988-1995.
+
+[25]    C. Newman: Originator-Info Message Header        Non-standard
+         field. work in progress, July 1997.
+
+[26]    Grant Neufeld and Joshua D. Baer: The Use of     Proposed
+         URLs as Meta-Syntax for Core Mail List           standard
+         Commands and their Transport through Message
+         Header fields, RFC 2369, July 1998.
+
+[27]    G. Klyne (ed.): Content Negotiation for          Non-standard
+         Facsimile Using Internet Mail, Work in
+         progress, March 2000.
+
+[27]    R. Chandhok, G. Wenger: List-IDE: A              Proposed
+         Structured Field and Namespace for the           standard
+         Identification if Mailing Lists, RFC 2919,
+         March 2001.
+
+                           6. Author's address
+
+Jacob Palme                     Phone: +46-8-16 16 67
+Stockholm University/KTH        Fax: +46-8-783 08 29
+Electrum 230                    E-mail: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
+
+                              Appendix A:
+Header fields sorted by Internet RFC document in which they appear.
+
+RFC 822
+-------
+
+bcc
+cc
+Comments
+Date
+From
+In-Reply-To
+Keywords
+Message-ID
+Received
+References
+Reply-To
+Resent-
+Resent-bcc
+Resent-cc
+Resent-Date
+Resent-From
+Resent-From
+Resent-Message-ID
+Resent-Reply-To
+Resent-Sender
+Resent-To
+Return-Path
+Sender
+Subject
+To
+
+RFC 976
+-------
+
+"From " (followed by space, not colon (:")
+
+RFC 1049
+--------
+
+Content-Type
+
+RFC 1036
+--------
+
+Approved
+Control
+Distribution
+Expires
+Followup-To
+Lines
+Newsgroups
+Organization
+Path
+Summary
+Xref
+
+RFC 1123
+--------
+
+Content-Type
+
+RFC 2156
+--------
+
+Alternate-recipient
+Auto-forwarded see Autoforwarded
+Autoforwarded
+Content-Identifier
+Content-Return
+Conversion
+Conversion-With-Loss
+Delivery-Date
+Discarded-X400-IPMS-Extensions
+Discarded-X400-MTS-Extensions
+Disclose-Recipients
+DL-Expansion-History
+Expiry-Date
+Generate-Delivery-Report
+Importance
+Incomplete-Copy
+Language
+Message-Type
+Obsoletes
+Original-Encoded-Information-Types
+Prevent-NonDelivery-Report
+Priority
+Reply-By
+Sensitivity
+
+RFC 1505
+--------
+
+Encoding
+
+RFC 1766
+--------
+
+Content-Language
+
+RFC 2183
+--------
+
+Content-Disposition
+
+RFC 1864
+--------
+
+Content-MD5
+
+RFC 2045
+--------
+
+Content-Description
+Content-ID
+Content-Transfer-Encoding
+Content-Type
+MIME-Version
+
+RFC 2110
+--------
+
+Content-Base
+Content-Location
+
+RFC 2298
+--------
+
+Disposition-Notification-To
+Disposition-Notification-Options
+Original-Recipient
+
+RFC 2369
+--------
+
+List-Archive
+List-Help
+List-Owner
+List-Post
+List-Software
+List-Subscribe
+List-Unsubscribe
+
+RFC 2421
+--------
+
+Importance
+Sensitivity
+
+son-of-RFC1036 [21]
+-------------------
+
+Also-Control
+Article-Names
+Article-Updates
+See-Also
+Supersedes
+
+RFC 2912
+--------
+
+Content-Features
+
+RFC 2919:
+--------
+
+List-ID
+
+World Wide Web Consortium (W3C) Recommendations
+-----------------------------------------------
+
+Pics-Label
+
+Not Internet standard (as of May 2001)
+-------------------------------------------
+
+"From " (not followed by ":")
+Abouse-Reports-To
+Apparently-To
+Approved-By
+Content-Alias
+Content-Alternative
+Content-Class
+Content-Conversion
+Content-Length
+Content-SGML-Entity
+Delivered-To
+Encoding
+Errors-To
+Fax
+Fcc
+For-Approval
+For-Comment
+For-Handling
+List-Digest
+List-URL
+Mailing-List
+Mail-Copies-To
+Mail-System-Version
+Mailer
+Message-Context
+NNTP-Posting-Host
+Organisation
+Originating-Client
+Originator
+Originator-Info
+Phone
+Posted-To
+Precedence
+Registered-Mail-Reply-Requested-By
+Replaces
+Return-Receipt-Requested
+Return-Receipt-To
+Read-Receipt-To
+Speech-Act
+Status
+Supersedes
+Telefax
+Translated-By
+Translation-Of
+User-Agent
+X-Admin
+X-Confirm-Reading-To
+X-Complaints-To
+X-Envelope-From
+X-Envelope-To
+X-Face
+X-IMAP
+X-Loop
+X-List-Host
+X-Listserver
+X-Mailer
+X-Mailing-List
+X-MIME-Autoconverted
+X-MIMEOLE
+X-MSMail-Priority
+X-Newsreader
+X-No-Archive
+X-OriginalArrivalTime
+X-Priority
+X-RCPT-TO
+X-Report-Abuse-To
+X-Sender
+X-UIDL
+X-URI
+X-URL
+X-X-Sender
+X400-Content-Return
+
+                    Appendix B: Alphabetical index
+
+Section Header field
+------- ------------
+
+3.5     Abuse-Reports-To
+3.3     Also-Control
+3.3     Alternate-Recipient
+3.4     Apparently-To
+3.4     Approved
+3.4     Approved-By
+3.6     Article-Names
+3.6     Article-Updates
+         Auto-Forwarded see Autoforwarded
+3.17    Autoforwarded
+3.4     bcc
+3.4     cc
+         Client, see Originating-Client
+         Comment, see For-Comment
+3.7     Comments
+3.6     Content-Alias
+3.12    Content-Alternative
+3.6     Content-Base
+3.13    Content-Class
+3.12    Content-Conversion
+3.7     Content-Description
+3.3     Content-Disposition
+3.13    Content-Features
+3.6     Content-ID
+3.7     Content-Identifier
+3.10    Content-Language see also Language
+3.11    Content-Length
+3.6     Content-Location
+3.15    Content-MD5
+3.4     Content-Return
+3.13    Content-SGML-Entity
+3.13    Content-Transfer-Encoding
+3.13    Content-Type
+3.3     Control
+3.12    Conversion
+3.12    Conversion-With-Loss
+         Copy, see Incomplete-Copy
+3.8     Date, see also Delivery-Date, Received, Expires, Expiry-
+         Date
+3.6     Delivered-To
+3.8     Delivery-Date
+         Delivery-Report, see Generate-Delivery-Report, Prevent-
+         Delivery-Report, Non-Delivery-Report, Content-Type
+         Description, see Content-Description
+3.17    Discarded-X400-IPMS-Extensions
+3.17    Discarded-X400-MTS-Extensions
+3.3     Disclose-Recipients
+         Disposition, see also Content-Disposition
+3.5     Disposition-Notification-Options
+3.5     Disposition-Notification-To
+3.4     Distribution
+3.2     DL-Expansion-History
+3.13    Encoding see also Content-Transfer-Encoding
+3.4     Errors-To
+3.8     Expires
+3.8     Expiry-Date
+         Extension see Discarded-X400-IPMS-Extensions, Discarded-
+         X400-MTS-Extensions
+3.4     Fax see also Telefax
+3.17    Fcc
+3.4     Followup-To
+3.4     For-Approval
+3.4     For-Comment
+3.4     For-Handling
+         Forwarded, see Autoforwarded
+3.4     From (not followed by (":" or preceded by ">")
+3.4     From (followed by ":")
+3.4     Generate-Delivery-Report
+         Handling, see For-Handling
+         History, see DL-Expansion-History
+         ID, see Content-ID and Message-ID
+         Identifier, see Content-ID and Message-ID
+3.9     Importance
+3.6     In-Reply-To
+3.9     Incomplete-Copy
+3.7     Keywords
+         Label, see PICS-Label
+3.10    Language see also Content-Language
+         Length see Content-Length
+3.11    Lines
+3.16    List-Archive
+3.16    List-Digest
+3.16    List-Help
+3.16    List-ID
+3.16    List-Owner
+3.16    List-Post
+3.16    List-Software
+3.16    List-Subscribe
+3.16    List-URL
+3.16    List-Unsubscribe
+         Loss, see Conversion-With-Loss
+3.16    Mailing-List, see also X-Mailing-List
+3.5     Mail-Copies-To
+3.4     Mail-System-Version see also X-mailer
+3.4     Mailer
+         MD5 see Content-MD5
+3.3     Message-Context
+3.6     Message-ID
+3.13    Message-Type
+3.3     MIME-Version
+3.4     Newsgroups
+         Newsreader, see X-Newsreader
+3.3     NNTP-Posting-Host
+3.6     Obsoletes
+3.7     Organisation
+3.7     Organization
+3.3     Original-Encoded-Information-Types
+3.6     Original-Recipient
+3.4     Originating-Client
+3.4     Originator
+3.4     Originator-Info see also Sender
+3.2     Path
+3.4     Phone
+3.9     PICS-Label
+3.4     Posted-To
+3.9     Precedence
+3.4     Prevent-NonDelivery-Report
+3.9     Priority
+3.5     Read-Reciept-To
+3.2     Received
+         Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
+         Recipients
+3.6     References
+3.5     Registered-Mail-Reply-Requested-By
+3.6     Replaces
+3.8     Reply-By
+3.4     Reply-To, see also In-Reply-To, References
+3.14    Resent-
+         Return see Content-Return
+3.2     Return-Path
+3.5     Return-Receipt-Requested
+3.5     Return-Receipt-To
+3.6     See-Also
+3.4     Sender
+3.9     Sensitivity
+3.17    Speech-Act
+3.17    Status
+3.7     Subject
+3.7     Summary
+3.6     Supersedes
+3.4     Telefax see also Fax
+3.4     To
+         Transfer-Encoding see Content-Transfer-Encoding
+3.6     Translated-By
+3.6     Translation-Of
+         Type see Content-Type, Message-Type, Original-Encoded-
+         Information-Types
+3.4     User-Agent
+         Version, see MIME-Version, X-Mailer
+3.4     X-Admin
+3.4     X-Complaints-To
+3.5     X-Confirm-Reading-To
+3.4     X-Envelope-From
+3.4     X-Envelope-To
+3.4     X-Face
+3.6     X-IMAP
+3.16    X-List-Host
+3.16    X-Listserver
+3.6     X-Loop
+3.16    X-Mailing-List, see also Mailing-List
+3.4     X-Mailer see also Mail-System-Version
+3.13    X-MIME-Autoconverted
+3.4     X-MimeOLE
+3.9     X-MSMail-Priority
+3.4     X-Newsreader
+3.17    X-No-Archive
+3.8     X-OriginalArrivaltime
+3.9     X-Priority
+3.4     X-Report-Abuse-To
+3.4     X-RCPT-TO
+3.4     X-Sender see also Originator-Info
+3.6     X-UIDL
+3.6     X-URI
+3.6     X-URL see also Content-Location
+3.4     X-X-Sender see also Originator-Info
+3.4     X400-Content-Return
+3.15    Xref
+
diff --git a/Documentation/en/I-D/draft-palme-mailext-headers-06.txt b/Documentation/en/I-D/draft-palme-mailext-headers-06.txt
new file mode 100644
index 00000000..05d1392a
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-mailext-headers-06.txt
@@ -0,0 +1,2078 @@
+Network Working Group                          Jacob Palme
+Internet Draft                                   Stockholm
+draft-palme-mailext-headers-06.txt          University/KTH
+Category: Informational                             Sweden
+Revision of: RFC 2076                  Date: November 2001
+                                        Expires: April 2002
+
+
+
+                   Common Internet Message Header Fields
+
+                         Status of this Memo
+
+This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright (C) The Internet Society 2001. All Rights Reserved.
+
+
+                             Abstract
+
+This memo contains tables of commonly occurring header
+fields in headings of e-mail messages. The document
+compiles information from other RFCs such as RFC 822, RFC
+1036, RFC 1123, RFC 2156, RFC 1496, RFC 1766, RFC 2183, RFC
+1864, RFC 2421 and RFC 2045. A few commonly occurring
+header fields which are not defined in RFCs are also
+included. For each header field, the memo gives a short
+description and a reference to the RFC in which the header
+field is defined.
+
+The latest, revised version of this document can be found
+at URL
+http://www.dsv.su.se/jpalme/ietf/mail-headers/.
+The version at that URL may be more recent than the version
+published as an RFC.
+
+Another list of headers can be found at URL
+http://www.hut.fi/~jkorpela/headers.html [28]
+
+
+                   Changes since previous version
+
+This document is a revision of RFC 2076. The following new
+header fields, not included in RFC 2076, have been added:
+Abuse-Reports-To:, Also-Control, Approved-By, Content-
+Alias, Content-Alternative, Content-Class, Content-
+Conversion, Content-Features, Content-ID, Delivered-To,
+Disposition-Notification-Options, Disposition-Notification-
+To, Expiry-Date, For-Approval, List-Archive, List-Digest,
+List-Help, List-ID, List-Owner, List-Post, List-Software,
+List-Subscribe, List-Unsubscribe, List-URL, Mail-Copies-
+To:, Original-Recipient, Originator, Originator-Info, Path,
+PICS-Label, NNTP-Posting-Host, Posted-To:, Read-Receipt-To,
+Received, Registered-Mail-Reply-Requested-By, Replaces,
+Return-Receipt-Requested, Speech-Act, Translated-By.
+Translation-Of, User-Agent, X-Confirm-Reading-To, X-
+Complaints-To:, X-Envelope-From, X-Envelope-To, X-Face, X-
+List-Host, X-Listserver, X-Loop, X-MIME-Autoconverted, X-No-
+Archive, X-OriginalArrivalTime, X-Priority, X-Report-Abuse-
+To, X-Sender, X-X-Sender, X-UIDL, X-URL, X-URI.
+
+
+                          Table of contents
+
+     Abstract                                              1
+     Changes since previous version                        2
+1. Introduction                                           3
+2. Use of gatewaying header fields                        4
+3. Table of header fields                                 5
+     **** 3.1 Phrases used in the tables                   5
+     **** 3.2 Trace information                            6
+     **** 3.3 Format and control information               7
+     **** 3.4 Sender and recipient indication              8
+     **** 3.5 Response control                            14
+     **** 3.6 Message identification and referral
+              header fields                               16
+     **** 3.7 Other textual header fields                 19
+     **** 3.8 Header fields containing dates and
+              times                                       20
+     **** 3.9 Quality information                         20
+     **** 3.10 Language information                       22
+     **** 3.11 Size information                           22
+     **** 3.12 Conversion control                         22
+     **** 3.13 Encoding information                       23
+     **** 3.14 Resent-header fields                       24
+     **** 3.15 Security and reliability                   25
+     **** 3.16 Mailing list control                       25
+     **** 3.17 Miscellaneous                              27
+4. Acknowledgments                                       28
+Copyright and disclaimer                                 29
+5. References                                            30
+6. Author's address                                      32
+Appendix A: Header fields sorted by Internet RFC
+             document in which they appear.               33
+     RFC 822                                              33
+     RFC 976                                              33
+     RFC 1049                                             33
+     RFC 1036                                             33
+     RFC 1123                                             34
+     RFC 2156                                             34
+     RFC 1505                                             34
+     RFC 1766                                             35
+     RFC 2183                                             35
+     RFC 1864                                             35
+     RFC 2045                                             35
+     RFC 2110                                             35
+     RFC 2298                                             35
+     RFC 2369                                             35
+     RFC 2421                                             36
+     son-of-RFC1036 [21]                                  36
+     RFC 2912                                             36
+     RFC 2919:                                            36
+     World Wide Web Consortium (W3C) Recommendations      36
+     Not Internet standard (as of May 2001)               36
+Appendix B: Alphabetical index                           38
+
+
+                          1. Introduction
+
+Many different Internet standards and RFCs define header
+fields which may occur on Internet Mail Messages and Usenet
+News Articles. The intention of this document is to list
+all such header fields in one document as an aid to people
+developing message systems or interested in Internet Mail
+standards.
+
+The document contains all header fields which the author
+has found in the following Internet standards: RFC 822 [2],
+RFC 1036 [3], RFC 1123 [5], RFC 2156 [7], RFC 1496 [8], RFC
+2045 [11], RFC 1766 [12], RFC 2183 [14], RFC 1864[17] and
+RFC 2421[20]. Note in particular that heading attributes
+defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 [16]) are
+not included. PEM and MOSS header fields only appear inside
+the body of a message, and thus are not header fields in
+the RFC 822 sense. Mail attributes in envelopes, i.e.
+attributes controlling the message transport mechanism
+between mail and news servers, are not included. This means
+that attributes from SMTP [1], UUCP [18] and NNTP [15] are
+mainly not covered either. Headings used only in HTTP [19]
+are not included yet, but may be included in future version
+of this memo. Some additional header fields which often can
+be found in e-mail headings but are not part of any
+Internet standard are also included.
+
+The author does not promise that this document contains a
+complete list of all heading fields which are specified in
+any standard or used by any mailer.
+
+For each header field, the document gives a short
+description and a reference to the Internet standard or
+RFC, in which they are defined.
+
+The header field names given here are spelled the same way
+as when they are actually used. This is usually American
+but sometimes English spelling.  One header field in
+particular, "Organisation/Organization", occurs in e-mail
+header fields sometimes with the English and other times
+with the American spelling.
+
+The following words are used in this memo with the meaning
+specified below:
+
+heading        Formatted text at the top of a message,
+                ended by a blank line
+
+header field   One field in the heading, beginning with a
+                field name, colon, and followed by the
+                field value(s). The words "heading field"
+                and "header" are also sometimes used with
+                this meaning.
+
+It is my intention to continue updating this document after
+its publication as an RFC. The latest version, which may be
+more up-to-date (but also less fully checked out) will be
+kept available for downloading from URL
+http://www.dsv.su.se/jpalme/ietf/mail-headers
+
+Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you
+have noted header fields which should be included in this
+memo but are not.
+
+
+                  2. Use of gatewaying header fields
+
+RFC 2156 defines a number of new header fields in Internet
+mail, which are defined to map header fields which X.400
+has but which were previously not standardized in Internet
+mail. The fact that a header field occurs in RFC 2156
+indicates that it is recommended for use in gatewaying
+messages between X.400 and Internet mail, but does not mean
+that the header field is recommended for messages wholly
+within Internet mail. Some of these header fields may
+eventually see widespread implementation and use in
+Internet mail, but at the time of this writing (2001) they
+are not widely implemented or used.
+
+Header fields defined only in RFC 1036 for use in Usenet
+News sometimes appear in mail messages, either because the
+messages have been gatewayed from Usenet News to e-mail, or
+because the messages were written in combined clients
+supporting both e-mail and Usenet News in the same client.
+These header fields are not standardized for use in
+Internet e-mail and should be handled with caution by e-
+mail agents.
+
+
+                       3. Table of header fields
+
+**** 3.1 Phrases used in the tables
+
+"not for general    Used to mark header fields which are
+usage"              defined in RFC 2156 for use in
+                     messages from or to Internet
+                     mail/X.400 gateways. These header
+                     fields have not been standardized for
+                     general usage in the exchange of
+                     messages between Internet mail-based
+                     systems.
+
+"not standardized   Used to mark header fields defined
+for use in e-       only in RFC 1036 for use in Usenet
+mail"               News. These header fields have no
+                     standard meaning when appearing in e-
+                     mail, some of them may even be used in
+                     different ways by different software.
+                     When appearing in e-mail, they should
+                     be handled with caution. Note that RFC
+                     1036, although generally used as a de-
+                     facto standard for Usenet News, is not
+                     an official IETF standard or even on
+                     the IETF standards track.
+
+"non-standard"      This header field is not specified in
+                     any of referenced RFCs which define
+                     Internet protocols, including Internet
+                     Standards, draft standards or proposed
+                     standards. The header field appears
+                     here because it often appears in e-
+                     mail or Usenet News. Usage of these
+                     header fields is not in general
+                     recommended. Some header field
+                     proposed in ongoing IETF standards
+                     development work, but not yet
+                     accepted, are also marked in this way.
+
+"discouraged"       This header field, which is non-
+                     standard, is known to create problems
+                     and should not be generated. Handling
+                     of such header fields in incoming mail
+                     should be done with great caution.
+
+"controversial"     The meaning and usage of this header
+                     field is controversial, i.e. different
+                     implementors have chosen to implement
+                     the header field in different ways.
+                     Because of this, such header fields
+                     should be handled with caution and
+                     understanding of the different
+                     possible interpretations.
+
+"experimental"      This header field is used for newly
+                     defined header fields, which are to be
+                     tried out before entering the IETF
+                     standards track. These should only be
+                     used if both communicating parties
+                     agree on using them. In practice, some
+                     experimental protocols become de-facto-
+                     standards before they are made into
+                     IETF standards.
+
+
+**** 3.2 Trace information
+
+Trace of distribution lists   DL-           RFC 2156, not
+passed.                       Expansion-    for general
+                               History:      usage.
+
+List of MTAs passed.          Path:         RFC 1036:
+                                             2.1.6, only in
+                                             Usenet News,
+                                             not in e-mail.
+
+Trace of MTAs which a         Received:     RFC 822: 4.3.2,
+message has passed.                         RFC 1123:
+                                             5.2.8.
+
+Used to convey the            Return-       RFC 821,
+information from the MAIL     Path:         RFC 1123:
+FROM envelope attribute in                  5.2.13.
+final delivery, when the
+message leaves the SMTP
+environment in which "MAIL
+FROM" is used.
+
+The netnews host, to which    NNTP-         Non-standard,
+this article was originally   Posting-      common in
+posted. Useful for finding    Host:         netnews
+the sender of spams. Since
+this header is added by the
+news server, it is a little
+more difficult to forge than
+other header fields.
+
+
+**** 3.3 Format and control information
+
+Special Usenet News commands  Also-         son-of-RFC1036
+and a normal article at the   Control:      [21], non-
+same time.                                  standard, only
+                                             in Usenet News,
+                                             not in e-mail
+
+Controls whether this         Alternate-    RFC 2156, not
+message may be forwarded to   Recipient:    for general
+alternate recipients such as                usage.
+a postmaster if delivery is
+not possible to the intended
+recipient. Default: Allowed.
+
+Whether a MIME body part is   Content-      RFC 2183,
+to be shown inline or is an   Disposition   experimental
+attachment; can also          :
+indicate a suggested
+filename for use when saving
+an attachment to a file.
+
+Can have the values "voice-   Message-      Non-standard
+message", "fax-message",      Context:
+"pager-message", "multimedia-
+message", "text-message",
+"none"
+
+Only in Usenet News,          Control:      RFC 1036:
+contains commands to be                     2.1.6, only in
+performed by News agents.                   Usenet News,
+                                             not in e-mail.
+
+Whether recipients are to be  Disclose-     RFC 2156, not
+told the names of other       Recipients:   for general
+recipients of the same                      usage.
+message. This is primarily
+an X.400 facility. In X.400,
+this is an envelope
+attribute and refers to
+disclosure of the envelope
+recipient list. Disclosure
+of other recipients is in
+Internet mail done via the
+To:, cc: and bcc: header
+fields.
+
+An indicator that this        MIME-         RFC 2045: 4.
+message is formatted          Version:
+according to the MIME
+standard, and an indication
+of which version of MIME is
+utilized.
+
+Which body part types occur   Original-     RFC 2156, not
+in this message.              Encoded-      for general
+                               Information-  usage.
+                               Types:
+
+
+**** 3.4 Sender and recipient indication
+
+Inserted by Sendmail when     Apparently-   Non-standard,
+there is no "To:" recipient   To:           discouraged,
+in the original message,                    mentioned in
+listing recipients derived                  RFC 1211.
+from the envelope into the
+message heading. This
+behavior is not quite
+proper, MTAs should not
+modify headings (except
+inserting Received lines),
+and it can in some cases
+cause Bcc recipients to be
+wrongly divulged to non-Bcc
+recipients.
+
+Name of the moderator of the  Approved:     RFC 1036:
+newsgroup to which this                     2.2.11, not
+article is sent; necessary                  standardized
+on an article sent to a                     for use in e-
+moderated newsgroup to allow                mail.
+its distribution to the
+newsgroup members. Also used
+on certain control messages,
+which are only performed if
+they are marked as Approved.
+
+Name of the moderator of a    Approved-     Non-standard,
+mailing list, and who has     By:           used by some
+approved this message for                   mailing list
+distribution to the members                 expansion
+of the list.                                systems.
+
+Recipients not to be          bcc:          RFC 822: 4.5.3,
+disclosed to other                          RFC 1123:
+recipients. (bcc = Blind                    5.2.15-16,
+Carbon Copy).                               5.3.7.
+
+Secondary, informational      cc:           RFC 822: 4.5.2,
+recipients. (cc = Carbon                    RFC 1123.
+Copy)                                       5.2.15-16,
+                                             5.3.7.
+
+Geographical or               Distributio   RFC 1036:
+organizational limitation on  n:            2.2.7, not
+where this article can be                   standardized
+distributed. Value can be a                 for use in e-
+compete or incomplete domain                mail.
+names, also various special
+values are accepted like
+"world", "usenet", "USA",
+etc.
+
+Fax number of the             Fax:,         Non-standard.
+originator.                   Telefax:
+
+Primary recipients, who are   For-          Non-standard
+requested to approve the      Approval:
+information in this message
+or its attachments.
+
+Primary recipients, who are   For-          Non-standard
+requested to comment on the   Comment:
+information in this message
+or its attachments.
+
+Primary recipients, who are   For-          Non-standard
+requested to handle the       Handling:
+information in this message
+or its attachments.
+
+(2) Used in Usenet News mail  From          RFC 976: 2.4
+transport, to indicate the    or            for use in
+path through which an         >From         Usenet News
+article has gone when         (not
+transferred to a new host.    followed by
+                               a colon)
+Sometimes called "From_"
+header field.
+
+(1) This header field should  From (not     not
+never appear in e-mail being  followed by   standardized
+sent, and should thus not     a colon)      for use in e-
+appear in this memo. It is                  mail
+however included, since
+people often ask about it.
+
+This header field is used in
+the so-called Unix mailbox
+format, also known as
+Berkely mailbox format or
+the MBOX format. This is a
+format for storing a set of
+messages in a file. A line
+beginning with "From " is
+used to separate successive
+messages in such files.
+
+This header field will thus
+appear when you use a text
+editor to look at a file in
+the Unix mailbox format.
+Some mailers also use this
+format when printing
+messages on paper.
+
+The information in this
+header field should NOT be
+used to find an address to
+which replies to a message
+are to be sent.
+
+Authors or persons taking     From:         RFC 822: 4.4.1,
+responsibility for the                      RFC 1123:
+message.                                    5.2.15-16,
+                                             5.3.7,
+Note difference from the                    RFC 1036 2.1.1
+"From " header field (not
+followed by ":") below.
+
+
+Information about the client  Mail-System-  Non-standard.
+software of the originator.   Version:,
+                               Mailer:,
+                               Originating-
+                               Client:, X-
+                               Mailer, X-
+                               Newsreader,
+                               X-MimeOLE:,
+                               User-Agent:
+
+In Usenet News: group(s) to   Newsgroups:   RFC 1036:
+which this article was                      2.1.3, not
+posted.                                     standardized
+Some systems provide this                   and
+header field also in e-mail                 controversial
+although it is not                          for use in e-
+standardized there.                         mail.
+
+Unfortunately, the header
+field can appear in e-mail
+with three different and
+contradictory meanings:
+
+(a) Indicating the newsgroup
+recipient of an
+article/message sent to both
+e-mail and Usenet News
+recipients.
+
+(b) In a message adressed to
+some mail to news gateways,
+indicates the newsgroup(s)
+that the message is to be
+posted to.
+
+(c) In a personally
+addressed reply to an
+article in a news-group,
+indicating the newsgroup in
+which this discussion
+originated.
+
+See also: "Posted-To:".
+
+Sometimes used in Usenet      Originator:   Non-standard in
+News in similar ways to                     Usenet News,
+"Sender:"                                   Experimental in
+                                             RFC 1528.
+Also used in printing
+protocols.
+
+Contains information about    Originator-   Non-standard
+the authentication of the     Info:         [25]
+originator in a format which
+is not easily used to send
+email to, to avoid the
+problems with "Sender" and
+"X-Sender".
+
+Phone number of the           Phone:        Non-standard.
+originator.
+
+The person or agent           Sender:       RFC 822: 4.4.2,
+submitting the message to                   RFC 1123:
+the network, if other than                  5.2.15-16,
+shown by the From: header                   5.3.7, RFC
+field. Should be                            1036.
+authenticated,
+according to RFC 822, but
+what
+kind of authentication is
+not
+clear. Some implementations
+expect that the e-mail
+address used in this field
+can be used to reach the
+sender, others do not. See
+also "X-Sender".
+
+Primary recipients.           To:           RFC 822: 4.5.1,
+                                             RFC 1123:
+                                             5.2.15-16,
+                                             5.3.7.
+
+If the sender in the          X-Envelope-   Non-standard.
+envelope (SMTP "RCTP TO") is  From:
+not the same as the senders
+in the "From" or "Sender"
+RFC822 header fields, some
+mail servers add this to the
+RFC822 header fields as an
+aid to clients which would
+otherwise not be able to
+display this information.
+
+If the recipient in the       X-Envelope-   Non-standard.
+envelope (SMTP "MAIL FROM")   To:,
+is not included in the CC     Envelope-
+list, some mail servers add   To:
+this to the RFC822 header
+field as an aid to clients
+which would otherwise not be
+able to display the envelope
+recipients.
+
+48x48 bitmap with picture of  X-Face:       Non-Standard
+the sender of this message.
+
+Indication in the mail        X-RCPT-TO:    Non-standard
+header of recipient on the
+SMTP envelope.
+
+Some mail software expect     X-Sender:     Non-standard
+"Sender:" to be an e-mail
+address which you can send
+mail to. However, some mail
+software has as the best
+authenticated sender a POP
+or IMAP account, which you
+might not be able to send
+to. Because of this, some
+mail software put the POP or
+IMAP account into an X-
+sender header field instead
+of a Sender header field, to
+indicate that you may not be
+able to send e-mail to this
+address. See also "X-X-
+Sender".
+
+Another use of" X-Sender:"
+is that some e-mail
+software, which wants to
+insert a "Sender:" header,
+will first change an
+existing "Sender:" header to
+"X-Sender". This use is
+actually often the same as
+that described in the
+previous paragraph, since
+the new "Sender:" is added
+because it is better
+authenticated than the old
+value.
+
+Even though some systems put  X-X-Sender:   Non-standard
+the POP or IMAP account name
+into the "X-Sender:" instead
+of the Sender header field,
+some mail software tries to
+send to the "X-Sender:" too.
+To stop this, some systems
+have begun to use "X-X-
+Sender:" to indicate an
+authentication of the sender
+which might not be useable
+to send e-mail to. See also
+"Originator-Info:"
+
+When a message is sent both   Posted-To:    Non-standard
+to netnews and e-mail, this
+header is used in the e-mail
+version of the message to
+indicate which newsgroup it
+was sent to. This header
+thus contains the same
+information as the
+"Newsgroups:" header in the
+netnews version of the
+message.
+
+E-mail address of             X-Admin:      Non-standard
+administrator of a server,
+through which this message
+was submitted.
+
+
+**** 3.5 Response control
+
+Indicates whether the         Content-      RFC 2156, not
+content of a message is to    Return:       for general
+be returned with non-                       usage.
+delivery notifications.
+
+For future options on         Disposition-  RFC 2298
+disposition notifications.    Notificatio
+                               n-Options:
+
+
+Indicate that the sender      Disposition-  RFC 2298
+wants a dispoisition          Notificatio
+notification when this        n-To:
+message is received (read,
+processed, etc.) by its
+receipents.
+
+Address to which              Errors-To:,   Non-standard,
+notifications are to be sent  Return-       discouraged,
+and a request to get          Receipt-      some of them
+delivery notifications.       To:,          widely used.
+Internet standards            Read-
+recommend, however, the use   Receipt-
+of MAIL FROM and Return-      To:, X-
+Path, not Errors-To, for      Confirm-
+where delivery notifications  reading-
+are to be sent.               to:, Return-
+                               Receipt-
+                               Requested,
+                               Register-
+                               Mail-Reply-
+                               Requested-
+                               By:
+
+Used in Usenet News to        Followup-     RFC 1036:
+indicate that future          To:           2.2.3, not
+discussions (=follow-up) on                 standardized
+an article should go to a                   for use in e-
+different set of newsgroups                 mail.
+than the replied-to article.
+The most common usage is
+when an article is posted to
+several newsgroups, and
+further discussions is to
+take place in only one of
+them.
+
+In e-mail, this header field
+may occur in a message which
+is sent to both e-mail and
+Usenet News, to show where
+follow-up in Usenet news is
+wanted. The header field
+does not say anything about
+where follow-up in e-mail is
+to be sent.
+
+The value of this header
+field should be one or more
+newsgroup names.
+
+The special value "poster"
+as in "Followup-To: poster"
+means that replies are to be
+sent as e-mail to the author
+only.
+
+Whether a delivery report is  Generate-     RFC 2156, not
+wanted at successful          Delivery-     for general
+delivery. Default is not to   Report:       usage.
+generate such a report.
+
+Original Recipient            Original-     RFC 2298
+information for inclusion in  Recipient
+disposition notifications.
+
+Whether non-delivery report   Prevent-      RFC 2156, not
+is wanted at delivery error.  NonDelivery-  for general
+Default is to want such a     Report:       usage.
+report.
+
+This header field is meant    Reply-To:     RFC 822: 4.4.3,
+to indicate where the sender                RFC 1036: 2.2.1
+wants replies to go.                        controversial.
+Unfortunately, this is
+ambiguous, since there are
+different kinds of replies,
+which the sender may wish to
+go to different addresses.
+In particular, there are
+personal replies intended
+for only one person, and
+group replies, intended for
+the whole group of people
+who read the replied-to
+message (often a mailing
+list, anewsgroup name cannot
+appear here because of
+different syntax, see
+"Followup-To" below.).
+
+Some mail systems use this    Reply-To2
+header field to indicate a
+better form of the e-mail
+address of the sender. Some
+mailing list expanders puts
+the name of the list in this
+header field. These
+practices are controversial.
+The personal opinion of the
+author of this RFC is that
+this header field should be
+avoided except in special
+cases, but this is a
+personal opinion not shared
+by all specialists in the
+area.
+
+Indicates where to send       Abuse-        non-standard
+complains if you get a        Reports-
+message which you think is    To:, X-
+against the laws or rules.    Complaints-
+                               To:, X-
+                               Report-
+                               Abuse-To:
+
+Used in netnews articles to   Mail-Copies-  non-standard,
+indicate that followup        To:           but commonly
+(=replies) should be sent to                supported by
+the indicated e-mail                        newsreaders
+address.
+
+Possible future change of     X400-         non-standard
+name for "Content-Return:"    Content-
+                               Return:
+
+
+**** 3.6 Message identification and referral header fields
+
+Reference to specially        Article-      son-of-RFC1036
+important articles for a      Names:        [21], non-
+particular Usenet Newsgroup.                standard
+
+Only in Usenet News, similar  Article-      son-of-RFC1036
+to "Supersedes:" but does     Updates:      [21], non-
+not cause the referenced                    standard
+article to be physically
+deleted.
+
+Used in addition to Content-  Content-      Work in
+Location if this content      Alias:        progress
+part can be retrieved
+through more than one URI.
+Only one of them is allowed
+in the Content-Location, the
+other can be specified in
+Content-Alias.
+
+Base to be used for           Content-      RFC 2110
+resolving relative URIs       Base:
+within this content part.
+
+Unique ID of one body part    Content-ID:   RFC 2045: 7.
+of the content of a message.
+
+URI with which the content    Content-      RFC 2110
+of this content part might    Location:
+be retrievable.
+
+Used by some automatic        Delivered-    non-standard
+services (mainly MLMs and     To:
+autoresponders) for the       or
+purpose of loop detection.    X-Loop:
+The service adds the
+Delivered-To header to
+outgoing messages, with its
+e-mail address as a value,
+and discards incoming
+messages which already have
+it.
+
+Reference to message which    In-Reply-     RFC 822: 4.6.2.
+this message is a reply to.   To:
+
+Unique ID of this message.    Message-ID:   RFC 822: 4.6.1
+                                             RFC 1036:
+                                             2.1.5.
+
+Reference to previous         Obsoletes:    RFC 2156, not
+message being corrected and                 for general
+replaced. Compare to                        usage.
+"Supersedes:" below. This
+field may in the future be
+replaced with "Supersedes:".
+
+In e-mail: reference to       References:   RFC 822: 4.6.3
+other related messages, in                  RFC 1036:
+Usenet News: reference to                   2.1.5.
+replied-to-articles.
+
+Still another name for        Replaces:     non-standard,
+similar functionality as for                proposed in
+"Obsoletes:" and                            IETF USEFOR
+"Supersedes:". This may                     working group
+become the most recommended
+header in the future, but is
+still under discussion in
+IETF standards development
+work.
+
+References to other related   See-Also:     Son-of-RFC1036
+articles in Usenet News.                    [21], non-
+                                             standard
+
+Commonly used in Usenet News  Supersedes:   son-of-RFC1036
+in similar ways to the                      [21], non-
+"Obsoletes" header field                    standard
+described above. In Usenet
+News, however, Supersedes
+causes a full deletion of
+the replaced article in the
+server, while "Supersedes"
+and "Obsoletes" in e-mail is
+implemented in the client
+and often does not remove
+the old version of the text.
+
+Mailbox of the person who     Translated-   non-standard
+made the translation.         By:
+
+Reference to the Message-ID   Translation-  non-standard
+of a message, which the       Of:
+current message is a
+translation of.
+
+Unique identifier for a       X-UIDL:       non-standard
+message, local to a
+particular local mailbox
+store. The UIDL identifier
+is defined in the POP3
+standard, but not the "X-
+UIDL:" header.
+
+Similar usage as "X-URL".     X-URI:        Non-standard
+The URI can be either a URL
+or a URN. URNs are meant to
+become more persistent
+references to resources than
+URLs.
+
+Sometimes used with the same  X-URL:        Non-standard
+meaning as "Content-
+Location:", sometimes to
+indicate the web home page
+of the sender or of his
+organisation.
+
+The UID, as defined in the    X-IMAP:       Non-standard
+IMAP standard. Only used in
+internal mailbox storage in
+some mail systems, should
+never be visible to a user.
+
+
+**** 3.7 Other textual header fields
+
+Comments on a message.        Comments:     RFC 822: 4.7.2.
+
+Description of a particular   Content-      RFC 2045: 8.
+body part of a message, for   Description
+example a caption for an      :
+image body part.
+
+A text string which           Content-      RFC 2156, not
+identifies the content of a   Identifier:   for general
+message.                                    usage.
+
+Search keys for data base     Keywords:     RFC 822: 4.7.1
+retrieval.                                  RFC 1036:
+                                             2.2.9.
+
+See Organization above.       Organisatio   Non-standard.
+                               n:
+
+Organization to which the     Organizatio   RFC 1036:
+sender of this article        n:            2.2.8, not
+belongs.                                    standardized
+                                             for use in e-
+                                             mail.
+
+Title, heading, subject.      Subject:      RFC 822: 4.7.1
+Often used as thread                        RFC 1036:
+indicator for messages                      2.1.4.
+replying to or commenting on
+other messages.
+
+Short text describing a       Summary:      RFC 1036:
+longer article. Warning:                    2.2.10, not
+Some mail systems will not                  standardized
+display this text to the                    for use in e-
+recipient. Because of this,                 mail,
+do not use this header field                discouraged.
+for text which you want to
+ensure that the recipient
+gets.
+
+
+**** 3.8 Header fields containing dates and times
+
+In Internet, the date when a  Date:         RFC 822: 5.1,
+message was written, in                     RFC 1123:
+X.400, the time a message                   5.2.14
+was submitted. Some Internet                RFC 1036:
+mail systems also use the                   2.1.2.
+date when the message was
+submitted.
+
+The time when a message was   Delivery-     RFC 2156, not
+delivered to its recipient.   Date:         for general
+                                             usage.
+
+A suggested expiration date.  Expires:      RFC 1036:
+Can be used both to limit                   2.2.4, not
+the time of an article which                standardized
+is not meaningful after a                   for use in e-
+certain date, and to extend                 mail.
+the storage of important
+articles.
+
+Time at which a message       Expiry-       RFC 2156, not
+loses its validity. This      Date:         for general
+field may in the future be                  usage.
+replaced by "Expires:".
+
+Latest time at which a reply  Reply-By:     RFC 2156, not
+is requested (not demanded).                for general
+                                             usage.
+
+Time when this message was    X-OriginalA   Non-standard
+delivered into the message    rrivalTime:
+transport system (usually
+the same time as in the last
+"Received:" header)
+
+
+**** 3.9 Quality information
+
+A hint from the originator    Importance:   RFC 2156 and
+to the recipients about how                 RFC 2421,
+important a message is.                     proposed
+Values: High, normal or low.
+Not used to control
+transmission speed.
+
+Body parts are missing.       Incomplete-   RFC 2156, not
+                               Copy:         for general
+                                             usage.
+
+Ratings label to control      PICS-Label:   REC-PICS-
+selection (filtering) of                    labels, W3C
+messages according to the                   document [23].
+PICS protocol.
+
+Sometimes used as a priority  Precedence:   Non-standard,
+value which can influence                   controversial,
+transmission speed and                      widely used.
+delivery. Common values are
+"bulk" and "first-class".
+Other uses is to control
+automatic replies and to
+control return-of-content
+facilities, and to stop
+mailing list loops.
+
+Can be "normal", "urgent" or  Priority:     RFC 2156, not
+"non-urgent" and can                        for general
+influence transmission speed                usage.
+and delivery.
+
+How sensitive it is to        Sensitivity   RFC 2156 and
+disclose this message to      :             RFC 2421,
+other people than the                       proposed
+specified recipients.
+Values: Personal, private,
+company confidential. The
+absence of this header field
+in messages gatewayed from
+X.400 indicates that the
+message is not sensitive.
+
+Yet another priority          X-MSMail-     Non-standard
+indication.                   Priority:
+
+Values: 1 (Highest), 2        X-Priority:   Non-standard
+(High), 3 (Normal), 4 (Low),                [24]
+5 (Lowest). 3 (Normal) is
+default if the field is
+omitted.
+
+
+**** 3.10 Language information
+
+Can include a code for the    Content-      RFC 1766,
+natural language used in a    Language:     proposed
+message, e.g. "en" for                      standard.
+English.
+
+Can include a code for the    Language:     RFC 2156, not
+natural language used in a                  for general
+message, e.g. "en" for                      usage.
+English.
+
+
+**** 3.11 Size information
+
+Inserted by certain mailers   Content-      Non-standard,
+to indicate the size in       Length:       discouraged.
+bytes of the message text.
+This is part of a format
+some mailers use when
+showing a message to its
+users, and this header field
+should not be used when
+sending a message through
+the net. The use of this
+header field in transmission
+of a message can cause
+several robustness and
+interoperability problems.
+
+Size of the message.          Lines:        RFC 1036:
+                                             2.2.12, not
+                                             standardized
+                                             for use in e-
+                                             mail.
+
+
+**** 3.12 Conversion control
+
+Information on where an       Content-      Non-standard
+alternative variant of this   Alternative   [27].
+document might be found.      :
+
+Non-standard variant of       Content-      Non-standard.
+Conversion: with the same     Conversion:
+values.
+
+The body of this message may  Conversion:   RFC 2156, not
+not be converted from one                   for general
+character set to another.                   usage.
+Values: Prohibited and
+allowed.
+
+The body of this message may  Conversion-   RFC 2156, not
+not be converted from one     With-Loss:    for general
+character set to another if                 usage.
+information will be lost.
+Values: Prohibited and
+allowed.
+
+
+**** 3.13 Encoding information
+
+Type information of the       Content-      non-standard
+content in some class         Class:
+hierarchy. Class hierarchies
+are commonly used to
+classify data structures in
+software development.
+
+Can give more detailed        Content-      Proposed
+information about the         Features:     Standard, RFC
+Content-Type. Example:                      2912
+
+Content-features:
+   (& (Type="image/tiff")
+   (color=Binary)
+   (image-file-structure=TIFF-
+S)
+   (dpi=200)
+   (dpi-xyratio=200/100)
+   (paper-size=A4)
+   (image-coding=MH) (MRC-
+mode=0)
+   (ua-media=stationery) )
+
+This header is meant to be
+used when you can choose
+between different versions of
+a resource, such as when
+using multipart/atlernative.
+
+Information from the SGML     Content-      non-standard
+entity declaration            SGML-
+corresponding to the entity   Entity:
+contained in the body of the
+body part.
+
+Coding method used in a MIME  Content-      RFC 2045: 6.
+message body.                 Transfer-
+                               Encoding:
+
+Format of content (character  Content-      RFC 1049,
+set etc.) Note that the       Type:         RFC 1123:
+values for this header field                5.2.13,
+are defined in different                    RFC 1766: 4.1
+ways in RFC 1049 and in MIME                RFC 2045: 5.
+(RFC 2045), look for the
+"MIME-version" header field
+to understand if Content-
+Type is to be interpreted
+according to RFC 1049 or
+according to MIME. The MIME
+definition should be used in
+generating mail. RFC 1049
+has "historic" status.
+
+RFC 1766 defines a parameter
+"difference" to this header
+field.
+
+Various other Content-Type
+define various additional
+parameters. For example, the
+parameter "charset" is
+mandatory for all textual
+Content-Types.
+
+Used in several different     Encoding:     RFC 1154,
+ways by different mail                      RFC 1505,
+systems. Some use it for a                  experimental.
+kind of content-type
+information, some for
+encoding and length
+information, some for a kind
+of boundary information,
+some in other ways.
+
+Only used with the value      Message-      RFC 2156, not
+"Delivery Report" to          Type:         for general
+indicates that this is a                    usage.
+delivery report gatewayed
+from X.400.
+
+Information about conversion  X-MIME-       non-standard
+of this message on the path   Autoconverte
+from sender to recipient,     d:
+like conversion between MIME
+encoding formats. Note: Auto-
+conversion may invalidate
+digital seals and
+signatures.
+
+
+**** 3.14 Resent-header fields
+
+When manually forwarding a    Resent-       RFC 822: C.3.3.
+message, header fields        Reply-To:,
+referring to the forwarding,  Resent-
+not to the original message.  From:,
+Note: MIME specifies another  Resent-
+way of resending messages,    Sender:,
+using the "Message" Content-  Resent-
+Type.                         From:,
+                               Resent-
+                               Date:,
+                               Resent-To:,
+                               Resent-cc:,
+                               Resent-
+                               bcc:,
+                               Resent-
+                               Message-ID:
+
+
+**** 3.15 Security and reliability
+
+Checksum of content to        Content-      RFC 1864,
+ensure that it has not been   MD5:          proposed
+modified.                                   standard.
+
+Used in Usenet News to store  Xref:         RFC 1036:
+information to avoid showing                2.2.13, only in
+a reader the same article                   Usenet News,
+twice if it was sent to more                not in e-mail.
+than one newsgroup. Only for
+local usage within one
+Usenet News server, should
+not be sent between servers.
+
+
+**** 3.16 Mailing list control
+
+Contains URL to use to        List-         RFC 2369 [26]
+browse the archives of the    Archive:
+mailing list from which this
+message was relayed.
+
+URL to use to get a           List-         Non-standard
+subscription to the digest    Digest:
+version of the mailing list
+from which this message was
+relayed.
+
+Contains URL to use to get a  List-Help:    RFC 2369 [26]
+information about the
+mailing list from which this
+message was relayed.
+
+Stores an identification of   List-ID:      RFC 2919 [27].
+the mailing list, through
+which this message was
+distributed.
+
+Non-standard precursors to    Mailing-      Non-standard
+List-ID and List-Post.        List:, X-
+                               Mailing-
+                               List:
+
+Contains URL to send e-mail   List-Owner:   RFC 2369 [26]
+to the owner of the mailing
+list from which this message
+was relayed.
+
+Contains URL to use to send   List-Post:    RFC 2369 [26]
+contributions to the mailing
+list from which this message
+was relayed.
+
+Information about the         List-         Non-standard,
+software used in a mailing    Software:     has been
+list expander through which                 considered for
+this message has passed.                    inclusion in
+                                             [26].
+Contains URL to use to get a  List-         RFC 2369 [26]
+subscription to the mailing   Subscribe:
+list from which this message
+was relayed.
+
+Contains URL to use to        List-         RFC 2369 [26]
+unsubscribe the mailing list  Unsubscribe
+from which this message was   :
+relayed.
+
+Contains URL where            List-URL:     Non-standard
+information of various kinds
+about the mailing list from
+which this message was
+relayed.
+
+Information about the server  X-            Non-standard.
+and software used in a        Listserver:   Recommended to
+mailing list expander         , X-List-     use "List-
+through which this message    Host:         Software"
+has passed. Warning:                        instead.
+"Listserv" is a trademark
+and should not be used for
+other than the "Listserv"
+product. Use, instead the
+"List-Software" header
+field.
+
+
+**** 3.17 Miscellaneous
+
+Has been automatically        Autoforward   RFC 2156, not
+forwarded.                    ed:           for general
+                                             usage.
+
+Can be used in Internet mail  Discarded-    RFC 2156, not
+to indicate X.400 IPM         X400-IPMS-    for general
+extensions which could not    Extensions:   usage.
+be mapped to Internet mail
+format.
+
+Can be used in Internet mail  Discarded-    RFC 2156, not
+to indicate X.400 MTS         X400-MTS-     for general
+extensions which could not    Extensions:   usage.
+be mapped to Internet mail         
+format.
+
+Name of file in which a copy  Fcc:          Non-standard.
+of this message is stored.
+
+Speech act categoriztion of   Speech-Act:   Non-standard
+a message, examples of
+speeach acts are Question,
+Idea, More, Promise, Sad,
+Happy, Angry, summary,
+Decision
+This field is used by some    Status:       Non-standard,
+mail delivery systems to                    should never
+indicate the status of                      appear in mail
+delivery for this message                   in transit.
+when stored. Common values
+of this field are:
+
+U    message is not
+downloaded
+      and not deleted.
+
+R    message is read or
+      downloaded.
+
+O    message is old but not
+      deleted.
+
+D    to be deleted.
+
+N    new (a new message also
+      sometimes is
+distinguished
+      by not having any
+"Status:"
+      header field.
+
+Combinations of these
+characters can occur, such
+as "Status: OR" to indicate
+that a message is downloaded
+but not deleted.
+
+Do not archive this message   X-No-         Non-standard
+in publicly available         Archive:
+archives.                     Yes
+
+
+
+                           4. Acknowledgments
+
+Harald Tveit Alvestrand, Neil Carpenter, William C.
+Carpenter, Rob Chandhok, Ned Freed, Olle J„rnefors, Jukka
+Korpela, Usi Paz, Martin Platt, Keith Moore, Robert A.
+Rosenberg, Mark Symons, Nick Smith Michael C. Tiernan and
+several other people have helped me with compiling this
+list. I especially thank Ned Freed and Olle J„rnefors for
+their thorough review and many helpful suggestions for
+improvements. I alone take responsibility for any errors
+which may still be in the list.
+
+An earlier version of this list has been published as part
+of [13].
+
+
+                  Copyright and disclaimer
+
+The IETF takes no position regarding the validity
+or scope of any intellectual property or other
+rights that might be claimed to pertain to the
+implementation or use of the technology described
+in this document or the extent to which any
+license under such rights might or might not be
+available; neither does it represent that it has
+made any effort to identify any such rights.
+Information on the IETF's procedures with respect
+to rights in standards-track and standards-
+related documentation can be found in BCP-11.
+Copies of claims of rights made available for
+publication and any assurances of licenses to be
+made available, or the result of an attempt made
+to obtain a general license or permission for the
+use of such proprietary rights by implementors or
+users of this specification can be obtained from
+the IETF Secretariat."
+
+The IETF invites any interested party to bring to
+its attention any copyrights, patents or patent
+applications, or other proprietary rights which
+may cover technology that may be required to
+practice this standard. Please address the
+information to the IETF Executive Director.
+
+Copyright (C) The Internet Society (date). All
+Rights Reserved.
+
+This document and translations of it may be
+copied and furnished to others, and derivative
+works that comment on or otherwise explain it or
+assist in its implmentation may be prepared,
+copied, published and distributed, in whole or in
+part, without restriction of any kind, provided
+that the above copyright notice and this
+paragraph are included on all such copies and
+derivative works. However, this document itself
+may not be modified in any way, such as by
+removing the copyright notice or references to
+the Internet Society or other Internet
+organizations, except as needed for the purpose
+of developing Internet standards in which case
+the procedures for copyrights defined in the
+Internet Standards process must be followed, or
+as required to translate it into languages other
+than English.
+
+The limited permissions granted above are
+perpetual and will not be revoked by the Internet
+Society or its successors or assigns.
+
+
+                             5. References
+
+Ref.   Author, title                            IETF
+                                                 status
+----   -------------------------------------    (Dec 2000)
+-      --------                                 ----------
+                                                 -
+[1]    J. Klensin: "Simple Mail Transfer        Proposed
+        Protocol", RFC 2821, April 2001.         Standard
+
+[2]    P. Resnick: "Internet Message Format"    Proposed
+        STD 11, RFC 2822, April 2001.            Standard
+
+[3]    M.R. Horton, R. Adams: "Standard for     Not an
+        interchange of USENET messages", RFC     offi-cial
+        1036, December 1987.                     IETF
+                                                 standard,
+                                                 but in
+                                                 reality a
+                                                 de-facto
+                                                 standard
+                                                 for Usenet
+                                                 News
+
+[4]    M. Sirbu: "A Content-Type header         Historic
+        field header field for internet
+        messages", RFC 1049, March 1988.
+
+[5]    R. Braden (editor): "Requirements for    Standard,
+        Internet Hosts -- Application and        Required
+        Support", STD-3, RFC 1123, October
+        1989.
+
+[6]    D. Robinson, R. Ullman: "Encoding        Non-
+        Header field for Internet Messages",     standard
+        RFC 1505, August 1993.
+
+[7]    S. Hardcastle-Kille: "Mapping between    Proposed
+        X.400(1988) / ISO 10021 and RFC 822",    standard,
+        RFC 2156 January 1998.                   elective
+
+[8]    H. Alvestrand & J. Romaguera: "Rules     Proposed
+        for Downgrading Messages from            standard,
+        X.400/88 to X.400/84 When MIME           elective
+        Content-Types are Present in the
+        Messages", RFC 1496, August 1993.
+
+[9]    A. Costanzo: "Encoding Header field      Non-
+        Header field for Internet Messages",     standard
+        RFC 1154, April 1990.
+
+[10]   A. Costanzo, D. Robinson: "Encoding      Experiment
+        Header field Header field for            al
+        Internet Messages", RFC 1505, August
+        1993.
+
+[11]   N. Freed & N. Borenstein: "MIME          Draft
+        (Multipurpose Internet Mail              Standard,
+        Extensions) Part One: Format of          elective
+        Internet Message Bodies. RFC 2045.
+        November 1996.
+
+[12]   H. Alvestrand: "Tags for the             Best
+        Identification of Languages", RFC        Current
+        3066, January 2001.                      Practice,
+                                                 elective
+
+[13]   J. Palme: "Electronic Mail", Artech      Non-
+        House publishers, London-Boston          standard
+        January 1995.
+
+[14]   R. Troost, S. Dorner: "Communicating     Experimental
+        Presentation Information in Internet
+        Messages: The Content-Disposition
+        Header field", RFC 2183, June 1995.
+
+[15]   B. Kantor, P. Lapsley, "Network News     Proposed
+        Transfer Protocol: "A Proposed           standard
+        Standard for the Stream-Based
+        Transmission of News", RFC 977,
+        January 1986.
+[16]   1848  PS   S. Crocker, N. Freed, J.      Proposed
+        Galvin, S. Murphy, "MIME Object          standard
+        Security Services", RFC 1848, March
+        1995.
+
+[17]   J. Myers, M. Rose: The Content-MD5       Draft
+        Header field Header field, RFC 1864,     standard
+        October 1995.
+
+[18]   M. Horton, UUCP mail interchange         Not an
+        format standard, RFC 976, Januari        offi-cial
+        1986.                                    IETF
+                                                 standard,
+                                                 but in
+                                                 reality a
+                                                 de-facto
+                                                 standard
+                                                 for Usenet
+                                                 News
+
+[19]   R. Fielding, J. Gettys, J. Mogul, H.     Draft
+        Frystyk, L. Masinter, P. Leach, T.       standard
+        Berners-Lee: Hypertext Transfer
+        Protocol -- HTTP/1.1, June 1999.
+[20]   G. Vaudreuil: Voice Profile for          Proposed
+        Internet Mail, RFC 2421 Feburary
+        1998.
+
+[21]   H. Spencer: News Article Format and      Not even an
+        Transmission, June 1994,                 RFC, but
+        FTP://zoo.toronto.edu/pub/news.ps.Z      still
+        FTP://zoo.toronto.edu/pub/news.txt.Z     widely used
+                                                 and partly
+        This document is often referenced        almost a de-
+        under the name "son-of-RFC1036".         facto
+                                                 standard
+                                                 for Usenet
+                                                 News
+
+[23]   PICS Label Distribution Label Syntax     Other
+        and Communication Protocols, World       standard
+        Wide Web Consortium, October 1996.
+
+[24]   Eudora Pro Macintosh User Manual,        Non-
+        Qualcomm Inc., 1988-1995.                standard
+
+[25]   C. Newman: Originator-Info Message       Non-
+        Header field. work in progress, July     standard
+        1997.
+
+[26]   Grant Neufeld and Joshua D. Baer: The    Proposed
+        Use of URLs as Meta-Syntax for Core      standard
+        Mail List Commands and their
+        Transport through Message Header
+        fields, RFC 2369, July 1998.
+
+[27]   G. Klyne (ed.): Content Negotiation      Non-
+        for Facsimile Using Internet Mail,       standard
+        Work in progress, March 2000.
+
+[27]   R. Chandhok, G. Wenger: List-IDE: A      Proposed
+        Structured Field and Namespace for       standard
+        the Identification if Mailing Lists,
+        RFC 2919, March 2001.
+
+[28]   Jukka "Yucca" Korpela: Quick             Non-
+        reference to Internet message            standard
+        headers,
+        http://www.cs.tut.fi/~jkorpela/header
+        s.html, October 2001.
+
+
+                           6. Author's address
+
+Jacob Palme                Phone: +46-8-16 16 67
+Stockholm University/KTH   Fax: +46-8-783 08 29
+Electrum 230               E-mail: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
+
+                              Appendix A:
+Header fields sorted by Internet RFC document in which
+they appear.
+
+RFC 822
+-------
+
+bcc
+cc
+Comments
+Date
+From
+In-Reply-To
+Keywords
+Message-ID
+Received
+References
+Reply-To
+Resent-
+Resent-bcc
+Resent-cc
+Resent-Date
+Resent-From
+Resent-From
+Resent-Message-ID
+Resent-Reply-To
+Resent-Sender
+Resent-To
+Return-Path
+Sender
+Subject
+To
+
+RFC 976
+-------
+
+"From " (followed by space, not colon (:")
+
+RFC 1049
+--------
+
+Content-Type
+
+RFC 1036
+--------
+
+Approved
+Control
+Distribution
+Expires
+Followup-To
+Lines
+Newsgroups
+Organization
+Path
+Summary
+Xref
+
+RFC 1123
+--------
+
+Content-Type
+
+RFC 2156
+--------
+
+Alternate-recipient
+Auto-forwarded see Autoforwarded
+Autoforwarded
+Content-Identifier
+Content-Return
+Conversion
+Conversion-With-Loss
+Delivery-Date
+Discarded-X400-IPMS-Extensions
+Discarded-X400-MTS-Extensions
+Disclose-Recipients
+DL-Expansion-History
+Expiry-Date
+Generate-Delivery-Report
+Importance
+Incomplete-Copy
+Language
+Message-Type
+Obsoletes
+Original-Encoded-Information-Types
+Prevent-NonDelivery-Report
+Priority
+Reply-By
+Sensitivity
+
+RFC 1505
+--------
+
+Encoding
+
+RFC 1766
+--------
+
+Content-Language
+
+RFC 2183
+--------
+
+Content-Disposition
+
+RFC 1864
+--------
+
+Content-MD5
+
+RFC 2045
+--------
+
+Content-Description
+Content-ID
+Content-Transfer-Encoding
+Content-Type
+MIME-Version
+
+RFC 2110
+--------
+
+Content-Base
+Content-Location
+
+RFC 2298
+--------
+
+Disposition-Notification-To
+Disposition-Notification-Options
+Original-Recipient
+
+RFC 2369
+--------
+
+List-Archive
+List-Help
+List-Owner
+List-Post
+List-Software
+List-Subscribe
+List-Unsubscribe
+
+RFC 2421
+--------
+
+Importance
+Sensitivity
+
+son-of-RFC1036 [21]
+-------------------
+
+Also-Control
+Article-Names
+Article-Updates
+See-Also
+Supersedes
+
+RFC 2912
+--------
+
+Content-Features
+
+RFC 2919:
+--------
+
+List-ID
+
+World Wide Web Consortium (W3C) Recommendations
+-----------------------------------------------
+
+Pics-Label
+
+Not Internet standard (as of May 2001)
+-------------------------------------------
+
+"From " (not followed by ":")
+Abouse-Reports-To
+Apparently-To
+Approved-By
+Content-Alias
+Content-Alternative
+Content-Class
+Content-Conversion
+Content-Length
+Content-SGML-Entity
+Delivered-To
+Encoding
+Errors-To
+Fax
+Fcc
+For-Approval
+For-Comment
+For-Handling
+List-Digest
+List-URL
+Mailing-List
+Mail-Copies-To
+Mail-System-Version
+Mailer
+Message-Context
+NNTP-Posting-Host
+Organisation
+Originating-Client
+Originator
+Originator-Info
+Phone
+Posted-To
+Precedence
+Registered-Mail-Reply-Requested-By
+Replaces
+Return-Receipt-Requested
+Return-Receipt-To
+Read-Receipt-To
+Speech-Act
+Status
+Supersedes
+Telefax
+Translated-By
+Translation-Of
+User-Agent
+X-Admin
+X-Confirm-Reading-To
+X-Complaints-To
+X-Envelope-From
+X-Envelope-To
+X-Face
+X-IMAP
+X-Loop
+X-List-Host
+X-Listserver
+X-Mailer
+X-Mailing-List
+X-MIME-Autoconverted
+X-MIMEOLE
+X-MSMail-Priority
+X-Newsreader
+X-No-Archive
+X-OriginalArrivalTime
+X-Priority
+X-RCPT-TO
+X-Report-Abuse-To
+X-Sender
+X-UIDL
+X-URI
+X-URL
+X-X-Sender
+X400-Content-Return
+
+                    Appendix B: Alphabetical index
+
+Sectio Header field
+n      ------------
+------
+-
+
+3.5    Abuse-Reports-To
+3.3    Also-Control
+3.3    Alternate-Recipient
+3.4    Apparently-To
+3.4    Approved
+3.4    Approved-By
+3.6    Article-Names
+3.6    Article-Updates
+        Auto-Forwarded see Autoforwarded
+3.17   Autoforwarded
+3.4    bcc
+3.4    cc
+        Client, see Originating-Client
+        Comment, see For-Comment
+3.7    Comments
+3.6    Content-Alias
+3.12   Content-Alternative
+3.6    Content-Base
+3.13   Content-Class
+3.12   Content-Conversion
+3.7    Content-Description
+3.3    Content-Disposition
+3.13   Content-Features
+3.6    Content-ID
+3.7    Content-Identifier
+3.10   Content-Language see also Language
+3.11   Content-Length
+3.6    Content-Location
+3.15   Content-MD5
+3.4    Content-Return
+3.13   Content-SGML-Entity
+3.13   Content-Transfer-Encoding
+3.13   Content-Type
+3.3    Control
+3.12   Conversion
+3.12   Conversion-With-Loss
+        Copy, see Incomplete-Copy
+3.8    Date, see also Delivery-Date, Received, Expires,
+        Expiry-Date
+3.6    Delivered-To
+3.8    Delivery-Date
+        Delivery-Report, see Generate-Delivery-Report,
+        Prevent-Delivery-Report, Non-Delivery-Report,
+        Content-Type
+        Description, see Content-Description
+3.17   Discarded-X400-IPMS-Extensions
+3.17   Discarded-X400-MTS-Extensions
+3.3    Disclose-Recipients
+        Disposition, see also Content-Disposition
+3.5    Disposition-Notification-Options
+3.5    Disposition-Notification-To
+3.4    Distribution
+3.2    DL-Expansion-History
+3.13   Encoding see also Content-Transfer-Encoding
+3.4    Errors-To
+3.8    Expires
+3.8    Expiry-Date
+        Extension see Discarded-X400-IPMS-Extensions,
+        Discarded-X400-MTS-Extensions
+3.4    Fax see also Telefax
+3.17   Fcc
+3.4    Followup-To
+3.4    For-Approval
+3.4    For-Comment
+3.4    For-Handling
+        Forwarded, see Autoforwarded
+3.4    From (not followed by (":" or preceded by ">")
+3.4    From (followed by ":")
+3.4    Generate-Delivery-Report
+        Handling, see For-Handling
+        History, see DL-Expansion-History
+        ID, see Content-ID and Message-ID
+        Identifier, see Content-ID and Message-ID
+3.9    Importance
+3.6    In-Reply-To
+3.9    Incomplete-Copy
+3.7    Keywords
+        Label, see PICS-Label
+3.10   Language see also Content-Language
+        Length see Content-Length
+3.11   Lines
+3.16   List-Archive
+3.16   List-Digest
+3.16   List-Help
+3.16   List-ID
+3.16   List-Owner
+3.16   List-Post
+3.16   List-Software
+3.16   List-Subscribe
+3.16   List-URL
+3.16   List-Unsubscribe
+        Loss, see Conversion-With-Loss
+3.16   Mailing-List, see also X-Mailing-List
+3.5    Mail-Copies-To
+3.4    Mail-System-Version see also X-mailer
+3.4    Mailer
+        MD5 see Content-MD5
+3.3    Message-Context
+3.6    Message-ID
+3.13   Message-Type
+3.3    MIME-Version
+3.4    Newsgroups
+        Newsreader, see X-Newsreader
+3.3    NNTP-Posting-Host
+3.6    Obsoletes
+3.7    Organisation
+3.7    Organization
+3.3    Original-Encoded-Information-Types
+3.6    Original-Recipient
+3.4    Originating-Client
+3.4    Originator
+3.4    Originator-Info see also Sender
+3.2    Path
+3.4    Phone
+3.9    PICS-Label
+3.4    Posted-To
+3.9    Precedence
+3.4    Prevent-NonDelivery-Report
+3.9    Priority
+3.5    Read-Reciept-To
+3.2    Received
+        Recipient, see To, cc, bcc, Alternate-Recipient,
+        Disclose-Recipients
+3.6    References
+3.5    Registered-Mail-Reply-Requested-By
+3.6    Replaces
+3.8    Reply-By
+3.4    Reply-To, see also In-Reply-To, References
+3.14   Resent-
+        Return see Content-Return
+3.2    Return-Path
+3.5    Return-Receipt-Requested
+3.5    Return-Receipt-To
+3.6    See-Also
+3.4    Sender
+3.9    Sensitivity
+3.17   Speech-Act
+3.17   Status
+3.7    Subject
+3.7    Summary
+3.6    Supersedes
+3.4    Telefax see also Fax
+3.4    To
+        Transfer-Encoding see Content-Transfer-Encoding
+3.6    Translated-By
+3.6    Translation-Of
+        Type see Content-Type, Message-Type, Original-
+        Encoded-Information-Types
+3.4    User-Agent
+        Version, see MIME-Version, X-Mailer
+3.4    X-Admin
+3.4    X-Complaints-To
+3.5    X-Confirm-Reading-To
+3.4    X-Envelope-From
+3.4    X-Envelope-To
+3.4    X-Face
+3.6    X-IMAP
+3.16   X-List-Host
+3.16   X-Listserver
+3.6    X-Loop
+3.16   X-Mailing-List, see also Mailing-List
+3.4    X-Mailer see also Mail-System-Version
+3.13   X-MIME-Autoconverted
+3.4    X-MimeOLE
+3.9    X-MSMail-Priority
+3.4    X-Newsreader
+3.17   X-No-Archive
+3.8    X-OriginalArrivaltime
+3.9    X-Priority
+3.4    X-Report-Abuse-To
+3.4    X-RCPT-TO
+3.4    X-Sender see also Originator-Info
+3.6    X-UIDL
+3.6    X-URI
+3.6    X-URL see also Content-Location
+3.4    X-X-Sender see also Originator-Info
+3.4    X400-Content-Return
+3.15   Xref
+
diff --git a/Documentation/en/I-D/draft-palme-maillist-01.txt b/Documentation/en/I-D/draft-palme-maillist-01.txt
new file mode 100644
index 00000000..444ff5c3
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-maillist-01.txt
@@ -0,0 +1,580 @@
+INTERNET-DRAFT                                      Jacob Palme
+Network Working Group                  Stockholm University/KTH
+draft-palme-maillist-01.txt                              Sweden
+Expires November 2001                                  May 2001
+
+
+
+
+
+Appropriate Mailing List Behaviour
+
+
+Status of this Memo
+
+
+This document is an Internet-Draft and is in full conformance
+with all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright (C) The Internet Society 2001. All Rights Reserved.
+
+
+
+Abstract
+
+This memo summarizes common ideas on how good mailing lists should
+behave. Some of this is taken from IETF standards, some is not. This
+memo is not intended, itself, to become a standard, but might, if
+accepted by the IETF, be published as informational RFC or as a Best
+Current Practice (BCP) document.
+
+
+Table of contents
+
+1.   Terminology and Scope
+2.   Reserved E-mail Addresses
+3.   Sending Requests to a List Expander
+  3.1   Subscription Control
+    3.1.1  To Subscribe
+    3.1.2  To Unsubscribe
+  3.2   To Get Information about a List
+4.   Who may Post to a Mailing List
+5.   SMTP Envelope
+6.   Delivery Status Notifications
+7.   Nested Lists
+8.   Loop Control
+9.   List Headers
+10.  Header Munging
+11.  Spam Control
+12.  Mail Bombing
+13.  Groupware
+14.  Security Considerations
+15.  Copyright and Disclaimer
+16.  Acknowledgments
+17.  References
+18.  Author's address
+
+
+1.    Terminology and Scope
+
+By a mailing list is in this specification meant an automatic agent
+which has an e-mail address, and which will resend messages, sent to
+this address via SMTP [RFC2821], to all e-mail addresses in a list of
+subscribers to the mailing list. This process of resending is
+designated "expansion" of the mailing list. Note that lists which are
+expanded by the sender's client before submission to the mail
+transport system are not covered by this specification, even though
+the word "mailing list" is sometimes used also for such lists.
+
+This memo summarizes customary ideas on how good mailing lists should
+behave. Some of this is taken from IETF standards, some is not.
+
+
+2.    Reserved E-mail Addresses
+
+Every mailing list has an e-mail address, named according to the same
+conventions as for personal mailboxes, and reachable through the same
+mail transport system as for personal mailboxes.
+
+If the e-mail address of a mailing list is "flowers@foo.bar.net" then
+the following e-mail addresses are also reserved:
+
+flowers-request@foo.bar.net
+flowers-owner@foo.bar.net
+flowers-errors@foo.bar.net
+
+Messages sent to "flowers-request@foo.bar.net" are usually handled by
+an automatic process which performs common actions as requested in the
+message. Sometimes all, or some, such messages are sent to a human
+administrator of the list.
+
+Messages sent to "flowers-owner@foo.bar.net" are sent to a human
+administrator of the list, or cause a non-delivery notification (see
+section 6. Delivery Status Notifications) in accordance with [RFC1891]
+and [RFC1894], if the list administrator is not willing to handle
+messages sent to this e-mail address.
+
+Messages sent to "flowers-errors@foo.bar.net" are usually handled by a
+person or a process which handles routine maintenance of a list, such
+as removal of list members who persistently (for at least 3-4 days)
+return negative Delivery Status Notifications. The e-mail address
+"flowers-errors@foo.bar.net" should in this case also be put as the
+SMTP sender when expanding messages from the mailing lists to its
+members. If there is no person or process doing such maintenance, the
+SMTP sender for expanded messages may instead be empty.
+
+
+3.    List Headers
+
+A mailing list expander should add headers to the mailing list
+according to [RFC2369] and [RFC2919]. Examples:
+
+List-Help: <mailto:flowers@foo.net?subject=help> (List Instructions)
+List-Unsubscribe: <mailto: flowers@foo.net?subject=unsubscribe>
+List-Subscribe: <mailto: flowers@foo.net?subject=subscribe>
+List-Archive: <http://www.foo.net/flowers-archive>
+List-Post: <mailto:moderator@foo.net> (Postings are Moderated)
+List-Owner: <mailto:grant@foo.net> (Grant Neufeld)
+List-Id: List Header Mailing List <list-header.nisto.com>
+
+Note that the "List-" headers can either contain an e-mail address, to
+which requests are sent in a format specified in the "List-" command,
+for example
+
+   List-Unsubscribe: <mailto: flowers@foo.net?subject=unsubscribe>
+
+Or can contain an URL of a web page, on which a subscription request
+can be made.
+
+
+4.    Sending Requests to a List Expander
+
+Some, but not all, mailing lists accept commands sent in messages to
+an automatic agent representing the list expander. The most common
+address for such an agent is "flowers-request@foo.bar.net", but other
+addresses occur, such as "list-handler@foo.bar.net".
+
+There is no agreed standard on the format of commands in such
+messages, so it is good practice to accept a number of common variants
+in either the subject or the text of the message to the agent. Such
+commands are case-insensitive. Information about which format is used
+by a particular mailing list expander is specified in the "List-"
+headers, see section 3 List Headers above.
+
+Common such commands are:
+
+4.1   Subscription Control
+
+The subscription control commands handle the subscription of the SMTP
+sender of the request (not the subscription for name in the From: or
+Sender: header). The mailing list expander may however find the name
+of the requestor from the "From:" or "Sender:" field, in order to
+register the name. This name is however not used in normal list
+expansion. The actual address for this agent or web page is specified
+in "List-" headers, see section 3 List Headers above.
+
+4.1.1 To Subscribe
+
+Common commands are: sub, subscribe, join. Best is to support all of
+them.
+
+Sometimes the name of the requestor (not the e-mail address) is
+specified after this command, for example "Subscribe Mary Woodfence".
+Other systems require the e-mail address to be specified in the
+subscribe command, or a full e-mail user-friendly name and address in
+the format used in From: e-mail header, like
+"Subscribe Mary Woodfence <maryw@foo.bar>"
+
+4.1.2 To Unsubscribe
+
+Common unsubscribe commands are: uns, unsubscribe, signoff, sign-off,
+sign off, delete, leave, cancel, remove, rem, del. Best is to support
+all of them.
+
+4.2   To Get Information about a List
+
+Common commands to retrieve information about a list are: help,
+review, query, info, information. Best is to support all of them.
+
+The information returned may include a textual description of the
+purpose of the list and of which postings are acceptable to the list.
+It may also include description of how to subscribe and unsubscribe
+and where archives of the mailing list are kept. Some lists also
+return a list of the subscribers of the list.
+
+The actual address for the agent or web page returning such
+information is specified in "List-" headers, see section 3 List
+Headers above.
+
+
+5.    Mail Bombing
+
+Some people will add other people's e-mail addresses to mailing lists
+without their permission, causing them to be bombarded with mail they
+do not want. To counteract this, good practice is that a mailing list
+expander, which receives a request to add an e-mail address to the
+mailing list, should send a message to this e-mail address, asking if
+the recipient really wants to be added to the list, and putting a
+secret codeword in the "Subject:". If no confirmatory reply arrives
+with this codeword in its "Subject:" then the person is not
+permanently added to the list.
+
+
+6.    Who may Post to a Mailing List
+
+There may be different kinds of restrictions on who may submit
+messages to a list. Common cases are:
+
+- Anyone:           Anyone can submit messages to the list (warning,
+                     see section 12. Spam Control below).
+- Subscribers only: Only subscribers are allowed to submit to the list.
+- Moderators only:  Only one or more designated moderators may
+                     submit to the list.
+
+Other cases, such as geographical or domain name restrictions, or that
+only a program, agent or filter may post, also occur. A sublist in a
+nested mailing list structure can be set to reject all postings which
+do not come from its superlist.
+
+The checking on who may submit to a list is usually done on the SMTP
+sender of the message, not on the names in From: or Sender: fields in
+the heading, because this name is a little more difficult to fake.
+Note however, that mail which is forwarded through nested mailing
+lists, will have the administrator of the previous list as SMTP
+sender. If the previous list does not perform filtering, and a list
+often gets messages from other mailing lists, filtering inom the From:
+header may be necessary.
+
+If a message is sent to a list, by someone who is not allowed to
+submit to the list, this can be handled in either of two ways:
+
+(a) Forward the message to the moderator of the list, who decides
+     whether to accept or reject the message. This option should
+     only be used if there really does exist a moderator who really
+     performs this task on a regular basis.
+
+(b) Send a non-delivery notification to the SMTP sender of the
+     rejected message, in accordance with [RFC1891] and [RFC1894].
+
+
+7.    SMTP Envelope
+
+The SMTP sender [RFC2821] of a message after expansion should be the
+list owner or maintainer [RFC1123], not the original sender, for
+exmaple the mailing list flowers@foo.bar.net may set flowers-
+errors@foo.bar.net as the SMTP sender of expanded messages.
+
+When several mailing lists are nested, each list in sequence, which
+expands a message, should set its owner or maintainer as SMTP sender,
+so that the SMTP sender always indicates the owner of the latest list
+expander, through which the message has passed.
+
+For small, closed lists, the option of retaining the SMTP sender of
+the original sender can also occur.
+
+The SMTP recipients should be the subscribers of the mailing list
+doing the expansion. A mailing list may send to all recipients in one
+envelope (SMTP submission) or may split the recipients into multiple
+submissions, like one submission for each recipient. For large lists,
+it may be best to split the recipients with only 99 RCPT TO for each
+submission, since some SMTP servers may not accept more than 99
+recipients.
+
+Some mailing list have a facility that a subscriper can stay a
+subscriber, but not get submissions sent. Other mailing list allow
+subscribers to get submissions in different formats, such as digests
+of all messages once a day or once a week, or only a list of URLs to
+retrieve the new messages, not the full text. Such options will mean
+that the content of the messages sent via SMTP is different for
+different subscribers.
+
+
+8.    Delivery Status Notifications
+
+Delivery Status Notification [RFC1891], [RFC1894] requests are usually
+not forwarded by mailing list expanders. Instead, notifications are
+sent when the message arrives at the list, and the list maintainer can
+request notifications when the messages are delivered to list
+subscribers.
+
+An exception to this is small, closed lists, where sometimes Delivery
+Status Notification requests are forwarded through the list, and the
+notifications are sent back to the original sender.
+
+
+9.    Nested Lists
+
+A subscriber of a mailing list can be another mailing list. This is
+called "nested lists". Nested lists are used for efficiency reasons
+and in order to distribute the management of different parts of the
+subscriber space.
+
+Nested lists can have a hierarchical structure or be looped, see
+Figure 7.1:
+
+
+   Figure 7.1   Examples of hierarchical and looped nesting
+
+                   Hierarchical                  Looped
+
+                      Top list               +---<-List A-<-+
+                         V                   V         ^    ^
+             +-----<-----+----->-----+     List B--->--+--<-+
+             V           V           V       V              ^
+          Sublist A  Sublist B  Sublist C    +---->------List C
+             V
+      +--<---+---->---+
+      V               V
+   SubList A1  Sublist A2
+
+
+With a hierarchical structure, contributions intended for all
+subscribers of the whole set of lists must be sent to the top list.
+Theoretically, messages intended for only a brach of the tree might be
+sent to the top of that branch, but this is usually not recommended,
+because users have difficulty understanding it.
+
+A way to stop contributions to other branches than the top list is to
+designated that the sublists will only accept contributions from their
+immediate superior in the nesting structure.
+
+Looped nesting can cause loops, where the same message circles
+indefinitely between the lists. How such loops can be avoided is
+described in section 8. Loop Control. Another alternative is to only
+use hierarhically nested lists. It is, however, sometimes desirable to
+allow looped nesting, for example when one or more of the nested lists
+is a groupware system which accepts local contributions using other
+submission methods than e-mail (see section 12 Mail Bombing). Looped
+nesting will also avoid the problem with contributions submitted to
+the wrong branch of a hierarchical structure.
+
+A common practice is to accept contributions only to the top list in a
+nested structure of mailing lists. This would mean that sublists will
+only accept contributions coming from the superior list.
+
+In a few cases, submissions are acceted to sublists, intended only to
+a subset of the main list, but this practice is usually not
+recommended.
+
+
+10.   Loop Control
+
+Loops can occur because lists are nested (see section 7. Nested
+Lists). Even if lists are not intended to be nested, it is advisable
+to employ loop control techniques, because nesting of lists can happen
+by mistake.
+
+Mailing lists commonly employ one or more of the following techniques
+for avoiding loops and duplicates. It is better to employ more than
+one of these techniques:
+
+(1) Add a "Received:" header to all messages passing the list. If a
+     mailing list recognizes its own "Received:" header in an incoming
+     message, such a message is dropped. No non-delivery notification
+     should be sent in this case (since it might cause another loop).
+
+     Note: The content of the Received header should be different from
+     what is added by the mail transport agent during ordinary routing
+     of e-mail, since otherwise a message routed by this mail transport
+     agent may at a later time be rejected by the mailing list, even
+     though it has not actually passed the list.
+
+(2) A variant of this which is *not* recommended is to use "Resent-"
+     headers or "List-" headers. A problem with such headers is that
+     they may not always correctly show the whole path which the
+     message has gone through. It is normally not desirable that
+     mailing lists add "Resent-" headers to messages, see section
+     11: Header Munging and [RFC2822].
+
+(3) Store a list of the Message-ID-s of messages which have passed
+     the list, and reject incoming messages whose Message-ID is on
+     this list. To achieve loop control, this list need not be kept
+     for a long time, a week may be enough in most cases.
+
+(4) Store a list of the content or checksum of messages which have
+     passed this list, and use it in the same way as the Message-ID.
+     The advantage with this is that it may work even when a message
+     did not have any Message-ID or when some badly behaving list
+     expander has removed or modified the Message-ID.
+
+
+11.   Header Munging
+
+Apart from what is specifed in sections 9. Loop Control and 10. List
+Headers, a mailing list expander should not in any way modify the
+heading of a message. In particular, the list should not change the
+Message-ID, not add "Resent-", "From:", "Sender:", "Auto-Submitted:"
+or "Reply-To:", and should not remove or modify "Received:" headers
+(but may add an additional "Received:" header with information about
+the mailing list expansion). The practice to add the e-mail address of
+the list in a "Reply-To:" header is common, but is not recommended.
+Instead, use the "List-Post:" command from [RFC2369].
+
+
+12.   Spam Control
+
+Many mailing list expanders employ various methods to counteract
+spamming. Examples of such methods are:
+
+(1) Do not allow non-subscribers to post to the list.
+
+(2) Check all submissions by a human moderator before acceptance.
+
+(3) Employ various filtering techniques to recognize spams, such as
+     multiple occurence of the same message sent to different mailing
+     lists. Since such techniques may reject legitimate messages,
+     rejected messages should be passed to a human moderator for
+     checking.
+
+
+13.   Groupware
+
+A groupware product may appear as a mailing list to people accessing
+it via e-mail, and may at the same time appear as a forum to people
+accessing it via other user interfaces, such as HTTP [RFC2068]/HTML
+[RFC1866] or own protocols for this particular groupware.
+
+Such groupware products may allow addition of e-mail addresses as
+subscribers to a forum in the same way as groupware users are added as
+members of the forum.
+
+A message created in a groupware system, and sent out via e-mail,
+should include the e-mail address of the forum (groupware discussion
+group) in a "To:" och "Cc:" header, as well as in the List-headers
+according to [RFC2369] and [RFC 2919].
+
+One particular class of Groupware is Usenet News. This document is not
+written to specially cater to the issues of gatewaying between e-mail
+and Usenet News. Such gatewaying is a complex issue, which requires
+special consideration for that particular case.
+
+
+14.   Security Considerations
+
+Allowing people to retrieve lists of subscribers of mailing lists may
+be misused by spammers and other people using these names for no-goood
+purposes.
+
+Allowing anyone to post to a list may be misused by spammers. See see
+section 12. Spam Control.
+
+Loop control may incur some risk of messages disappearing, but this
+should normally not happen.
+
+Loop control with Message-ID can be misused to stop unwanted messages,
+but this would be difficult, since the offender must send the false
+message with the same Message-ID before the message to be stopped.
+
+Spam control may incur some risk of messages disappearing. A way to
+reduce this risk is to forward rejected messages to a human moderator
+for checking.
+
+A well-known problem with moderated mailing lists is that if the
+moderator is sick, on holiday, or otherwise occupied, the list ceases
+to work. Some mailing list try to solve this problem by having
+multiple moderators, so that another moderator can take over when one
+of them cannot perform the moderating task.
+
+
+15.   Copyright and Disclaimer
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to pertain
+to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; neither does it represent that it has made any
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims of
+rights made available for publication and any assurances of licenses
+to be made available, or the result of an attempt made to obtain a
+general license or permission for the use of such proprietary rights
+by implementors or users of this specification can be obtained from
+the IETF Secretariat."
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary
+rights which may cover technology that may be required to practice
+this standard. Please address the information to the IETF Executive
+Director.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implmentation may be prepared, copied, published and
+distributed, in whole or in part, without restriction of any kind,
+provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of developing
+Internet standards in which case the procedures for copyrights defined
+in the Internet Standards process must be followed, or as required to
+translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+
+16.   Acknowledgments
+
+Many people have helped with the production of this document. Of
+special value have been .....
+
+
+17.   References
+
+[RFC821]    Simple Mail Transfer Protocol. J. Postel. Aug-01-
+             1982. (Format: TXT=124482 bytes) (Obsoletes
+             RFC0788) (Also STD0010) (Status: STANDARD)
+
+[RFC822]    Standard for the format of ARPA Internet text
+             messages. D. Crocker. Aug-13-1982. (Format:
+             TXT=109200 bytes) (Obsoletes RFC0733) (Updated by
+             RFC1123, RFC1138, RFC1148, RFC1327, RFC2156) (Also
+             STD0011) (Status: STANDARD)
+
+[RFC1123]   Requirements for Internet hosts - application and
+             support. R.T. Braden. Oct-01-1989. (Format:
+             TXT=245503 bytes) (Updates RFC0822) (Updated by
+             RFC2181) (Status: STANDARD)
+
+[RFC1866]   Hypertext Markup Language - 2.0. T. Berners-Lee &
+             D. Connolly. November 1995. (Format: TXT=146904
+             bytes) (Status: PROPOSED STANDARD)
+
+[RFC1891]   SMTP Service Extension for Delivery Status
+             Notifications. K. Moore. January 1996. (Format:
+             TXT=65192 bytes) (Status: PROPOSED STANDARD)
+
+[RFC1894]   An Extensible Message Format for Delivery Status
+             Notifications. K. Moore & G. Vaudreuil. January
+             1996. (Format: TXT=77462 bytes) (Status: PROPOSED
+             STANDARD)
+
+[RFC2068]   Hypertext Transfer Protocol -- HTTP/1.1. R.
+             Fielding, J. Gettys, J. Mogul, H. Frystyk, T.
+             Berners-Lee. January 1997. (Format: TXT=378114
+             bytes) (Status: PROPOSED STANDARD)
+
+[RFC2369]   The Use of URLs as Meta-Syntax for Core Mail List
+             Commands and their Transport through Message
+             Header Fields. G. Neufeld, J. Baer. July 1998.
+             (Format: TXT=30853 bytes) (Status: PROPOSED
+             STANDARD)
+
+[RFC2919]   List-Id: A Structured Field and Namespace for the
+             Identification of Mailing Lists, By R. Chandhok
+             and G. Wegner, March 2001 (Status: PROPOSED
+             STANDARD).
+
+[RFC2821]   Simple Mail Transfer Protocol, by J. Klensin,
+             April 2001.
+
+[RFC2822]   Internet Message Format, by P. Resnick, April
+             2001.
+
+
+
+18.   Author's address
+
+Jacob Palme                          Phone: +46-8-16 16 67
+Stockholm University/KTH             Fax: +46-8-783 08 29
+Skeppargatan 73                      E-mail: jpalme@dsv.su.se
+S-115 30 Stockholm, Sweden
diff --git a/Documentation/en/I-D/draft-palme-newfields-info-01.txt b/Documentation/en/I-D/draft-palme-newfields-info-01.txt
new file mode 100644
index 00000000..a625c6d4
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-newfields-info-01.txt
@@ -0,0 +1,244 @@
+Network Working Group                                       Jacob Palme
+Internet Draft                                 Stockholm University/KTH
+draft-palme-newfields-info-01.txt
+IETF status: To become an informational RFC
+Expires: January 1998                                        March 1998
+
+
+
+
+Advice on the implementation of In-Reply-To, References and Supersedes
+e-mail and netnews headers
+
+
+
+Status of this Document
+
+
+This document is an Internet-Draft. Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its areas, and
+its working groups. Note that other groups may also distribute working
+documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as ``work in progress.''
+
+To learn the current status of any Internet-Draft, please check the
+``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ftp.isi.edu (US West Coast).
+
+Copyright (C) The Internet Society 1998. All Rights Reserved.
+
+
+
+Abstract
+
+Separate Internets standards documents define the e-mail headers
+In-Reply-To, References, Supersedes and Expires. This document, which
+is an informational RFC, gives some advice on the implementation of
+these features.
+
+
+Table of Contents
+
+1. User interface
+2. Hard and soft Supersedes
+3. Data base
+4. Copyright
+5. References
+6. Author's Address
+
+1.    User interface
+
+The fields "In-Reply-To", "References" and "Supersedes" are all used to
+convey information about references between different e-mail messages
+or netnews articles.
+
+A good way to implement these fields is to tell the recipient that two
+messages reference each other, and to make it easy for readers to
+traverse threads (series of linked messages) up and down.
+
+It is also possible to have special features to see a whole thread (set
+of related messages) graphically, or as an indented list, and to allow
+users to traverse, print, save or do other actions on a thread.
+
+Example of showing a thread as an indented list:
+
+   This is entry no. 1, the start entry of the thread
+     This is entry no. 2, a reply to entry no. 1
+       This is entry no. 3, a reply to entry no. 2
+     This is entry no. 4, a reply to entry no. 1
+
+In the particular case of "Supersedes", a user who has not yet read
+either the old or the new version, may be shown only the new version as
+a new message, but with methods to easily find the old version.
+
+A way to show this information to users is to show the "In-Reply-To",
+"Supersedes" and "References" fields, possibly as buttons, and allow
+the user to click on them to get to the referred-to messages.
+Additionally, it is useful to add buttons to follow threads forward,
+with texts like "Next in thread" or "Replies" or "This document is
+referenced by" or "Superseding documents". This allows a user, when
+reading a message, to see if someone else has already replied, and it
+allows users to traverse threads downwards and not only upwards. Such
+reverse buttons should not be sent in e-mail, they are just for local
+handling in user mailbox databases. Note that their values may change
+after a message has been submitted, when more new messages arrive which
+reference it.
+
+Example of showing a message with thread information:
+
+   To: IETF-Announce: ;
+   From: The IESG <iesg-secretary@ns.ietf.org>
+   Subject: Last Call: The Auto-Submitted, Supersedes and Expires
+      Headers in E-mail and Netnews to Proposed Standard
+   In-Reply-To: <v04003a00b12335fb8686@ns.ietf.org>
+   Replied-By: <v04003a00b12335fb8687@ns.ietf.org>
+   Date: Thu, 05 Mar 1998 07:02:47 -0500
+   Sender: scoya@cnri.reston.va.us
+
+
+2.    Hard and soft Supersedes
+
+By a hard supersedes is meant a Supersedes which causes deletion of the
+superseded message. By a soft supersedes is meant a Supersedes which
+still keeps both messages, and allows a user to see and use the
+reference between them, somewhat similar to In-Reply-To and References.
+
+Supersedes is best implemented as soft supersedes. Users of the
+supersedes field should however be aware that some implementations,
+especially in Usenet News, do implement it as hard supersedes.
+
+Hard supersedes has the same security problem as the Cancel command of
+Usenet News. They can be used to maliciously delete other people's
+messages. Use of strong authentication of the author can reduce this
+risk.
+
+
+3.    Data base
+
+In order to implement threads, a data base is needed which, given a
+Message-ID, can find the message which this Message-ID refers to. This
+data base has a very simple structure, just a single value mapped to
+one or more messages. Note, however, that the same message can be
+copied to more than one mailbox, so the data base should not be
+restricted to only one location for each Message-ID.
+
+Every time a message is added, moved, copied, deleted or purged, this
+data base need to be updated.
+
+When a new message arrives, the mailer can find the messages, to which
+this message has references. Note that there is a risk that replies
+arrive before the replied-to message, so a good implementation should
+work even in this case.
+
+A problem with these kinds of Message-ID data bases is that they tend
+to become very large with time, and they easily collect garbage
+(Message-ID-s of messages not any more available in the mailbox data
+base).
+
+The two most common methods to implement such data bases are:
+
+(a) Implement a large data base, but with some method of purging to
+    avoid unlimited growth of the data base.
+
+(b) Implement a smaller data base, where all objects are deleted
+    after a certain time. A couple of months is enough if the
+    techniques described in the next paragraph are used.
+
+With implementation method (b), information about the references in the
+form of "In-Reply-To", "References", "Supersedes", "Replied-By",
+"Referenced-By" and "Superseded-By" should also be stored in the
+message headers themselves. The reason method (b) works is that it is
+very uncommon that a message has a reference to other than very recent
+messages. Thus, the lack of "Replied-By", "Referenced-By" and
+"Superseded-By" headers in these very uncommon cases is acceptable.
+
+The advantage with method (b) is that a complex garbage collection
+method, as for method (a), is not needed. A much simpler garbage
+collection method can be used instead, just removing records after a
+certain expiration time.
+
+4.    Copyright
+
+Copyright (C) The Internet Society (date). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it or
+assist in its implementation may be prepared, copied, published and
+distributed, in whole or in part, without restriction of any kind,
+provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing the
+copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of developing
+Internet standards in which case the procedures for copyrights defined
+in the Internet Standards process must be followed, or as required to
+translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
+NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
+NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
+FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+5.    References
+
+Ref.            Author, title
+---------       --------------------------------------------------------
+
+[AUTOLOOP]      J. Palme: "Loop control for the Auto-Submitted e-mail
+                header", draft-palme-autosub-03.txt, July 1997.
+
+[MIME1]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
+                Extensions (MIME) Part One: Format of Internet Message
+                Bodies", RFC 2045, December 1996.
+                .
+[MIME2]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
+                Extensions (MIME) Part Two:  Media Types", RFC 2046,
+                December 1996.
+
+[MIME3]         K. Moore, "MIME (Multipurpose Internet Mail Extensions)
+                Part Three:  Message Header Extensions for Non-ASCII
+                Text", RFC 2047, December 1996.
+
+[MIME4]          N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
+                Mail Extensions (MIME) Part Four:  Registration
+                Procedures", RFC 2048, January 1997.
+
+[MIME5]         "Multipurpose Internet Mail Extensions (MIME) Part Five:
+                Conformance Criteria and Examples", RFC 2049, December
+                1996.
+
+[NEWFIELDS]     J. Palme: "The Auto-Submitted, Supersedes and Expires
+                E-mail Headers", draft-ietf-mailext-new-fields-08.txt,
+                July 1997.
+
+[NEWS]          M.R. Horton, R. Adams: "Standard for interchange of
+                USENET messages", RFC 1036, December 1987.
+
+[RFC822]        D. Crocker: "Standard for the format of ARPA Internet
+                text messages." STD 11, RFC 822, August 1982.
+
+[SMTP]          J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
+                821, August 1982.
+
+
+
+6.    Author's Address
+
+Jacob Palme                          Phone: +46-8-16 16 67
+Stockholm University and KTH         Fax: +46-8-783 08 29
+Electrum 230                         E-mail: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
diff --git a/Documentation/en/I-D/draft-palme-newsmail-01.txt b/Documentation/en/I-D/draft-palme-newsmail-01.txt
new file mode 100644
index 00000000..2cc38fc0
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-newsmail-01.txt
@@ -0,0 +1,19 @@
+

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

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

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

+an RFC.

+

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

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

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

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

+deleted Internet-Draft.

+

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

+

+Draft Author(s):

+

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

+

+

diff --git a/Documentation/en/I-D/draft-palme-select-01.txt b/Documentation/en/I-D/draft-palme-select-01.txt
new file mode 100644
index 00000000..1795600b
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-select-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):

+

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

+J. Kaers: johan@starlab.net                                                       

+

+

diff --git a/Documentation/en/I-D/draft-palme-supersedes-01.txt b/Documentation/en/I-D/draft-palme-supersedes-01.txt
new file mode 100644
index 00000000..d09a2ded
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-supersedes-01.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.