nuke obsolete drafts

44 files changed, 0 insertions, 40465 deletions

diff --git a/Documentation/en/I-D/draft-bernstein-mpls-sonet-00.txt b/Documentation/en/I-D/draft-bernstein-mpls-sonet-00.txt
deleted file mode 100644
index 5693fcb5..00000000
--- a/Documentation/en/I-D/draft-bernstein-mpls-sonet-00.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-Network Working Group                               Greg Bernstein
-Internet Draft                                      Ciena Networks
-Expiration Date:  August 2000
-
-
-    Some Comments on the Use of MPLS Traffic Engineering for 
-                    SONET/SDH Path Establishment
-
-                   draft-bernstein-mpls-sonet-00.txt
-
-
-1. Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-2. Abstract
-
-   In [Awduche] the MPLS Traffic Engineering control plane was applied
-   to the creation of light paths (optical circuits). Due to the general
-   hierarchical capabilities of MPLS, and the flexibility of the label 
-   switching paradigm the same techniques used to apply the MPLS control 
-   plane to the optical layer can be used to apply it to the SONET/SDH 
-   path layer and in fact any form of circuit switching. This note 
-   discusses advantages of such an approach and some of the issues 
-   involved in its application. 
-
-
-3. Introduction
-
-   In [Awduche] the MPLS Traffic Engineering control plane was applied 
-   to the creation of light paths (optical circuits). This initial work 
-   along with the formation of a new optical signaling working group at 
-   the Optical Internetworking Forum (OIF), and a new industry 
-   coalition, the Optical Domain Service Interconnect(ODSI)has very much 
-   underscored the desire to automate the control of optical networks.
-   Due to the hierarchical capabilities of MPLS and the flexibility of 
-   the MPLS paradigm, MPLS techniques can be applied to the general 
-   problem of control of hierarchical circuit switched networks. Given 
-   the number of recent internet drafts concerning the optical domain
-   [Kompella, Wang, Fan, Krishna]  the comments here will be 
-   concentrated on time division multiplexed hierarchies. Before 
-   focusing on some SONET specific issues (note that [Mannie] gives a 
-   good overview of the SDH specific issues) we review some of the
-   problems to be solved.
-
-3.1 Transport Network Issues
- 
-3.1.1 Multi Vendor Topology/Resource Discovery 
-
-   Although modern transport networks based on SONET/SDH excel at 
-   interoperability in the performance monitoring (PM) and fault 
-   management (FM) areas, they do not inter-operate in the areas of 
-   topology discovery or resource status.  Although link state route 
-   protocols, such as IS-IS and OSPF, have been used for some time in 
-   the IP world to compute destination based next hops for routes 
-   (without routing loops). Their value in providing timely topology and 
-   network status information in a distributed manner, i.e., at any 
-   network node, is immense. If resource utilization information is 
-   disseminated along with the link status (as was done in ATM's PNNI 
-   routing protocol) then a very complete picture of network status is 
-   available to a network operator for use in planning, provisioning and 
-   operations. Note that in the circuit switch domain bandwidth 
-   utilization and connection admission control is much simplified over 
-   similar concepts in the packet switching world.
-   Other items of interest for circuit based network control include 
-   switching capabilities of the nodes (granularity, signal types, 
-   etc.), protection properties of the links (linear 1+1, linear 1:N, 
-   ring), failure risk of the links (which links have a tendency to fail 
-   at the same time - ).  At this point the main difference in this 
-   application of link state routing versus that for IP is that no 
-   routes have actually be calculated.
-
-3.1.2 Multi Vendor Connection Control
-
-   Traditionally end-to-end circuit connections have been set up via an 
-   equipment vendor's element management system (EMS). Only limited 
-   interoperability has been achieved via management systems. Hence, 
-   end-to-end circuits in a multi-vendor environment typically require 
-   the use of multiple management systems and the infamous configuration 
-   via "yellow sticky notes". A common signaling protocol such as RSVP 
-   with TE extensions or CR-LDP appropriately extended for circuit 
-   switching applications can solve this interoperability problem.
-
-3.1.3 Customer/Edge Connection Control
-
-   This is the case where the edge device, by desire, does not fully 
-   participate in the routing protocol, i.e., does not receive or share 
-   topology information with the rest of the network. Such a device 
-   would typically be discovered/register through a separate protocol 
-   from the routing protocol.  The edge device would then typically use 
-   a signaling protocol similar to that used in the network to request 
-   services associated with circuits (setup, clear, query). Note that 
-   the multiplex hierarchy used in TDM networks generally alleviates the 
-   scaling issues that could otherwise be troublesome, i.e., a core 
-   SONET switch with OC-192 trunks will not be dealing with signals of 
-   DS0 or DS1 granularity. Defining some these protocols is the type of 
-   work of initial interest at both ODSI and the OIF's signaling working 
-   group.
-
-3.1.4 Path Computation
-
-   Although a link state route protocol can be used to obtain network 
-   topology and resource information, this does not imply the use of an 
-   "open shortest path first" route. The path must be open in the sense 
-   that the bandwidth must be available, however the switches along the 
-   path must also be capable, in some way, of transporting the desired 
-   signal type, i.e., we've got an additional constraint.  Other 
-   constraints may include hop count, total delay (mostly propagation), 
-   and hop count. In addition, in addition it may be desirable to route 
-   traffic in order to optimize overall network capacity, reliability or 
-   some combination of the two. Dikstra's algorithm computes the 
-   shortest path with respect to link weights for a single connection at 
-   a time. This can be much different than the paths that would be 
-   selected in response to a request to set up a batch of connections 
-   between a set of endpoints in order to optimize network link 
-   utilization. One can think along the line of global or local 
-   optimization of the network. Due to the complexity of some of the 
-   route algorithms (high dimensionality non-linear integer programming 
-   problems) and various criteria by which one may optimize their 
-   network it may not be possible or desirable to run these algorithms 
-   on network nodes. However, it may still be desirable to have some 
-   basic path computation ability running on the network nodes, 
-   particularly in restoration situations. Such an approach is in line 
-   with the use of MPLS for traffic engineering but is much different 
-   than typical OSPF or IS-IS usage where all nodes must run the same 
-   route algorithm.
-
-3.2 Decomposition of the MPLS/Circuit Switching Problem Space
-
-   Although those familiar with MPLS may be familiar with its 
-   application in a variety of application areas, e.g., ATM, Frame 
-   Relay, etc.  We quickly review its decomposition when applied to the 
-   circuit switching problem space.
-   
-   (i) Information needed to compute paths must be made globally 
-   available throughout the network.  Since this is done via the 
-   link state route protocol any information of this nature must 
-   either be in the existing link state advertisements (LSAs) or 
-   the LSAs must be supplemented to convey this information.  For 
-   example, if its desirable to offer different levels of service 
-   in a network based on whether a circuit is routed over SONET 
-   lines are Ring protected vs. not being protected 
-   (differentiation based on reliability). Then the type of 
-   protection on a SONET line would be an important topological 
-   parameter that should be distributed via the link state route 
-   protocol. Other important parameters are described in 
-   [Kompella].
-
-   (ii) Information that is only needed between two "adjacent" switches 
-   for the purposes of connection establishment is appropriate for 
-   distribution via one of the label distribution protocols. In 
-   fact this information may form the "virtual" label. For example 
-   in SONET if we are distributing information to switches 
-   concerning an end-to-end STS-1 path traversing a network. It is 
-   critical that adjacent switches agree on the "time slot" used 
-   by this STS-1 (but this information is only of local 
-   significance between the two switches). Hence the time slot 
-   number in this case can be used as a virtual label. Note that 
-   it is virtual in that it is not appended to the payload in 
-   anyway, but it is still a label in the sense that it uniquely 
-   identifies the signal local to the link between the two 
-   switches.
-
-   (iii) Information that all switches in the path will need to know 
-   about a connection will also be distributed via the label 
-   distribution protocol. Example of such information can include 
-   bandwidth, priority, and preemption information.
-
-   (iv) Information intended only for end systems of the connection. 
-   Some of the payload type information in [Mannie] may fall into 
-   this category.
-
-
-4. SONET Considerations
-
-   SONET/SDH is a a TDM based multiplexing technology that has a number
-   of standard options that a network user may choose to use. In
-   addition a number of extensions have been proposed [Jones] or are
-   beneficial for network operations, e.g., eliminate the need for link
-   grooming.  This draft reviews the SONET multiplex structure, options
-   and possible extensions with respect to the information that is
-   required to be shared between MPLS LSRs working at the SONET layer
-   for the establishment of SONET layer LSPs.
-
-
-4.1 SONET Structure and Extensions
-
-   The fundamental signal in SONET is the STS-1 (about 51 Mbps). This 
-   signal consists of a transport overhead and a Synchronous Payload 
-   Envelope (SPE). The SPE floats within its alloted space within the 
-   SONET frame structure with the pointer bytes (H1, H2 and H3) in the 
-   Line Overhead of the SONET transport overhead pointing to the 
-   begining of the SPE.  An STS-N signal is formed from a SONET STS-(N- 
-   1) signal and an STS-1 signal via byte interleaving.  The transport 
-   overhead structures are frame aligned prior to interleaving but this 
-   is not required of the SPEs, i.e., there is no special relationship 
-   between the payload envelopes.  To transport signals in excess of 
-   about 50Mbps the SPEs can be concatenated, i.e., glued together. In 
-   this case their relationship with respect to each other is fixed in 
-   time and hence this relieves, when possible, and end system of any 
-   inverse multiplexing bonding processes.
-   
-   Due to the previously describe structure the end points of SONET 
-   connections can be identified by the "time slots" (position) that 
-   they occupy within the interleaved frame structure. In the standard 
-   SONET case we are concerned with which of the M STS-1 paths within an 
-   STS-N signal will be used to transport our data (M <= N, and N = 3, 
-   12, 48, 192,...). The SPEs of these M STS-1s can be concatenated to 
-   form an STS-Mc. The STS-Mc notation is really a short hand way of 
-   describing an STS-M signal whose SPEs have been concatenated.
-   
-   In BellCore GR-253 [GR-253] section 6.1.2 (requirement R6-3) two 
-   conventions are given for identifying an STS-1 within an STS-N:
-
-         - A two-level "STS-3 #, STS-1 #"
-
-         - A single-level "1 to N in order of appearance at the input to
-         the byte-interleaver"
-
-   For example STS-1 number 23 within an OC-48 can also be represented
-   by the tuple (8, 2).  We will be using the single-level numbering
-   scheme in our discussion, but this is not imply an encoding format.
-
-   A second complication is in dealing with concatenated signals. In
-   Bellcore GR-253 section 5.1 the multiplexing procedures for SONET are
-   given. Constraints are imposed on the size of STS-Mc signals, i.e.,
-   they must be a multiple of 3, and on their starting location and
-   interleaving.  This has the following advantages: (a) restriction to
-   multiples of 3 helps with SDH compatibility (there is no STS-1
-   equivalent signal in STS-1 an STM-1 is equivalent (essentially) to an
-   STS-3c); (b) the restriction to multiples of 3 reduces the number of
-   connection types; (c) the restriction on the placement and
-   interleaving could allow more compact representation of the "label";
-   The major disadvantage of these restrictions are: (a) Limited
-   flexibility in bandwidth assignment (somewhat inhibits finer grained
-   traffic engineering). (b) The lack of flexibility in starting time
-   slots for STS-Mc signals and in their interleaving (where the rest of
-   the signal gets put in terms of STS-1 slot numbers) leads to the
-   requirement for re-grooming (due to bandwidth fragmentation).
-
-4.2 SONET Concatenation Extensions
-
-   Due to these disadvantages some SONET framer manufacturers now 
-   support "arbitrary" concatenation, i.e., no restrictions on the size 
-   of an STS-Mc (as long as M <= N) and no constraints on the STS-1 
-   timeslots used to convey it. It is recommended that arbitrary 
-   concatenation be supported in the format for SONET labels. It is also 
-   recommended that the use of arbitrary concatenation or "standard" 
-   concatenation be negotiated as part of the label assignment process 
-   between two SONET LSRs.
-   
-   Note that arbitrary concatenation as used here is a network service 
-   that is similar in nature to the SONET end system service of higher 
-   order virtual concatenation [Jones],[Mannie]. In one example of 
-   virtual concatenation two end systems supporting this feature could 
-   essentially "inverse multiplex" two STS-1s into a virtual STS-2c for 
-   the efficient transport of 100Mbps Ethernet traffic.  The burden in 
-   virtual concatenation is on the end systems while in arbitrary 
-   concatenation it is on the network.  In addition arbitrary 
-   concatenation includes arbitrary interleaving which avoids the need 
-   for link regrooming between any pair of nodes supporting this 
-   feature.
-
-4.3 SONET Connection Bundling
-
-   Connection Bundling is the process of routing a set of non-
-   concatenated STS-1s together as a group, i.e., they are all contained 
-   within the same SONET line (or WDM signal) and receive essentially 
-   the same delay and propagation. This simplifies connection 
-   establishment (especially for batches of DS-3s that are being 
-   wholesaled) and speeds re-routes. Such bundling may be important when 
-   establishing STS-1s that will be used between end systems 
-   implementing virtual concatenation. It is recommended that the labels 
-   chosen for SONET paths can incorporate the concept of STS-1 bundling. 
-   Whether it is desirable to bundle larger signals, i.e., groups of 
-   STS-Mc, is for further study.
-
-4.4 SONET Transparency
-
-   One last transport technique that bears mentioning since it can be 
-   viewed as a service is that of transparent multiplexing or switching. 
-   The SONET over head is broken into three layers: Section, Line and 
-   Path. All these layers are concerned with fault and performance 
-   monitoring. Section overhead is primarily concerned with framing and 
-   Line overhead is primarily concerned with multiplexing and 
-   protection. To perform multiplexing a SONET network element should be 
-   line terminating. However not all SONET multiplexers/switches perform 
-   SONET pointer adjustments on all the STS-1s contained within them or 
-   if they perform the pointer adjustments they do not terminate the 
-   line overhead. For example a multiplexer may take four SONET STS-48 
-   signals and multiplex them onto an STS-192 without performing 
-   standard line pointer adjustments on the individual STS-1s.  This can 
-   be looked at as a service since it may be desirable to pass SONET 
-   signals, like an STS-12 or STS-48, with some level of transparency 
-   through a network and still take advantage of TDM.  Transparent 
-   multiplexing and switching can also be viewed as a constraint since 
-   some multiplexers and switches may not switch at as fine a 
-   granularity as others.  The levels of transparency and their 
-   representation is for further study.
-
-4.5 SONET Protection
-
-   SONET and SDH networks offer a variety of protection options at both 
-   the SONET line and SONET path level.  Standardized SONET line level 
-   protection techniques include Linear 1+1 and Linear 1:N automatic 
-   protection switching (APS)[GR-253] and both two fiber and four fiber 
-   bi-directional line switched rings (BLSRs) [GR-1230]. At the path 
-   layer SONET offers uni-directional path switched ring protection. 
-   Both ring and 1:N line protection also allow for "extra traffic" to 
-   be carried over the protection line when it is not being used, i.e., 
-   not carrying traffic for a failed working line. It may be desirable 
-   to route some connections over lines with protection of a given type, 
-   unprotected lines, or primarily over protection lines as "extra 
-   data". In order to do this the method of protecting a line (if any) 
-   or whether a line is a protection line is useful topology information 
-   that can be disseminated via the link state route protocol. In 
-   addition, a signaling protocol should allow the optional 
-   specification of link protection types as one of the connection 
-   attributes.
-
-5. Summary
-
-   This note has discussed some of the advantages of a circuit switching 
-   control plane based on MPLS in terms of the current interoperability 
-   problems that MPLS can help solve. An overview of the application of 
-   MPLS to circuit switching and its decomposition into routing and 
-   label distribution components was presented. And, finally a few of 
-   the subtleties particular to SONET that need to be taken into account 
-   when an MPLS control plane is applied to this application were 
-   detailed.
-
-6. Acknowledgements
-   The author would like to thank Yakov Rekhter and Jeff Weiss for a 
-   number of enlightening and stimulating discussions that prompted 
-   these notes.
-
-7. References
-
-   [Awduche] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi-
-   Protocol Lambda Switching: Combining MPLS Traffic Engineering Control
-   With Optical Crossconnects", draft-awduche-mpls-te-optical-01.txt
-
-   [Jones] Jones, N., Murton, C., "Extending PPP over SONET/SDH, with
-   virtual concatenation, high order and low order payloads", draft-
-   ietf-pppext-posvcholo-01.txt
-
-   [GR-253] Bellcore Generic Requirements, GR-253-CORE, Synchronous
-   Optical Network (SONET) Transport Systems: Common Generic Criteria,
-   Issue 2, December 1995.
-
-   [Mannie] Mannie, E., "MPLS for SDH control", draft-mannie-mpls-sdh-
-   control-00.txt.
-   
-   [Kompella] Kireeti Kompella, et. al., "Extensions to IS-IS/OSPF and 
-   RSVP in support of MPL(ambda)S", draft-kompella-mpls-optical-00.txt.
-   
-   [Wang] Gouqiand Wang, et. al., "Extensions to OSPF/IS-IS for Optical 
-   Routing", March 2000, Internet Draft, draft-wang-ospf-isis-lambda-te-
-   routing-00.txt. 
-   
-   [Fan] Yanhe Fan, et. al., "Extensions to CR-LDP and RSVP-TE for 
-   Optical Path Set-up", March 2000, draft-fan-mpls-lambda-signaling-
-   00.txt.
-   
-   [Krishna] Murali Krishnaswamy, et. al., "MPLS control plane for 
-   Switched Optical Networks",2/25/00,draft-krishnaswamy-mpls-son-
-   00.txt.
-
-8. Author Information
-
-   Greg Bernstein
-   Ciena Core Switching Division
-   10201 Bubb Road
-   Cupertino, CA 95014
-   e-mail: Greg@ciena.com
-   Phone: (408) 865-6213
-
diff --git a/Documentation/en/I-D/draft-ema-vpim-pndn-00.txt b/Documentation/en/I-D/draft-ema-vpim-pndn-00.txt
deleted file mode 100644
index 534794d3..00000000
--- a/Documentation/en/I-D/draft-ema-vpim-pndn-00.txt
+++ /dev/null
@@ -1,1374 +0,0 @@
-
-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
deleted file mode 100644
index e301be64..00000000
--- a/Documentation/en/I-D/draft-ema-vpim-pndn-01.txt
+++ /dev/null
@@ -1,1311 +0,0 @@
-
-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
deleted file mode 100644
index 43653699..00000000
--- a/Documentation/en/I-D/draft-ema-vpim-pndn-02.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-

-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-03.txt b/Documentation/en/I-D/draft-ema-vpim-pndn-03.txt
deleted file mode 100644
index 09efbe34..00000000
--- a/Documentation/en/I-D/draft-ema-vpim-pndn-03.txt
+++ /dev/null
@@ -1,1290 +0,0 @@
-
-Network Working Group                                              E. Burger
-Internet Draft                                      SnowShore Networks, Inc.
-Document: draft-ema-vpim-pndn-03.txt                       November 21, 2000
-Category: Standards Track 
-Expires May 2001 
- 
- 
-                   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 5/21/2001                   [Page 1] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001          [Page 2] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001          [Page 3] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001          [Page 4] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001          [Page 5] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001          [Page 6] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001          [Page 7] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001          [Page 8] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001          [Page 9] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 10] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 11] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 12] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001
-                                 -                           [Page 13] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 14] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 15] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 16] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 17] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 18] 
-                  Partial Non-Delivery Notification     November, 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-    -field, last
-              code            -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 5/21/2001         [Page 19] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 20] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 21] 
-                  Partial Non-Delivery Notification     November, 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 
-   SnowShore Networks, Inc.
-   c/o CRV
-   1000 Winter St., Suite 3300
-   Waltham, MA  02451-1448
-   USA 
-   Phone: +1 781/487-5406
-   Email: e.burger@ieee.org 
-    
-    
-    
-    
-
-
-
- 
-Burger            Internet Draft - Expires 5/21/2001         [Page 22] 
-                  Partial Non-Delivery Notification     November, 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 5/21/2001         [Page 23] 
-
diff --git a/Documentation/en/I-D/draft-hoffman-rfc2487bis-05.txt b/Documentation/en/I-D/draft-hoffman-rfc2487bis-05.txt
deleted file mode 100644
index 87279606..00000000
--- a/Documentation/en/I-D/draft-hoffman-rfc2487bis-05.txt
+++ /dev/null
@@ -1,363 +0,0 @@
-Internet Draft                                          Paul Hoffman
-draft-hoffman-rfc2487bis-05.txt             Internet Mail Consortium
-February 24, 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.
-
-Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-1. Abstract
-
-   This document describes an extension to the SMTP service that allows
-   an SMTP server and client to use transport-layer security to provide
-   private, authenticated communication over the Internet. This gives
-   SMTP agents the ability to protect some or all of their
-   communications from eavesdroppers and attackers.
-
-   This document updates RFC 2487, as described in Appendix B.
-
-2. Introduction
-
-   SMTP [RFC-821] servers and clients normally communicate in the clear
-   over the Internet. In many cases, this communication goes through one
-   or more router that is not controlled or trusted by either entity.
-   Such an untrusted router might allow a third party to monitor or
-   alter the communications between the server and client.
-
-   Further, there is often a desire for two SMTP agents to be able to
-   authenticate each others' identities. For example, a secure SMTP
-   server might only allow communications from other SMTP agents it
-   knows, or it might act differently for messages received from an
-   agent it knows than from one it doesn't know.
-
-   TLS [TLS], more commonly known as SSL, is a popular mechanism for
-   enhancing TCP communications with privacy and authentication. TLS is
-   in wide use with the HTTP protocol, and is also being used for adding
-   security to many other common protocols that run over TCP.
-
-2.1 Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC-2119].
-
-3. STARTTLS Extension
-
-   The STARTTLS extension to SMTP is laid out as follows:
-
-   (1) the name of the SMTP service defined here is STARTTLS;
-
-   (2) the EHLO keyword value associated with the extension is STARTTLS;
-
-   (3) the STARTTLS keyword has no parameters;
-
-   (4) a new SMTP verb, "STARTTLS", is defined;
-
-   (5) no additional parameters are added to any SMTP command.
-
-4. The STARTTLS Keyword
-
-    The STARTTLS keyword is used to tell the SMTP client that the SMTP
-    server is currently able to negotiate the use of TLS. It takes no
-    parameters.
-
-5. The STARTTLS Command
-
-   The format for the STARTTLS command is:
-
-   STARTTLS
-
-   with no parameters.
-
-   After the client gives the STARTTLS command, the server responds with
-   one of the following reply codes:
-
-   220 Ready to start TLS
-   501 Syntax error (no parameters allowed)
-   454 TLS not available due to temporary reason
-
-   If the client receives the 454 response, the client must decide
-   whether or not to continue the SMTP session. Such a decision is
-   based on local policy. For instance, if TLS was being used for
-   client authentication, the client might try to continue the
-   session, in case the server allows it even with no authentication.
-   However, if TLS was being negotiated for encryption, a client
-   that gets a 454 response needs to decide whether to send the
-   message anyway with no TLS encryption, whether to wait and try
-   again later, or whether to give up and notify the sender of the
-   error.
-
-   A publicly-referenced SMTP server MUST NOT require use of the
-   STARTTLS extension in order to deliver mail locally. This rule
-   prevents the STARTTLS extension from damaging the interoperability of
-   the Internet's SMTP infrastructure. A publicly-referenced SMTP server
-   is an SMTP server which runs on port 25 of an Internet host listed in
-   the MX record (or A record if an MX record is not present) for the
-   domain name on the right hand side of an Internet mail address.
-
-   Any SMTP server may refuse to accept messages for relay based on
-   authentication supplied during the TLS negotiation. An SMTP server
-   that is not publicly referenced may refuse to accept any messages for
-   relay or local delivery based on authentication supplied during the
-   TLS negotiation.
-
-   A SMTP server that is not publicly referenced may choose to require
-   that the client perform a TLS negotiation before accepting any
-   commands. In this case, the server SHOULD return the reply code:
-
-   530 Must issue a STARTTLS command first
-
-   to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
-   client and server are using the ENHANCEDSTATUSCODES ESMTP extension
-   [RFC-2034], the status code to be returned SHOULD be 5.7.0.
-
-   After receiving a 220 response to a STARTTLS command, the client 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 1854, the
-   STARTTLS command must be the last command in a group.
-
-   Servers MUST be able to understand backwards compatible SSL Client
-   Hello messages (provided that client_version is TLS 1.0 or later),
-   and clients MAY use backwards compatible Client Hellos messages. 
-   Neither clients or servers are required to actually offer Client
-   Hello messages for anything other than TLS 1.0.
-
-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.ietf.org
-   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.ietf.org
-   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.
-   An SMTP client can partially protect against these attacks by
-   recording the fact that a particular SMTP server offers TLS during
-   one session and generating an alarm if it does not appear in the
-   EHLO response for a later session. The lack of TLS during a session
-   SHOULD NOT result in the bouncing of email, although it could result
-   in delayed processing.
-
-   If the TLS negotiation fails or if the client receives a 454
-   response, the client has to decide what to do next. There are three
-   main choices: go ahead with the rest of the SMTP session, retry TLS
-   at a later time, or give up and return the mail to the sender. If a
-   failure or error occurs, the client can assume that the server may
-   be able to negotiate TLS in the future, and should try negotiate TLS
-   in a later session, until some locally-chosen timeout occurs, at
-   which point, the client should return the mail to the sender.
-   However, if the client and server were only using TLS for
-   authentication, the client may want to 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-821]   Postel, J., "Simple Mail Transfer Protocol", RFC 821,
-               August 1982.
-
-   [RFC-1869]  Klensin, J., Freed, N, Rose, M, Stefferud, E. and D.
-               Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
-               November 1995.
-
-   [RFC-2034]  Freed, N., "SMTP Service Extension for Returning Enhanced
-               Error Codes", RFC 2034, October 1996.
-
-   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [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: Added a requirement to understand Client Hello messages
-     for earlier versions of SSL.
-   - 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.
-
-
-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-00.txt b/Documentation/en/I-D/draft-huitema-shipworm-00.txt
deleted file mode 100644
index cc926e39..00000000
--- a/Documentation/en/I-D/draft-huitema-shipworm-00.txt
+++ /dev/null
@@ -1,922 +0,0 @@
-INTERNET DRAFT                                              C. Huitema
-<draft-huitema-shipworm-00.txt>                              Microsoft            
-Expires January 12, 2001                                 July 12, 2001
-
-Shipworm: Tunneling IPv6 over UDP through NATs
-
-Status of this memo
-
-This document is an Internet-Draft and is in full conformance with 
-all provisions of Section 10 of RFC2026.
-
-This document is an Internet-Draft. Internet-Drafts are working 
-documents of the Internet Engineering Task Force (IETF), its areas, 
-and its working groups.  Note that other groups may also distribute 
-working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six 
-months and may be updated, replaced, or obsoleted by other documents 
-at any time.  It is inappropriate to use Internet- Drafts as 
-reference material or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at 
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-The list of Internet-Draft Shadow Directories can be accessed at 
-http://www.ietf.org/shadow.html.
-
-Abstract
-
-We propose here a service that would enable nodes located behind one 
-or several IPv4 NATs to obtain IPv6 connectivity by tunneling 
-packets over UDP; we call this the Shipworm service. The 
-establishment of the tunnel is automatic, and does not require any 
-configuration parameters on the client. Running the service requires 
-the help of "Shipworm servers" and "Shipworm relays"; the Shipworm 
-servers are stateless, and only have to manage a small fraction of 
-the traffic between Shipworm clients; the Shipworm relays act as 
-IPv6 routers between the Shipworm service and the "native" IPv6 
-Internet.
-
-1	Introduction
-
-Classic tunneling methods envisaged for IPv6 transition operate by 
-sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal 
-proposes automatic discovery in this context. A problem with these 
-methods is that they don't work when the IPv6 candidate node is 
-isolated behind a Network Address Translation device: NAT are 
-typically not programmed to allow the transmission of arbitrary 
-payload types; even when they are, the local address cannot be used 
-in a 6to4 scheme. 6to4  will work with NAT if the NAT and 6to4 
-router functions are in the same box; we want to cover the 
-relatively frequent case when the NAT cannot be readily upgraded to 
-provide a 6to4 router function. 
-
-
-Huitema                                                      [Page  1]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-A possible way to solve the problem is to rely on a set of "tunnel 
-brokers." There are however limits to any solution that is based on 
-such brokers: the quality of service is not very good, since the 
-traffic follows a "dog leg" route from the source to the broker and 
-then the destination; the broker has to provide sufficient 
-transmission capacity to relay all packets and thus suffers a high 
-cost. For these two reasons, we tend to prefer solutions that allow 
-for "automatic tunneling", i.e. let the packets follow a direct path 
-to the destination.
-
-The automatic tunneling requirement is indeed at odds with some of 
-the specificities of NATs. Establishing a direct path supposes that 
-the IPv6 Candidate can retrieve a "globally routable" address that 
-results from the translation of its local address by one or several 
-NATs; it also supposes that we can find a way to bypass the various 
-"per destination protections" that many NATs implement. In this 
-memo, we will explain how IPv6 candidates located behind NATs can 
-enlist the help of "v6 UDP routers" to learn their "global address" 
-and to obtain connectivity.
-
-2	Definitions
-
-2.1	Shipworm service
-
-The transmission of IPv6 packets over UDP, as defined in this memo.
-
-2.2	Shipworm Client
-
-A node that has some access to the IPv4 Internet and that wants to 
-gain access to the IPv6 Internet. This node may behave either as an 
-IPv6 host or as an IPv6 router. 
-
-2.3	Shipworm Server
-
-A node that has access to the IPv4 Internet through a globally 
-routable address, and that is used as a helper to provide IPv6 
-connectivity to Shipworm Client. The node is also reachable through 
-the Shipworm IPv4 anycast address.
-
-2.4	Shipworm relay router
-
-An IPv6 router that can receive traffic destined to Shipworm clients 
-and forward it using the Shipworm service.
-
-2.5	Shipworm IPv6 service prefix
-
-A 16 bit IPv6 addressing prefix, whose value is XXXX::/16. (TBD 
-IANA) 
-
-
-
-
-
-Huitema                                                      [Page  2]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-2.6	Shipworm IPv4 anycast prefix
-
-An IPv4 address prefix, whose value is x.x.x.0/24. (TBD IANA)
-This prefix is announced in the IPv4 routing tables.
-
-2.7	Shipworm IPv4 anycast address
-
-An IPv4 address whose value is x.x.x.y, where "x.x.x" is the 24 bit 
-Shipworm IPv4 anycast prefix. (TBD IANA)
-IPv4 Packets sent to this address are directed to the nearest 
-Shipworm server.
-
-2.8	Shipworm UDP port
-
-An UDP port number at which Shipworm Servers are waiting for 
-packets. The value of this port is PPPP. (TBD IANA)
-
-2.9	Shipworm bubble
-
-A packet sent over UDP by a Shipworm agent in order to trigger a 
-side effect in the NAT.
-
-2.10	Shipworm Discard port
-
-An UDP port number that is used as the destination of Shipworm 
-bubbles. The normal value for that port number is 9, i.e. the port 
-number reserved by IANA for the discard service.
-
-2.11	Shipworm service port
-
-The port over which the Shipworm client sends Shipworm packets. This 
-port is attached to one of the client's IPv4 interfaces. The IPv4 
-address may or may not be globally routable, as the client may be 
-located behind one or several NAT.
-
-2.12	Shipworm mapped address and Shipworm mapped port
-
-A global IPv4 address and a UDP port that results from the 
-translation by one or several NAT of the IPv4 address and UDP port 
-of a client's Shipworm service port. The client learns these values 
-through the Shipworm protocol described in this memo.
-
-2.13	Shipworm IPv6 client prefix
-
-A global scope 64 bit IPv6 prefix composed from the Shipworm IPv6 
-service prefix, the Shipworm mapped address and Shipworm mapped 
-port. 
-
-2.14	Shipworm IPv6 address
-
-A Shipworm IPv6 address obtained by combining a Shipworm IPv6 client 
-
-Huitema                                                      [Page  3]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-prefix and a 64 bit node identifier.
-
-2.15	Shipworm IPv6 anycast address
-
-A global scope IPv6 address obtained by combining the Shipworm IPv6 
-service prefix, the Shipworm IPv4 anycast address, the Shipworm port 
-and a null 64 bit node identifier (i.e., all zeroes).
-
-
-3	Model, requirements
-
-The Shipworm service requires the cooperation of three kinds of 
-actors: Shipworm clients, who want to use IPv6 despite being located 
-behind a NAT, Shipworm servers who will facilitate the service, and 
-Shipworm relays that provide for the interconnection between the 
-service and the "native IPv6 Internet."
-
-In order to enable the service, the Shipworm servers must have an 
-unencumbered IPv4 connection, i.e. they must have a global IPv4 
-address. In fact, these servers must be dual homed, capable of 
-receiving packet on a specific, topology dependent, IPv4 address, 
-and also of receiving packets on the generic "Shipworm anycast IPv4 
-address."
-
-The Shipworm routers must be connected to the IPv6 Internet and must 
-participate in IPv6 routing; they must be able to announce 
-reachability over IPv6 of the "Shipworm service IPv6 prefix." They 
-must then be able to relay packets over IPv4 UDP towards Shipworm 
-clients. It is very sensible to combine the functions of Shipworm 
-server and Shipworm relay in a single box.
-
-The Shipworm service is designed primarily for robustness: packets 
-are carried over UDP in order to cross as many NAT implementations 
-as possible. The servers are designed to be stateless, which means 
-that they can easily be replicated. We expect indeed to find many 
-such servers replicated at multiple Internet locations.
-
-The primary role of the servers is to enable the NAT traversal. The 
-service is designed in such a way that, as soon as NAT traversal is 
-guaranteed, packets can flow on a direct path between source and 
-destination, without necessarily involving a relay by a Shipworm 
-server.
-
-4	Description of the solution
-
-The Shipworm service is realized by having clients interact with 
-"Shipworm servers" through the Shipworm service protocol.
-
-The Shipworm server is designed to be stateless. It waits for 
-Shipworm requests or test requests on the Shipworm service and 
-Shipworm test ports, and processes by sending a response to the 
-adequate address and port; it waits for IPv6 packets on the Shipworm 
-
-Huitema                                                      [Page  4]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-relay port, and forwards them to the adequate IPv4 address and UDP 
-port.
-
-4.1	Message formats
-
-4.1.1	Shipworm IPv6 addresses
-
-Shipworm IPv6 addresses comprise four components:
-
-   +------+------------+----+-----------------------------+
-   |Prefix|IPv4 address|Port|       Node identifier       |
-   +------+------------+----+-----------------------------+
-
-The 16 bit prefix is the "Shipworm IPv6 Prefix."
-
-The next 32 bits contain a globally routable IPv4 address.
-
-The next 16 bits contain a port number associated with that address.
-
-The last 64 bits contain a node identifier.
-
-4.1.2	Shipworm IPv6 packets encapsulation
-
-Shipworm IPv6 packets are transmitted as UDP packets [13] within 
-IPv4 [14].  The source and destination IP addresses and UDP port 
-take values that are specified in this section.
-
-4.1.3	Maximum Transmission Unit
-
-Since Shipworm uses UDP as an underlying transport, a Shipworm
-Maximum Transfer Unit (MTU) could potentially be as large as the 
-payload of the largest valid UDP datagram (65527 bytes).  However, 
-since Shipworm packets can travel unto unpredictable path over the 
-Internet, it is best to contain this MTU to a small size, in order 
-to minimize the effect of packet fragmentation and reassembly. The 
-default link MTU assumed by a host, and the link MTU supplied by a 
-Shipworm server during Router Advertisement SHOULD normally be set 
-to the minimum IPv6 MTU size of 1280 bytes [5].
-
-Shipworm implementations SHOULD NOT set the "do not fragment" (DF) 
-bit of the encapsulating IPv4 header.
-
-4.1.4	Shipworm bubble
-
-A Shipworm bubble is a minimal UDP packet sent to a specific 
-destination to "prime" a NAT for later accepting packets from this 
-destination. The bubble has the following parameter:
-
-- IPv4 source address: the Shipworm mapped address of the sender
-
-- IPv4 destination address: the IPv4 address of the target
-
-
-Huitema                                                      [Page  5]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-- UDP source port: the Shipworm mapped port of the sender
-
-- UDP destination port: the Shipworm Discard Port.
-
-- UDP payload: the string "Shipworm." 
-
-4.2	Shipworm Client specification
-
-A Shipworm client expects to exchange IPv6 packets through an UDP 
-port, the Shipworm service port. The client will maintain the 
-following variables that reflect the state of the Shipworm service:
-
-- Shipworm connectivity status,
-- Mapped address and port number of the Shipworm service port,
-- Shipworm IPv6 prefix associated with the Shipworm service port,
-- Shipworm IPv6 address or addresses derived from the prefix,
-- Date and time of the last interaction with the Shipworm server,
-- List of recent Shipworm peers.
-
-Before sending any packets, the client must perform the Shipworm 
-qualification procedure, which determines the Shipworm connectivity 
-status, the mapped address and port number, and the Shipworm IPv6 
-prefix. If the qualification is successful, the client may use the 
-Shipworm service port to transmit and receive IPv6 packets, 
-according to the transmission and reception procedures; these 
-procedures use the "list of recent peers". The client must regularly 
-perform the maintenance procedure in order to guarantee that the 
-Shipworm service port remains usable; the need to use this procedure 
-or not depend on the delay since the last interaction with the 
-Shipworm server. 
-
-4.2.1	Qualification procedure
-
-The purpose of the qualification procedure is to establish the 
-status of the local IPv4 connection, and to determine the Shipworm 
-IPv6 client prefix of the local Shipworm interface. The procedure 
-starts when the service is in the "initial" state, and results in a 
-"qualified" state if successful, in an "off-line" or "bad-NAT" stage 
-if unsuccessful.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Huitema                                                      [Page  6]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-          /---------\
-          | Initial |
-          \---------/
-               |
-          +----+----+
-          | Start   |<------+
-          +----+----+       |
-               |            |
-               v            |
-          /---------\ Timer |
-          |Starting |-------+ N attempts   /----------\
-          \---------/--------------------->| Off-line |
-               | Response                  \----------/
-               |
-          +----+----+
-          | Test    |<------+
-          +----+----+       |
-               | OK         |
-               v            |
-          /---------\ Timer |
-          | Testing |-------+ N attempts   /----------\
-          \---------/--------------------->| Bad-NAT  |
-               | Response                  \----------/
-               V
-          /---------\
-          |Qualified|
-          \---------/
-
-Initially, the Shipworm connectivity status is set to "Initial". 
-When the interface is initialized, the system first performs the 
-"start action" by sending a Router Solicit packet. The IPv6 
-destination of the RS is the Shipworm IPv6 anycast address; the IPv6 
-source is the unspecified address; the packet will be sent over UDP 
-to the Shipworm anycast address and Shipworm service port. The 
-connectivity status moves then to "Starting".
-
-In the starting state, the client waits for a router advertisement 
-from the Shipworm server. If no response comes within a time-out, 
-the client should repeat the start action, by resending the Router 
-Solicit packet. If no response has arrived after N=4 repetitions, 
-the client concludes that it cannot use UDP, and that the Shipworm 
-service is not available; the status is set to "Off-line." 
-
-If a response arrives, the client checks that the router 
-advertisement contains exactly one advertised address prefix. This 
-prefix should be a valid Shipworm IPv6 client prefix:
-
-- the first 16 bits contain the Shipworm service TLA,
-
-- the next 32 bits are the client's Shipworm mapped address,
-
-
-Huitema                                                      [Page  7]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-- the next 16 bits are the client's Shipworm mapped port.
-
-The source address of the Router Advertisement is the Shipworm IPv6 
-address of the Shipworm server. This address must be built using an 
-IPv4 unicast address of the server, and a port number at which the 
-server is waiting for packets. 
-
-If the response is a valid router advertisement, from a valid 
-Shipworm source address, and containing a valid Shipworm address 
-prefix, the client should build a Shipworm IPv6 address using the 
-Shipworm IPv6 client prefix learned from the RA and locally selected 
-identifier. The client will then initiate the test of the 
-connection. It does so by sending first a Shipworm bubble whose 
-target is the IPv4 unicast address of the server, as learned from 
-the IPv6 source address of the RA, and then by sending IPv6 ICMP 
-echo request whose IPv6 source address is the client's Shipworm IPv6 
-address, and whose IPv6 destination is the server's Shipworm IPv6 
-address, i.e. the source address of the RA; the echo request is sent 
-over IPv4 UDP to the Shipworm IPv4 anycast address and Shipworm UDP 
-port.
-
-The client is now in the "testing" state, and waits for the ICMP 
-echo response from the Shipworm server. If no response comes within 
-a time-out, the client should repeat the test action, by resending 
-the Shipworm bubble and the Shipworm ICMP echo request. If no 
-response has arrived after N=4 repetitions, the client concludes 
-that the NAT cannot be reliably traversed, and that the Shipworm 
-service is not available; the status is set to "Bad-NAT." 
-
-If the echo response arrives, the address is qualified, and the 
-client can start using the Shipworm service.
-
-4.2.2	Packet reception
-
-The Shipworm client receives packet over the Shipworm interface. The 
-role of the packet reception procedure, besides receiving packets, 
-is to maintain the date and time of the last interaction with the 
-Shipworm server, and the "list of recent peers." Each entry in the 
-list contains an IPv4 address, a UDP port, and a date and time.
-
-When a UDP packet is received, the Shipworm client examines the IPv4 
-source address and port number from which the packet is received. If 
-these values match the Shipworm IPv4 anycast address and Shipworm 
-port, the client updates the "date and time of the last interaction 
-with the Shipworm server" to the current data and time.
-
-The Shipworm client will then examine the IPv6 source address of the 
-encapsulated packet. If the source IPv6 address is a Shipworm IPv6 
-address, the client extracts the "peer IPv4 address" and "peer UDP 
-port" corresponding to that address. If the address and port pair 
-are already represented in the "list of recent peers", the client 
-updates the data and time associated to that list entry. If the pair 
-
-Huitema                                                      [Page  8]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-is not yet represented, the client creates a new list entry for the 
-pair, associated with the current data and time.
-
-The list of peers is used to "optimize" the transmission of IPv6 
-packets by using a "direct path" for the recently active peers. The 
-list of peers could grow over time. Clients should implement a list 
-management strategy, such as for example deleting the least recently 
-used entries. Clients should make sure that the list has a 
-sufficient size, so that most traffic goes over the "direct path."
-
-4.2.3	Packet transmission
-
-When a Shipworm client has to transmit a packet over a Shipworm 
-interface, it examines the destination IPv6 address. If the 
-destination is not a Shipworm IPv6 address, the packet is posted 
-over UDP to the Shipworm IPv4 anycast address and Shipworm UDP port.
-
-If the destination is a Shipworm IPv6 address, the client extracts 
-the "peer IPv4 address" and "peer UDP port" corresponding to that 
-address.
-
-If there is an entry for this address and port pair in the List of 
-recent Shipworm peers for this address and port pair, the packet 
-should be sent over UDP directly to the specified "peer IPv4 
-address" and "peer UDP port".
-
-If there is no entry in the list, the client should first send a 
-Shipworm bubble to the "peer IPv4 address". It should then send the 
-IPv6 packet over IPv4 UDP to the Shipworm IPv4 anycast address and 
-Shipworm UDP port.
-
-4.2.4	Maintenance
-
-The Shipworm client must ensure that the mappings that it uses 
-remain valid. It does so by checking that packets are regularly 
-received from the Shipworm server.
-
-At regular intervals, the client must check the "date and time of 
-the last interaction with the Shipworm server", to ensure that at 
-least one packet has been received in the last 30 seconds. If this 
-is not the case, the client shall send a router solicitation to the 
-Shipworm IPv6 Anycast address. When the router advertisement is 
-received, the client checks that the advertised prefix corresponds 
-to the current Shipworm service prefix. If this is not the case, the 
-mapping has changed; the client must check that the new prefix is 
-valid, as specified in the qualification procedure. It should then 
-invalidate the addresses derived from the old prefixes.
-
-4.3	Shipworm Server specification
-
-The Shipworm server is designed to be stateless. The Shipworm server 
-waits for incoming UDP packets at the Shipworm Relay Port. The 
-
-Huitema                                                      [Page  9]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-incoming packets may be sent to either the Shipworm IPv4 Anycast 
-Address, or to the specific unicast address of the Shipworm Server.
-
-The Shipworm server acts as an IPv6 router. As such, it will receive 
-Router Solicitation packets, to which it will respond with router 
-advertisement packets as explained in the "router solicitation" 
-procedure; it may also receive other packets, for example ICMP 
-packets; ICMP echo request packets must be processed according to 
-the "echo request" procedure.
-
-4.3.1	Processing of Shipworm IPv6 packets
-
-Upon reception of a packet on the Shipworm port, the Shipworm server 
-will first check that the UDP payload contains a valid IPv6 packet; 
-if this is not the case, the packet will be silently discarded. The 
-Shipworm server will then check the IPv6 destination address of the 
-encapsulated IPv6 packet.
-
-If the IPv6 destination address is either the Shipworm IPv6 anycast 
-address or the Shipworm IPv6 address associated to the local 
-interface, the Shipworm server processes the packet; it may in 
-particular have to process "router solicitation" and "echo request" 
-packets according to the corresponding procedures.
-
-If the IPv6 destination address is a valid Shipworm IPv6 address, 
-the Shipworm server encapsulates the IPv6 packet in a new UDP 
-datagram, in which the following parameters are set:
-
-- The destination IPv4 address is derived from the IPv6 destination.
-
-- The source IPv4 address is the Shipworm IPv4 anycast address.
-
-- The destination UDP port is derived from the IPv6 destination.
-
-- The source UDP port is set to the Shipworm Relay Port.
-
-If the destination address is not a Shipworm IPv6 address, the 
-packet should be relayed to the IPv6 Internet using IPv6 routing.
-
-Before relaying packets, the Shipworm server MAY perform the 
-security tests suggested in section 7. 
-
-4.3.2	Processing of router solicitations
-
-When the Shipworm server receives a router solicitation (RS), it 
-retains the IPv4 address and UDP port from which the solicitation 
-was received; these become the Shipworm mapped address and Shipworm 
-mapped port of the client. The router uses these values to compose a 
-Shipworm IPv6 Prefix.
-
-The Shipworm server responds to the router solicitation by sending a 
-Router Advertisement. The router advertisement must advertise the 
-
-Huitema                                                      [Page 10]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-Shipworm IPv6 prefix composed from the mapped address and mapped 
-port. The IPv6 destination address is normally set to the IPv6 
-source address of the RS; if that address was the unspecified 
-address, the IPv6 destination should be set to the Shipworm IPv6 
-anycast address. The Router Advertisement must be sent over UDP to 
-the Shipworm mapped address and Shipworm mapped port of the client; 
-the IPv4 source address and UDP source port should be set to the 
-Shipworm IPv4 anycast address and Shipworm Port.
-
-4.3.3	Processing of echo requests
-
-When the Shipworm server receives an echo request over the Shipworm 
-port, it prepares an ICMP echo reply. If the IPv6 source address of 
-the echo request is a Shipworm address, the IPv6 source address of 
-the response must be set to the Shipworm IPv6 address of the server; 
-the IPv4 destination address and UDP destination port should be set 
-to the value derived from the Shipworm IPv6 address of the client; 
-the IPv4 source address and UDP source address should be set to the 
-values derived from the Shipworm IPv6 address of the server. 
-
-4.3.4	Processing of bubbles
-
-Shipworm servers may receive Shipworm Discard messages on a discard 
-port; these messages are silently discarded.
-
-4.4	Shipworm Relay specification
-
-Shipworm relays are IPv6 routers that advertise reachability of the 
-Shipworm service IPv6 prefix. Shipworm relays will receive IPv6 
-packets bound to Shipworm clients. Shipworm routers can transmit 
-Shipworm packets in one of two ways, depending of whether or not the 
-local configuration allows them to use the Shipworm IPv4 anycast 
-address as the source address of UDP packets.
-
-If the Shipworm Relay can use the Shipworm IPv4 anycast address as a 
-source address, it should transmit the IPv6 packets directly to the 
-target Shipworm client: the IPv4 destination address and UDP 
-destination port are derived from the destination Shipworm IPv6 
-address; the IPv4 source address and UDP source port are set to the 
-Shipworm IPv4 anycast address and Shipworm UDP port.
-
-If the Shipworm Relay cannot use the Shipworm IPv4 anycast address 
-as a source address, it should transmit the IPv6 packets through the 
-nearest Shipworm server: the IPv4 destination address and UDP 
-destination port are set to the Shipworm IPv4 anycast address and 
-Shipworm UDP port; the IPv4 source address and UDP source port are 
-set to a local interface address and local port number on the relay.
-
-It is obviously desirable to combine the functions of Shipworm relay 
-and Shipworm server, but this is not mandatory.
-
-
-
-Huitema                                                      [Page 11]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-5	Discussion of the solution
-
-5.1	Why do we have bubbles and lists of peers?
-
-Experience shows that the implementers of NAT products can adopt 
-widely different treatments of UDP packets:
-
-1. Some implement the simplest solution, which is to map an internal 
-UDP port, defined by an internal address and a port number on the 
-corresponding host, to an external port, defined by a global address 
-managed by the NAT and a port number valid for that address. In this 
-simple case, the mapping is retained as long as the port is active, 
-and is removed after an inactivity timer. As long as the mapping is 
-retained, any packet received by the NAT for the external port is 
-relayed to the internal address and port.
-
-2. Some implement a more complex solution, in which the NAT not only 
-establishes a mapping for the UDP port, but also maintains a list of 
-external hosts to which traffic has been sent from that port. The 
-packets originating from third party hosts to which the local host 
-has not yet sent traffic are rejected.
-
-3. Instead of keeping just a list of authorized hosts, some NAT 
-implementations keep a list of authorized host and port pairs. UDP 
-packets coming from remote addresses are rejected if the internal 
-host has not yet sent traffic to the outside host and port pair.
-
-4. Finally, some NAT map the same internal address and port pair to 
-different external address and port pairs, depending on the address 
-of the remote host.
-
-Measurement campaigns and studies of documentations have shown that 
-most NAT implement either option 1 or option 2. The combination of 
-"bubbles" and "list of peers" allows us to cross these types of NAT; 
-it is not strictly required for the NAT of type 1, but it does not 
-hurt either.
-
-5.2	Why do we test with ICMP?
-
-The purpose of the ICMP test is to check that the client is capable 
-of receiving UDP packets on a mapped port, from a different server 
-than the one which performed the address mapping - i.e. to verify 
-that the NAT is of type 1 or 2, not 3 or 4. The ICMP request will 
-trigger a "triangle":
-
-1) ICMP request sent by the client to the Shipworm IPv4 anycast 
-address,
-
-2) Local transmission on the server between the anycast address and 
-the unicast interface,
-
-
-Huitema                                                      [Page 12]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-3) ICMP response sent from the unicast address of the server.
-
-This test, combined with the transmission of a bubble, is sufficient 
-to check that the same mapping can be used independently of the IPv4 
-address of the peer.
-
-5.3	Why do we need an anycast address?
-
-The use of an IPv4 anycast address to locate the Shipworm server has 
-many advantages. An obvious one is that it solves configuration 
-issues, making it very easy for the Shipworm client to locate the 
-nearest server. A less obvious one is the interaction with the NAT. 
-The type 2 NAT check that the packet comes from a source with which 
-the local client already interacted; by using a single unicast 
-address as the source address of all UDP packets coming from all 
-Shipworm servers, we guarantee that the "pin-hole in the NAT" can be 
-use by all of these servers.
-
-The use of an anycast address is facilitated by the stateless 
-implementation of Shipworm servers: since the service is performed 
-in exactly the same way by any server, it does not matter whether 
-anycast routing carries the packet to a specific server or another.
-
-The only dependency that we have is during the qualification phase: 
-it is important that the echo packet be processed by the same server 
-for which we have sent a bubble. However, since the IPv6 destination 
-address of the echo request specifies a specific server address, we 
-know that even the anycast packet was routed to another server, the 
-normal routing rule will ensure that the packet is relayed from 
-there to the intended server.
-
-The consequences of the use of anycast addresses on access control, 
-scaling, and failover are discussed in [RFC3068] in the context of 
-the "6to4" service.   
-
-5.4	When to use Shipworm?
-
-Shipworm is designed to robustly enable IPv6 traffic through NAT, 
-and the price of robustness is a reasonable amount of overhead, due 
-to UDP encapsulation, transmission of bubbles, and relaying of 
-packets through the Shipworm servers. Nodes that want to connect to 
-the IPv6 Internet should only use the Shipworm service as a "last 
-resort" option: they should prefer using direct IPv6 connectivity if 
-it is locally available, and they should prefer using the less 
-onerous "6to4" encapsulation if they can use a global IPv4 address.
-
-5.5	What about firewalls?
-
-The Shipworm service is not designed to "transparently traverse 
-firewalls." A local administrator can decide to allow or disallow 
-the service, by programming the local firewall to authorize or deny 
-traffic on the Shipworm UDP port. 
-
-Huitema                                                      [Page 13]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-5.6	Why do we use the name Shipworm?
-
-A "Shipworm" is a little saltwater critter that is common in the 
-harbors of warm seas and that digs holes in immersed wood pieces, 
-such as boat hulls or posts. The animal is not an actual worm - it 
-is a mollusk. The Shipworm service also digs holes, albeit in NATs, 
-not in wood. 
-
-On one hand, one may think that the shipworm is a pretty nasty 
-animal. On the other hand, the animal only survives in relatively 
-clean and unpolluted water; its recent comeback in several Northern 
-American harbors is a testimony to their newly retrieved 
-cleanliness. The Shipworm service should, in turn, contribute to a 
-newly retrieved transparency of the Internet. 
-
-6	Future Work
-
-Obviously a lot - this is a first draft.
-
-7	Security Considerations
-
-The security consideration for using a dynamic encapsulation of IPv6 
-over UDP are very similar to the implications of "6to4" [RFC3056], 
-which we partially reproduce here.
-
-Implementors should be aware that, in addition to possible attacks 
-against IPv6, security attacks against IPv4 must also be considered. 
-Use of IP security at both IPv4 and IPv6 levels should nevertheless 
-be avoided, for efficiency reasons.  For example, if IPv6 is running 
-encrypted, encryption of IPv4 would be redundant except if traffic 
-analysis is felt to be a threat.  If IPv6 is running authenticated, 
-then authentication of IPv4 will add little.  Conversely, IPv4 
-security will not protect IPv6 traffic once it leaves the Shipworm 
-service. Therefore, implementing IPv6 security is required even if 
-IPv4 security is available. 
-
-By default, Shipworm traffic will be accepted and decapsulated from 
-any source from which regular IPv4 traffic is accepted.  If this is 
-for any reason felt to be a security risk (for example, if IPv6 
-spoofing is felt to be more likely than IPv4 spoofing), then 
-additional source address based packet filtering could be applied.  
-A possible plausibility check is whether the encapsulating IPv4 
-address is consistent with the encapsulated Shipworm IPv6 address.  
-If this check is applied, exceptions to it must be configured to 
-admit traffic from Shipworm relays and Shipworm servers. 
-
-In any case, any Shipworm traffic whose source or destination 
-address embeds a mapped IPv4 address which is not in the format of a 
-global unicast address MUST be silently discarded by both Shipworm 
-clients and Shipworm servers.  Specifically, this means that IPv4 
-addresses defined in [RFC 1918], broadcast, subnet broadcast, 
-
-Huitema                                                      [Page 14]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-multicast and loopback addresses are unacceptable.
-
-8	IANA Considerations
-
-This memo documents a request to IANA to allocate a Shipworm IPv6 
-service prefix, a Shipworm IPv4 anycast prefix, a Shipworm IPv4 
-anycast address and a Shipworm UDP port.
-
-
-9	Copyright
-
-The following copyright notice is copied from RFC 2026 [Bradner, 
-1996], Section 10.4, and describes the applicable copyright for this 
-document.
-
-Copyright (C) The Internet Society July 12, 2001. All Rights 
-Reserved.
-
-This document and translations of it may be copied and furnished to 
-others, and derivative works that comment on or otherwise explain it 
-or assist in its implementation may be prepared, copied, published 
-and distributed, in whole or in part, without restriction of any 
-kind, provided that the above copyright notice and this paragraph 
-are included on all such copies and derivative works.  However, this 
-document itself may not be modified in any way, such as by removing 
-the copyright notice or references to the Internet Society or other 
-Internet organizations, except as needed for the purpose of 
-developing Internet standards in which case the procedures for 
-copyrights defined in the Internet Standards process must be 
-followed, or as required to translate it into languages other than 
-English.
-
-The limited permissions granted above are perpetual and will not be 
-revoked by the Internet Society or its successors or assignees.
-
-This document and the information contained herein is provided on an 
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-10	Intellectual Property
-
-The following notice is copied from RFC 2026 [Bradner, 1996], 
-Section 10.4, and describes the position of the IETF concerning 
-intellectual property claims made against this document.
-
-The IETF takes no position regarding the validity or scope of any 
-intellectual property or other rights that might be claimed to 
-pertain to the implementation or use other technology described in 
-this document or the extent to which any license under such rights 
-
-Huitema                                                      [Page 15]
-
-
-INTERNET DRAFT               Shipworm                    July 12, 2001
-
-might or might not be available; neither does it represent that it 
-has made any effort to identify any such rights.  Information on the 
-IETF's procedures with respect to rights in standards-track and 
-standards-related documentation can be found in BCP-11.  Copies of 
-claims of rights made available for publication and any assurances 
-of licenses to be made available, or the result of an attempt made 
-to obtain a general license or permission for the use of such 
-proprietary rights by implementers or users of this specification 
-can be obtained from the IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any 
-copyrights, patents or patent applications, or other proprietary 
-rights which may cover technology that may be required to practice 
-this standard.  Please address the information to the IETF Executive 
-Director.
-
-11	Acknowledgements
-
-Many of the ideas in this memo are the result of discussions between 
-the author and Microsoft colleagues, notably Brian Zill and Rick 
-Rashid. Several encapsulation details are inspired from early work 
-by Keith Moore.
-
-12	References
-
-[RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 
-IPv4 Clouds", RFC 3056, February 2001.
-
-[RFC3068] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", 
-RFC 3068, June 2001.
-
-13	Authors' Addresses
-
-Christian Huitema
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052-6399
-
-Email: huitema@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Huitema                                                      [Page 16]
diff --git a/Documentation/en/I-D/draft-ietf-impp-datetime-00.txt b/Documentation/en/I-D/draft-ietf-impp-datetime-00.txt
deleted file mode 100644
index 60235891..00000000
--- a/Documentation/en/I-D/draft-ietf-impp-datetime-00.txt
+++ /dev/null
@@ -1,960 +0,0 @@
-Network Working Group                                C. Newman, Innosoft
-Internet Draft                          G. Klyne, Baltimore Technologies
-                                                            3 April 2001
-                                                 Expires: September 2001
-
-
-               Date and Time on the Internet: Timestamps
-                   <draft-ietf-impp-datetime-00.txt>
-
-
-Status of this memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC 2026.
-
-   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                                          FORMFEED[Page 1]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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 make 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                                          FORMFEED[Page 2]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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
-               Internaational 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                                          FORMFEED[Page 3]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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                                          FORMFEED[Page 4]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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:58: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
-   semanticly 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                                          FORMFEED[Page 5]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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                                          FORMFEED[Page 6]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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 redunant 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                                          FORMFEED[Page 7]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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                                          FORMFEED[Page 8]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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                                          FORMFEED[Page 9]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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.
-
-
-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.
-
-   [HOST-REQ]  Braden, R., "Requirements for Internet Hosts --
-               Application and Support", RFC 1123, Internet Engineering
-               Task Force, October 1989.
-
-
-
-
-
-Newman & Klyne                                         FORMFEED[Page 10]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 2001
-
-
-   [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
-   Innosoft International, Inc.
-   1050 Lakes Drive
-   West Covina, CA 91790 USA
-
-   Email: chris.newman@innosoft.com
-
-   Graham Klyne
-   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
-
-   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 authoratative reference.
-
-   Note that due to ambiguities in ISO 8601, some interpretations had to
-
-
-
-Newman & Klyne                                         FORMFEED[Page 11]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 2001
-
-
-   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 ["-"])
-
-      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                                         FORMFEED[Page 12]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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                                         FORMFEED[Page 13]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 2001
-
-
-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));
-      }
-
-
-
-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>
-
-
-
-Newman & Klyne                                         FORMFEED[Page 14]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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
-
-
-
-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.
-
-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                                         FORMFEED[Page 15]
-
-
-
-
-
-Internet Draft         Date and Time - Timestamps             April 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                                         FORMFEED[Page 16]
-
-
diff --git a/Documentation/en/I-D/draft-ietf-impp-datetime-01.txt b/Documentation/en/I-D/draft-ietf-impp-datetime-01.txt
deleted file mode 100644
index 015c034f..00000000
--- a/Documentation/en/I-D/draft-ietf-impp-datetime-01.txt
+++ /dev/null
@@ -1,962 +0,0 @@
-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
deleted file mode 100644
index 43025ed7..00000000
--- a/Documentation/en/I-D/draft-ietf-impp-datetime-02.txt
+++ /dev/null
@@ -1,1081 +0,0 @@
-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
deleted file mode 100644
index 1ae7cd3d..00000000
--- a/Documentation/en/I-D/draft-ietf-impp-datetime-03.txt
+++ /dev/null
@@ -1,1141 +0,0 @@
-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
deleted file mode 100644
index 8b9bee79..00000000
--- a/Documentation/en/I-D/draft-ietf-impp-datetime-04.txt
+++ /dev/null
@@ -1,1140 +0,0 @@
-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-ldapbis-url-00.txt b/Documentation/en/I-D/draft-ietf-ldapbis-url-00.txt
deleted file mode 100644
index 515d2467..00000000
--- a/Documentation/en/I-D/draft-ietf-ldapbis-url-00.txt
+++ /dev/null
@@ -1,752 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                Mark Smith, Editor
-Request for Comments: DRAFT               Netscape Communications Corp.
-Obsoletes: RFC 2255                                           Tim Howes
-                                                        Loudcloud, Inc.
-
-                                                       21 February 2001
-
-
-                          The LDAP URL Format
-                    <draft-ietf-ldapbis-url-00.txt>
-
-
-
-1.  Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups.  Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet- Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   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
-   [RFC2251], [RFC2253], and [RFC2252].  This document describes a
-   format for an LDAP Uniform Resource Locator.  The format describes an
-   LDAP search operation used to retrieve information from an LDAP
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 1]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 2001
-
-
-   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 [RFC2251] 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 RFC 2396 [RFC2396]>
-       dn         = <distinguishedName from Section 3 of [RFC2253]>
-       attributes = attrdesc *("," attrdesc)
-       attrdesc   = <AttributeDescription from Section 4.1.5 of [RFC2251]> / "*"
-       scope      = "base" / "one" / "sub"
-       filter     = <filter from Section 4 of [RFC2254]>
-       extensions = extension *("," extension)
-       extension  = ["!"] extype ["=" exvalue]
-       extype     = token / xtoken
-       exvalue    = <LDAPString from section 4.1.2 of [RFC2251]>
-       token      = <oid from section 4.1 of [RFC2252]>
-       xtoken     = "x-" token
-
-   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 [RFC2253]. 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           21 February 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 [RFC2251].
-
-   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 [RFC2254].
-
-   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.
-
-   Extension types prefixed by "X-" or "x-" are reserved for use in
-   bilateral agreements between communicating parties. Other extension
-   types MUST be defined in this document, or in other standards-track
-   documents.
-
-   One LDAP URL extension is defined in this document (see the section
-   "The Bindname Extension" below).  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 RFC 2396 [RFC2396]), and the single Reserved character
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 3]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 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 RFC
-   2396 [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
-   [RFC 2251] 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.  The Bindname Extension
-
-   This section defines an LDAP URL extension for representing the
-   distinguished name for a client to use when authenticating to an LDAP
-   directory during resolution of an LDAP URL. Clients MAY implement
-   this extension.
-
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 4]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 2001
-
-
-   The extension type is "bindname". The extension value is the
-   distinguished name of the directory entry to authenticate as, in the
-   same form as described for dn in the grammar above. The dn may be the
-   NULL string to specify unauthenticated access. The extension may be
-   either critical (prefixed with a '!' character) or non-critical (not
-   prefixed with a '!' character).
-
-   If the bindname extension is critical, the client resolving the URL
-   MUST authenticate to the directory using the given distinguished name
-   and an appropriate authentication method. Note that for a NULL
-   distinguished name, no bind MAY be required to obtain anonymous
-   access to the directory. If the extension is non-critical, the client
-   MAY bind to the directory using the given distinguished name.
-
-6.  URL Processing
-
-   This section describes how an LDAP URL SHOULD be resolved by a
-   client.
-
-   First, the client obtains a connection to the LDAP server referenced
-   in the URL, or an LDAP server of the client's choice if no LDAP
-   server is explicitly referenced.  This connection MAY be opened
-   specifically for the purpose of resolving the URL or the client MAY
-   reuse an already open connection if the open connection is compatible
-   with the URL.  The connection MAY provide confidentiality, integrity,
-   or other services, e.g., using TLS.  Use of security services is at
-   the client's discretion if not specified in the URL but is encouraged
-   if the request or any potential responses contains sensitive
-   information.  If the URL represents a referral for an update
-   operation, security services SHOULD be used.
-
-
-   Next, the client authenticates itself to the LDAP server.  This step
-   is optional, unless the URL contains a critical bindname extension
-   with a non-NULL value. If a bindname extension is given, the client
-   proceeds according to the section above.
-
-   If a bindname extension is not specified, the client MAY bind to the
-   directory using an appropriate authentication method of its own
-   choosing (including NULL authentication).  The client may interrogate
-   the server to determine the most appropriate method.
-
-   Next, the client performs the LDAP search operation specified in the
-   URL. Additional fields in the LDAP protocol search request, such as
-   sizelimit, timelimit, deref, and anything else not specified or
-   defaulted in the URL specification, MAY be set at the client's
-   discretion.
-
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 5]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 2001
-
-
-   Once the search has completed, the client MAY close the connection to
-   the LDAP server, or the client MAY keep the connection open for
-   future use.
-
-7.  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:
-
-     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.
-
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 6]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 2001
-
-
-   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)
-
-   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 final example shows the use of the bindname extension to specify
-   the dn a client should use for authentication when resolving the URL.
-
-     ldap:///??sub??bindname=cn=Manager%2co=Foo
-     ldap:///??sub??!bindname=cn=Manager%2co=Foo
-
-   The two URLs are the same, except that the second one marks the
-   bindname extension as critical. Notice the use of the % encoding
-   method to encode the comma in the distinguished name value in the
-   bindname extension.
-
-8.  Security Considerations
-
-   General URL security considerations discussed in RFC 2396 [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 7]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 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 [RFC2829] 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.
-
-9.  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.
-
-10.  References
-
-   [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
-   Requirement Levels," RFC 2119, March 1997.
-
-   [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 8]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 2001
-
-
-   Specifications:  ABNF", RFC 2234, November 1997.
-
-   [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
-   Access Protocol (v3)", RFC 2251, December 1997.
-
-   [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
-   "Lightweight Directory Access Protocol (v3): Attribute Syntax
-   Definitions", RFC 2252, December 1997.
-
-   [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
-   Access Protocol (v3): UTF-8 String Representation of Distinguished
-   Names", RFC 2253, December 1997.
-
-   [RFC2254] Howes, T., "A String Representation of LDAP Search
-   Filters", RFC 2254, December 1997.
-
-   [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
-   Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
-   [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
-   "Authentication Methods for LDAP", RFC 2829, May 2000.
-
-
-11.  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
-
-12.  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
-
-
-
-Smith & Howes      Intended Category: Standards Track           [Page 9]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 2001
-
-
-   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.
-
-
-13.  Appendix A: Changes Since RFC 2255
-
-13.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", "exvalue", and "token" rules.  Simplified the "xtoken" rule
-   by removing the "X-" option (case insensitivity is taken care of by
-   the ABNF).  Reordered rules to more closely follow the order the
-   elements appear in the URL.
-
-
-13.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
-   [RFC2251] can be expressed using this format.
-
-   IESG Note: removed note about lack of satisfactory mandatory
-
-
-
-Smith & Howes      Intended Category: Standards Track          [Page 10]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 2001
-
-
-   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.
-
-   "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 [RFC2251] style
-   throughout the document.  Added references to RFCs 2234 and 2829.
-   Updated RFC 1738 references to the appropriate sections within RFC
-   2396.
-
-   Header and "Authors' Addresses" sections: added "editor" next to Mark
-   Smith's name.  Updated affiliation and contact information.
-
-   Copyright: updated the year.
-
-   "Appendix C: Loose Ends" section: added.
-
-   "Table of Contents" section: added.
-
-
-
-
-
-
-Smith & Howes      Intended Category: Standards Track          [Page 11]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 2001
-
-
-14.  Appendix B: Changes Since Previous Document Revision
-
-   This appendix lists all changes relative to the last published
-   revision, draft-smith-ldapv3-url-update-01.txt.  Note that these
-   changes are also included in Appendix A, but are included here for
-   those who have already reviewed draft-smith-ldapv3-url-update-01.txt.
-
-
-14.1.  Technical Changes
-
-   "URL Definition" section: added angle brackets around free-form prose
-   in the "dn", "hostport", "attrdesc", "filter", "exvalue", and "token"
-   rules.  Simplified the "xtoken" rule by removing the "X-" option
-   (case insensitivity is taken care of by the ABNF).  Reordered rules
-   to more closely follow the order the elements appear in the URL.
-
-
-14.2.  Editorial Changes
-
-   Header: changed document from an individual submission to an ldapbis
-   working group submission.  Discussion referred to the ietf-
-   ldapbis@openldap.org mailing list.
-
-   Header and "Authors' Addresses" sections: added "editor" next to Mark
-   Smith's name.
-
-   "Abstract" section: 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 [RFC2251] can be expressed using this format.
-
-   "URL Definition" section: added text that refers to the ABNF from RFC
-   2234.
-
-   "Defaults for Fields of the LDAP URL" section: added a note to
-   clarify that other specifications MAY specify different defaulting
-   rules.
-
-   Copyright: changed the year to 2001.
-
-   References: changed from [1] style to [RFC2251] style throughout the
-   document.  Added a reference to RFC 2234.  Updated RFC 1738
-   references to the appropriate sections within RFC 2396.
-
-   "Acknowledgements" section: added statement about this being an
-   update to RFC 2255.  Added Jim Sermersheim.
-
-   "Loose Ends" section: removed item about referencing RFC 2396 instead
-
-
-
-Smith & Howes      Intended Category: Standards Track          [Page 12]
-
-INTERNET-DRAFT            The LDAP URL Format           21 February 2001
-
-
-   of 1738 (done).  Removed "Search URLs vs. Referral URLs" item (the
-   editor believe this has been resolved)." Added item about potentially
-   supporting userinfo in LDAP URLs.  Added item about not supporting
-   all parameters of the LDAPv3 search operation.
-
-
-15.  Appendix C: Loose Ends
-
-   Other Extensions: Suggestions for TLS and SASL URL extensions have
-   been made, but more discussion is needed about whether they are
-   needed, how they will be specified, and whether they should be added
-   to this document.
-
-   We need to consider whether it makes sense to support constructs like
-   <userinfo>@<host>:<port> within the hostport field.  We do not want
-   to preclude this in the future, but we may keep the details out of
-   this document.  Note this specification uses the "hostport" construct
-   from RFC 2396, but not the "server" construct (which is the one that
-   contains "userinfo"):
-
-         server        = [ [ userinfo "@" ] hostport ]
-         hostport      = host [ ":" port ]
-
-   Therefore, it may be necessary to replace "hostport" with "server" in
-   this specification.
-
-   Some parameters of the LDAPv3 search operation defined in section
-   4.5.1 of RFC 2251 are not supported by the LDAP URL format, e.g.,
-   derefAliases, sizeLimit, timeLimit, typesOnly, controls.  Some
-   ldapbis working group participants would like to see them supported,
-   while others see this as "out of scope" for ldapbis.  Support for
-   these options could be added using the extension mechanism.
-
-
-This Internet Draft expires on 21 August 2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith & Howes      Intended Category: Standards Track          [Page 13]
-
-
-
-1.     Status of this Memo............................................1
-2.     Abstract.......................................................1
-3.     URL Definition.................................................2
-4.     Defaults for Fields of the LDAP URL............................4
-5.     The Bindname Extension.........................................4
-6.     URL Processing.................................................5
-7.     Examples.......................................................6
-8.     Security Considerations........................................7
-9.     Acknowledgements...............................................8
-10.    References.....................................................8
-11.    Authors' Address...............................................9
-12.    Full Copyright Statement.......................................9
-13.    Appendix A: Changes Since RFC 2255.............................10
-13.1.     Technical Changes...........................................10
-13.2.     Editorial Changes...........................................10
-14.    Appendix B: Changes Since Previous Document Revision...........12
-14.1.     Technical Changes...........................................12
-14.2.     Editorial Changes...........................................12
-15.    Appendix C: Loose Ends.........................................13
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-model-03.txt b/Documentation/en/I-D/draft-ietf-msgtrk-model-03.txt
deleted file mode 100644
index a4a5d751..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-model-03.txt
+++ /dev/null
@@ -1,541 +0,0 @@
-Internet Draft                                                 T. Hansen
-draft-ietf-msgtrk-model-03.txt                         AT&T Laboratories
-Valid for six months                                    November 2, 2000
-
-
-
-                Message Tracking Model and Requirements
-
-                    <draft-ietf-msgtrk-model-03.txt>
-
-                         Authors' version: 1.13
-
-     Status of this Memo
-
-     This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC2026.
-
-     Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other documents at
-any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed on the MSGTRK working
-group mailing list, ietf-msgtrk@imc.org.  To subscribe, send a message
-with the word "subscribe" in the body (on a line by itself) to the
-address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
-be found at http://www.ietf.org/archive/msgtrk.
-
-Copyright Notice
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can I track
-the messages?  Message tracking is the ability to find out the path that
-a particular message has taken through a messaging system and the
-current routing status of that message.  This document provides a model
-
-
-
-Hansen                                                      [Page 1]
-
-Internet Draft  Message Tracking Model and Requirements November 2, 2000
-
-
-of message tracking that can be used for understanding the Internet-wide
-message infrastructure and to further enhance those capabilities to
-include message tracking, as well as requirements for proposed message
-tracking solutions.
-
-1.  Problem Statement
-
-     Consider sending a package through a package delivery company.
-Once you've sent a package, you would like to be able to find out if the
-package has been delivered or not, and if not, where that package
-currently is and what its status is.  Note that the status of a package
-may not include whether it was delivered to its addressee, but just the
-destination.  Many package carriers provide such services today, often
-via a web interface.
-
-     Message tracking extends that capability to the Internet-wide mes-
-sage infrastructure, analogous to the service provided by package car-
-riers:  the ability to quickly locate where a message (package) is, and
-to determine whether or not the message (package) has been delivered to
-its final destination.  An Internet-standard approach will allow the
-development of message tracking applications that can operate in a
-multi-vendor messaging environment, and will encourage the operation of
-the function across administrative boundaries.
-
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS].
-
-2.  Definitions
-The following terms are relevant to message tracking.  The terms Track-
-ing User Agent and Tracking Server are new, while all other terms have
-been collected here from other sources.
-
-     Originating Mail User Agent (MUA)
-               The originating mail user agent is the software used to
-               compose and originate a message.  It is the software sit-
-               ting on a person's desktop.
-
-     Originating Mail Submission Agent (MSA)
-               The Mail Submission Agent accepts a message from a User
-               Agent, adds or modifies it as required for Internet stan-
-               dards and/or site policy, and injects the message into
-               the network.  The MSA may be the initial MTA or may hand
-               off the message to an MTA.
-
-     Message Transfer Agent (MTA)
-               A Message Transfer Agent accepts a message and moves it
-               forward towards its destination.  That destination may be
-
-
-
-Hansen                                                      [Page 2]
-
-Internet Draft  Message Tracking Model and Requirements November 2, 2000
-
-
-               local or reached via another MTA.  It may use a local
-               queue to store the message before transferring it
-               further.  Any MTA may generate a Non-Delivery Notifica-
-               tion.
-
-     Intermediate Message Transfer Agent (MTA)
-               An Intermediate MTA is an MTA that accepts a message for
-               transfer somewhere else.
-
-     Final Message Transfer Agent (MTA)
-               A Final MTA is an MTA that accepts a message for local
-               delivery.  It is the final place that a message is
-               accepted.  The final MTA is what sends any Delivery
-               Status Notificatons (DSNs).  (Intermediate MTA's may also
-               send a DSN if it relays to a non-DSN aware MTA.)
-
-     Foreign Message Transfer Agent
-               A foreign MTA provides delivery of messages using other
-               protocols than those specified for Internet mail, such as
-               an X.400 mail system.
-
-     Gateway Message Transfer Agent (GW-MTA)
-               A gateway MTA accepts a message for transfer to a foreign
-               MTA outside of the Internet protocol space.
-
-     Local Delivery Agent (LDA)
-               The local Delivery Agent delivers the message to the
-               local message store.  (The MTA and LDA are often combined
-               into the same program.)
-
-     Delivery Status Notification (DSN)
-               A Delivery Status Notification [RFC-DSN] is produced by
-               an MTA when a message is unsuccessfully delivered, either
-               to its next hop or the final message store, or when it is
-               successfully delivered, either to a foreign MTA, to a
-               local delivery agent, or a non-DSN aware MTA.  Positive
-               notifications are only performed [RFC-ESMTP-DSN] when
-               specifically requested.
-
-     Non-Delivery Notification (NDN)
-               A non-delivery notification is a special form of DSN
-               indicating unsuccessful delivery.
-
-     Message Disposition Notification (MDN)
-               A Message Disposition Notification is used to report the
-               disposition of a message after it has been successfully
-               delivered to a recipient.
-
-
-
-
-Hansen                                                      [Page 3]
-
-Internet Draft  Message Tracking Model and Requirements November 2, 2000
-
-
-     Tracking User Agent (TUA)
-               A tracking user agent wants to find information on a mes-
-               sage on the behalf of a user.  It is the requestor or
-               initiator of such a request.  (The MUA and TUA could be
-               combined into the same program.)
-
-     Tracking Server
-               A tracking server provides tracking information to a
-               tracking client.  It is the repository of the information
-               about a message for the traversal through a particular
-               MTA.  (The tracking server and MTA may run on the same
-               system.)
-
-3.  Entities
-
-     The entities involved in message tracking are:  message user
-agents, message submission agents, message transfer agents, tracking
-user agents and tracking servers.
-
-4.  Requirements
-
-     These are requirements that any message tracking solution must be
-able to satisfy:
-
-     The message tracking solution:
-
-     **   MUST scale to the internet.
-
-     **   MUST be easy to deploy.
-
-     **   SHOULD maximize the reuse of existing, already deployed tech-
-          nology and infrastructure.
-
-     **   If possible, SHOULD extend existing protocols and not invent
-          new ones.
-
-     **   SHOULD have a low implementation cost.  (This makes it easy to
-          incorporate into existing products.)
-
-     **   MUST restrict tracking of a message to the originator of the
-          message (or a delegate).
-
-     **   MUST be able to do authentication.
-
-     **   MAY allow an originator to delegate this responsibility to a
-          third party.
-
-     **   SHOULD have the property that they would allow per-message
-
-
-
-Hansen                                                      [Page 4]
-
-Internet Draft  Message Tracking Model and Requirements November 2, 2000
-
-
-          delegation of the tracking responsibility.
-
-     **   MUST require a tracking user agent to prove that they are per-
-          mitted to request the tracking information.
-
-     **   MUST be able to uniquely identify messages.
-
-     **   MUST require every message to have unique identification.
-
-5.  Interaction Models
-
-     There are several models by which tracking of messages can be
-enabled, by which messages can be tracked, and by which information can
-be requested and gathered.
-
-5.1.  Tracking Enabling Models
-
-     Either the envelope or message header must contain enough informa-
-tion to track a message and securely retrieve information about the mes-
-sage.  Any message that does not have enough information to track it is
-by definition not trackable.
-
-     If there is not enough information available in current standard
-envelopes or message headers, then the current standards will need to be
-extended.  Either the MUA or MSA must determine the additional informa-
-tion and enable the tracking by adding the additional information to
-either the envelope or header.
-
-     This leads to two tracking enabling models:  passive enabling and
-active enabling.
-
-5.1.1.  Passive Enabling Model
-The "passive enabling" model assumes that there is sufficient informa-
-tion available.  No UA or MSA interaction occurs to turn tracking on; it
-is on by default.
-
-5.1.2.  Active Enabling Model
-
-     The "active  enabling" model requires that the MUA and MSA exchange
-information when the message is submitted.  This exchange indicates that
-logging of the message's traversal should be performed, as well as pro-
-viding enough additional information to allow the message to be tracked.
-This information will need to be passed on to subsequent MTAs as needed.
-
-5.2.  Tracking Request Models
-There are several models by which tracking information may be requested.
-
-
-
-
-
-Hansen                                                      [Page 5]
-
-Internet Draft  Message Tracking Model and Requirements November 2, 2000
-
-
-5.2.1.  Passive Request Model
-
-     The "passive request" model requires active enabling to indicate
-that some form of tracking is to be performed.  The tracking information
-can be sent back immediately (as a form of telemetry) or sent to a 3rd
-party for later retrieval.
-
-5.2.2.  Passive Request Tracking Information
-
-     Forms of passive tracking information that could potentially be
-requested are  as  follows.  Note that mechanisms already exist for
-requesting the information marked with a (+).  The references for such
-mechanisms are listed at the end of each such entry.
-
-     **   send a DSN of a message arriving at an intermediate MTA
-
-     **   (+) send a DSN of a message being rejected while at an inter-
-          mediate MTA [RFC-DSN]
-
-     **   (+) send a DSN of a message leaving an intermediate MTA and
-          going to another MTA [RFC-DELIVER-BY]
-
-     **   send a DSN of a message arriving at a final MTA
-
-     **   (+) send a DSN of a message being rejected while at a final
-          MTA [RFC-DSN]
-
-     **   (+) send a DSN of a message being delivered to a user's mes-
-          sage store [RFC-DSN]
-
-     **   (+) send a DSN of a message being delivered to a foreign MTA
-          [RFC-DSN]
-
-     **   (+) send an MDN of a message being read by an end user [RFC-
-          MDN]
-
-5.3.  Active Request Model
-
-     The "active request" model requires an active query by a user's
-user agent to the MSA, intermediate MTAs and final MTA, or to a third
-party, to find the message's status as known by that MTA.  Active
-request will work with either passive enabling or active enabling.
-
-5.3.1.  Server Chaining vs. Server Referrals
-When a tracking server has been asked for tracking information, and the
-message has been passed on to another MTA of which this tracking server
-has no tracking knowledge, there are two modelling choices:
-
-
-
-
-Hansen                                                      [Page 6]
-
-Internet Draft  Message Tracking Model and Requirements November 2, 2000
-
-
-     **   the first tracking server will contact the next tracking
-          server to query for status and pass back the combined status
-          (server chaining), or
-
-     **   the first tracking server will return the address of the next
-          MTA and the tracking client has the responsibility of contact-
-          ing the next tracking server (server referrals).
-
-5.3.2.  Active Request Tracking Information
-Forms of active tracking information that could potentially be requested
-are as follows.  (Note that no mechanisms currently exist for requesting
-such information.)
-
-     **   the message has been queued for later delivery
-
-     **   the message was delivered locally
-
-     **   the message was delivered to another MTA,
-
-     **   the message was delivered to a foreign MTA
-
-     **   ask a different tracking server,
-
-     **   I know but can't tell you,
-
-     **   I don't know.
-
-5.4.  Combining DSN and MDN Information with Message Tracking Informa-
-tion
-
-     The information that would be retrieved by message tracking and the
-information that is returned for DSN and MDN requests all attempt to
-answer the question of "what happened to message XX"?  The information
-provided by each is complementary in nature, but similar.  A tracking
-user agent could use all three possible information  sources  to present
-a total view of the status of a message.
-
-     Both DSN and MDN notifications utilize the formats defined by RFC
-1892 [RFC-REPORT].  This suggests that the information returned by mes-
-sage tracking solutions should also be similar.
-
-6.  Security
-
-     This is a security model for message identification and authentica-
-tion that could be deployed.  (There may be others.)
-
-     A Tracking User Agent must prove that they are permitted to request
-tracking information about a message.  Every [RFC-822]-compliant message
-
-
-
-Hansen                                                      [Page 7]
-
-Internet Draft  Message Tracking Model and Requirements November 2, 2000
-
-
-is supposed to contain a Message-Id header.  One possible mechanism is
-for the originator to calculate a one-way hash A from the message ID +
-time stamp + a per-user secret.  The user then calculates another one-
-way hash B to be the hash of A.  The user includes B in the submitted
-message, and retains A.  Later, when the user makes a message tracking
-request to the messaging system or tracking entity, it submits A in the
-tracking request.  The entity receiving the tracking request then uses A
-to calculate B, since it was already provided B, verifying that the
-requestor is authentic.  In summary,
-
-     A = H(message ID + time stamp + secret)
-
-     B = H(A)
-
-Another possible mechanism for A is to ignore the message ID and time
-stamp and just use a one-way hash from a large (>128 bits) random
-number.  B would be calculated as before.  In summary,
-
-     A = H(large-random-number)
-
-     B = H(A)
-
-This is similar in technique to the methods used for One-Time Passwords
-[RFC-OTP].  The success of these techniques is dependent on the random-
-ness of the per-user secret or the large random number, which can be
-incredibly difficult in some environments.
-
-     If the originator of a message were to delegate his or her tracking
-request to a third party by sending it A, this would be vulnerable to
-snooping over unencrypted sessions.  The user can decide on a message-
-by-message basis if this risk is acceptable.
-
-7.  References
-
-
-     [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
-               Text Messages", STD 11, RFC 822, UDEL, August 1982.
-
-     [RFC-DELIVER-BY]
-               Newman, D., "Deliver By SMTP Service Extension", draft-
-               newman-deliver-02.txt, Innosoft, January 1999.
-
-     [RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible Message For-
-               mat for Delivery Status Notifications", RFC 1894, Univer-
-               sity of Tennessee, Octel Network Services, January 1996.
-
-     [RFC-ESMTP-DSN]
-               Moore, K., "SMTP Service Extension for Delivery Status
-
-
-
-Hansen                                                      [Page 8]
-
-Internet Draft  Message Tracking Model and Requirements November 2, 2000
-
-
-               Notifications", RFC 1891, University of Tennessee, Janu-
-               ary 1996.
-
-     [RFC-KEYWORDS]
-               Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", RFC 2119, Harvard University, March
-               1997.
-
-     [RFC-MDN] Fajman, R., "An Extensible Message Format for Message
-               Disposition Notifications", RFC 2298, National Institutes
-               of Health, March 1998.
-
-     [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw, M., "A One-Time
-               Password System", RFC 2289, Bellcore, Kaman Sciences Cor-
-               poration, Nesser & Nesser Consulting, Bellcore, February
-               1998.
-
-     [RFC-REPORT]
-               Vaudreuil, G., "The Multipart/Report Content Type for the
-               Reporting of Mail System Administrative Messages", RFC
-               1892, Octel Network Services, January 1996.
-
-     [RFC-SMTP]Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-               821, USC/Information Sciences Institute, August 1982.
-
-8.  Acknowledgements
-
-     This document is the product of input from many people and many
-sources, including all of the members of the Message Tracking Working
-Group.  It owes much to earlier work by Gordon Jones, Bruce Ernst and
-Greg Vaudreuil.  In particular, I'd like to also thank Ken Lin for his
-considerable contributions to the early drafts.
-
-9.  Authors' Addresses
-     Tony Hansen
-     AT&T Laboratories
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1 732 576-3207
-     E-Mail: tony@att.com
-
-10.  Full Copyright Statement
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-     This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it or
-
-
-
-Hansen                                                      [Page 9]
-
-Internet Draft  Message Tracking Model and Requirements November 2, 2000
-
-
-assist in its implmentation may be prepared, copied, published and dis-
-tributed, in whole or in part, without restriction of any kind, provided
-that the above copyright notice and this paragraph are included on all
-such copies and derivative works.  However, this document itself may not
-be modified in any way, such as by removing the copyright notice or
-references to the Internet Society or other Internet organisations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet Stan-
-dards process must be followed, or as required to translate it into
-languages other than English.
-
-     The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-     This document and the information contained herein is provided on
-an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
-NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
-NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE.
-
-     This document expires May 2, 2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hansen                                                     [Page 10]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-02.txt b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-02.txt
deleted file mode 100644
index 6135bf48..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-02.txt
+++ /dev/null
@@ -1,954 +0,0 @@
-
-
-
-
-
-
-Internet Draft                                                 T. Hansen
-draft-ietf-msgtrk-mtqp-02.txt                          AT&T Laboratories
-Valid for six months                                       March 2, 2001
-
-
-
-                    Message Tracking Query Protocol
-
-                    <draft-ietf-msgtrk-mtqp-02.txt>
-
-                         Authors' version: 1.6
-
-     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        March 2, 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 [RFC-TRACK-
-MODEL] discusses the models that message tracking solutions could fol-
-low, along with requirements for a message tracking solution that can be
-used with the Internet-wide message infrastructure.  This memo and its
-companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete
-message tracking solution that satisfies those requirements.  The memo
-[RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides
-the information necessary to track messages.  This memo defines a proto-
-col that can be used to query the status of messages that have been
-transmitted on the Internet via SMTP.  The memo [RFC-TRACK-TSN]
-describes the message/tracking-status MIME media type that is used to
-report tracking status information.  Using the model document's termi-
-nology, 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], [RFC-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        March 2, 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.  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        March 2, 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        March 2, 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
-"unknown".
-     "/" "unavailable"
-     "/" "admin"
-     "/" "unknown"
-     "/" "referral" "=" net_loc
-
-     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.
-
-     One option specification is defined here:
-
-
-
-
-Hansen                                                          [Page 5]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-     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: .
-
-     Example #6 (Referred to another server):
-     S: -ERR/MTQP/referral=server42.example.com:37
-
-4.  TRACK Command
-
-     Syntax:
-          "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF
-
-          mtrk-secret = base64
-
-     Envid is defined in [RFC-TRACK-ESMTP].  Mtrk-secret is the secret A
-described in [RFC-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
-
-
-
-Hansen                                                          [Page 6]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-subparts of message/tracking-status, as defined in [RFC-TRACK-TSN].  The
-response contains the tracking information about the email message that
-used the given tracking-id.
-
-
-     In each of the examples below, the envid is "<12345-
-20010101@example.com>", the secret A is "abcdefghijklmnopqrstuvwxyz",
-and the SHA1 hash B is TBD.  The message came from example.com and the
-MTQP server is example2.com.
-
-     Example #7 Message Delivered:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
-     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: user1
-     S: Final-Recipient: user1
-     S: Action: delivered
-     S: --%%%%--
-     S: .
-
-     Example #8 Message Transferred:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
-     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: user1
-     S: Final-Recipient: user1
-     S: Action: transferred
-     S: Remote-MTA: example3.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S: --%%%%--
-     S: .
-
-
-
-
-Hansen                                                          [Page 7]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-     Example #9 Message Delayed:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
-     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: user1
-     S: Final-Recipient: user1
-     S: Action: delayed
-     S: Remote-MTA: 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: .
-
-     Example #10 Two Users, One Relayed, One Failed:
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
-     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: user1
-     S: Final-Recipient: user1
-     S: Action: relayed
-     S: Remote-MTA: example3.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S:
-     S: Original-Recipient: user2
-     S: Final-Recipient: user2
-     S: Action: failed
-     S: Remote-MTA: example3.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     S: --%%%%--
-     S: .
-
-     Example #11 Firewall, Hiding System Names Behind the Firewall:
-
-
-
-Hansen                                                          [Page 8]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo=
-     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: user1
-     S: Final-Recipient: user1
-     S: Action: relayed
-     S: Remote-MTA: example2.com
-     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
-     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: user1
-     S: Final-Recipient: user1
-     S: Action: delivered
-     S: --%%%%--
-     S: .
-
-5.  COMMENT Command
-
-     Syntax:
-          "COMMENT" opt-text CRLF
-
-          opt-text = [WSP *(VCHAR / WSP)]
-
-     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
-
-
-
-Hansen                                                          [Page 9]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-"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
-
-     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
-from the client (other than a QUIT command) with a negative "-BAD"
-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
-
-
-
-Hansen                                                         [Page 10]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-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 #12 :
-     C: TRACK <tracking-id> 1234567890ABCDEF
-     S: +OK+ Tracking information follows
-     S:
-     S: ... tracking details #1 go here ...
-     S: .
-     C: TRACK <tracking-id-2> ABCDEF1234567890
-     S: +OK+ Tracking information follows
-     S:
-     S: ... tracking details #2 go here ...
-     S: .
-
-     Example #13 :
-     C: TRACK <tracking-id> 1234567890ABCDEF
-     C: TRACK <tracking-id-2> ABCDEF1234567890
-     S: +OK+ Tracking information follows
-     S:
-
-
-
-Hansen                                                         [Page 11]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-     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".
-
-     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
-
-
-
-
-Hansen                                                         [Page 12]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-     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
-
-     Security considerations discussed in [RFC-TRACK-MODEL] and [RFC-
-TRACK-ESMTP] are relevant.
-
-     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.
-
-     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.
-
-
-
-Hansen                                                         [Page 13]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-     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.
-
-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
-
-     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
-
-
-
-Hansen                                                         [Page 14]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-     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.
-
-     [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-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-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.
-
-
-
-Hansen                                                         [Page 15]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-     [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
-
-     [RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T.
-Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc.,
-AT&T Laboratories, TBD 2000.
-
-     [RFC-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, "Mes-
-sage Tracking Models and Requirements", AT&T Laboratories, November
-2000.
-
-     [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
-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.
-
-
-
-Hansen                                                         [Page 16]
-
-Internet Draft      Message Tracking Query Protocol        March 2, 2001
-
-
-     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 August 2, 2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hansen                                                         [Page 17]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-01.txt b/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-01.txt
deleted file mode 100644
index b4216227..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-01.txt
+++ /dev/null
@@ -1,434 +0,0 @@
-
-
-
-
-Internet Draft                                               E. Allman
-draft-ietf-msgtrk-smtpext-01.txt                        Sendmail, Inc.
-Valid for six months                                         T. Hansen
-Updates: RFC 1891                                    AT&T Laboratories
-                                                        March 20, 2001
-
-
-
-
-                        SMTP Service Extension
-                         for Message Tracking
-
-                  <draft-ietf-msgtrk-smtpext-01.txt>
-
-Status of This Memo
-
-     This  document  is  an  Internet-Draft and is in full conformance
-with all provisions of Section 10  of  RFC2026.   Internet-Drafts  are
-working  documents  of the Internet Engineering Task Force (IETF), its
-areas, and its working groups.  Note that other groups may  also  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 msgtrk@imc.org mailing list.  An archive of  the  mailing  list
-may be found at
-
-    http://www.ietf.org/archive/msgtrk
-
-
-     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     March 20, 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     March 20, 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 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     March 20, 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 retransmissions of  this  message  MUST  assign  a  new
-      ENVID.  In this context, "retransmission" includes forwarding or
-      resending a message.
-
-   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
-      receive tracking certifiers.  MTAs MUST NOT forward MTRK  certi-
-      fiers when doing mailing list expansion.
-
-
-
-Allman & Hansen                                               [Page 4]
-
-Internet Draft     Message Tracking ESMTP Extension     March 20, 2001
-
-
-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.
-
-           MTAs  SHOULD  take precautions to make certain that message
-      tracking cannot be used to explore internal topologies  of  net-
-      works.
-
-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.
-
-   [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.
-
-
-
-
-Allman & Hansen                                               [Page 5]
-
-Internet Draft     Message Tracking ESMTP Extension     March 20, 2001
-
-
-   [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]
-
-   [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.
-
-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
-
-
-
-
-
-
-Allman & Hansen                                               [Page 6]
-
-Internet Draft     Message Tracking ESMTP Extension     March 20, 2001
-
-
-       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-02.txt b/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-02.txt
deleted file mode 100644
index 4c3edb74..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-smtpext-02.txt
+++ /dev/null
@@ -1,434 +0,0 @@
-
-
-
-
-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-trkstat-01.txt b/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-01.txt
deleted file mode 100644
index 0eb9548a..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-01.txt
+++ /dev/null
@@ -1,502 +0,0 @@
-
-
-
-
-Internet Draft                                               E. Allman
-draft-ietf-msgtrk-trkstat-01.txt                        Sendmail, Inc.
-Valid for six months                                    March 20, 2001
-Updates: RFC 1893
-
-
-
-
-              The Message/Tracking-Status MIME Extension
-
-                  <draft-ietf-msgtrk-trkstat-01.txt>
-
-Status of This Memo
-
-     This  document  is  an  Internet-Draft and is in full conformance
-with all provisions of Section 10  of  RFC2026.   Internet-Drafts  are
-working  documents  of the Internet Engineering Task Force (IETF), its
-areas, and its working groups.  Note that other groups may  also  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 msgtrk@imc.org mailing list.  An archive of  the  mailing  list
-may be found at
-
-    http://www.ietf.org/archive/msgtrk
-
-
-     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         March 20, 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 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 of "tracking-status"; each subpart  MUST  be  type  "mes-
-   sage/tracking-status" as described herein.
-
-   3.1.  The message/tracking-status content-type
-
-           The message/tracking-status content-type is defined as fol-
-      lows:
-
-          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.
-
-
-Allman                                                        [Page 2]
-
-Internet Draft          Message/Tracking-Status         March 20, 2001
-
-
-           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 headers "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.  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  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 )
-
-
-      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.
-
-
-
-
-
-Allman                                                        [Page 3]
-
-Internet Draft          Message/Tracking-Status         March 20, 2001
-
-
-      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.
-
-              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
-
-
-Allman                                                        [Page 4]
-
-Internet Draft          Message/Tracking-Status         March 20, 2001
-
-
-                      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.
-
-      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
-
-
-Allman                                                        [Page 5]
-
-Internet Draft          Message/Tracking-Status         March 20, 2001
-
-
-         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  an  LDA  that  under-
-      stands  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 com-
-      pliant  MTA;  that  is,  a "transferred" tracking 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
-
-
-Allman                                                        [Page 6]
-
-Internet Draft          Message/Tracking-Status         March 20, 2001
-
-
-      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.
-
-   [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.
-
-
-Allman                                                        [Page 7]
-
-Internet Draft          Message/Tracking-Status         March 20, 2001
-
-
-        November 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.
-
-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 8]
-
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-02.txt b/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-02.txt
deleted file mode 100644
index cc008806..00000000
--- a/Documentation/en/I-D/draft-ietf-msgtrk-trkstat-02.txt
+++ /dev/null
@@ -1,565 +0,0 @@
-
-
-
-
-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-ngtrans-ipv6-smtp-requirement-01.txt b/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-01.txt
deleted file mode 100644
index d674b76e..00000000
--- a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-01.txt
+++ /dev/null
@@ -1,354 +0,0 @@
-
-
-
-Internet Engineering Task Force                        Motonori Nakamura
-INTERNET-DRAFT                                          Kyoto University
-Expires: January 5, 2002                        Jun-ichiro itojun Hagino
-                                                 IIJ Research Laboratory
-                                                            July 5, 2001
-
-
-                   IPv6 SMTP operational requirements
-            draft-ietf-ngtrans-ipv6-smtp-requirement-01.txt
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as ``work in progress.''
-
-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 5, 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 5, 2002                [Page 1]
-
-
-DRAFT              IPv6 SMTP operational requirements          July 2001
-
-In IPv4 SMTP operation, we register MX records like below, for
-"sample.org."  domain:
-
-     sample.org.             IN MX   1  mx1.sample.org.
-                             IN MX   10 mx10.sample.org.
-     mx1.sample.org.         IN A    1.0.0.1
-     mx10.sample.org.        IN A    1.0.0.2
-
-When an MTA delivers a message to a particular destination (say it is to
-foo@sample.org), the MTA would send DNS queries to lookup DNS database
-in the following order:
-
-o Lookup MX record for "sample.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.
-
-  o If MX lookup failed with NO_DATA, it means that there is no MX
-    record but there can be other record for "sample.org.".  Lookup A
-    record for "sample.org.".
-
-  o If MX lookup failed with HOST_NOT_FOUND, it means that there is no
-    record at all for "sample.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
-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] .
-
-
-
-
-
-NAKAMURA, HAGINO        Expires: January 5, 2002                [Page 2]
-
-
-DRAFT              IPv6 SMTP operational requirements          July 2001
-
-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:
-
-     sample.org.             IN MX   1  mx1.sample.org.
-                             IN MX   10 mx10.sample.org.
-     mx1.sample.org.         IN A    1.0.0.1          ; IPv4/v6 dual stack
-                             IN AAAA 3ffe:501:ffff::1
-     mx10.sample.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).
-
-(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)
-     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).
-
-
-
-
-NAKAMURA, HAGINO        Expires: January 5, 2002                [Page 3]
-
-
-DRAFT              IPv6 SMTP operational requirements          July 2001
-
-(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.sample.org.
-
-     sample.org.     IN MX   1   mx1.sample.org.
-                     IN MX   10  mx10.sample.org.
-                     IN MX   100 mx100.sample.org.
-
-If mx1.sample.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.sample.org.
-     sample.org.     IN MX   1   mx1.sample.org.     ; IPv6 only
-                     IN MX   10  mx10.sample.org.    ; IPv4 only
-                     IN MX   100 mx100.sample.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.
-     sample.org.     IN MX   1   mx1.sample.org.     ; IPv4/v6 dual stack
-                     IN MX   10  mx10.sample.org.    ; IPv4 only
-                     IN MX   100 mx100.sample.org.   ; IPv6 only
-
-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.
-
-
-
-
-NAKAMURA, HAGINO        Expires: January 5, 2002                [Page 4]
-
-
-DRAFT              IPv6 SMTP operational requirements          July 2001
-
-5.  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.
-
-
-6.  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.
-
-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.
-
-
-Change history
-
-00 -> 01
-     Correct email address notation for source-routed emails, based on a
-
-
-NAKAMURA, HAGINO        Expires: January 5, 2002                [Page 5]
-
-
-DRAFT              IPv6 SMTP operational requirements          July 2001
-
-     comment from Gregory Neil Shapiro.
-
-
-Acknowledgements
-
-The draft was written based on discussions with Japanese IPv6 users, and
-help from WIDE research group.
-
-
-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: January 5, 2002                [Page 6]
-
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
deleted file mode 100644
index 9ad33375..00000000
--- a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt
+++ /dev/null
@@ -1,413 +0,0 @@
-
-
-
-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
deleted file mode 100644
index ad9e0a68..00000000
--- a/Documentation/en/I-D/draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt
+++ /dev/null
@@ -1,413 +0,0 @@
-
-
-
-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-vpim-hint-04.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-04.txt
deleted file mode 100644
index 783bd956..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-hint-04.txt
+++ /dev/null
@@ -1,1116 +0,0 @@
-
-Network Working Group                                           E. Burger
-Internet Draft                                         SnowShore Networks
-Document: draft-ietf-vpim-hint-04.txt                          E. Candell
-Category: Standards Track                        Comverse Network Systems
-Expires August 2001                                              C. Eliot
-                                                    Microsoft Corporation
-                                                                 G. Klyne
-                                                     Content Technologies
-                                                        February 22, 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.  The URL for the VPIM website is 
-   <http://www.vpim.org>. 
-    
-    
-    
-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 8/22/01                    [Page 1] 
-                  Message Context for Internet Mail      February 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. short-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.................................................11 
-9.2.3. fax-message...................................................11 
-9.2.4. short-message.................................................12 
-9.2.5. multimedia-message............................................13 
-9.2.6. text-message..................................................13 
-9.2.7. none..........................................................14 
-10. APPENDIX: Some messaging scenarios...............................14 
-10.1. Internet e-mail................................................15 
-10.2. Short text messaging service...................................15 
-10.3. Facsimile......................................................16 
-10.4. Voice mail.....................................................16 
-10.5. Multimedia message.............................................16 
-11. References.......................................................17 
-12. Acknowledgments..................................................18 
-13. Author's Addresses...............................................18 
-14. Full Copyright Statement.........................................20 
-    
-
-
-
-
-
-
-
-
-  
-Burger et. al.             Expires 8/22/01                    [Page 2] 
-                  Message Context for Internet Mail      February 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 8/22/01                    [Page 3] 
-                  Message Context for Internet Mail      February 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 short text 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., short text 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 8/22/01                    [Page 4] 
-                  Message Context for Internet Mail      February 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 8/22/01                    [Page 5] 
-                  Message Context for Internet Mail      February 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 8/22/01                    [Page 6] 
-                  Message Context for Internet Mail      February 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 8/22/01                    [Page 7] 
-                  Message Context for Internet Mail      February 2001  
- 
-        message-context-class =  (   "voice-message" 
-                                   | "fax-message" 
-                                   | " short-message" 
-                                   | "multimedia-message" 
-                                   | "text-message" 
-                                   | "none" 
-                                   | extension-type ) 
-    
-        extension-type = token   ; Defined and registered per Section 8 
-                       / x-token ; Experimental, private use 
-    
-        token = <syntax as defined by [8],  
-                 but not starting with the characters "X-" or "x-"> 
-    
-        x-token = <syntax as defined by [Error! Bookmark not defined.] 
-   for private use> 
-    
-   Note: The values for Message-Context must be either IANA registered 
-   values or experimental, X- 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. short-message 
-    
-   The short-message class states the message is a short text message, 
-   such as a short text message service (SMS) message or text pager 
-   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 8/22/01                    [Page 8] 
-                  Message Context for Internet Mail      February 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. 
-    
-   NOTE: ietf-types@iana.org is a placeholder for the appropriate IANA 
-   address for registrations. 
-    
-   We would expect new registrations to reflect sensible message 
-   contexts that will arise in the future. 
-    
-    
-9.1. Message-Context Registration 
-    
-   To: ietf-types@iana.org 
-   Subject: Registration of New Top-Level Header Field Message-Context 
-    
-   Header name: 
-   Message-Context 
-    
-   Required parameters: 
-   Single 7bit text value 
-    
-   Parameter value: 
-   The parameter value specifies the message context for the message. 
-    
-   Security considerations: 
-   The intention for this header is to indicate media content type 
-   only.  One can imagine one creating an "Application" primary content 
-
-  
-Burger et. al.             Expires 8/22/01                    [Page 9] 
-                  Message Context for Internet Mail      February 2001  
- 
-   type, and have a poorly designed user agent blindly execute a mailed 
-   program. 
-    
-   Published specification: 
-   draft-ietf-vpim-hint-04.txt 
-    
-   Applications that use this context class: 
-   Mail 
-   VPIM 
-   FPIM 
-    
-   Additional information: none 
-    
-   Person & email address to contact for further information: 
-   Eric Burger 
-   e.burger@ieee.org 
-    
-   Intended usage: COMMON 
-    
-    
-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: ietf-types@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 
-  
-Burger et. al.             Expires 8/22/01                   [Page 10] 
-                  Message Context for Internet Mail      February 2001  
- 
-       | relates, etc. 
-    
-   Person & email address to contact for further information: 
-       | Name & e-mail! 
-    
-   Intended usage: 
-       | pick one of COMMON, LIMITED USE, or OBSOLETE 
-    
-9.2.2. voice-message 
-    
-   To: ietf-types@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: 
-   none 
-    
-   Interoperability considerations: 
-   None. 
-    
-   Applications that use this context class: 
-   VPIM  
-    
-   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 
-    
-   Intended usage: COMMON 
-    
-    
-9.2.3. fax-message 
-    
-   To: ietf-types@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. 
-  
-Burger et. al.             Expires 8/22/01                   [Page 11] 
-                  Message Context for Internet Mail      February 2001  
- 
-    
-   Security considerations: 
-   none 
-    
-   Interoperability considerations: 
-   none 
- 
-   Applications that use this context class: 
-   FPIM 
-    
-   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 
-    
-   Intended usage: COMMON 
-    
-9.2.4. short-message 
-    
-   To: ietf-types@iana.org 
-   Subject: Registration of New Message-Context class short-message 
-    
-   Message-Context class name: 
-   short-message 
-    
-   Summary of the message class: 
-   "short-message" indicates a message whose primary content is a short 
-   text message.  The primary content is text data.  The context is 
-   usually an urgent message of a limited length. 
-    
-   Security considerations: 
-   none 
-    
-   Interoperability considerations: 
-   none 
-    
-   Applications that use this context class: 
-   Mail 
-    
-   Additional information: 
-   none 
-    
-   Person & email address to contact for further information: 
-   Eric Burger 
-   e.burger@ieee.org 
-    
-   Intended usage: COMMON 
-    
-  
-Burger et. al.             Expires 8/22/01                   [Page 12] 
-                  Message Context for Internet Mail      February 2001  
- 
- 
-9.2.5. multimedia-message 
-    
-   To: ietf-types@iana.org 
-   Subject: Registration of New Message-Context class short-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 
-    
-   Applications that use this context class: 
-   Mail 
-    
-   Additional information: 
-   none 
-    
-   Person & email address to contact for further information: 
-   Eric Burger 
-   e.burger@ieee.org 
-    
-   Intended usage: COMMON 
-    
- 
-9.2.6. text-message 
-    
-   To: ietf-types@iana.org 
-   Subject: Registration of New Message-Context class text-message 
-    
-   Message-Context class name: 
-   text-message 
-    
-   Security considerations: 
-   none 
-    
-   Interoperability considerations: 
-   none 
-    
-   Published specification: 
-   draft-ietf-vpim-hint-04.txt 
-    
-   Applications that use this context class: 
-   Mail 
-  
-Burger et. al.             Expires 8/22/01                   [Page 13] 
-                  Message Context for Internet Mail      February 2001  
- 
-    
-   Additional information: 
-   none 
-    
-   Person & email address to contact for further information: 
-   Eric Burger 
-   e.burger@ieee.org 
-    
-   Intended usage: COMMON 
-    
-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-04.txt 
-    
-   Applications that use this context class: 
-   Mail 
-    
-   Additional information: 
-   none 
-    
-   Person & email address to contact for further information: 
-   Eric Burger 
-   e.burger@ieee.org 
-    
-   Intended usage: COMMON 
-    
- 
-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. 
-    
-
-  
-Burger et. al.             Expires 8/22/01                   [Page 14] 
-                  Message Context for Internet Mail      February 2001  
- 
-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. Short text messaging service 
-    
-   One can use a short text message to convey textual information of 
-   limited size.  The typical limit is 160 characters. 
-    
-   The short text messaging service (SMS) is a facility that has 
-   evolved for use with mobile telephones, and has an associated per-
-   message transmission charge.  People use SMS for relatively urgent 
-   messages, which the sender wishes the receiver to see and possibly 
-   respond to within a short time period. 
-    
-   The normal device for sending and receiving a short text message is 
-   a mobile telephone with a small character display and a numeric-only 
-   keyboard.  Personal computers and personal digital assistants (PDAs) 
-   can also participate in short text messaging. 
-    
-   Currently, the most common use of short text messages are between 
-   just two parties (one-to-one). 
-    
-   Users often send short text 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 8/22/01                   [Page 15] 
-                  Message Context for Internet Mail      February 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 8/22/01                   [Page 16] 
-                  Message Context for Internet Mail      February 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  Crocker, D., "Standard for the Format of ARPA Internet Text 
-      Messages", STD 11, RFC 822, August 1982. 
-    
-   6  Burger, E. and Candell, E., "Critical Content of Internet Mail", 
-      draft-ietf-vpim-cc-01.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 8/22/01                   [Page 17] 
-                  Message Context for Internet Mail      February 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.  
-    
-   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 703 304 3883 
-   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 
-    
-    
-
-
-
-  
-Burger et. al.             Expires 8/22/01                   [Page 18] 
-                  Message Context for Internet Mail      February 2001  
- 
-   Graham Klyne 
-   Content Technologies Ltd. 
-   1220 Parkview, 
-   Arlington Business Park 
-   Theale 
-   Reading, RG7 4SA 
-   United Kingdom. 
-    
-   Telephone: +44 118 930 1300 
-   Facsimile: +44 118 930 1301 
-   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 8/22/01                   [Page 19] 
-                  Message Context for Internet Mail      February 2001  
- 
-Full Copyright Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   intellectual property or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; neither does it represent that it 
-   has made any effort to identify any such rights.  Information on the 
-   IETF's procedures with respect to rights in standards-track and 
-   standards-related documentation can be found in BCP-11.  Copies of 
-   claims of rights made available for publication and any assurances 
-   of licenses to be made available, or the result of an attempt made 
-   to obtain a general license or permission for the use of such 
-   proprietary rights by implementers or users of this specification 
-   can be obtained from the IETF Secretariat. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to practice 
-   this standard.  Please address the information to the IETF Executive 
-   Director. 
-    
-   Copyright (C) 2000, 2001 The Internet Society.  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this 
-   document itself may not be modified in any way, such as by removing 
-   the copyright notice or references to the Internet Society or other 
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-
-
-
-
-  
-Burger et. al.             Expires 8/22/01                   [Page 20] 
-
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-05.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-05.txt
deleted file mode 100644
index 7ad94698..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-hint-05.txt
+++ /dev/null
@@ -1,1116 +0,0 @@
-
-
-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
deleted file mode 100644
index 9f3dfaeb..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-hint-06.txt
+++ /dev/null
@@ -1,999 +0,0 @@
-
-
-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-khanna-smtp-mail-transfer-reliability-00.txt b/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-00.txt
deleted file mode 100644
index a5e21f9e..00000000
--- a/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-00.txt
+++ /dev/null
@@ -1,291 +0,0 @@
-INTERNET-DRAFT									3rd October 2000    
-      									   Expires: 3rd April 2001
-
-   Mail transfer reliability in Simple Mail Tranfer Protocol(SMTP)
-          draft-khanna-smtp-mail-transfer-reliability-00.txt
-                       Kumar Gaurav Khanna
-
-
-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 maybe updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-
-Abstract
-
-This draft discusses the issue which makes the data tranfer in SMTP 
-protocol highly vulnerable to a "resend" in case of a network 
-disruption. We then discuss a means by which such a "resend" can be 
-avoided, by tranferring mail data only from the point of disruption.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires: 3rd April, 2001									[Page 1]
-
-
-INTERNET-DRAFT draft-khanna-smtp-mail-transfer-reliability-00.txt 3rd Oct,2K
-
-1. Introduction
-
-So tell me, how many times has it happened that when you were sending a 
-lengthy mail, then due to network disruption (either due to the dialup 
-connection breaking up, or the network timing out, or for some reason 
-which I forgot to mention here!), your mail transfer was forced to come 
-to an abrupt halt ??? You, then, had to send it all over again, and 
-transfer would be successful only if the lady luck be with you. Else, 
-the irony repeats itself.
-
-The problem, that incase of a failed mail tranfer you have to send the 
-mail all over again, resending what you had sent earlier, is due to the 
-nature of the SMTP protocol. This draft is aimed at discussing why and 
-how this problem occurs, and also suggests a solution which can help 
-solve it effectively.
-
-2. The Problem
-
-To understand why we have to resend a mail entirely incase of 
-disruption while sending it previously, lets look at a simple SMTP
-conversation between a SMTP client (C) and a SMTP server (S):
-
-<Server waits for an incoming connection...>
-<Client connects to the SMTP server...>
-
-S: 220 SMTP service ready
-C: Helo mydomain.com
-S: 250 Pleased to meet you
-C: MAIL FROM: <gauravkhanna@mailandnews.com>
-S: 250 sender okay
-C: RCPT TO: <prabhakhanna@yahoo.com>
-S: 250 Recipient okay
-C: Data
-S: 354 send data with <CRLF>.<CRLF> to end
-
-<Client sends the mail here. The mail is comprised of all the standard 
-SMTP headers, including the X- headers, and any attachments. Finally, 
-the termination period is sent.>
-
-S: 250 message accepted for delivery
-C: QUIT
-S: 221 Transmission channel closed
-
-That's how the most basic of SMTP conversations are held. Note that 
-after the DATA command, when the client is sending the mail, the entire 
-mail is sent as one big chunk!! Now suppose, that while sending that  
-chunk, the connection breaks up for some reason. Bingo! The SMTP 
-server closes the transmission channel (it gets to know that connection 
-has broken up, so it cleans up its resource usage), and the SMTP client 
-is left with no option but to resend the entire mail. Infact, this 
-entire conversation has to occur again!! Consider the amount of 
-bandwidth going waste, let alone time.
-
-Expires: 3rd April, 2001									[Page 2]
-
-INTERNET-DRAFT draft-khanna-smtp-mail-transfer-reliability-00.txt 3rd Oct,2K
-
-3. The Solution
-
-This draft suggests a mechanism by introducing few additional commands
-in the SMTP protocol, which can help overcome this problem. So, lets
-look at it...
-
-The philosophy behind the solution to the above problem is to divide
-the chunk to be sent by the SMTP client, after the DATA command, be
-divided in blocks of size, say N. 
-
-Next, during the course of a SMTP conversation, instead of sending a
-DATA command, the SMTP client sends the (new) DB command. The syntax
-of the command is:
-
-DB <N>
-
-Its purpose is to tell the SMTP server that the mail shall now be
-delivered in small(er) blocks of size N. This block size is decided
-by the client. If the server doesn't accept the command, it returns
-421 error code. However, if the server accepts this command, it saves
-the block size and returns...
-
-250 <mesg ID>
-
-where <mesg ID> is a unique number produced by the SMTP server to 
-uniquely identify this mail transaction. This ID is saved both by the
-SMTP server and the SMTP client.
-
-After the acceptence of the DB command by the SMTP server, the SMTP
-client sends the first block of the mail to the server, which 
-maintains an internal count (CNT) of the number of mail blocks 
-successfully transferred from the client to the server. After 
-receiving each block successfully, the server increments CNT and 
-sends a 250 success code. The client continues to send the blocks
-of mail in this manner to server. The server should make sure that the 
-block sent by the client is not more than N bytes, as decided. It can, 
-however, be less than N. 
-
-The termination of the blocks is indicated by the SMTP client by sending 
-the <CRLF>.<CRLF>, as done conventionally. The server responds with a 
-successful 250 code, after which the client can issue the QUIT command 
-and proceed normally. After a successful QUIT, both the server and
-client discard the block size N and the <mesg ID>. The server, in
-addition, discards the CNT. Here's a sample conversation illustrating 
-this concept between the SMTP client (C) and the SMTP Server (S)...
-
-<Server waits for an incoming connection>
-<Client connects to the SMTP server>
-
-S: 220 SMTP Server Ready
-C: Helo mydomain.com
-S: 250 Pleased to meet you
-C: MAIL FROM: <gauravkhanna@mailandnews.com>
-
-Expires: 3rd April, 2001									[Page 3]
-
-INTERNET-DRAFT draft-khanna-smtp-mail-transfer-reliability-00.txt Oct,2K
-
-S: 250 Sender okay
-C: RCPT TO: <prabhakhanna@yahoo.com>
-S: 250 Recipient okay
-C: DB 100
-S: 250 20001003152543
-
-<Assume that the mail is 450 bytes in length>
-
-C: <send the 1st block of 100 bytes>
-S: 250 block 1 accepted
-C: <send the 2nd block of 100 bytes>
-S: 250 block 2 accepted
-C: <send the 3rd block of 100 bytes>
-S: 250 block 3 accepted
-C: <send the 4th block of 100 bytes>
-S: 250 block 4 accepted
-C: <send the 5th block of 50 bytes>
-S: 250 block 5 accepted
-C: <CRLF>.<CRLF>
-S: 250 message accepted for delivery
-C: QUIT
-S: 221 Transmission channel closed
-
-As evident from above, the server maintains an internal count of the 
-number of blocks transmitted. after a successful QUIT, the server
-can work upon the mail as it does normally, either by queueing it, or
-asking a Message Transfer Agent (MTA) to work on it.
-
-Now, for example, while the 4th block was being transmitted, the network 
-got disrupted and the connection broke up. In such a case, the server 
-shall save the partial mail sent to it by the client, for some defined 
-period of time (after which it may discard it), indentifying it with its 
-<mesg ID>. The client shall re-establish a connection with the SMTP 
-server and, instead of HELO, shall give the RESEND command whose syntax 
-is:
-
-RESEND <mesg ID>
-
-where <mesg ID> is the unique identifier which the server returned to
-the client, in reply to the DB command. If there is partial mail saved 
-by the server, whose <mesg ID> matches the one sent by the SMTP client
-in the RESEND command, then the server shall read the partial mail in
-the memory and proceed ahead to complete the interrupted transmission
-by sending the block size (N) and the number of blocks already sent by
-the SMTP client as part of 250 response code. Else, it shall send a 421
-error code.
-
-In the conversation above, if the connection broke up during the sending 
-of the 4th block, the SMTP server saves the <mesg ID>, the block size N 
-and the number of blocks which have already been sent by the SMTP 
-client. The SMTP client also, upon connection breakup, saves the 
-<mesg ID>. It then proceeds to resend the mail as follows (C=> SMTP
-Client, S=> SMTP Server) :
-
-Expires: 3rd April, 2001									[Page 4]
-
-INTERNET-DRAFT draft-khanna-smtp-mail-transfer-reliability-00.txt 3rd Oct,2K
-
-<Server waits for an incoming connection>
-<Client connects to the server>
-S: 220 SMTP service ready
-C: RESEND 20001003152543
-S: 250 100 3
-
-<This reply tells the SMTP client that block size is 100 bytes, and
-3 blocks have already been sent.>
-
-C: <sends the 4th block of 100 bytes again>
-S: 250 block 4 accepted
-C: <sends the 5th block of 50 bytes>
-S: 250 block 5 accepted
-C: <CRLF>.<CRLF>
-S: 250 message accepted for delivery
-C: QUIT
-S: 221 Transmission channel closed
-
-As can be seen above, during the "recovery" by the RESEND command, the
-SMTP client doesn't sends the MAIL FROM and RCPT TO commands again as
-they have already been stored by the SMTP server in the partial mail
-that it saves. Also, the SMTP server tells the client the block size
-that was decided, and how many blocks have been sent. This helps the
-SMTP client to send blocks of mail of size N and resume the broken
-transmission from the block where it had got disrupted, thereby saving
-the time and bandwidth involved in resending what had already been sent
-to the SMTP server.
-
-Thus, as we can see, if modified in the manner suggested by this draft,
-the SMTP protocol can inherit good amount of reliability in the 
-transfer of mails, which can help save time and network bandwidth.
-
-5. Author's Address
-
-Kumar Gaurav Khanna,
-#23, TTTI Campus,
-Sector 26,
-Chandigarh - 160 019
-India
-Phone: 91-172-773454
-WWW: http://www.wintools.f2s.com/
-Email: gauravkhanna@mailandnews.com
-       gaurav@wintools.f2s.com
-
-
-
-
-
-
-
-
-
-
-
-Expires: 3rd April, 2001									[Page 5]
diff --git a/Documentation/en/I-D/draft-melnikov-smtp-lang-03.txt b/Documentation/en/I-D/draft-melnikov-smtp-lang-03.txt
deleted file mode 100644
index 50b46f0c..00000000
--- a/Documentation/en/I-D/draft-melnikov-smtp-lang-03.txt
+++ /dev/null
@@ -1,498 +0,0 @@
-Network Working Group                            Mike Gahrns, Microsoft 
-Internet Draft           Alexey Melnikov, ACI WorldWide/MessagingDirect
-Document: draft-melnikov-smtp-lang-03.txt                    March 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
-
-2). Other minor bugfixes
-
-
-   Changes since -02 
-    
-1). Extended DSN format to include language tag
-
-2). Fixed few typos.
-
-
-   Open issues
-
-1) Should language information be added to MAIL FROM so that it could be used
-   in DSN/MDN notification messages?
-
-2). 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) No additional SMTP parameters to either MAIL FROM or RCPT TO commands 
-      are defined by this extension.
-
-  An additional document may define an extension to LANGUAGE ESMTP extension.
-  Any such extension MUST use ESMTP extension name that starts with LANGUAGE
-  prefix. This document doesn't specify any LANG command extension.
-
-
-4. Requirements
-
-   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 LANG extension.
-
-         LANG extension document may define additional parameters to LANG command.  Client
-         MUST NOT issue the optional extension parameters unless a server has indicated
-         in its EHLO response that it supports that extension. In case when server
-         doesn't support requested parameter(s) or any parameters, it MUST respond with
-         504 code.
-
-     Example 1:
-
-        < The server defaults to using responses in "i-default" language
-          until the user explicitly changes the language. >
-
-         S: 220 smtp.example.com ESMTP server ready
-         C: EHLO main.example.com
-         S: 250-smtp.example.com
-         S: 250-AUTH CRAM-MD5 DIGEST-MD5
-         S: 250 LANGUAGE EN FR RU i-default
-         C: HELP
-         S: 214-This is Sendmail version X.X.X
-         S: 214-Topics:
-         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
-         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
-         S: 214-    EXPN    VERB    ETRN    DSN
-         S: 214-For more info use "HELP <topic>".
-         S: 214 End of HELP info
-
-        < Once the client changes the language, all responses will be in
-          that language starting with 250 response to the LANG command. >
-
-         C: LANG FR
-         S: 250 La Language commande a ete execute avec success
-
-         C: HELP
-         S: 214-C'est le programme Sendmail version X.X.X
-         S: 214-Topics:
-         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
-         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
-         S: 214-    EXPN    VERB    ETRN    DSN
-         S: 214-Pour obtenir l'information supplementaire utilisez "HELP <topic>".
-         S: 214 La fin de l'information 
-
-        < If a server does not support the requested language, responses
-          will continue to be returned in the current language the server is
-          using. >
-
-         C: LANG DE
-         S: 504 Ce Language n'est pas supporte
-
-     Example 2:
-
-        < The client tries to select MUL language that couldn't be used with described
-          extension>
-
-         C: LANG MUL
-         S: 504 It is not allowed to use MUL language.
-
-     Example 3:
-
-        < The client tries to use LANG extension not supported by server>
-
-         C: LANG i-default (blah blah)
-         S: 504 LANG extension blah is not recognized.
-
-
-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 Enchanced Error Code in reply.
-
-     Example 5:
-
-        < The server supports both LANGUAGE and ENHANCEDSTATUSCODES>
-
-         S: 220 smtp.example.com ESMTP server ready
-         C: EHLO main.example.com
-         S: 250-smtp.example.com
-         S: 250 LANGUAGE EN FR RU i-default
-         S: 250 ENHANCEDSTATUSCODES
-         C: LANG FR-ca
-         S: 250 2.0.0 [LANG FR]La Language commande a ete execute avec success
-
-
-7. 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 a new DSN field, 
-   Language, indicating the language tag for diagnostic-code-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]
-            diagnostic-code-field CRLF ]
-          [ last-attempt-date-field CRLF ]
-          [ will-retry-until-field CRLF ]
-          *( extension-field CRLF )
-
-    language-field = "Language" ":" language
-
-   where language is a language tag as described in [RFC-1766].
-
-   An SMTP server that supports both DSN and LANG extensions SHOULD include language-field
-   if it knows that diagnostic-code-field contains 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., "IMAP4 Language Extension", 
-   draft-gahrns-imap-language-01.txt (work in progress), Microsoft, 
-   October 1999
-
-   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
-   ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd.,
-   November 1997, <ftp://ftp.isi.edu/in-notes/rfc2234.txt>
-
-   [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced
-   Error Codes", RFC 2034, Innosoft, October 1996
-
-   [DSN]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
-   Delivery Status Notifications", RFC 1894, January 1996.
-
-11.  Acknowledgments
-
-   This document is derived from [IMAP-LANGUAGE]. Thus the work of
-   Mike Gahrns and Andrew McCown is appreciated.
-
-
-12.  Copyright
-
-   Copyright (C) The Internet Society 2000-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-00.txt b/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-00.txt
deleted file mode 100644
index c59552b4..00000000
--- a/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-00.txt
+++ /dev/null
@@ -1,351 +0,0 @@
-Internet Engineering Task Force                        Motonori Nakamura
-INTERNET-DRAFT                                          Kyoto University
-Expires: March 4, 2001                          Jun-ichiro itojun Hagino
-                                                 IIJ Research Laboratory
-                                                       Septebmer 4, 2000
-
-
-                   IPv6 SMTP operational requirements
-              draft-motonori-ipv6-smtp-requirement-00.txt
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as ``work in progress.''
-
-      Distribution of this memo is unlimited.
-
-     The list of current Internet-Drafts can be accessed at
-     http://www.ietf.org/ietf/1id-abstracts.txt
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-     http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-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: March 4, 2001                 [Page 1]
-
-
-DRAFT              IPv6 SMTP operational requirements     Septebmer 2000
-
-In IPv4 SMTP operation, we register MX records like below, for
-"sample.org."  domain:
-
-     sample.org.             IN MX   1  mx1.sample.org.
-                             IN MX   10 mx10.sample.org.
-     mx1.sample.org.         IN A    1.0.0.1
-     mx10.sample.org.        IN A    1.0.0.2
-
-When an MTA delivers a message to a particular destination (say it is to
-foo@sample.org), the MTA would send DNS queries to lookup DNS database
-in the following order:
-
-o Lookup MX record for "sample.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.
-
-  o If MX lookup failed with NO_DATA, it means that there is no MX
-    record but there can be other record for "sample.org.".  Lookup A
-    record for "sample.org.".
-
-  o If MX lookup failed with HOST_NOT_FOUND, it means that there is no
-    record at all for "sample.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
-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] .
-
-
-
-
-
-NAKAMURA, HAGINO         Expires: March 4, 2001                 [Page 2]
-
-
-DRAFT              IPv6 SMTP operational requirements     Septebmer 2000
-
-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:
-
-     sample.org.             IN MX   1  mx1.sample.org.
-                             IN MX   10 mx10.sample.org.
-     mx1.sample.org.         IN A    1.0.0.1          ; IPv4/v6 dual stack
-                             IN AAAA 3ffe:501:ffff::1
-     mx10.sample.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).
-
-(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.
-
-(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)
-     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).
-
-
-NAKAMURA, HAGINO         Expires: March 4, 2001                 [Page 3]
-
-
-DRAFT              IPv6 SMTP operational requirements     Septebmer 2000
-
-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.sample.org.
-
-     sample.org.     IN MX   1   mx1.sample.org.
-                     IN MX   10  mx10.sample.org.
-                     IN MX   100 mx100.sample.org.
-
-If mx1.sample.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.sample.org.
-     sample.org.     IN MX   1   mx1.sample.org.     ; IPv6 only
-                     IN MX   10  mx10.sample.org.    ; IPv4 only
-                     IN MX   100 mx100.sample.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.
-     sample.org.     IN MX   1   mx1.sample.org.     ; IPv4/v6 dual stack
-                     IN MX   10  mx10.sample.org.    ; IPv4 only
-                     IN MX   100 mx100.sample.org.   ; IPv6 only
-
-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.  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.
-
-
-NAKAMURA, HAGINO         Expires: March 4, 2001                 [Page 4]
-
-
-DRAFT              IPv6 SMTP operational requirements     Septebmer 2000
-
-  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
-
-                <itojun@kame.net@oshokuji.org@itojun.org>
-
-  it gets more trickier.
-
-
-6.  Security consideration
-
-The document should have no new security problem.
-
-
-References
-
-Partridge, 1986.
-C. Partridge, "Mail routing and the domain system" in RFC974 (January
-1986). ftp://ftp.isi.edu/in-notes/rfc974.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.
-
-
-Change history
-
-None.
-
-
-Acknowledgements
-
-The draft was written based on discussions with Japanese IPv6 users, and
-help from WIDE research group.
-
-
-
-
-
-
-
-NAKAMURA, HAGINO         Expires: March 4, 2001                 [Page 5]
-
-
-DRAFT              IPv6 SMTP operational requirements     Septebmer 2000
-
-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: March 4, 2001                 [Page 6]
-
diff --git a/Documentation/en/I-D/draft-newman-datetime-01.txt b/Documentation/en/I-D/draft-newman-datetime-01.txt
deleted file mode 100644
index 48ffe3cb..00000000
--- a/Documentation/en/I-D/draft-newman-datetime-01.txt
+++ /dev/null
@@ -1,1288 +0,0 @@
-
-
-
-Network Working Group                                          C. Newman
-Internet Draft: Date and Time on the Internet                   Innosoft
-Document: draft-newman-datetime-01.txt                      January 1997
-
-
-                     Date and Time on the Internet
-
-
-Status of this memo
-
-     This document is an Internet Draft.  Internet Drafts are working
-     documents of the Internet Engineering Task Force (IETF), its Areas,
-     and its Working Groups.  Note that other groups may also distribute
-     working documents as Internet Drafts.
-
-     Internet Drafts are draft documents valid for a maximum of six
-     months.  Internet Drafts may be updated, replaced, or obsoleted by
-     other documents at any time.  It is not appropriate to use Internet
-     Drafts as reference material or to cite them other than as a
-     ``working draft'' or ``work in progress``.
-
-     To learn the current status of any Internet-Draft, please check the
-     1id-abstracts.txt listing contained in the Internet-Drafts Shadow
-     Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
-     munnari.oz.au.
-
-     A revised version of this draft document will be submitted to the
-     IESG as a Proposed Standard for the Internet Community.  Discussion
-     and suggestions for improvement are requested.  This document will
-     expire six months after publication.  Distribution of this draft is
-     unlimited.
-
-
-
-1. Introduction
-
-     Date and time formats cause a lot of confusion and interoperability
-     problems on the Internet.  This document will address many of the
-     problems encountered and make recommendations to improve
-     consistancy 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.
-
-     Changes from draft -00:
-      * added some more definitions and references (fixed NTP reference)
-
-
-
-Newman                                                          [Page 1]
-
-Internet Draft               Date and Time                  January 1997
-
-
-      * language clarifications
-      * include rules for day of month and leap seconds
-      * disallow hour of 24
-      * add registry of named timezones and local time format
-      * use . instead of , for fractions of second
-      * removed references to AM/PM
-      * simplified appendix B program
-      * added appendix C program to calculate leap year
-
-     Controversial in last draft, but unchanged:
-      * use of "T" as date/time separator.  Proposal is to use " " instead,
-        but my reading of ISO 8601 does not permit that.
-      * suggestion to make minutes offset from UTC optional.
-      * interpretation of 2 digit years
-
-     Open issues:
-      * See controversial issues above.  More comment is welcome.
-      * Are more definitions needed?
-      * A number of the timezones in the initial registry list are
-        duplicates for future times.  I already removed the Indiana county
-        ones since they all duplicate Indianapolis for future times.
-      * Need reference to good article demonstrating year 2000 problems.
-      * Need commentary on registry and to set up address for registry.
-      * Will add appendix D, E with sample POSIX generation/parsing code
-        for section 5.6.  Markus Kuhn is working on code.
-
-
-2. Definitions
-
-     UTC         Coordinated Universal Time as maintained by the Bureau
-                 Internaational de l'Heure (International Time Bureau).
-
-     second      A basic unit of measurement of time in the
-                 International System of Units.
-
-     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.
-
-     ABNF        Augmented Backus-Naur Form, a format used to represent
-
-
-
-Newman                                                          [Page 2]
-
-Internet Draft               Date and Time                  January 1997
-
-
-                 permissible strings in a protocol or language, as
-                 defined in [IMAIL].
-
-     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
-
-     Two digit years are expected to cause great expense to many as the
-     year 2000 approaches.  Many existing computer programs simply add
-     or subtract 1900 from a two digit year.  Such programs will clearly
-     stop functioning on the year 2000 and will have to be upgraded,
-     possibly at great expense [XXX - ref to article on IRS year 2000
-     problems would be cool].  The following requirements are made of
-     Internet protocols to address this problem:
-
-     o  Internet Protocols MUST generate four digit years in dates.
-
-     o  If a two digit year is received, the values 00-49 MUST be
-        interpreted as referring to the 21st century (add 2000) and the
-        values 50-99 MUST be interpreted as referring to the 20th
-        century (add 1900).  While different interpretations may result
-        in a few more years of 2-digit usability for some applications,
-        it is believed that a single interpretation for two digit years
-        in all Internet protocols will result in better
-        interoperability.  In addition, it is reasonable to expect all
-        Internet Protocols using 2 digit dates to be upgraded by the
-        year 2050.
-
-     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
-
-
-
-Newman                                                          [Page 3]
-
-Internet Draft               Date and Time                  January 1997
-
-
-        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 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).
-
-
-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:58: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 semanticly 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
-
-
-
-Newman                                                          [Page 4]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     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.  Devices which are unaware of the
-     time in UTC MUST use one of the following techniques when
-     communicating on the Internet:
-
-     o  Use Network Time Protocol [NTP] to obtain the time in UTC.
-
-     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 formats
-
-     This section discusses desirable qualities of date and time formats
-     and defines a profile of ISO 8601 for use in new Internet
-     protocols.  Email Date/Time Format lacks many of these
-     characteristics and its use in new protocols is discouraged.
-
-
-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
-
-
-
-Newman                                                          [Page 5]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     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 redunant 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
-     as defined in [IMAIL].  Internet protocols have somewhat different
-     requirements and simplicity has proved to be an important
-     characteristic.  In addition, Internet protocols usually need
-
-
-
-Newman                                                          [Page 6]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     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 ABNF as
-     defined in [IMAIL].
-
-     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
-
-
-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:
-
-
-
-
-
-
-
-
-
-
-
-
-Newman                                                          [Page 7]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     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:60) or December (XXXX-12-31T23:59:60).
-     At all other times the maximum value of time-second is "59".
-
-     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.
-
-     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 insertted at the end of 1990.
-
-
-
-
-Newman                                                          [Page 8]
-
-Internet Draft               Date and Time                  January 1997
-
-
-6. Future Events in Local Time
-
-     Some applications (e.g. calendaring) require the representation of
-     repeating or future dates in local time.  Because the conversion
-     rules between UTC and local time may change by season and political
-     whim, it is necessary to label the local time zone with a standard
-     label so that if new conversion rules are issued the interpretation
-     of the time relative to UTC can be corrected.  For this reason, an
-     IANA registry of timezone names which may be used to represent
-     future dates is necessary.
-
-
-6.1. Problems Too Hard to Solve
-
-     Since local timezone rules are set by local governments, the only
-     authoratative reference for such rules is those governments, most
-     of which do not currently provide their rules on line in a computer
-     parsible format.  In addition, local timezones were historically
-     set by cities and towns, so attempting to exhaustively enumerate
-     all historical timezones for use in representing past dates is not
-     practical.  Attempting to predict where new timezones will be
-     created as a subset of the area covered by an old timezone is also
-     a hopeless prospect.
-
-     Therefore the only formal part of the registry will be names for a
-     minimal set of modern timezones.  As a convenience, the registry
-     will also include the base UTC offset and daylight savings rules
-     (if determinable) at the time of registration.  Because the UTC
-     offset and rules may changed by other bodies, they will not be
-     considered an authoratative part of the registry.
-
-
-6.2. Prior Art
-
-     An informal collection of timezone information is currently being
-     maintained by volunteer Internet participants.  The current
-     location of this information is:
-
-          <ftp://elsie.nci.nih.gov/pub/>
-
-     This is valuable work, and is used in some operating systems.  The
-     initial set of timezone names for the IANA registry is a subset of
-     the names collected by this effort.
-
-
-6.3. Legal Characters in Timezone Names
-
-     Only the US-ASCII characters A-Z, a-z, 0-9, "-", "_" and "/" are
-
-
-
-Newman                                                          [Page 9]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     legal in timezone names.  The basic format is the name of a
-     continent or ocean followed by a "/" followed by the name of a city
-     or political entity.  A political entity may be followed by a "/"
-     and a subentity if necessary.  Timezone names SHOULD use the
-     standard case in the registry, but MUST be interpreted in a case
-     insensitive manner.   New timezone names SHOULD use "-" rather than
-     "_", as the latter is difficult to see in some output contexts.
-
-
-6.4. Template for IANA Registration of Timezone Names
-
-     To: timezone@XXX
-     Subject: Timezone Name Registration
-
-     Timezone Name:
-
-     ISO 3166 2-character country code:
-
-     Description:
-
-
-6.5. Proceedure for IANA Registration of Timezone Names
-
-     The IESG is responsible for appointing a reviewer of Timezone
-     Names.  The job of this reviewer is to verify that the new timezone
-     name has unique UTC rules, is likely to be used, fits the rules in
-     section 6.3 and does not conflict unnecessarily with prior art
-     (especially that mentioned in section 6.2).  Within two weeks of
-     posting, the reviewer must take one of the following actions:
-
-     (1) Pass the registration proposal to IANA.
-
-     (2) Reject the registration proposal.
-
-     (3) Recommend alterations to the registration proposal likely to make
-         it acceptable.
-
-     In order to assist the reviewer, the address timezone@XXX will be a
-     public mailing list where registration proposals may be discussed.
-     Subscription and unsubscription requests may be sent to timezone-
-     request@XXX.
-
-
-6.6. Initial List of IANA Timezone Names
-
-     The following list will serve as the initial list of IANA Timezone
-     Names.  This list was generated from the archive mentioned in
-     section 6.2.  Some of these timezone names (especially within the
-
-
-
-Newman                                                         [Page 10]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     same country) are redundant for future dates, but compatibility
-     with the timezone names in the databases discussed section 6.2. is
-     useful.
-
-     Timezone Name                    Country
-     -------------                    -------
-     Europe/Andorra                     AD
-     Asia/Dubai                         AE
-     Asia/Kabul                         AF
-     America/Antigua                    AG
-     America/Anguilla                   AI
-     Europe/Tirane                      AL
-     Asia/Yerevan                       AM
-     America/Curacao                    AN
-     Africa/Luanda                      AO
-     Antarctica/Casey                   AQ
-     Antarctica/DumontDUrville          AQ
-     Antarctica/Mawson                  AQ
-     Antarctica/McMurdo                 AQ
-     Antarctica/Palmer                  AQ
-     Antarctica/South_Pole              AQ
-     America/Buenos_Aires               AR
-     America/Catamarca                  AR
-     America/Cordoba                    AR
-     America/Jujuy                      AR
-     America/Mendoza                    AR
-     America/Rosario                    AR
-     Pacific/Pago_Pago                  AS
-     Europe/Vienna                      AT
-     Australia/Adelaide                 AU
-     Australia/Brisbane                 AU
-     Australia/Broken_Hill              AU
-     Australia/Darwin                   AU
-     Australia/Hobart                   AU
-     Australia/Lindeman                 AU
-     Australia/Lord_Howe                AU
-     Australia/Melbourne                AU
-     Australia/Perth                    AU
-     Australia/Sydney                   AU
-     America/Aruba                      AW
-     Asia/Baku                          AZ
-     Europe/Sarajevo                    BA
-     America/Barbados                   BB
-     Asia/Dacca                         BD
-     Europe/Brussels                    BE
-     Africa/Ouagadougou                 BF
-     Europe/Sofia                       BG
-     Asia/Bahrain                       BH
-
-
-
-Newman                                                         [Page 11]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     Africa/Bujumbura                   BI
-     Africa/Porto-Novo                  BJ
-     Atlantic/Bermuda                   BM
-     Asia/Brunei                        BN
-     America/La_Paz                     BO
-     America/Cuiaba                     BR
-     America/Fortaleza                  BR
-     America/Maceio                     BR
-     America/Manaus                     BR
-     America/Noronha                    BR
-     America/Porto_Acre                 BR
-     America/Sao_Paulo                  BR
-     America/Nassau                     BS
-     Asia/Thimbu                        BT
-     Africa/Gaborone                    BW
-     Europe/Minsk                       BY
-     America/Belize                     BZ
-     America/Dawson                     CA
-     America/Dawson_Creek               CA
-     America/Edmonton                   CA
-     America/Glace_Bay                  CA
-     America/Goose_Bay                  CA
-     America/Halifax                    CA
-     America/Inuvik                     CA
-     America/Iqaluit                    CA
-     America/Montreal                   CA
-     America/Nipigon                    CA
-     America/Pangnirtung                CA
-     America/Rainy_River                CA
-     America/Rankin_Inlet               CA
-     America/Regina                     CA
-     America/St_Johns                   CA
-     America/Swift_Current              CA
-     America/Thunder_Bay                CA
-     America/Vancouver                  CA
-     America/Whitehorse                 CA
-     America/Winnipeg                   CA
-     America/Yellowknife                CA
-     Indian/Cocos                       CC
-     Africa/Bangui                      CF
-     Africa/Brazzaville                 CG
-     Europe/Zurich                      CH
-     Africa/Abidjan                     CI
-     Pacific/Rarotonga                  CK
-     America/Santiago                   CL
-     Pacific/Easter                     CL
-     Africa/Douala                      CM
-     Asia/Chungking                     CN
-
-
-
-Newman                                                         [Page 12]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     Asia/Harbin                        CN
-     Asia/Kashgar                       CN
-     Asia/Shanghai                      CN
-     Asia/Urumqi                        CN
-     America/Bogota                     CO
-     America/Costa_Rica                 CR
-     America/Havana                     CU
-     Atlantic/Cape_Verde                CV
-     Indian/Christmas                   CX
-     Asia/Nicosia                       CY
-     Europe/Prague                      CZ
-     Europe/Berlin                      DE
-     Africa/Djibouti                    DJ
-     Europe/Copenhagen                  DK
-     America/Dominica                   DM
-     America/Santo_Domingo              DO
-     Africa/Algiers                     DZ
-     America/Guayaquil                  EC
-     Pacific/Galapagos                  EC
-     Europe/Tallinn                     EE
-     Africa/Cairo                       EG
-     Africa/El_Aaiun                    EH
-     Africa/Asmera                      ER
-     Africa/Ceuta                       ES
-     Atlantic/Canary                    ES
-     Europe/Madrid                      ES
-     Africa/Addis_Ababa                 ET
-     Europe/Helsinki                    FI
-     Pacific/Fiji                       FJ
-     Atlantic/Stanley                   FK
-     Pacific/Kosrae                     FM
-     Pacific/Ponape                     FM
-     Pacific/Truk                       FM
-     Pacific/Yap                        FM
-     Atlantic/Faeroe                    FO
-     Europe/Paris                       FR
-     Africa/Libreville                  GA
-     Europe/Belfast                     GB
-     Europe/London                      GB
-     America/Grenada                    GD
-     Asia/Tbilisi                       GE
-     America/Cayenne                    GF
-     Africa/Accra                       GH
-     Europe/Gibraltar                   GI
-     America/Godthab                    GL
-     America/Scoresbysund               GL
-     America/Thule                      GL
-     Africa/Banjul                      GM
-
-
-
-Newman                                                         [Page 13]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     Africa/Conakry                     GN
-     America/Guadeloupe                 GP
-     Africa/Malabo                      GQ
-     Europe/Athens                      GR
-     Atlantic/South_Georgia             GS
-     America/Guatemala                  GT
-     Pacific/Guam                       GU
-     Africa/Bissau                      GW
-     America/Guyana                     GY
-     Asia/Hong_Kong                     HK
-     America/Tegucigalpa                HN
-     Europe/Zagreb                      HR
-     America/Port-au-Prince             HT
-     Europe/Budapest                    HU
-     Asia/Jakarta                       ID
-     Asia/Jayapura                      ID
-     Asia/Ujung_Pandang                 ID
-     Europe/Dublin                      IE
-     Asia/Gaza                          IL
-     Asia/Jerusalem                     IL
-     Asia/Calcutta                      IN
-     Indian/Chagos                      IO
-     Asia/Baghdad                       IQ
-     Asia/Tehran                        IR
-     Atlantic/Reykjavik                 IS
-     Europe/Rome                        IT
-     America/Jamaica                    JM
-     Asia/Amman                         JO
-     Asia/Ishigaki                      JP
-     Asia/Tokyo                         JP
-     Africa/Nairobi                     KE
-     Asia/Bishkek                       KG
-     Asia/Phnom_Penh                    KH
-     Pacific/Enderbury                  KI
-     Pacific/Kiritimati                 KI
-     Pacific/Tarawa                     KI
-     Indian/Comoro                      KM
-     America/St_Kitts                   KN
-     Asia/Pyongyang                     KP
-     Asia/Seoul                         KR
-     Asia/Kuwait                        KW
-     America/Cayman                     KY
-     Asia/Alma-Ata                      KZ
-     Asia/Aqtau                         KZ
-     Asia/Aqtobe                        KZ
-     Asia/Vientiane                     LA
-     Asia/Beirut                        LB
-     America/St_Lucia                   LC
-
-
-
-Newman                                                         [Page 14]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     Europe/Vaduz                       LI
-     Asia/Colombo                       LK
-     Africa/Monrovia                    LR
-     Africa/Maseru                      LS
-     Europe/Vilnius                     LT
-     Europe/Luxembourg                  LU
-     Europe/Riga                        LV
-     Africa/Tripoli                     LY
-     Africa/Casablanca                  MA
-     Europe/Monaco                      MC
-     Europe/Chisinau                    MD
-     Indian/Antananarivo                MG
-     Pacific/Kwajalein                  MH
-     Pacific/Majuro                     MH
-     Europe/Skopje                      MK
-     Africa/Bamako                      ML
-     Africa/Timbuktu                    ML
-     Asia/Rangoon                       MM
-     Asia/Ulan_Bator                    MN
-     Asia/Macao                         MO
-     Pacific/Saipan                     MP
-     America/Martinique                 MQ
-     Africa/Nouakchott                  MR
-     America/Montserrat                 MS
-     Europe/Malta                       MT
-     Indian/Mauritius                   MU
-     Indian/Maldives                    MV
-     Africa/Blantyre                    MW
-     America/Ensenada                   MX
-     America/Mazatlan                   MX
-     America/Mexico_City                MX
-     America/Tijuana                    MX
-     Asia/Kuala_Lumpur                  MY
-     Asia/Kuching                       MY
-     Africa/Maputo                      MZ
-     Africa/Windhoek                    NA
-     Pacific/Noumea                     NC
-     Africa/Niamey                      NE
-     Pacific/Norfolk                    NF
-     Africa/Lagos                       NG
-     America/Managua                    NI
-     Europe/Amsterdam                   NL
-     Europe/Oslo                        NO
-     Asia/Katmandu                      NP
-     Pacific/Nauru                      NR
-     Pacific/Niue                       NU
-     Pacific/Auckland                   NZ
-     Pacific/Chatham                    NZ
-
-
-
-Newman                                                         [Page 15]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     Asia/Muscat                        OM
-     America/Panama                     PA
-     America/Lima                       PE
-     Pacific/Gambier                    PF
-     Pacific/Marquesas                  PF
-     Pacific/Tahiti                     PF
-     Pacific/Port_Moresby               PG
-     Asia/Manila                        PH
-     Asia/Karachi                       PK
-     Europe/Warsaw                      PL
-     America/Miquelon                   PM
-     Pacific/Pitcairn                   PN
-     America/Puerto_Rico                PR
-     Atlantic/Azores                    PT
-     Atlantic/Madeira                   PT
-     Europe/Lisbon                      PT
-     Pacific/Palau                      PW
-     America/Asuncion                   PY
-     Asia/Qatar                         QA
-     Indian/Reunion                     RE
-     Europe/Bucharest                   RO
-     Asia/Anadyr                        RU
-     Asia/Irkutsk                       RU
-     Asia/Kamchatka                     RU
-     Asia/Krasnoyarsk                   RU
-     Asia/Magadan                       RU
-     Asia/Novosibirsk                   RU
-     Asia/Omsk                          RU
-     Asia/Vladivostok                   RU
-     Asia/Yakutsk                       RU
-     Asia/Yekaterinburg                 RU
-     Europe/Kaliningrad                 RU
-     Europe/Moscow                      RU
-     Europe/Samara                      RU
-     Africa/Kigali                      RW
-     Asia/Riyadh                        SA
-     Pacific/Guadalcanal                SB
-     Indian/Mahe                        SC
-     Africa/Khartoum                    SD
-     Europe/Stockholm                   SE
-     Asia/Singapore                     SG
-     Atlantic/St_Helena                 SH
-     Europe/Ljubljana                   SI
-     Arctic/Longyearbyen                SJ
-     Atlantic/Jan_Mayen                 SJ
-     Europe/Bratislava                  SK
-     Africa/Freetown                    SL
-     Europe/San_Marino                  SM
-
-
-
-Newman                                                         [Page 16]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     Africa/Dakar                       SN
-     Africa/Mogadishu                   SO
-     America/Paramaribo                 SR
-     Africa/Sao_Tome                    ST
-     America/El_Salvador                SV
-     Asia/Damascus                      SY
-     Africa/Mbabane                     SZ
-     America/Grand_Turk                 TC
-     Africa/Ndjamena                    TD
-     Indian/Kerguelen                   TF
-     Africa/Lome                        TG
-     Asia/Bangkok                       TH
-     Asia/Dushanbe                      TJ
-     Pacific/Fakaofo                    TK
-     Asia/Ashkhabad                     TM
-     Africa/Tunis                       TN
-     Pacific/Tongatapu                  TO
-     Europe/Istanbul                    TR
-     America/Port_of_Spain              TT
-     Pacific/Funafuti                   TV
-     Asia/Taipei                        TW
-     Africa/Dar_es_Salaam               TZ
-     Europe/Kiev                        UA
-     Europe/Simferopol                  UA
-     Africa/Kampala                     UG
-     Pacific/Johnston                   UM
-     Pacific/Midway                     UM
-     Pacific/Wake                       UM
-     America/Adak                       US
-     America/Anchorage                  US
-     America/Boise                      US
-     America/Chicago                    US
-     America/Denver                     US
-     America/Detroit                    US
-     America/Indianapolis               US
-     America/Juneau                     US
-     America/Los_Angeles                US
-     America/Louisville                 US
-     America/Menominee                  US
-     America/New_York                   US
-     America/Nome                       US
-     America/Phoenix                    US
-     America/Shiprock                   US
-     America/Yakutat                    US
-     Pacific/Honolulu                   US
-     America/Montevideo                 UY
-     Asia/Tashkent                      UZ
-     Europe/Vatican                     VA
-
-
-
-Newman                                                         [Page 17]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     America/St_Vincent                 VC
-     America/Caracas                    VE
-     America/Tortola                    VG
-     America/St_Thomas                  VI
-     Asia/Saigon                        VN
-     Pacific/Efate                      VU
-     Pacific/Wallis                     WF
-     Pacific/Apia                       WS
-     Asia/Aden                          YE
-     Indian/Mayotte                     YT
-     Europe/Belgrade                    YU
-     Africa/Johannesburg                ZA
-     Africa/Lusaka                      ZM
-     Africa/Kinshasa                    ZR
-     Africa/Lubumbashi                  ZR
-     Africa/Harare                      ZW
-
-
-6.7. Local Date/Time Format
-
-     The following format MAY be used to refer to future dates in a
-     local timezone.  This is defined based on the format in section
-     5.6.
-
-     zone-char = ALPHA / DIGIT / "-" / "_" / "/"
-     zone-name = 1*zone_char
-                    ; case insensitive interpretation
-     offset-hint = time-numoffset
-
-     local-datetime = full-date "T" partial-time " " zone-name
-                      [" " offset-hint]
-
-     A local-datetime represents an event relative to a specific local
-     timezone.  The offset-hint represents the generator's prediction of
-     what the UTC offset will be at that local time, and may become
-     incorrect if the rules for the specified zone are changed.  The
-     offset-hint MAY be omitted if the generating program only knows
-     local time, but the zone-name is REQUIRED.  This format SHOULD NOT
-     be used for timestamps or past events.
-
-
-6.8. Examples
-
-     Here are some examples of Local Date/Time Format:
-
-     1999-12-31T23:59:59 America/New_York -05:00
-
-     This represents a time one (or two if there's a leap second) second
-
-
-
-Newman                                                         [Page 18]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     before the year 2000 in the timezone used in New York City in North
-     America (currently U.S. Eastern Time).  The offset-hint is the
-     number to add to the local time to get an estimate UTC for that
-     date, so this will probably be equivalent to 2000-01-01T04:59:59Z.
-
-     2000-12-31T23:59:59 Australia/Adelaide +09:30
-
-     This represents a time one (or two if there's a leap second) second
-     before the 21st century in Adelaide, Australia.  The hint suggests
-     that this will be equivalent to 2000-12-31T14:29:59Z.
-
-     2000-03-31T02:00:00 America/Los_Angeles -08:00
-
-     The represents a time of the 2nd hour on the 31st of March in Los
-     Angeles, USA.  The hint suggests that would be equivalent to 2000-
-     03-31T10:00:00Z.  However, if the U.S. government were to adopt the
-     daylight savings rules currently used by the European Union, which
-     change daylight savings on the last Sunday of March, then the time
-     would be equivalent to 2000-03-31T09:00:00Z.
-
-
-7. Acknowledgements
-
-     May thanks to the following people who have provided helpful advice
-     for 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.
-
-
-8. 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, University of Delaware, August 1982.
-
-    <ftp://ds.internic.net/rfc/rfc822.txt>
-
-[ISO8601] "Data elements and interchange formats -- Information
- interchange -- Representation of dates and times", ISO 8601:1988(E),
- International Organization for Standardization, June, 1988.
-
-[HOST-REQ] Braden, R., "Requirements for Internet Hosts -- Application
- and Support", RFC 1123, Internet Engineering Task Force, October 1989.
-
-    <ftp://ds.internic.net/rfc/rfc1123.txt>
-
-
-
-Newman                                                         [Page 19]
-
-Internet Draft               Date and Time                  January 1997
-
-
-[NTP] Mills, D., "Network Time Protocol (Version 3) Specification,
- Implementation and Analysis", RFC 1305, University of Delaware, March
- 1992.
-
-    <ftp://ds.internic.net/rfc/rfc1305.tar.Z>
-    <ftp://ds.internic.net/rfc/rfc1305.txt>
-
-[ITU-R-TF] International Telecommunication Union Recommendations for
- Time Signals and Frequency Standards Emissions.
-
-    <http://www.itu.ch/publications/itu-r/iturtf.htm>
-
-
-9. 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.
-
-
-10. Author's Address
-
-Chris Newman
-Innosoft International, Inc.
-1050 East Garvey Ave. South
-West Covina, CA 91790 USA
-
-Email: chris.newman@innosoft.com
-
-APPENDIX
-
-A. ISO 8601 Collected ABNF
-
-     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 authoratative 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                                                         [Page 20]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     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 ["-"])
-
-     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
-
-
-
-
-Newman                                                         [Page 21]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     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 (periods):
-
-     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
-
-
-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:
-
-
-
-
-
-
-
-
-
-
-
-Newman                                                         [Page 22]
-
-Internet Draft               Date and Time                  January 1997
-
-
-     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]);
-     }
-
-
-C. Leap Years
-
-     Here's 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                                                         [Page 23]
-
diff --git a/Documentation/en/I-D/draft-palme-e-mail-translation-00.txt b/Documentation/en/I-D/draft-palme-e-mail-translation-00.txt
deleted file mode 100644
index 4523815d..00000000
--- a/Documentation/en/I-D/draft-palme-e-mail-translation-00.txt
+++ /dev/null
@@ -1,350 +0,0 @@
-Network Working Group                                     Jacob Palme
-Internet Draft                               Stockholm University/KTH
-draft-palme-e-mail-translation-00.txt                          Sweden
-Category-to-be: Proposed standard                    Date: April 1999
-                                                Expires: October 1999
-
-
-                  Support for Language Translation of E-Mail
-
-                        Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time.  It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 1998. All Rights Reserved.
-
-
-1.1.1.                            Abstract
-
-This memo proposes extensions to e-mail and netnews standards, to allow
-for the submission of translation of messages, not only at initial
-submission time, but also at later time, and made by other translators
-than the original author of the message. Two new e-mail/netnews header
-fields are proposed, "Translation-Of" and "Translator".
-
-This proposal does not propose any change to the already existing
-proposed standard for the Content-Language header (RFC 1766).
-
-Further discussion of this memo can take place in the mailing list WG-
-I18N@TERENA.NL.
-
-Mailing List Information
-
-To write contributions
-
- Further discussion on this document should be done through the
- mailing list WG-I18N@TERENA.NL.
-
- Comments on less important details may also be sent to the editor,
- Jacob Palme <jpalme@dsv.su.se>.
-
-To subscribe
-
- To subscribe to this mailing list, send a message to
- LISTSERV@TERENA.NL
- which contains the text
- SUB[SCRIBE] WG-I18N <your name (not your email address)>
-
-To unsubscribe
-
- To unsubscribe from this list, send a message to
- LISTSERV@TERENA.NL
- which contains the text
- UNS[UBSCRIBE] WG-I18N
-
-To access mailing list archives
-
- The archives are available for browsing from
- http://www.terena.nl/working-groups/wg-i18n/hypermail/
-
-The archives are also available by email. Send a message to
- LISTSERV@TERENA.NL with the text "INDEX WG-I18N" to get a list
- of the archive files, and then a new message "GET <file name>" to
- retrieve archive files.
-
-                         Table of contents
-
-1.   Introduction
-2.   Multi-Language Scenario
-3.   The Translation-Of Header Field
-4.   The Translator Header Field
-5.   Examples
-6.   Security considerations
-7.   Copyright and disclaimer
-8.   Acknowledgments
-9.   References
-10.  Author's address
-
-
-1.    Introduction
-
-The "Language:" e-mail content header specified in RFC 1766 [5] can be
-used to specify one or a list of natural languages used in that message
-body.
-
-The "Content-Type: Multipart/alternative" defined in MIME [4] can be
-used to send the same text in more than one language. Each part is
-marked with the "Language:" header to indicate its language, and the
-recipient can choose the body part according to his or her language
-preferences.
-
-In HTTP [6], a GET operation can indicate a list of preferred
-languages, and the server can then deliver the resource in the
-preferred language. HTTP also has facilities for the server to tell the
-client which alternatives are available in different languages, letting
-the client choose between them. It is also possible, with HTTP, to
-deliver a resource in the "Multipart/alternative" format, if the
-recipient wants to store the resource in all available language
-versions.
-
-All of these methods of transmitting information is based on the
-assumption that all language versions are ready and available when a
-message is sent.
-
-
-2.    Multi-Language Scenario
-
-John Smith writes a message in English and submits it to a mailing list
-or to a Usenet newsgroup. An automatic translation agent gets this
-message and translates it into German. The German translation is
-submitted to the same mailing list or newsgroup. Ernst Dürrenmatt reads
-this message in English, because he has indicated that he prefers
-English original documents to automatic German translations. Hilda
-Schmidt reads the message in both English and German, decides that the
-automatic German translation is not very good, and cleans it up,
-submitting a new better translation to German. Ernst Dürrenmatt checks
-this translation, makes some corrections, and submits a final corrected
-version of the German translation of the original message.
-
-
-3.    The Translation-Of Header Field
-
-The "Translation-Of" header field is used when submitting a translation
-to a message, which earlier has been sent in another language. The
-syntax for this header field is similar to the syntax for the "In-Reply-
-To" header, but only one value is allowed, since every translation can
-only be the translation of one previous message. The value contains the
-Message-ID of the original message before translation. If a message is
-available in more than one language, "Translation-Of" should always
-reference the original message, even if the translation was actually
-based on a translated version. If the original message is available in
-more than one version, with "Supersedes" or "Replaces" references
-between the versions, then the "Translation-Of" should reference the
-version which was the basis of this translation.
-
-If more than one translation is available of the same original message,
-the "Supersedes" or "Replaces" header field should not be used between
-them. "Supersedes" or "Replaces" is only to be used when the original
-message is revised. Example:
-
-
-4.    The Translator Header Field
-
-The "Translator" header field indicates who made the translation. When
-a translation is submitted, the "From" header field should still
-indicate the original author, but the "Translator" header field can
-indicate who made the translation.
-
-The syntax of the "Translator" header field is:
-
-translator           = "Translator:" CFWS mailbox-list
-                       *(";" translator-parameter) CFWS CRLF
-
-translator-parameter = art / fluency / future-extension
-
-art                  = "Human" / "Machine"
-
-fluency              = "Expert" / "Native"
-
-The meaning of these parameters are:
-
-Human   = Translation was made or revised/approved by a human
-          translator.
-
-Machine = Translation was entirely automatic, with no human checking
-          of the translation. In this case, the "Auto-Submitted" [7]
-          header should also be added to the message heading.
-
-Expert  = Translation was made by an expert translator.
-
-Native  = Translation was made by a native speaker of the target
-          language.
-
-
-5.    Examples
-
-Message-ID: A
-From: John Smith <jsmit@foo.bar.net>
-To: Tropical Flowers Mailing list
-Language: en
-
-Message-ID: B
-From: John Smith <jsmit@foo.bar.net>
-To: Tropical Flowers Mailing list
-Translation-Of: A
-Translator: Erika Ernst <eernst@foo.bar.de>; human; native
-Language: de
-
-Message-ID: C
-From: John Smith <jsmit@foo.bar.net>
-To: Tropical Flowers Mailing list
-Translation-Of: A
-Translator: Tomas Dürrenmatt <tdurrenmatt@foo.bar.de>; expert
-Language: de
-
-Message-ID: D
-From: John Smith <jsmit@foo.bar.net>
-To: Tropical Flowers Mailing list
-Language: en
-Supersedes: A
-
-Message-ID: E
-From: John Smith <jsmit@foo.bar.net>
-To: Tropical Flowers Mailing list
-Translation-Of: D
-Translator: Supertrans Super Translation Engine <supertrans@foo.bar>
-Auto-Submitted: Auto-generated
-Language: de
-Supersedes: A
-
-
-6.    Security considerations
-
-Translations made by other people than the original author of
-a message will of ourse entail the risk of intentional or
-unintentional incorrectness of the translation. But this is a
-risk we must accept if we want to have translations, and if
-everyone is not fluent in every language.
-
-Some people claim that machine translation technology is so
-bad, that it should not be used at all. However, if the
-recipient has a choice of either not understanding a message
-at all, or getting a bad machine translation, the recipient
-may still prefer the automatic translation. Based on this, the
-recipient might decide whether the message is of enough
-interest to be willing to pay for a human to make a better
-translation.
-
-The risk can be reduced, if the receiving user agent clearly
-shows that a message is a translator, who made the
-translation, and allows the user to check the original text
-and compare it with the translation.
-
-
-7.    Copyright and disclaimer
-
-The IETF takes no position regarding the validity or scope of
-any intellectual property or other rights that might be
-claimed to pertain to the implementation or use of the
-technology described in this document or the extent to which
-any license under such rights might or might not be available;
-neither does it represent that it has made any effort to
-identify any such rights. Information on the IETF's procedures
-with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims
-of rights made available for publication and any assurances of
-licenses to be made available, or the result of an attempt
-made to obtain a general license or permission for the use of
-such proprietary rights by implementors or users of this
-specification can be obtained from the IETF Secretariat."
-
-The IETF invites any interested party to bring to its
-attention any copyrights, patents or patent applications, or
-other proprietary rights which may cover technology that may
-be required to practice this standard. Please address the
-information to the IETF Executive Director.
-
-Copyright (C) The Internet Society (date). All Rights
-Reserved.
-
-This document and translations of it may be copied and
-furnished to others, and derivative works that comment on or
-otherwise explain it or assist in its implmentation may be
-prepared, copied, published and distributed, in whole or in
-part, without restriction of any kind, provided that the above
-copyright notice and this paragraph are included on all such
-copies and derivative works. However, this document itself may
-not be modified in any way, such as by removing the copyright
-notice or references to the Internet Society or other Internet
-organizations, except as needed for the purpose of developing
-Internet standards in which case the procedures for copyrights
-defined in the Internet Standards process must be followed, or
-as required to translate it into languages other than English.
-
-The limited permissions granted above are perpetual and will
-not be revoked by the Internet Society or its successors or
-assigns.
-
-
-8.    Acknowledgments
-
-Suggestions during the development of this memo has been given by Henry
-Spencer and Larry Masinter.
-
-
-9.    References
-
-Ref.    Author, title                                    IETF status
-                                                         (July 1996)
------   ---------------------------------------------    -----------
-[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
-        STD 10, RFC 821, August 1982.                    Recommended
-
-[2]     D. Crocker: "Standard for the format of ARPA     Standard,
-        Internet text messages." STD 11, RFC 822,        Recommended
-        August 1982.
-
-[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
-        interchange of USENET messages", RFC 1036,       cial IETF
-        December 1987.                                   standard,
-                                                         but in
-                                                         reality a de-
-                                                         facto
-                                                         standard for
-                                                         Usenet News
-
-[4]     N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
-        Internet Mail Extensions) Part One: Format of    Standard,
-        Internet Message Bodies. RFC 2945. November      elective
-        1996.
-
-[5]     H. Alvestrand: "Tags for the Identification      Proposed
-        of Languages", RFC 1766, February 1995.          standard,
-                                                         elective
-
-[6]     R. Fielding, J. Gettys, J. Mogul, H. Frystyk,    Proposed
-        T. Berners-Lee: Hypertext Transfer Protocol -    standard
-        - HTTP/1.1, RFC 2068, January 1997.
-
-[7]     J. Palme: The Auto-Submitted, Supersedes and     Work in
-        Expires Headers in E-mail and Netnews, draft-    progress
-        ietf-mailext-new-fields-14.txt, November
-        1998.
-
-
-10.   Author's address
-
-Jacob Palme                     Phone: +46-8-16 16 67
-Stockholm University/KTH        Fax: +46-8-783 08 29
-Electrum 230                    E-mail: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
diff --git a/Documentation/en/I-D/draft-palme-e-mail-translation-01.txt b/Documentation/en/I-D/draft-palme-e-mail-translation-01.txt
deleted file mode 100644
index a84423c5..00000000
--- a/Documentation/en/I-D/draft-palme-e-mail-translation-01.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-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
deleted file mode 100644
index e4a45e3b..00000000
--- a/Documentation/en/I-D/draft-palme-e-mail-translation-02.txt
+++ /dev/null
@@ -1,991 +0,0 @@
-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-int-print-03.txt b/Documentation/en/I-D/draft-palme-int-print-03.txt
deleted file mode 100644
index 3104d3c7..00000000
--- a/Documentation/en/I-D/draft-palme-int-print-03.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-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
deleted file mode 100644
index e346cf6f..00000000
--- a/Documentation/en/I-D/draft-palme-mailext-headers-00.txt
+++ /dev/null
@@ -1,1499 +0,0 @@
-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
deleted file mode 100644
index 4fb44682..00000000
--- a/Documentation/en/I-D/draft-palme-mailext-headers-01.txt
+++ /dev/null
@@ -1,1612 +0,0 @@
-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
deleted file mode 100644
index ee5d2448..00000000
--- a/Documentation/en/I-D/draft-palme-mailext-headers-02.txt
+++ /dev/null
@@ -1,1699 +0,0 @@
-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-03.txt b/Documentation/en/I-D/draft-palme-mailext-headers-03.txt
deleted file mode 100644
index 289699e1..00000000
--- a/Documentation/en/I-D/draft-palme-mailext-headers-03.txt
+++ /dev/null
@@ -1,1737 +0,0 @@
-Network Working Group                                     Jacob Palme
-Internet Draft                               Stockholm University/KTH
-draft-palme-mailext-headers-03.txt                             Sweden
-Category: Informational                               Date: June 2000
-Revision of: RFC 2076                          Expires: December 2000
-
-
-
-                  Common Internet Message Header Fields
-
-
-                        Status of this Memo
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time.  It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 1998. All Rights
-Reserved.
-
-                            Abstract
-
-This memo contains tables of commonly occurring header fields in
-headings of e-mail messages. The document compiles information from
-other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 2156, RFC 1496,
-RFC 1766, RFC 2183, RFC 1864, RFC 2421 and RFC 2045. A few commonly
-occurring header fields which are not defined in RFCs are also
-included. For each header field, the memo gives a short description
-and a reference to the RFC in which the header field is defined.
-
-                  Changes since previous version
-
-This document is a revision of RFC 2076. The following new header
-fields, not included in RFC 2076, have been added:
-Also-Control, Approved-By, Content-Alias, Content-Alternative,
-Content-Class, Content-Conversion, Content-Features, Content-ID,
-Delivered-To, Disposition-Notification-Options, Disposition-
-Notification-To, Expiry-Date, For-Approval, List-Archive, List-
-Digest, List-Help, List-ID, List-Owner, List-Post, List-Software,
-List-Subscribe, List-Unsubscribe, List-URL, Original-Recipient,
-Originator, Originator-Info, Path, PICS-Label, Read-Receipt-To,
-Received, Registered-Mail-Reply-Requested-By, Replaces, Return-
-Receipt-Requested, Speech-Act, Translated-By. Translation-Of, X-
-Confirm-Reading-To, X-Envelope-From, X-Envelope-To, X-Face, X-List-
-Host, X-Listserver, X-Loop, X-MIME-Autoconverted, X-No-Archive, X-
-OriginalArrivalTime, X-Priority, X-Sender, X-X-Sender, X-UIDL, X-URL,
-X-URI.
-
-The latest, revised version of this document is available from URL
-http://www.dsv.su.se/jpalme/ietf/mail-headers
-
-
-                         Table of contents
-
-Abstract
-Changes since previous version
-1. Introduction
-2. Use of gatewaying header fields
-3. Table of header fields
-     3.1 Phrases used in the tables
-     3.2 Trace information
-     3.3 Format and control information
-     3.4 Sender and recipient indication
-     3.5 Response control
-     3.6 Message identification and referral header fields
-     3.7 Other textual header fields
-     3.8 Header fields containing dates and times
-     3.9 Quality information
-     3.10 Language information
-     3.11 Size information
-     3.12 Conversion control
-     3.13 Encoding information
-     3.14 Resent-header fields
-     3.15 Security and reliability
-     3.16 Mailing list control
-     3.17 Miscellaneous
-4. Acknowledgments
-Copyright and disclaimer
-5. References
-6. Author's address
-Appendix A:
-Header fields sorted by Internet RFC document in which they
-appear.
-     RFC 822
-     RFC 976
-     RFC 1049
-     RFC 1036
-     RFC 1123
-     RFC 2156
-     RFC 1505
-     RFC 1766
-     RFC 2183
-     RFC 1864
-     RFC 2421
-     RFC 2045
-     RFC 2110
-     RFC 2369
-     son-of-RFC1036 [21]
-     draft-ietf-receipt
-     World Wide Web Consortium (W3C) Recommendations
-     Not Internet standard (as of June 2000)
-Appendix B: Alphabetical index
-
-
-                         1. Introduction
-
-Many different Internet standards and RFCs define header fields which
-may occur on Internet Mail Messages and Usenet News Articles. The
-intention of this document is to list all such header fields in one
-document as an aid to people developing message systems or interested
-in Internet Mail standards.
-
-The document contains all header fields which the author has found in
-the following Internet standards: RFC 822 [2], RFC 1036 [3], RFC 1123
-[5], RFC 2156 [7], RFC 1496 [8], RFC 2045 [11], RFC 1766 [12], RFC
-2183 [14], RFC 1864[17] and RFC 2421[20]. Note in particular that
-heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
-[16]) are not included. PEM and MOSS header fields only appear inside
-the body of a message, and thus are not header fields in the RFC 822
-sense. Mail attributes in envelopes, i.e. attributes controlling the
-message transport mechanism between mail and news servers, are not
-included. This means that attributes from SMTP [1], UUCP [18] and
-NNTP [15] are mainly not covered either. Headings used only in HTTP
-[19] are not included yet, but may be included in future version of
-this memo. Some additional header fields which often can be found in
-e-mail headings but are not part of any Internet standard are also
-included.
-
-The author does not promise that this document contains a complete
-list of all heading fields which are specified in any standard or
-used by any mailer.
-
-For each header field, the document gives a short description and a
-reference to the Internet standard or RFC, in which they are defined.
-
-The header field names given here are spelled the same way as when
-they are actually used. This is usually American but sometimes
-English spelling.  One header field in particular,
-"Organisation/Organization", occurs in e-mail header fields sometimes
-with the English and other times with the American spelling.
-
-The following words are used in this memo with the meaning specified
-below:
-
-heading           Formatted text at the top of a message, ended by a
-                  blank line
-
-header field      One field in the heading, beginning with a field
-                  name, colon, and followed by the field value(s). The
-                  words "heading field" and "header" are also
-                  sometimes used with this meaning.
-
-It is my intention to continue updating this document after its
-publication as an RFC. The latest version, which may be more up-to-
-date (but also less fully checked out) will be kept available for
-downloading from URL
-http://www.dsv.su.se/jpalme/ietf/mail-headers
-
-Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
-header fields which should be included in this memo but are not.
-
-
-                 2. Use of gatewaying header fields
-
-RFC 2156 defines a number of new header fields in Internet mail,
-which are defined to map header fields which X.400 has but which were
-previously not standardized in Internet mail. The fact that a header
-field occurs in RFC 2156 indicates that it is recommended for use in
-gatewaying messages between X.400 and Internet mail, but does not
-mean that the header field is recommended for messages wholly within
-Internet mail. Some of these header fields may eventually see
-widespread implementation and use in Internet mail, but at the time
-of this writing (2000) they are not widely implemented or used.
-
-Header fields defined only in RFC 1036 for use in Usenet News
-sometimes appear in mail messages, either because the messages have
-been gatewayed from Usenet News to e-mail, or because the messages
-were written in combined clients supporting both e-mail and Usenet
-News in the same client. These header fields are not standardized for
-use in Internet e-mail and should be handled with caution by e-mail
-agents.
-
-
-                      3. Table of header fields
-
-3.1 Phrases used in the tables
-
-"not for general        Used to mark header fields which are defined
-usage"                  in RFC 2156 for use in messages from or to
-                        Internet mail/X.400 gateways. These header
-                        fields have not been standardized for general
-                        usage in the exchange of messages between
-                        Internet mail-based systems.
-
-"not standardized       Used to mark header fields defined only in RFC
-for use in e-mail"      1036 for use in Usenet News. These header
-                        fields have no standard meaning when appearing
-                        in e-mail, some of them may even be used in
-                        different ways by different software. When
-                        appearing in e-mail, they should be handled
-                        with caution. Note that RFC 1036, although
-                        generally used as a de-facto standard for
-                        Usenet News, is not an official IETF standard
-                        or even on the IETF standards track.
-
-"non-standard"          This header field is not specified in any of
-                        referenced RFCs which define Internet
-                        protocols, including Internet Standards, draft
-                        standards or proposed standards. The header
-                        field appears here because it often appears in
-                        e-mail or Usenet News. Usage of these header
-                        fields is not in general recommended. Some
-                        header field proposed in ongoing IETF
-                        standards development work, but not yet
-                        accepted, are also marked in this way.
-
-"discouraged"           This header field, which is non-standard, is
-                        known to create problems and should not be
-                        generated. Handling of such header fields in
-                        incoming mail should be done with great
-                        caution.
-
-"controversial"         The meaning and usage of this header field is
-                        controversial, i.e. different implementors
-                        have chosen to implement the header field in
-                        different ways. Because of this, such header
-                        fields should be handled with caution and
-                        understanding of the different possible
-                        interpretations.
-
-"experimental"          This header field is used for newly defined
-                        header fields, which are to be tried out
-                        before entering the IETF standards track.
-                        These should only be used if both
-                        communicating parties agree on using them. In
-                        practice, some experimental protocols become
-                        de-facto-standards before they are made into
-                        IETF standards.
-
-3.2 Trace information
-
-Trace of distribution lists          DL-Expansion-   RFC 2156, not for
-passed.                              History:        general usage.
-
-List of MTAs passed.                 Path:           RFC 1036: 2.1.6,
-                                                     only in Usenet
-                                                     News, not in e-
-                                                     mail.
-
-Trace of MTAs which a message has    Received:       RFC 822: 4.3.2,
-passed.                                              RFC 1123: 5.2.8.
-
-Used to convey the information       Return-Path:    RFC 821,
-from the MAIL FROM envelope                          RFC 1123: 5.2.13.
-attribute in final delivery, when
-the message leaves the SMTP
-environment in which "MAIL FROM"
-is used.
-
-3.3 Format and control information
-
-Special Usenet News commands and     Also-Control:   son-of-RFC1036
-a normal article at the same                         [21], non-
-time.                                                standard, only in
-                                                     Usenet News, not
-                                                     in e-mail
-
-Controls whether this message may    Alternate-      RFC 2156, not for
-be forwarded to alternate            Recipient:      general usage.
-recipients such as a postmaster
-if delivery is not possible to
-the intended recipient. Default:
-Allowed.
-
-Whether a MIME body part is to be    Content-        RFC 2183,
-shown inline or is an attachment;    Disposition:    experimental
-can also indicate a suggested
-filename for use when saving an
-attachment to a file.
-
-Only in Usenet News, contains        Control:        RFC 1036: 2.1.6,
-commands to be performed by News                     only in Usenet
-agents.                                              News, not in e-
-                                                     mail.
-
-Whether recipients are to be told    Disclose-       RFC 2156, not for
-the names of other recipients of     Recipients:     general usage.
-the same message. This is
-primarily an X.400 facility. In
-X.400, this is an envelope
-attribute and refers to
-disclosure of the envelope
-recipient list. Disclosure of
-other recipients is in Internet
-mail done via the To:, cc: and
-bcc: header fields.
-
-An indicator that this message is    MIME-Version:   RFC 2045: 4.
-formatted according to the MIME
-standard, and an indication of
-which version of MIME is
-utilized.
-
-Which body part types occur in       Original-       RFC 2156, not for
-this message.                        Encoded-        general usage.
-                                     Information-
-                                     Types:
-
-3.4 Sender and recipient indication
-
-Inserted by Sendmail when there      Apparently-     Non-standard,
-is no "To:" recipient in the         To:             discouraged,
-original message, listing                            mentioned in
-recipients derived from the                          RFC 1211.
-envelope into the message
-heading. This behavior is not
-quite proper, MTAs should not
-modify headings (except inserting
-Received lines), and it can in
-some cases cause Bcc recipients
-to be wrongly divulged to non-Bcc
-recipients.
-
-Name of the moderator of the         Approved:       RFC 1036: 2.2.11,
-newsgroup to which this article                      not standardized
-is sent; necessary on an article                     for use in e-mail.
-sent to a moderated newsgroup to
-allow its distribution to the
-newsgroup members. Also used on
-certain control messages, which
-are only performed if they are
-marked as Approved.
-
-Name of the moderator of a           Approved-By:    Non-standard, used
-mailing list, and who has                            by some mailing
-approved this message for                            list expansion
-distribution to the members of                       systems.
-the list.
-Recipients not to be disclosed to    bcc:            RFC 822: 4.5.3,
-other recipients. (bcc = Blind                       RFC 1123: 5.2.15-
-Carbon Copy).                                        16, 5.3.7.
-
-Secondary, informational             cc:             RFC 822: 4.5.2,
-recipients. (cc = Carbon Copy)                       RFC 1123. 5.2.15-
-                                                     16, 5.3.7.
-
-Geographical or organizational       Distribution:   RFC 1036: 2.2.7,
-limitation on where this article                     not standardized
-can be distributed. Value can be                     for use in e-mail.
-a compete or incomplete domain
-names, also various special
-values are accepted like "world",
-"usenet", "USA", etc.
-
-Fax number of the originator.        Fax:,           Non-standard.
-                                     Telefax:
-
-Primary recipients, who are          For-Approval:   Non-standard
-requested to approve the
-information in this message or
-its attachments.
-
-Primary recipients, who are          For-Comment:    Non-standard
-requested to comment on the
-information in this message or
-its attachments.
-
-Primary recipients, who are          For-Handling:   Non-standard
-requested to handle the
-information in this message or
-its attachments.
-
-(2) Used in Usenet News mail         From            RFC 976: 2.4 for
-transport, to indicate the path      or              use in Usenet News
-through which an article has gone    >From
-when transferred to a new host.      (not followed
-                                     by a colon)
-Sometimes called "From_" header
-field.
-
-(1) This header field should         From (not       not standardized
-never appear in e-mail being         followed by a   for use in e-mail
-sent, and should thus not appear     colon)
-in this memo. It is however
-included, since people often ask
-about it.
-
-This header field is used in the
-so-called Unix mailbox format,
-also known as Berkely mailbox
-format or the MBOX format. This
-is a format for storing a set of
-messages in a file. A line
-beginning with "From " is used to
-separate successive messages in
-such files.
-
-This header field will thus
-appear when you use a text editor
-to look at a file in the Unix
-mailbox format. Some mailers also
-use this format when printing
-messages on paper.
-
-The information in this header
-field should NOT be used to find
-an address to which replies to a
-message are to be sent.
-
-Authors or persons taking            From:           RFC 822: 4.4.1,
-responsibility for the message.                      RFC 1123: 5.2.15-
-                                                     16, 5.3.7,
-Note difference from the "From "                     RFC 1036 2.1.1
-header field (not followed by
-":") below.
-
-
-Information about the client         Mail-System-    Non-standard.
-software of the originator.          Version:,
-                                     Mailer:,
-                                     Originating-
-                                     Client:, X-
-                                     Mailer, X-
-                                     Newsreader, X-
-                                     MimeOLE:
-
-In Usenet News: group(s) to which    Newsgroups:     RFC 1036: 2.1.3,
-this article was posted.                             not standardized
-Some systems provide this header                     and controversial
-field also in e-mail although it                     for use in e-mail.
-is not standardized there.
-Unfortunately, the header field
-can appear in e-mail with three
-different and contradictory
-meanings:
-
-(a) Indicating the newsgroup
-recipient of an article/message
-sent to both e-mail and Usenet
-News recipients.
-
-(b) In a message adressed to some
-mail to news gateways, indicates
-the newsgroup(s) that the message
-is to be posted to.
-
-(c) In a personally addressed
-reply to an article in a news-
-group, indicating the newsgroup
-in which this discussion
-originated.
-
-Sometimes used in Usenet News in     Originator:     Non-standard in
-similar ways to "Sender:"                            Usenet News,
-                                                     Experimental in
-Also used in printing protocols.                     RFC 1528.
-
-Contains information about the       Originator-     Non-standard [25]
-authentication of the originator     Info:
-in a format which is not easily
-used to send email to, to avoid
-the problems with "Sender" and "X-
-Sender".
-
-Phone number of the originator.      Phone:          Non-standard.
-
-The person or agent submitting       Sender:         RFC 822: 4.4.2,
-the message to the network, if                       RFC 1123: 5.2.15-
-other than shown by the From:                        16, 5.3.7, RFC
-header field. Should be                              1036.
-authenticated,
-according to RFC 822, but what
-kind of authentication is not
-clear. Some implementations
-expect that the e-mail address
-used in this field can be used to
-reach the sender, others do not.
-See also "X-Sender".
-
-Primary recipients.                  To:             RFC 822: 4.5.1,
-                                                     RFC 1123: 5.2.15-
-                                                     16, 5.3.7.
-
-If the sender in the envelope        X-Envelope-     Non-standard.
-(SMTP "RCTP TO") is not the same     From
-as the senders in the "From" or
-"Sender" RFC822 header fields,
-some mail servers add this to the
-RFC822 header fields as an aid to
-clients which would otherwise not
-be able to display this
-information.
-
-If the recipient in the envelope     X-Envelope-To   Non-standard.
-(SMTP "MAIL FROM") is not
-included in the CC list, some
-mail servers add this to the
-RFC822 header field as an aid to
-clients which would otherwise not
-be able to display the envelope
-recipients.
-
-48x48 bitmap with picture of the     X-Face          Non-Standard
-sender of this message.
-
-Indication in the mail header of     X-RCPT-TO:      Non-standard
-recipient on the SMTP envelope.
-
-Some mail software expect            X-Sender:       Non-standard
-"Sender:" to be an e-mail address
-which you can send mail to.
-However, some mail software has
-as the best authenticated sender
-a POP or IMAP account, which you
-might not be able to send to.
-Because of this, some mail
-software put the POP or IMAP
-account into an X-sender header
-field instead of a Sender header
-field, to indicate that you may
-not be able to send e-mail to
-this address. See also "X-X-
-Sender".
-
-Another use of" X-Sender:" is
-that some e-mail software, which
-wants to insert a "Sender:"
-header, will first change an
-existing "Sender:" header to "X-
-Sender". This use is actually
-often the same as that described
-in the previous paragraph, since
-the new "Sender:" is added
-because it is better
-authenticated than the old value.
-
-Even though some systems put the     X-X-Sender:     Non-standard
-POP or IMAP account name into the
-"X-Sender:" instead of the Sender
-header field, some mail software
-tries to send to the "X-Sender:"
-too. To stop this, some systems
-have begun to use "X-X-Sender:"
-to indicate an authentication of
-the sender which might not be
-useable to send e-mail to. See
-also "Originator-Info:"
-
-3.5 Response control
-
-Indicates whether the content of     Content-        RFC 2156, not for
-a message is to be returned with     Return:         general usage.
-non-delivery notifications.
-For future options on disposition    Disposition-    RFC 2298
-notifications.                       Notification-
-                                     Options:
-
-
-Indicate that the sender wants a     Disposition-    RFC 2298
-dispoisition notification when       Notification-
-this message is received (read,      To:
-processed, etc.) by its
-receipents.
-
-Address to which notifications       Errors-To:,     Non-standard,
-are to be sent and a request to      Return-         discouraged.
-get delivery notifications.          Receipt-To:,
-Internet standards recommend,        Read-Receipt-
-however, the use of MAIL FROM and    To:, X-
-Return-Path, not Errors-To, for      Confirm-
-where delivery notifications are     reading-to:,
-to be sent.                          Return-
-                                     Receipt-
-                                     Requested,
-                                     Register-Mail-
-                                     Reply-
-                                     Requested-By:
-
-Used in Usenet News to indicate      Followup-To:    RFC 1036: 2.2.3,
-that future discussions (=follow-                    not standardized
-up) on an article should go to a                     for use in e-mail.
-different set of newsgroups than
-the replied-to article. The most
-common usage is when an article
-is posted to several newsgroups,
-and further discussions is to
-take place in only one of them.
-
-In e-mail, this header field may
-occur in a message which is sent
-to both e-mail and Usenet News,
-to show where follow-up in Usenet
-news is wanted. The header field
-does not say anything about where
-follow-up in e-mail is to be
-sent.
-
-The value of this header field
-should be one or more newsgroup
-names.
-
-The special value "poster" as in
-"Followup-To: poster" means that
-replies are to be sent as e-mail
-to the author only.
-
-Whether a delivery report is         Generate-       RFC 2156, not for
-wanted at successful delivery.       Delivery-       general usage.
-Default is not to generate such a    Report:
-report.
-Original Recipient information       Original-       RFC 2298
-for inclusion in disposition         Recipient
-notifications.
-
-Whether non-delivery report is       Prevent-        RFC 2156, not for
-wanted at delivery error. Default    NonDelivery-    general usage.
-is to want such a report.            Report:
-
-This header field is meant to        Reply-To:       RFC 822: 4.4.3,
-indicate where the sender wants                      RFC 1036: 2.2.1
-replies to go. Unfortunately,                        controversial.
-this is ambiguous, since there
-are different kinds of replies,
-which the sender may wish to go
-to different addresses. In
-particular, there are personal
-replies intended for only one
-person, and group replies,
-intended for the whole group of
-people who read the replied-to
-message (often a mailing list,
-anewsgroup name cannot appear
-here because of different syntax,
-see "Followup-To" below.).
-
-Some mail systems use this header    Reply-To2
-field to indicate a better form
-of the e-mail address of the
-sender. Some mailing list
-expanders puts the name of the
-list in this header field. These
-practices are controversial. The
-personal opinion of the author of
-this RFC is that this header
-field should be avoided except in
-special cases, but this is a
-personal opinion not shared by
-all specialists in the area.
-
-Possible future change of name       X400-Content-   non-standard
-for "Content-Return:"                Return:
-
-3.6 Message identification and referral header fields
-
-Reference to specially important     Article-        son-of-RFC1036
-articles for a particular Usenet     Names:          [21], non-standard
-Newsgroup.
-Only in Usenet News, similar to      Article-        son-of-RFC1036
-"Supersedes:" but does not cause     Updates:        [21], non-standard
-the referenced article to be
-physically deleted.
-
-Used in addition to Content-         Content-        Work in progress
-Location if this content part can    Alias:
-be retrieved through more than
-one URI. Only one of them is
-allowed in the Content-Location,
-the other can be specified in
-Content-Alias.
-
-Base to be used for resolving        Content-Base:   RFC 2110
-relative URIs within this content
-part.
-
-Unique ID of one body part of the    Content-ID:     RFC 2045: 7.
-content of a message.
-URI with which the content of        Content-        RFC 2110
-this content part might be           Location:
-retrievable.
-Used by some automatic services      Delivered-To:   non-standard
-(mainly MLMs and autoresponders)     or
-for the purpose of loop              X-Loop:
-detection. The service adds the
-Delivered-To header to outgoing
-messages, with its e-mail address
-as a value, and discards incoming
-messages which already have it.
-
-Reference to message which this      In-Reply-To:    RFC 822: 4.6.2.
-message is a reply to.
-Unique ID of this message.           Message-ID:     RFC 822: 4.6.1
-                                                     RFC 1036: 2.1.5.
-
-Reference to previous message        Obsoletes:      RFC 2156, not for
-being corrected and replaced.                        general usage.
-Compare to "Supersedes:" below.
-This field may in the future be
-replaced with "Supersedes:".
-
-In e-mail: reference to other        References:     RFC 822: 4.6.3
-related messages, in Usenet News:                    RFC 1036: 2.1.5.
-reference to replied-to-articles.
-Still another name for similar       Replaces:       non-standard,
-functionality as for "Obsoletes:"                    proposed in IETF
-and "Supersedes:". This may                          USEFOR working
-become the most recommended                          group
-header in the future, but is
-still under discussion in IETF
-standards development work.
-
-References to other related          See-Also:       Son-of-RFC1036
-articles in Usenet News.                             [21], non-standard
-
-Commonly used in Usenet News in      Supersedes:     son-of-RFC1036
-similar ways to the "Obsoletes"                      [21], non-standard
-header field described above. In
-Usenet News, however, Supersedes
-causes a full deletion of the
-replaced article in the server,
-while "Supersedes" and
-"Obsoletes" in e-mail is
-implemented in the client and
-often does not remove the old
-version of the text.
-
-Mailbox of the person who made       Translated-     non-standard
-the translation.                     By:
-
-Reference to the Message-ID of a     Translation-    non-standard
-message, which the current           Of:
-message is a translation of.
-
-Unique identifier for a message,     X-UIDL:         non-standard
-local to a particular local
-mailbox store. The UIDL
-identifier is defined in the POP3
-standard, but not the "X-UIDL:"
-header.
-
-Similar usage as "X-URL". The URI    X-URI:          Non-standard
-can be either a URL or a URN.
-URNs are meant to become more
-persistent references to
-resources than URLs.
-
-Sometimes used with the same         X-URL:          Non-standard
-meaning as "Content-Location:",
-sometimes to indicate the web
-home page of the sender or of his
-organisation.
-
-The UID, as defined in the IMAP      X-IMAP:         Non-standard
-standard. Only used in internal
-mailbox storage in some mail
-systems, should never be visible
-to a user.
-
-3.7 Other textual header fields
-
-Comments on a message.               Comments:       RFC 822: 4.7.2.
-
-Description of a particular body     Content-        RFC 2045: 8.
-part of a message, for example a     Description:
-caption for an image body part.
-A text string which identifies       Content-        RFC 2156, not for
-the content of a message.            Identifier:     general usage.
-
-Search keys for data base            Keywords:       RFC 822: 4.7.1
-retrieval.                                           RFC 1036: 2.2.9.
-
-See Organization above.              Organisation:   Non-standard.
-
-Organization to which the sender     Organization:   RFC 1036: 2.2.8,
-of this article belongs.                             not standardized
-                                                     for use in e-mail.
-
-Title, heading, subject. Often       Subject:        RFC 822: 4.7.1
-used as thread indicator for                         RFC 1036: 2.1.4.
-messages replying to or
-commenting on other messages.
-
-Short text describing a longer       Summary:        RFC 1036: 2.2.10,
-article. Warning: Some mail                          not standardized
-systems will not display this                        for use in e-mail,
-text to the recipient. Because of                    discouraged.
-this, do not use this header
-field for text which you want to
-ensure that the recipient gets.
-
-3.8 Header fields containing dates and times
-
-In Internet, the date when a         Date:           RFC 822: 5.1,
-message was written, in X.400,                       RFC 1123: 5.2.14
-the time a message was submitted.                    RFC 1036: 2.1.2.
-Some Internet mail systems also
-use the date when the message was
-submitted.
-
-The time when a message was          Delivery-       RFC 2156, not for
-delivered to its recipient.          Date:           general usage.
-
-A suggested expiration date. Can     Expires:        RFC 1036: 2.2.4,
-be used both to limit the time of                    not standardized
-an article which is not                              for use in e-mail.
-meaningful after a certain date,
-and to extend the storage of
-important articles.
-
-Time at which a message loses its    Expiry-Date:    RFC 2156, not for
-validity. This field may in the                      general usage.
-future be replaced by "Expires:".
-Latest time at which a reply is      Reply-By:       RFC 2156, not for
-requested (not demanded).                            general usage.
-
-Time when this message was           X-OriginalArr   Non-standard
-delivered into the message           ivalTime:
-transport system (usually the
-same time as in the last
-"Received:" header)
-
-3.9 Quality information
-
-A hint from the originator to the    Importance:     RFC 2156 and
-recipients about how important a                     RFC 2421, proposed
-message is. Values: High, normal
-or low. Not used to control
-transmission speed.
-
-Body parts are missing.              Incomplete-     RFC 2156, not for
-                                     Copy:           general usage.
-
-Ratings label to control             PICS-Label:     REC-PICS-labels,
-selection (filtering) of messages                    W3C document [23].
-according to the PICS protocol.
-Sometimes used as a priority         Precedence:     Non-standard,
-value which can influence                            controversial.
-transmission speed and delivery.
-Common values are "bulk" and
-"first-class". Other uses is to
-control automatic replies and to
-control return-of-content
-facilities, and to stop mailing
-list loops.
-
-Can be "normal", "urgent" or "non-   Priority:       RFC 2156, not for
-urgent" and can influence                            general usage.
-transmission speed and delivery.
-How sensitive it is to disclose      Sensitivity:    RFC 2156 and
-this message to other people than                    RFC 2421, proposed
-the specified recipients. Values:
-Personal, private, company
-confidential. The absence of this
-header field in messages
-gatewayed from X.400 indicates
-that the message is not
-sensitive.
-
-Yet another priority indication.     X-MSMail-       Non-standard
-                                     Priority:
-
-Values: 1 (Highest), 2 (High), 3     X-Priority:     Non-standard [24]
-(Normal), 4 (Low), 5 (Lowest). 3
-(Normal) is default if the field
-is omitted.
-
-3.10 Language information
-
-Can include a code for the           Content-        RFC 1766, proposed
-natural language used in a           Language:       standard.
-message, e.g. "en" for English.
-Can include a code for the           Language:       RFC 2156, not for
-natural language used in a                           general usage.
-message, e.g. "en" for English.
-3.11 Size information
-
-Inserted by certain mailers to       Content-        Non-standard,
-indicate the size in bytes of the    Length:         discouraged.
-message text. This is part of a
-format some mailers use when
-showing a message to its users,
-and this header field should not
-be used when sending a message
-through the net. The use of this
-header field in transmission of a
-message can cause several
-robustness and interoperability
-problems.
-
-Size of the message.                 Lines:          RFC 1036: 2.2.12,
-                                                     not standardized
-                                                     for use in e-mail.
-
-3.12 Conversion control
-
-Information on where an              Content-        Non-standard [27].
-alternative variant of this          Alternative:
-document might be found.
-Non-standard variant of              Content-        Non-standard.
-Conversion: with the same values.    Conversion:
-
-The body of this message may not     Conversion:     RFC 2156, not for
-be converted from one character                      general usage.
-set to another. Values:
-Prohibited and allowed.
-
-The body of this message may not     Conversion-     RFC 2156, not for
-be converted from one character      With-Loss:      general usage.
-set to another if information
-will be lost. Values: Prohibited
-and allowed.
-
-3.13 Encoding information
-
-Type information of the content      Content-        non-standard
-in some class hierarchy. Class       Class:
-hierarchies are commonly used to
-classify data structures in
-software development.
-
-Can give more detailed               Content-        non-standard
-information about the Content-       Features:
-Type. Example:
-
-(&  (color=binary)
-    (image-file-structure=TIFF-S)
-    (dpi=200)
-    (paper-size=A4)
-    (image-coding=MH)
-    (MRC-mode=0)
-    (ua-media=stationery) )
-
-This header is meant to be used
-when you can choose between
-different versions of a resource,
-such as when using
-multipart/atlernative.
-
-Information from the SGML entity     Content-SGML-   non-standard
-declaration corresponding to the     Entity:
-entity contained in the body of
-the body part.
-
-Coding method used in a MIME         Content-        RFC 2045: 6.
-message body.                        Transfer-
-                                     Encoding:
-
-Format of content (character set     Content-Type:   RFC 1049,
-etc.) Note that the values for                       RFC 1123: 5.2.13,
-this header field are defined in                     RFC 1766: 4.1
-different ways in RFC 1049 and in                    RFC 2045: 5.
-MIME (RFC 2045), look for the
-"MIME-version" header field to
-understand if Content-Type is to
-be interpreted according to RFC
-1049 or according to MIME. The
-MIME definition should be used in
-generating mail. RFC 1049 has
-"historic" status.
-
-RFC 1766 defines a parameter
-"difference" to this header
-field.
-
-Various other Content-Type define
-various additional parameters.
-For example, the parameter
-"charset" is mandatory for all
-textual Content-Types.
-
-Used in several different ways by    Encoding:       RFC 1154,
-different mail systems. Some use                     RFC 1505,
-it for a kind of content-type                        experimental.
-information, some for encoding
-and length information, some for
-a kind of boundary information,
-some in other ways.
-
-Only used with the value             Message-Type:   RFC 2156, not for
-"Delivery Report" to indicates                       general usage.
-that this is a delivery report
-gatewayed from X.400.
-
-Information about conversion of      X-MIME-         non-standard
-this message on the path from        Autoconverted:
-sender to recipient, like
-conversion between MIME encoding
-formats. Note: Auto-conversion
-may invalidate digital seals and
-signatures.
-
-3.14 Resent-header fields
-
-When manually forwarding a           Resent-Reply-   RFC 822: C.3.3.
-message, header fields referring     To:,
-to the forwarding, not to the        Resent-From:,
-original message.  Note: MIME        Resent-
-specifies another way of             Sender:,
-resending messages, using the        Resent-From:,
-"Message" Content-Type.              Resent-Date:,
-                                     Resent-To:,
-                                     Resent-cc:,
-                                     Resent-bcc:,
-                                     Resent-
-                                     Message-ID:
-
-3.15 Security and reliability
-
-Checksum of content to ensure        Content-MD5:    RFC 1864, proposed
-that it has not been modified.                       standard.
-
-Used in Usenet News to store         Xref:           RFC 1036: 2.2.13,
-information to avoid showing a                       only in Usenet
-reader the same article twice if                     News, not in e-
-it was sent to more than one                         mail.
-newsgroup. Only for local usage
-within one Usenet News server,
-should not be sent between
-servers.
-
-3.16 Mailing list control
-
-Contains URL to use to browse the    List-Archive    RFC 2369 [26]
-archives of the mailing list from
-which this message was relayed.
-
-URL to use to get a subscription     List-Digest     Non-standard
-to the digest version of the
-mailing list from which this
-message was relayed.
-
-Contains URL to use to get a         List-Help       RFC 2369 [26]
-information about the mailing
-list from which this message was
-relayed.
-
-Stores an identification of the      List-ID         Approved by the
-mailing list, through which this                     IESG for
-message was distributed.                             standardization.
-
-Contains URL to send e-mail to       List-Owner      RFC 2369 [26]
-the owner of the mailing list
-from which this message was
-relayed.
-
-Contains URL to use to send          List-Post       RFC 2369 [26]
-contributions to the mailing list
-from which this message was
-relayed.
-
-Information about the software       List-Software   Non-standard, has
-used in a mailing list expander                      been considered
-through which this message has                       for inclusion in
-passed.                                              [26].
-
-Contains URL to use to get a         List-           RFC 2369 [26]
-subscription to the mailing list     Subscribe
-from which this message was
-relayed.
-
-Contains URL to use to               List-           RFC 2369 [26]
-unsubscribe the mailing list from    Unsubscribe
-which this message was relayed.
-
-Contains URL where information of    List-URL        Non-standard
-various kinds about the mailing
-list from which this message was
-relayed.
-
-Information about the server and     X-Listserver,   Non-standard.
-software used in a mailing list      X-List-Host     Recommended to use
-expander through which this                          "List-Software"
-message has passed. Warning:                         instead.
-"Listserv" is a trademark and
-should not be used for other than
-the "Listserv" product. Use,
-instead the "List-Software"
-header field.
-
-3.17 Miscellaneous
-
-Has been automatically forwarded.    Autoforwarded   RFC 2156, not for
-                                     :               general usage.
-
-Can be used in Internet mail to      Discarded-      RFC 2156, not for
-indicate X.400 IPM extensions        X400-IPMS-      general usage.
-which could not be mapped to         Extensions:
-Internet mail format.
-Can be used in Internet mail to      Discarded-      RFC 2156, not for
-indicate X.400 MTS extensions        X400-MTS-       general usage.
-which could not be mapped to         Extensions:
-Internet mail format.
-Name of file in which a copy of      Fcc:            Non-standard.
-this message is stored.
-Speech act categoriztion of a        Speech-Act:     Non-standard
-message, examples of speeach acts
-are Question, Idea, More,
-Promise, Sad, Happy, Angry,
-summary, Decision
-This field is used by some mail      Status:         Non-standard,
-delivery systems to indicate the                     should never
-status of delivery for this                          appear in mail in
-message when stored. Common                          transit.
-values of this field are:
-U    message is not downloaded
-     and not deleted.
-
-R    message is read or
-     downloaded.
-
-O    message is old but not
-     deleted.
-
-D    to be deleted.
-
-N    new (a new message also
-     sometimes is distinguished
-     by not having any "Status:"
-     header field.
-
-Combinations of these characters
-can occur, such as "Status: OR"
-to indicate that a message is
-downloaded but not deleted.
-
-Do not archive this message in       X-No-Archive:   Non-standard
-publicly available archives.         Yes
-
-
-
-                          4. Acknowledgments
-
-Harald Tveit Alvestrand, Neil Carpenter, William C. Carpenter, Rob
-Chandhok, Ned Freed, Olle J„rnefors, Usi Paz, Martin Platt, Keith
-Moore, Robert A. Rosenberg, Mark Symons, Nick Smith Michael C.
-Tiernan and several other people have helped me with compiling this
-list. I especially thank Ned Freed and Olle J„rnefors for their
-thorough review and many helpful suggestions for improvements. I
-alone take responsibility for any errors which may still be in the
-list.
-
-An earlier version of this list has been published as part of [13].
-
-
-                 Copyright and disclaimer
-
-The IETF takes no position regarding the validity or scope
-of any intellectual property or other rights that might be
-claimed to pertain to the implementation or use of the
-technology described in this document or the extent to
-which any license under such rights might or might not be
-available; neither does it represent that it has made any
-effort to identify any such rights. Information on the
-IETF's procedures with respect to rights in standards-track
-and standards-related documentation can be found in BCP-11.
-Copies of claims of rights made available for publication
-and any assurances of licenses to be made available, or the
-result of an attempt made to obtain a general license or
-permission for the use of such proprietary rights by
-implementors or users of this specification can be obtained
-from the IETF Secretariat."
-
-The IETF invites any interested party to bring to its
-attention any copyrights, patents or patent applications,
-or other proprietary rights which may cover technology that
-may be required to practice this standard. Please address
-the information to the IETF Executive Director.
-
-Copyright (C) The Internet Society (date). All Rights
-Reserved.
-
-This document and translations of it may be copied and
-furnished to others, and derivative works that comment on
-or otherwise explain it or assist in its implmentation may
-be prepared, copied, published and distributed, in whole or
-in part, without restriction of any kind, provided that the
-above copyright notice and this paragraph are included on
-all such copies and derivative works. However, this
-document itself may not be modified in any way, such as by
-removing the copyright notice or references to the Internet
-Society or other Internet organizations, except as needed
-for the purpose of developing Internet standards in which
-case the procedures for copyrights defined in the Internet
-Standards process must be followed, or as required to
-translate it into languages other than English.
-
-The limited permissions granted above are perpetual and
-will not be revoked by the Internet Society or its
-successors or assigns.
-
-
-                            5. References
-
-Ref.    Author, title                                    IETF status
-                                                         (July 1999)
------   ---------------------------------------------    -----------
-[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
-        STD 10, RFC 821, August 1982.                    Recommended
-
-[2]     D. Crocker: "Standard for the format of ARPA     Standard,
-        Internet text messages." STD 11, RFC 822,        Recommended
-        August 1982.
-
-[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
-        interchange of USENET messages", RFC 1036,       cial IETF
-        December 1987.                                   standard,
-                                                         but in
-                                                         reality a de-
-                                                         facto
-                                                         standard for
-                                                         Usenet News
-
-[4]     M. Sirbu: "A Content-Type header field header    Historic
-        field for internet messages", RFC 1049, March
-        1988.
-
-[5]     R. Braden (editor): "Requirements for            Standard,
-        Internet Hosts -- Application and Support",      Required
-        STD-3, RFC 1123, October 1989.
-
-[6]     D. Robinson, R. Ullman: "Encoding Header         Non-standard
-        field for Internet Messages", RFC 1505,
-        August 1993.
-
-[7]     S. Hardcastle-Kille: "Mapping between            Proposed
-        X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
-        2156 January 1998.                               elective
-
-[8]     H. Alvestrand & J. Romaguera: "Rules for         Proposed
-        Downgrading Messages from X.400/88 to            standard,
-        X.400/84 When MIME Content-Types are Present     elective
-        in the Messages", RFC 1496, August 1993.
-
-[9]     A. Costanzo: "Encoding Header field Header       Non-standard
-        field for Internet Messages", RFC 1154, April
-        1990.
-
-[10]    A. Costanzo, D. Robinson: "Encoding Header       Experimental
-        field Header field for Internet Messages",
-        RFC 1505, August 1993.
-
-[11]    N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
-        Internet Mail Extensions) Part One: Format of    Standard,
-        Internet Message Bodies. RFC 2045. November      elective
-        1996.
-
-[12]    H. Alvestrand: "Tags for the Identification      Proposed
-        of Languages", RFC 1766, February 1995.          standard,
-                                                         elective
-
-[13]    J. Palme: "Electronic Mail", Artech House        Non-standard
-        publishers, London-Boston January 1995.
-
-[14]    R. Troost, S. Dorner: "Communicating             Experimental
-        Presentation Information in Internet
-        Messages: The Content-Disposition Header
-        field", RFC 2183, June 1995.
-
-[15]    B. Kantor, P. Lapsley, "Network News Transfer    Proposed
-        Protocol: "A Proposed Standard for the Stream-   standard
-        Based Transmission of News", RFC 977, January
-        1986.
-[16]    1848  PS   S. Crocker, N. Freed, J. Galvin,      Proposed
-        S. Murphy, "MIME Object Security Services",      standard
-        RFC 1848, March 1995.
-
-[17]    J. Myers, M. Rose: The Content-MD5 Header        Draft
-        field Header field, RFC 1864, October 1995.      standard
-
-[18]    M. Horton, UUCP mail interchange format          Not an offi-
-        standard, RFC 976, Januari 1986.                 cial IETF
-                                                         standard,
-                                                         but in
-                                                         reality a de-
-                                                         facto
-                                                         standard for
-                                                         Usenet News
-
-[19]    T. Berners-Lee, R. Header fielding, H.           Informatio
-        Frystyk: Hypertext Transfer Protocol --          nal
-        HTTP/1.0, RFC 1945.
-
-[20]    G. Vaudreuil: Voice Profile for Internet         Proposed
-        Mail, RFC 2421 Feburary 1998.
-
-[21]    H. Spencer: News Article Format and              Not even an
-        Transmission, June 1994,                         RFC, but
-        FTP://zoo.toronto.edu/pub/news.ps.Z              still widely
-        FTP://zoo.toronto.edu/pub/news.txt.Z             used and
-                                                         partly almost
-        This document is often referenced under the      a de-facto
-        name "son-of-RFC1036".                           standard for
-                                                         Usenet News
-
-[23]    PICS Label Distribution Label Syntax and         Other
-        Communication Protocols, World Wide Web          standard
-        Consortium, October 1996.
-
-[24]    Eudora Pro Macintosh User Manual, Qualcomm       Non-standard
-        Inc., 1988-1995.
-
-[25]    C. Newman: Originator-Info Message Header        Non-standard
-        field. work in progress, July 1997.
-
-[26]    Grant Neufeld and Joshua D. Baer: The Use of     Proposed
-        URLs as Meta-Syntax for Core Mail List           standard
-        Commands and their Transport through Message
-        Header fields, RFC 2369, July 1998.
-
-[27]    G. Klyne (ed.): Content Negotiation for          Non-standard
-        Facsimile Using Internet Mail, Work in
-        progress, March 2000.
-
-                          6. Author's address
-
-Jacob Palme                     Phone: +46-8-16 16 67
-Stockholm University/KTH        Fax: +46-8-783 08 29
-Electrum 230                    E-mail: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
-
-                             Appendix A:
-Header fields sorted by Internet RFC document in which they appear.
-
-RFC 822
--------
-
-bcc
-cc
-Comments
-Date
-From
-In-Reply-To
-Keywords
-Message-ID
-Received
-References
-Reply-To
-Resent-
-Resent-bcc
-Resent-cc
-Resent-Date
-Resent-From
-Resent-From
-Resent-Message-ID
-Resent-Reply-To
-Resent-Sender
-Resent-To
-Return-Path
-Sender
-Subject
-To
-
-RFC 976
--------
-
-"From " (followed by space, not colon (:")
-
-RFC 1049
---------
-
-Content-Type
-
-RFC 1036
---------
-
-Approved
-Control
-Distribution
-Expires
-Followup-To
-Lines
-Newsgroups
-Organization
-Path
-Summary
-Xref
-
-RFC 1123
---------
-
-Content-Type
-
-RFC 2156
---------
-
-Alternate-recipient
-Auto-forwarded see Autoforwarded
-Autoforwarded
-Content-Identifier
-Content-Return
-Conversion
-Conversion-With-Loss
-Delivery-Date
-Discarded-X400-IPMS-Extensions
-Discarded-X400-MTS-Extensions
-Disclose-Recipients
-DL-Expansion-History
-Expiry-Date
-Generate-Delivery-Report
-Importance
-Incomplete-Copy
-Language
-Message-Type
-Obsoletes
-Original-Encoded-Information-Types
-Prevent-NonDelivery-Report
-Priority
-Reply-By
-Sensitivity
-
-RFC 1505
---------
-
-Encoding
-
-RFC 1766
---------
-
-Content-Language
-
-RFC 2183
---------
-
-Content-Disposition
-
-RFC 1864
---------
-
-Content-MD5
-
-RFC 2421
---------
-
-Importance
-Sensitivity
-
-RFC 2045
---------
-
-Content-Description
-Content-ID
-Content-Transfer-Encoding
-Content-Type
-MIME-Version
-
-RFC 2110
---------
-
-Content-Base
-Content-Location
-
-RFC 2369
---------
-
-List-Archive
-List-Help
-List-Owner
-List-Post
-List-Software
-List-Subscribe
-List-Unsubscribe
-
-son-of-RFC1036 [21]
--------------------
-
-Also-Control
-Article-Names
-Article-Updates
-See-Also
-Supersedes
-
-draft-ietf-receipt
-------------------
-
-Disposition-Notification-To
-Disposition-Notification-Options
-Original-Recipient
-
-World Wide Web Consortium (W3C) Recommendations
------------------------------------------------
-
-Pics-Label
-
-Not Internet standard (as of June 2000)
----------------------------------------
-
-"From " (not followed by ":")
-Apparently-To
-Approved-By
-Content-Alias
-Content-Alternative
-Content-Class
-Content-Conversion
-Content-Features
-Content-Length
-Content-SGML-Entity
-Delivered-To
-Encoding
-Errors-To
-Fax
-Fcc
-For-Approval
-For-Comment
-For-Handling
-List-Digest
-List-ID
-List-URL
-Mail-System-Version
-Mailer
-Organisation
-Originating-Client
-Originator
-Originator-Info
-Phone
-Precedence
-Registered-Mail-Reply-Requested-By
-Replaces
-Return-Receipt-Requested
-Return-Receipt-To
-Read-Receipt-To
-Speech-Act
-Status
-Supersedes
-Telefax
-Translated-By
-Translation-Of
-X-Confirm-Reading-To
-X-Envelope-From
-X-Envelope-To
-X-Face
-X-IMAP
-X-Loop
-X-List-Host
-X-Listserver
-X-Mailer
-X-MIME-Autoconverted
-X-MIMEOLE
-X-MSMail-Priority
-X-Newsreader
-X-No-Archive
-X-OriginalArrivalTime
-X-Priority
-X-RCPT-TO
-X-Sender
-X-UIDL
-X-URI
-X-URL
-X-X-Sender
-X400-Content-Return
-
-                   Appendix B: Alphabetical index
-
-Section Header field
-------- ------------
-
-3.3     Also-Control
-3.3     Alternate-Recipient
-3.4     Apparently-To
-3.4     Approved
-3.4     Approved-By
-3.6     Article-Names
-3.6     Article-Updates
-        Auto-Forwarded see Autoforwarded
-3.17    Autoforwarded
-3.4     bcc
-3.4     cc
-        Client, see Originating-Client
-        Comment, see For-Comment
-3.7     Comments
-3.6     Content-Alias
-3.12    Content-Alternative
-3.6     Content-Base
-3.13    Content-Class
-3.12    Content-Conversion
-3.7     Content-Description
-3.3     Content-Disposition
-3.13    Content-Features
-3.6     Content-ID
-3.7     Content-Identifier
-3.10    Content-Language see also Language
-3.11    Content-Length
-3.6     Content-Location
-3.15    Content-MD5
-3.4     Content-Return
-3.13    Content-SGML-Entity
-3.13    Content-Transfer-Encoding
-3.13    Content-Type
-3.3     Control
-3.12    Conversion
-3.12    Conversion-With-Loss
-        Copy, see Incomplete-Copy
-3.8     Date, see also Delivery-Date, Received, Expires, Expiry-
-        Date
-3.6     Delivered-To
-3.8     Delivery-Date
-        Delivery-Report, see Generate-Delivery-Report, Prevent-
-        Delivery-Report, Non-Delivery-Report, Content-Type
-        Description, see Content-Description
-3.17    Discarded-X400-IPMS-Extensions
-3.17    Discarded-X400-MTS-Extensions
-3.3     Disclose-Recipients
-        Disposition, see also Content-Disposition
-3.5     Disposition-Notification-Options
-3.5     Disposition-Notification-To
-3.4     Distribution
-3.2     DL-Expansion-History
-3.13    Encoding see also Content-Transfer-Encoding
-3.4     Errors-To
-3.8     Expires
-3.8     Expiry-Date
-        Extension see Discarded-X400-IPMS-Extensions, Discarded-
-        X400-MTS-Extensions
-3.4     Fax see also Telefax
-3.17    Fcc
-3.4     Followup-To
-3.4     For-Approval
-3.4     For-Comment
-3.4     For-Handling
-        Forwarded, see Autoforwarded
-3.4     From (not followed by (":" or preceded by ">")
-3.4     From (followed by ":")
-3.4     Generate-Delivery-Report
-        Handling, see For-Handling
-        History, see DL-Expansion-History
-        ID, see Content-ID and Message-ID
-        Identifier, see Content-ID and Message-ID
-3.9     Importance
-3.6     In-Reply-To
-3.9     Incomplete-Copy
-3.7     Keywords
-        Label, see PICS-Label
-3.10    Language see also Content-Language
-        Length see Content-Length
-3.11    Lines
-3.16    List-Archive
-3.16    List-Digest
-3.16    List-Help
-3.16    List-ID
-3.16    List-Owner
-3.16    List-Post
-3.16    List-Software
-3.16    List-Subscribe
-3.16    List-URL
-3.16    List-Unsubscribe
-        Loss, see Conversion-With-Loss
-3.4     Mail-System-Version see also X-mailer
-3.4     Mailer
-        MD5 see Content-MD5
-3.6     Message-ID
-3.13    Message-Type
-3.3     MIME-Version
-3.4     Newsgroups
-        Newsreader, see X-Newsreader
-3.6     Obsoletes
-3.7     Organisation
-3.7     Organization
-3.3     Original-Encoded-Information-Types
-3.6     Original-Recipient
-3.4     Originating-Client
-3.4     Originator
-3.4     Originator-Info see also Sender
-3.2     Path
-3.4     Phone
-3.9     PICS-Label
-3.9     Precedence
-3.4     Prevent-NonDelivery-Report
-3.9     Priority
-3.5     Read-Reciept-To
-3.2     Received
-        Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
-        Recipient
-3.6     References
-3.5     Registered-Mail-Reply-Requested-By
-3.6     Replaces
-3.8     Reply-By
-3.4     Reply-To, see also In-Reply-To, References
-3.14    Resent-
-        Return see Content-Return
-3.2     Return-Path
-3.5     Return-Receipt-Requested
-3.5     Return-Receipt-To
-3.6     See-Also
-3.4     Sender
-3.9     Sensitivity
-3.17    Speech-Act
-3.17    Status
-3.7     Subject
-3.7     Summary
-3.6     Supersedes
-3.4     Telefax see also Fax
-3.4     To
-        Transfer-Encoding see Content-Transfer-Encoding
-3.6     Translated-By
-3.6     Translation-Of
-        Type see Content-Type, Message-Type, Original-Encoded-
-        Information-Types
-        Version, see MIME-Version, X-Mailer
-3.5     X-Confirm-Reading-To
-3.4     X-Envelope-From
-3.4     X-Envelope-To
-3.4     X-Face
-3.6     X-IMAP
-3.16    X-List-Host
-3.16    X-Listserver
-3.6     X-Loop
-3.4     X-Mailer see also Mail-System-Version
-3.13    X-MIME-Autoconverted
-3.4     X-MimeOLE
-3.9     X-MSMail-Priority
-3.4     X-Newsreader
-3.17    X-No-Archive
-3.8     X-OriginalArrivaltime
-3.9     X-Priority
-3.4     X-RCPT-TO
-3.4     X-Sender see also Originator-Info
-3.6     X-UIDL
-3.6     X-URI
-3.6     X-URL see also Content-Location
-3.4     X-X-Sender see also Originator-Info
-3.4     X400-Content-Return
-3.15    Xref
diff --git a/Documentation/en/I-D/draft-palme-mailext-headers-04.txt b/Documentation/en/I-D/draft-palme-mailext-headers-04.txt
deleted file mode 100644
index 8e4ecb58..00000000
--- a/Documentation/en/I-D/draft-palme-mailext-headers-04.txt
+++ /dev/null
@@ -1,1813 +0,0 @@
-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
deleted file mode 100644
index 9901bb21..00000000
--- a/Documentation/en/I-D/draft-palme-mailext-headers-05.txt
+++ /dev/null
@@ -1,1842 +0,0 @@
-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-maillist-00.txt b/Documentation/en/I-D/draft-palme-maillist-00.txt
deleted file mode 100644
index 59118de2..00000000
--- a/Documentation/en/I-D/draft-palme-maillist-00.txt
+++ /dev/null
@@ -1,460 +0,0 @@
-INTERNET-DRAFT                                      Jacob Palme
-Network Working Group                  Stockholm University/KTH
-draft-palme-maillist-00.txt                              Sweden
-Expires August 1999                               February 1999
-
-
-
-
-
-Good Mailing List Behaviour
-
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time.  It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 1998. All Rights Reserved.
-
-
-
-Abstract
-
-This memo summarizes common ideas on how good mailing lists should
-behave. Some of this is taken from IETF standards, some is not. This
-memo is not intended, itself, to become a standard, but might, if
-accepted by the IETF, be published as informational RFC.
-
-
-Table of contents
-
-1.   Terminology and Scope
-2.   Reserved E-mail Addresses
-3.   Sending Requests to a List Expander
- 3.1   Subscription Control
-   3.1.1  To Subscribe
-   3.1.2  To Unsubscribe
- 3.2   To Get Information about a List
-4.   Who may Post to a Mailing List
-5.   SMTP Envelope
-6.   Delivery Status Notifications
-7.   Nested Lists
-8.   Loop Control
-9.   List Headers
-10.  Header Munging
-11.  Spam Control
-12.  Groupware
-13.  Security Considerations
-14.  Copyright and Disclaimer
-15.  Acknowledgments
-16.  References
-17.  Author's address
-
-
-1.    Terminology and Scope
-
-By a mailing list is in this specification meant an automatic agent
-which has an e-mail address, and which will resend messages, sent to
-this address via SMTP [RFC821], to all e-mail addresses in a list of
-subscribers to the mailing list. This process of resending is
-designated "expansion" of the mailing list. Note that lists which are
-expanded by the sender's client before submission to the mail
-transport system are not covered by this specification, even though
-the word "mailing list" is sometimes used also for such lists.
-
-This memo summarizes customary ideas on how good mailing lists should
-behave. Some of this is taken from IETF standards, some is not.
-
-
-2.    Reserved E-mail Addresses
-
-Every mailing list has an e-mail address, named according to the same
-conventions as for personal mailboxes, and reachable through the same
-mail transport system as for personal mailboxes.
-
-If the e-mail address of a mailing list is "flowers@foo.bar.net" then
-the following e-mail addresses are also reserved:
-
-flowers-request@foo.bar.net
-flowers-owner@foo.bar.net
-
-Messages sent to "flowers-request@foo.bar.net" are usually handled by
-an automatic process which performs common actions as requested in the
-message. Sometimes all, or some, such messages are sent to a human
-administrator of the list.
-
-Messages sent to "flowers-owner@foo.bar.net" are sent to a human
-administrator of the list, or cause a non-delivery notification (see
-section 6. Delivery Status Notifications) in accordance with [RFC1891]
-and [RFC1894], if the list administrator is not willing to handle
-messages sent to this e-mail address.
-
-
-3.    Sending Requests to a List Expander
-
-Some, but not all, mailing lists accept commands sent in messages to
-an automatic agent representing the list expander. The most common
-address for such an agent is "flowers-request@foo.bar.net", but other
-addresses occur, such as "list-handler@foo.bar.net".
-
-There is no agreed standard on the format of commands in such
-messages, so it is good practice to accept a number of common variants
-in either the subject or the text of the message to the agent. Such
-commands are case-insensitive.
-
-Common such commands are:
-
-3.1   Subscription Control
-
-The subscription control commands handle the subscription of the SMTP
-sender of the request (not the name in the From: or Sender: header).
-The mailing list expander may however find the name of the requestor
-from the "From:" or "Sender:" field, in order to register the name.
-This name is however not used in normal list expansion.
-
-3.1.1 To Subscribe
-
-Common commands are: sub, subscribe, join. Best is to support all of
-them.
-
-Sometimes the name of the requestor (not the e-mail address) is
-specified after this command, for example "Subscribe Mary Woodfence".
-
-3.1.2 To Unsubscribe
-
-Common unsubscribe commands are: uns, unsubscribe, signoff, sign-off,
-sign off, delete, leave, cancel, remove, rem, del. Best is to support
-all of them.
-
-3.2   To Get Information about a List
-
-Common commands to retrieve information about a list are: help,
-review, query, info, information. Best is to support all of them.
-
-The information returned may include a textual description of the
-purpose of the list and of which postings are acceptable to the list.
-It may also include description of how to subscribe and unsubscribe
-and where archives of the mailing list are kept. Some lists also
-return a list of the subscribers of the list.
-
-
-4.    Who may Post to a Mailing List
-
-There may be different kinds of restrictions on who may submit
-messages to a list. Common cases are:
-
-- Anyone:           Anyone can submit messages to the list (warning,
-                    see section 11. Spam Control below).
-- Members only:     Only members are allowed to submit to the list
-- Moderators only:  Only one or more designated moderators may
-                    submit to the list
-
-Other cases, such as geographical or domain name restrictions, or that
-only a program, agent or filter may post, also occur.
-
-The checking on who may submit to a list is done on the SMTP sender of
-the message, not on the names in From: or Sender: fields in the
-heading.
-
-If a message is sent to a list, by someone who is not allowed to
-submit to the list, this can be handled in either of two ways:
-
-(a) Forward the message to the moderator of the list, who decides
-    whether to accept or reject the message.
-
-(b) Send a non-delivery notification to the SMTP sender of the
-    rejected message, in accordance with [RFC1891] and [RFC1894].
-
-
-5.    SMTP Envelope
-
-The SMTP sender [RFC821] of a message after expansion should be the
-list owner or maintainer [RFC1123], not the original sender. For
-small, closed lists, the option of retaining the SMTP sender of the
-original sender can also occur.
-
-
-6.    Delivery Status Notifications
-
-Delivery Status Notification [RFC1891], [RFC1894] requests are usually
-not forwarded by mailing list expanders. Instead, notifications are
-sent when the message arrives at the list, and the list maintainer can
-request notifications when the messages are delivered to list
-subscribers.
-
-An exception to this is small, closed lists, where sometimes Delivery
-Status Notification requests are forwarded through the list, and the
-notifications are sent back to the original sender.
-
-
-7.    Nested Lists
-
-A subscriber of a mailing list can be another mailing list. This is
-called "nested lists". Nested lists are used for efficiency reasons
-and in order to distribute the management of different parts of the
-subscriber space.
-
-Nested lists can have a hierarchical structure or be looped, see
-Figure 7.1:
-
-
-  Figure 7.1   Examples of hierarchical and looped nesting
-
-                  Hierarchical                  Looped
-
-                     Top list               +---<-List A-<-+
-                        |                   |         |    |
-            +-----<-----+----->-----+     List B--->--+--<-+
-            |           |           |       |              |
-         Sublist A  Sublist B  Sublist C    +---->------List C
-            |
-     +--<---+---->---+
-     |               |
-  SubList A1  Sublist A2
-
-
-With a hierarchical structure, contributions intended for all members
-of the whole set of lists must be sent to the top list. Theoretically,
-messages intended for only a brach of the tree might be sent to the
-top of that branch, but this is usually not recommended, because users
-have difficulty understanding it.
-
-A way to stop contributions to other branches than the top list is to
-designated that the sublists will only accept contributions from their
-immediate superior in the nesting structure.
-
-Looped nesting can cause loops, where the same message circles
-indefinitely between the lists. How such loops can be avoided is
-described in section 8. Loop Control. Another alternative is to only
-use hierarhically nested lists. It is, however, sometimes desirable to
-allow looped nesting, for example when one or more of the nested lists
-is a groupware system which accepts local contributions using other
-submission methods than e-mail (see section 12. Groupware). Looped
-nesting will also avoid the problem with contributions submitted to
-the wrong branch of a hierarchical structure.
-
-
-8.    Loop Control
-
-Loops can occur because lists are nested (see section 7. Nested
-Lists). Even if lists are not intended to be nested, it is advisable
-to employ loop control techniques, because nesting of lists can happen
-by mistake.
-
-Mailing lists commonly employ one or more of the following techniques
-for avoiding loops and duplicates. It is better to employ more than
-one of these techniques:
-
-(1) Add a "Received:" header to all messages passing the list. If a
-    mailing list recognizes its own "Received:" header in an incoming
-    message, such a message is dropped. No non-delivery notification
-    should be sent in this case (since it might cause another loop).
-
-    Note: The content of the Received header should be different from
-    what is added by the mail transport agent during ordinary routing
-    of e-mail, since otherwise a message routed by this mail transport
-    agent may at a later time be rejected by the mailing list, even
-    though it has not actually passed the list.
-
-(2) Store a data base of the Message-ID-s of messages which have
-    passed the list, and reject incoming messages whose Message-ID
-    is on this list. To achieve loop control, this list need not be
-    kept for a long time, a week is enough.
-
-(3) Store a data base of the content or checksum of messages which
-    have passed this list, and use it in the same way as the
-    Message-ID. The advantage with this is that it may work even when
-    a message did not have any Message-ID or when some badly behaving
-    list expander has removed or modified the Message-ID.
-
-
-9.    List Headers
-
-A mailing list expander should add headers to the mailing list
-according to [RFC2369]. Examples:
-
-List-Help: <mailto:flowers@foo.net?subject=help> (List Instructions)
-List-Unsubscribe: <mailto: flowers@foo.net?subject=unsubscribe>
-List-Subscribe: <mailto: flowers@foo.net?subject=subscribe>
-List-Archive: <http://www.foo.net/flowers-archive>
-List-Post: <mailto:moderator@foo.net> (Postings are Moderated)
-List-Owner: <mailto:grant@foo.net> (Grant Neufeld)
-
-
-10.   Header Munging
-
-Apart from what is specifed in sections 8. Loop Control and 9. List
-Headers, a mailing list expander should not in any way modify the
-heading of a message. In particular, the list should not change the
-Message-ID, not add "Resent-", "From:", "Sender:", "Auto-Submitted:"
-or "Reply-To:". The practice to add the e-mail address of the list in
-a "Reply-To:" header is common, but is not recommended. Instead, use
-the "List-Post:" command from [RFC2369].
-
-
-11.   Spam Control
-
-Many mailing list expanders employ various methods to counteract
-spamming. Examples of such methods are:
-
-(1) Do not allow non-subscribers to post to the list.
-
-(2) Check all submissions by a human moderator before acceptance.
-
-(3) Employ various filtering techniques to recognize spams, such as
-    multiple occurence of the same message sent to different mailing
-    lists. Since such techniques may reject legitimate messages,
-    rejected messages should be passed to a human moderator for
-    checking.
-
-
-12.   Groupware
-
-A groupware product may appear as a mailing list to people accessing
-it via e-mail, and may at the same time appear as a forum to people
-accessing it via other user interfaces, such as HTTP [RFC2068]/HTML
-[RFC1866] or own protocols for this particular groupware.
-
-Such groupware products may allow addition of e-mail addresses as
-subscribers to a forum in the same way as groupware users are added as
-members of the forum.
-
-
-13.   Security Considerations
-
-Allowing people to retrieve lists of members of mailing lists may be
-misused by spammers and other people using these names for no-goood
-purposes.
-
-Allowing anyone to post to a list may be misused by spammers. See see
-section 11. Spam Control.
-
-Loop control may incur some risk of messages disappearing, but this
-should normally not happen.
-
-Loop control with Message-ID can be misused to stop unwanted messages,
-but this would be difficult, since the offender must send the false
-message with the same Message-ID before the message to be stopped.
-
-Spam control may incur some risk of messages disappearing. A way to
-reduce this risk is to forward rejected messages to a human moderator
-for checking.
-
-A well-known problem with moderated mailing lists is that if the
-moderator is sick, on holiday, or otherwise occupied, the list ceases
-to work.
-
-
-14.   Copyright and Disclaimer
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-rights made available for publication and any assurances of licenses
-to be made available, or the result of an attempt made to obtain a
-general license or permission for the use of such proprietary rights
-by implementors or users of this specification can be obtained from
-the IETF Secretariat."
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary
-rights which may cover technology that may be required to practice
-this standard. Please address the information to the IETF Executive
-Director.
-
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it
-or assist in its implmentation may be prepared, copied, published and
-distributed, in whole or in part, without restriction of any kind,
-provided that the above copyright notice and this paragraph are
-included on all such copies and derivative works. However, this
-document itself may not be modified in any way, such as by removing
-the copyright notice or references to the Internet Society or other
-Internet organizations, except as needed for the purpose of developing
-Internet standards in which case the procedures for copyrights defined
-in the Internet Standards process must be followed, or as required to
-translate it into languages other than English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-
-15.   Acknowledgments
-
-Many people have helped with the production of this document. Of
-special value have been .....
-
-
-16.   References
-
-[RFC821]    Simple Mail Transfer Protocol. J. Postel. Aug-01-
-            1982. (Format: TXT=124482 bytes) (Obsoletes
-            RFC0788) (Also STD0010) (Status: STANDARD)
-            
-[RFC822]    Standard for the format of ARPA Internet text
-            messages. D. Crocker. Aug-13-1982. (Format:
-            TXT=109200 bytes) (Obsoletes RFC0733) (Updated by
-            RFC1123, RFC1138, RFC1148, RFC1327, RFC2156) (Also
-            STD0011) (Status: STANDARD)
-            
-[RFC1123]   Requirements for Internet hosts - application and
-            support. R.T. Braden. Oct-01-1989. (Format:
-            TXT=245503 bytes) (Updates RFC0822) (Updated by
-            RFC2181) (Status: STANDARD)
-            
-[RFC1866]   Hypertext Markup Language - 2.0. T. Berners-Lee &
-            D. Connolly. November 1995. (Format: TXT=146904
-            bytes) (Status: PROPOSED STANDARD)
-            
-[RFC1891]   SMTP Service Extension for Delivery Status
-            Notifications. K. Moore. January 1996. (Format:
-            TXT=65192 bytes) (Status: PROPOSED STANDARD)
-            
-[RFC1894]   An Extensible Message Format for Delivery Status
-            Notifications. K. Moore & G. Vaudreuil. January
-            1996. (Format: TXT=77462 bytes) (Status: PROPOSED
-            STANDARD)
-            
-[RFC2068]   Hypertext Transfer Protocol -- HTTP/1.1. R.
-            Fielding, J. Gettys, J. Mogul, H. Frystyk, T.
-            Berners-Lee. January 1997. (Format: TXT=378114
-            bytes) (Status: PROPOSED STANDARD)
-            
-[RFC2369]   The Use of URLs as Meta-Syntax for Core Mail List
-            Commands and their Transport through Message
-            Header Fields. G. Neufeld, J. Baer. July 1998.
-            (Format: TXT=30853 bytes) (Status: PROPOSED
-            STANDARD)
-            
-
-17.   Author's address
-
-Jacob Palme                          Phone: +46-8-16 16 67
-Stockholm University/KTH             Fax: +46-8-783 08 29
-Skeppargatan 73                      E-mail: jpalme@dsv.su.se
-S-115 30 Stockholm, Sweden
-
diff --git a/Documentation/en/I-D/draft-palme-newfields-info-01.txt b/Documentation/en/I-D/draft-palme-newfields-info-01.txt
deleted file mode 100644
index a625c6d4..00000000
--- a/Documentation/en/I-D/draft-palme-newfields-info-01.txt
+++ /dev/null
@@ -1,244 +0,0 @@
-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-00.txt b/Documentation/en/I-D/draft-palme-newsmail-00.txt
deleted file mode 100644
index 0259eefd..00000000
--- a/Documentation/en/I-D/draft-palme-newsmail-00.txt
+++ /dev/null
@@ -1,719 +0,0 @@
-Network Working Group                                       Jacob Palme
-Internet Draft                             Stockholm University and KTH
-draft-palme-newsmail-00.txt                                 August 1997
-Category-to-be: Proposed standard                Expires: February 1998
-
-
-
-                  Messages between Email and Netnews
-
-                         Status of this Memo
-
- This document is an Internet-Draft. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet- Drafts as reference material
-or to cite them other than as ``work in progress.''
-
- To learn the current status of any Internet-Draft, please check the
-``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
-Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-ftp.isi.edu (US West Coast).
-
- This memo provides information for the Internet community. This' memo
-does not specify an Internet standard of any kind, since this document
-is mainly a compilation of information taken from other RFC-s..
-Distribution of this memo is unlimited.
-
-
-                            Abstract
-
-Messages can be transported through gateways between email and netnews.
-Combined clients for mail and netnews can submit the same message at the
-same time to email and netnews. Many netnews clients can produce email
-replies to the author of netnews articles. This standard specifies how
-to handle these kinds of messages. This standard specifies three new
-email headers: 'Posted-To', 'Group-Reply-To' and 'Personal-Reply-To'.
-Further discussions on this memo should take place in the mailing-list
-MAILNEWS-L@SEGATE.SUNET.SE. More info in the full text of this memo or
-at URL http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#newsharmony.
-
-
-Table of contents
-
-1. Mailing List
-2. Status
-3. Introduction
-4. Definitions
-5. Headers in Combined and Converted Messages
-    5.1 References and In-Reply-To
-    5.2 Message-ID Header
-    5.3 "Followup-To" and "Group-Reply-To" Headers
-    5.4 "Posted-To" header
-    5.5 "Newsgroups" Header
-    5.6 "Approved" Header
-    5.7 "Subject" Header
-    5.8 "Received" and "Path" headers
-    5.9 "Control" messages
-    5.10 Other Headers
-    5.11 Headers Mandatory in Netnews but not in Email
-    5.12 Headers Optional in Netnews and not Defined in Email
-6. Preparation of Replies to Combined Messages
-7. Cooperating Clients and Gateways
-8. Security considerations
-9. Acknowledgments
-10. References
-11. Author's Addresses
-Appendix A: Examples
-Appendix B: Algorithm for Assigning Message-IDs to Messages in Gateways
-from Email to Netnews
-Appendix C: Example of two partially overlapping threads
-
-1.    Mailing List
-
-Further discussion on this memo should be done through the mailing list
-MAILNEWS-L@SEGATE.SUNET.SE. To subscribe to this list, send a message to
-LISTSERV@SEGATE.SUNET.SE which contains the text
-SUB MHTML <your name (not your email address)>
-
-Archives of this list are available by anonymous ftp from
-FTP://SEGATE.SUNET.SE in the
-directory /lists/mailnews-l. The archives are also available by email.
-Send a message to
-LISTSERV@SEGATE.SUNET.SE with the text INDEX MAILNEWS-L to get a list of
-the archive files,
-and then a new message GET <file name> to retrieve the archive files.
-
-You can also browse the archives by http from
-HTTP://segate.sunet.se/archives/mailnews-l.html. The FTP archives are
-better if you want to
-download all messages, the HTTP archives are better if you want to
-browse and find a
-particular message only.
-
-Finally, the archives from December 3, 1996 are also available in
-searchable format from URL
-http://www.reference.com/cgi-bin/pn/listarch?list=MAILNEWS-L@segate.sune
-t.se
-
-
-2.    Status
-
-This standard updates current email and netnews standards [RFC822],
-[RFC1036], [RFC1123] and [MIME].
-
-
-3.    Introduction
-
-Clients which can handle both email and netnews are becoming more
-common. Also those clients which are mainly intended for netnews often
-provide facilities for replying by email to the author of netnews
-articles. Messages are often gatewayed between netnews and email, for
-example by having a mailing list paralleling a newsgroup. Thus the same
-message is often sent to both email and netnews, or an email message is
-a reply to a netnews article. This standard specifies the use and
-interpretation of certain header information in such messages. This
-standard specifies three not-previously standardized email headers:
-"Posted-To", "Group-Reply-To" and "Personal-Reply-To" and gives
-additional advice on the use of other email and netnews headers. This
-standard also registers a global domain name, "md5.net" which should not
-be used except as specified in this standard.
-
-One goal of this standard is that the recipient should be able to
-unambiguously identify the recipients (newsgroups and/or email) of a
-message and get information as a basis for decisions on where to send
-replies and followups to such messages.
-
-In particular, some existing practice can cause the undesired public
-posting of private email messages to news. It is for this reason that a
-solution is necessary.  Because of the installed base of software which
-is based on two irreconcilable meanings of the "Newsgroups" header, when
-it occurs in email, it is not feasible to simply change the definition
-of these headers. New agents which use one of the two uses of this
-header might increase the likelihood of very undesirable results, in
-particular the undesired and unintended automatic conversion of private
-messages to public newsgroup postings.
-
-This standard does not repeat information which is in the email and
-netnews standards [SMTP], [RFC822], [RFC1036], [RFC1123] and [MIME],
-except where this is needed for clarity.
-
-
-4.    Definitions
-
-The following terms are used in this standard. These terms may have a
-broader meaning in other standards, but are limited to the specific
-definitions within this document.
-
-News Client        A program used by a user to read and post news.
-
-Mail Client        A program used by a user to read and send mail.
-
-Combined Client    A program which combines the some or all of the functions
-                   of a mail client and a news client.
-
-Message            A message sent to either netnews, email or both.
-
-Mail Message       Any message prepared by a client for transmission by mail
-                   only.
-
-News Message       Any message prepared by a client for transmission by news
-                   only.
-
-Combined Message   Any message which a combined agent distributes via both
-                   news and mail.
-
-Group              A group of people receiving a message. A group can be a
-                   newsgroup (representing its subscribers), a mailing list
-                   (representing its subscribers), a set of nested mailing
-                   lists, or a number of recipient names in To, Cc or Bcc
-                   headers, or any combinations of these kinds of groups.
-
-Original Message   The message to which the current message is a reply.
-
-Root Message       A message which does not have any References, In-Reply-To
-                   or Supersedes headers.
-
-Thread             The set of messages which can be found by finding all
-                   messages which have "References", "In-Reply-To" or
-                   "Supersedes" references to a certain root message, and
-                   continuing this operation recursively. Note that a message
-                   which has "In-Reply-To", "References" or "Supersedes"
-                   headers referring to messages in more than one thread, will
-                   not cause these two threads to merge into one thread.
-                   Successive messages, however, will in this case belong to
-                   more than one thread. See appendix C for an example.
-
-Netnews Standards  See [RFC 1036]
-
-Email Standards    See [RFC822], [RFC1123], [SMTP], [MIME]
-
-
-5.    Headers in Combined and Converted Messages
-
-5.1   References and In-Reply-To
-
-Messages which are sent at the same time to both mail and news MUST use
-the References field according to the definitions in netnews standards
-[RFC 1036], both for the copy of the message sent via email and the copy
-sent via netnews.
-
-Gateways from news to mail SHOULD not modify the "References" field.
-
-Gateways from mail to news MUST, if needed, modify the syntax of
-References and In-Reply-To to agree with netnews standards (where the
-"phrase" variant is not allowed).
-
-Gateways from mail to news MAY transport the "References" and
-"In-Reply-To" header unchanged except for necessary syntax changes
-("phrase" is not allowed in netnews). If they are able to do it
-correctly, they MAY convert the "References" and "In-Reply-To" field
-contents from the usage specified for email to the usage specified for
-netnews. Note that such a conversion requires a check on the messages
-whose Message-ID are given in the "References" and "In-Reply-To" field,
-and this check may have to be performed recursively all the way back to
-the root message of a thread (since the netnews usage of the
-"References" field requires the "References" field to contain the first,
-the last and as many as possible of the intermediate earlier messages in
-the thread, see [RFC 1036] clause 2.2.5). Thus, such a conversion is not
-easy to perform. Conversion should not be done unless the gateway is
-capable of doing it correctly.
-
-Netnews messages can get replies, which are sent only as personal mail
-and are not to be gatewayed to netnews. Such replies SHOULD use the
-netnews (? or email?) conventions for "References" and "In-Reply-To".
-
-Email replies to news messages MAY indicate the newsgroup of the
-original message as a comment in the "In-Reply-To" header. Example:
-
-In-Reply-To: <message.id@some.host> (article in newsgroup foo.bar)
-
-
-5.2   Message-ID Header
-
-The "Message-ID" header MUST [RFC1036] be used (with its netnews syntax
-[RFC1036]) in messages sent to netnews and in combined messages and
-SHOULD be used with this syntax in messages sent via email to gateways
-from mail to news.
-
-A message to be gatewayed from email to netnews may lack a "Message-ID"
-header. For creation of the Message-ID, the algorithm described in
-appendix B is recommended. Mail and news software should however not
-assume, without further checking, that a Message-ID which looks like it
-had been generated according to this algorithm is the same for copies of
-the same message which have been gatewayed at different places.
-
-
-5.3   "Followup-To" and "Group-Reply-To" Headers
-
-If the sender wishes to specify that further discussion on a message
-sent to more than one newsgroup and/or mailing list is to be sent to
-only one newsgroup, the "Followup-To" header MUST be used according to
-netnews conventions in both the email and netnews version of combined
-messages. It MUST only contain newsgroup names or the string "poster",
-never email addresses, not even email addresses which are gatewayed to
-newsgroups.
-
-If the sender of a message wants followups, intended for the group of
-people who saw the replied-to article, to be sent to a mailing-list,
-this SHOULD be indicated using the "Group-Reply-To" header. The
-"Group-Reply-To" header has the same syntax as the "Reply-To" header in
-email standards, thus, multiple values are allowed. The "Group-Reply-To"
-can be used to indicate a recommended reply-address for replies intended
-for the same group of people who read the original message. Like
-"Followup-To" in netnews, this header can suggest followups to only some
-of the groups who got the original message. Readers of messages that
-contain "Followup-To" or "Group-Reply-To" headers, who want to read
-followups, should ensure that they are subscribed to one of the
-newsgroups in "Followup-To" or one of the mailing lists in
-"Group-Reply-To".
-
-If the sender wants group followups to be sent to both a newsgroup and a
-mailing-list, both a Followup-To and a Group-Reply-To header can be
-used. This SHOULD however not be done if there is a gateway between the
-mailing-list and the newsgroup.
-
-A person who sends a message to a mailing list, and does not want to get
-group replies except via this list, can include the list name in a
-"Group-Reply-To" header. If this person wants group replies both
-directly to his e- mail address and through the list, or if the person
-does not subscribe to the list, s/he can put both his/her personal
-e-mail address and the mailing list name in a "Group-Reply-To" header.
-
-If "Group-Reply-To" refers to a mailing list which is run in parallel
-with a newsgroup, gateways from mail to news may translate the
-"Group-Reply-To" mailing list to its newsgroup equivalent in a
-"Followup-To" clause, and gateways from news to mail may translate the
-"Followup-To" clause to the equivalent "Group-Reply-To" header referring
-to its parallel mailing list.
-
-The "Reply-To" header in e-mail is unfortunately used in two conflicting
-ways: (A) to indicate a replacement for the author as recipient of
-personal replies, (B) as specified above for "Group-Reply-To". Because
-of this, it SHOULD be phased-out, and replaced by the more explicit
-headers "Personal-Reply-To" and "Group-Reply-To". However, because of
-the wide usage of "Reply-To" (in both meanings) its phasing-out may take
-some years. "Personal-Reply-To" can be used both in e-mail and netnews
-to indicate where personal replies should be sent.
-
-
-5.4   "Posted-To" header
-
-This standard defines the new header "Posted-To".  The "Posted-To"
-header shall have the same syntax as the "Newsgroups" header defined in
-netnews standards.
-
-The email version of a combined message MUST use the "Posted-To" header
-to indicate the newsgroups which this message is sent to. "Posted-To"
-MUST NOT be used in the netnews version of the message (there, the
-"Newsgroups" header is used instead). "Posted-To" must not be used for
-any other purpose than described here.
-
-Gateways between netnews and email SHOULD convert the "Newsgroups"
-header in netnews to the "Posted-To" header in email and the reverse.
-Gateways which do not perform this conversion MUST remove the
-"Newsgroups" header from outgoing email messages and remove "Posted-To"
-from outgoing news articles.
-
-
-5.5   "Newsgroups" Header
-
-The "Newsgroups" header SHOULD not be used in email messages, even if
-these messages are also sent to newsgroups or are replies to news
-messages. If a message arriving via email has a "Newsgroups" header, the
-value of this header should be ignored. The value of this header shall
-in particular not be interpreted either to indicate the newsgroup to
-which this message is also posted (use Posted-To see 5.4), or to
-indicate the newsgroup of the original message (use a comment in the
-"In-Reply-To" field instead, see 5.1).
-
-Note: the reason for this rule is that older software uses the
-"Newsgroups" header in either of these two very different ways in email.
-It is not possible to agree on a single meaning of the "Newsgroups"
-header in email, therefore its use is deprecated and replaced by other
-notation instead.
-
-
-5.6   "Approved" Header
-
-The "Approved" header defined in netnews standards may be used in email
-with the same meaning: This message has been approved by the moderator
-for distribution to members of a moderated group.
-
-
-5.7   "Subject" Header
-
-Combined messages SHOULD follow the netnews rules for the "Subject"
-header.
-
-It is the responsibility of the client to create "Subject" headers which
-are correct. It is recommended that the netnews "Re: " convention is
-used also in email.
-
-
-5.8   "Received" and "Path" headers
-
-Email to news gateways MUST remove "Received" headers from incoming
-email messages while converting them to netnews. Attempts at converting
-"Received" headers to "Path" header MUST NOT be done. It is STRONGLY
-RECOMMENDED that the original email message be stored in the gateway
-(including all headers) for a period following processing, to allow
-tracing of forged or otherwise problematical articles. Netnews to email
-gateways MAY copy the "Path" header from the news article into the
-outgoing email.
-
-Note: The "Path" header in netnews has as one of its uses to avoid
-duplicates of the same message. Because of this, trying to convert
-"Received" headers to "Path" headers might cause a message to be skipped
-in netnews, and that is why such conversion MUST NOT be done.
-
-
-5.9   "Control" messages
-
-Mail to netnews gateways should provide the ability for users to cancel
-articles they have used the gateway to post. To prevent the use of such
-gateways for illegitimate cancels, gateways should not post cancels for
-articles which were not posted through that gateway, and should require
-some authentication for cancels it does post.
-
-For example, the gateway may generate a key which is returned to the
-user by email for each article posted. The user would include this key
-in the cancel message he sends to the gateway.
-
-
-5.10  Other Headers
-
-Headers defined for netnews only can occur in email, and headers defined
-for email can occur in netnews. An exception to this is the "Newsgroups"
-header, which must be handled as described in clause 5.4 and 5.5 above.
-Headers defined only for netnews should not be interpreted by email
-clients, nor should email-only headers be interpreted by news clients.
-
-Some headers have a more restricted syntax in netnews than in email, in
-that case, the netnews syntax shall be used in combined messages.
-Gateways must restrict the syntax of such headers if they are conveyed
-from email to netnews.
-
-
-5.11  Headers Mandatory in Netnews but not in Email
-
-The following headers are mandatory in netnews but optional in email:
-"Newsgroups", "Subject", "Message-ID" and "Path". Combined messages
-SHOULD include these fields in both the mail and the netnews copy of the
-message, except that the "Newsgroups" header in netnews is replaced by
-the "Posted-To" header in email.
-
-
-5.12  Headers Optional in Netnews and not Defined in Email
-
-Headers optional in netnews and not defined in email may occur in email
-messages. Combined clients MUST, and email to news gateways SHOULD,
-include these optional headers in the netnews versions of any messages
-they post.
-
-
-6.    Preparation of Replies to Combined Messages
-
-Combined clients generating replies intended only for the author or for
-only a few email recipients shall follow the email conventions for
-replies and MAY indicate the newsgroup of the original message in a
-comment in the "In-Reply-To" clause as specified in section 5.1 of this
-standard.
-
-Combined clients generating replies intended for the group who saw the
-original message should use the information in any "Followup-To" (or
-"Posted-To"/"Newsgroups" header, lacking a "Followup-To") to determine a
-default list of newsgroups to which the reply may be posted, and
-information from "Group-Reply-To" to determine a list of email
-recipients for group replies. The client MUST allow the user to modify
-any default list of email and newsgroup destinations.
-
-"Group-Reply-To" indicates recommendations by the author of where to
-send group replies, when these recommendations are email addresses (or
-email addresses of mail gateways to newsgroups). "Followup-To" also
-indicates such recommendations as specified in RFC 1036. A message may
-include both "Followup-To" indicating a newsgroup, and "Group-Reply-To"
-indicating a mailing list, which for example is run in parallel with the
-same newsgroup or where the message is intended for recipients of both
-the newsgroup and the mailing list.
-
-A client which knows that a followup will reach a mailing list in a
-"Group-Reply-To" header through a gateway from a newsgroup in a
-"Followup-To" header may send a followup only to the newsgroup, relying
-on the gateway to forward it to the mailing list. In this way, the risk
-of recipients getting multiple copies of the message can be reduced. If
-the client is not sure this will work, it should send the followup to
-both "Followup-To" and "Group-Reply-To" recipients.
-
-The choice of the appropriate recipients for a reply to the same group
-as the original message is not always easy, and good user interfaces
-will help users by clarifying to them what they are doing and where
-their reply will be sent, and make the user aware if s/he is moving a
-mail discussion to a news discussion or the reverse.
-
-In particular, any "Newsgroups" header in an email message SHOULD NOT be
-used as an indication that the original message has been sent to this
-newsgroup. Use of the "Newsgroups" header can otherwise easily result in
-a reply to a private message being sent to a newsgroup even though the
-original message was not sent to this newsgroup.
-
-
-7.    Cooperating Clients and Gateways
-
-If an email client is designed to cooperate with a certain gateway from
-email to netnews, then messages sent only between clients of this type
-and gateways of this type may employ additional information, not
-standardized here, to improve the cooperation between them. Such
-additional information MUST not be specified in ways which can cause
-misunderstandings if the message gets to other than the specified
-cooperating recipients.
-
-
-8.    Security considerations
-
-This standard will reduce the risk of various unexpected results for
-combined messages. Some existing risks in email and netnews may stay
-even with this standard, but no new risks are expected as a result of
-this standard. In general, increased transportation of messages between
-news and email may mean that existing risks in news are propagated to
-email or the reverse, but these risks would not be reduced by the lack
-of a standard for such combined messages.
-
-One security problem is that many Usenet News servers will totally
-reject an incoming article, if the server already has an article with
-the same Message-ID. This is of course proper if the new copy is
-destined for the same newsgroup, but if the new copy is destined for
-another newsgroup, the proper handling would be to distribute it to that
-group, but not to the group where it already appears.
-
-Newsgroup servers SHOULD accept articles even if the server already has
-an article with the same Message-ID, but only if the new article has as
-recipient some newsgroup where this message is not already stored, and
-then only distribute the new copy to the new newsgroup. Until all Usenet
-News servers have been modified to work this way, there is a security
-risk with gatewaying mailing lists to news, in that a message sent to
-more than one mailing lists, which are gatewayed to news at different
-hosts, might not get to both newsgroups. The best way to handle this
-problem is to change the behavious of news servers. An alternate
-solution might be to change the Message-ID in gateways, but this
-alternative has obvious drawbacks and is not recommended.
-
-The algorithm for generating Message-IDs for messages lacking them can
-slightly increase this security risk, but since most messages have
-Message-IDs, the problem is there with or without this algorithm.
-
-
-9.    Acknowledgments
-
-This standard is based on an earlier draft written by John Stanley.
-
-
-10.   References
-
-Ref.          Author, title                         IETF status (May 1997)
-                                                    ----------------------
----           -------------
-
-[SMTP]        J. Postel: "Simple Mail Transfer      Standard, Recommended.
-              Protocol", STD 10, RFC 821, August
-              1982.
-
-[RFC822]      D. Crocker: "Standard for the         Standard, Recommended.
-              format of ARPA Internet text
-              messages." STD 11, RFC 822, August
-              1982.
-
-[RFC1036]     M.R. Horton, R. Adams: "Standard      Non-standard (but still
-              for interchange of USENET             widely used as a de-facto
-              messages", RFC 1036, December         standard).
-              1987.
-
-[RFC1123]     R. Braden (editor): "Requirements     Standard, Required.
-              for Internet Hosts -- Application
-              and Support", STD-3, RFC 1123,
-              October 1989.
-
-[MIME]        N. Freed, N. Borenstein and           Draft Standard, elective.
-              others, "Multipurpose Internet
-              Mail Extensions (MIME) Part One to
-              Five, RFC 2045 to 2049.
-
-[MD5]         Rivest, R., "The MD5                  Non-standard
-              Message-Digest Algorithm", RFC
-              1321, MIT Laboratory for Computer
-              Science and RSA Data Security,
-              Inc., April 1992.
-
-[CMD5]        J. Myers, M. Rose: The Content-MD5    Draft standard, Elective
-              Header. RFC 1864, October 1995.
-
-
-11.   Author's Addresses
-
-Jacob Palme                        Phone: +46-8-16 16 67
-Stockholm University/KTH           Fax: +46-8-783 08 29
-Electrum 230                       Email: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
-
-Appendix A: Examples
-
-A.1 One Combined Message in two Instances.
-
-The following is an example of a combined message, sent both to a
-newsgroup comp.lang.c and via e-mail to a person mary@foo.bar when
-transported via netnews:
-
-   Newsgroups: comp.lang.c
-   To: mary@foo.bar
-   Date: 7 Jan 1997 12:34:21 +0000 (GMT)
-   Subject: A message about inheritance
-   From: fred@somewhere.zz
-   Message-ID: <123zx@somewhere.zz>
-   Path: a.news.system!b.news.system!somewhere.zz!fred
-
-   What is it?
-
-
-The same message when transported via email:
-
-   Posted-To: comp.lang.c
-   To: mary@foo.bar
-   Date: 7 Jan 1997 12:34:21 +0000 (GMT)
-   Subject: A message about inheritance
-   From: fred@somewhere.zz
-   Message-ID: <123zx@somewhere.zz>
-   Path: a.news.system!b.news.system!somewhere.zz!fred
-
-   What is it?
-
-
-A.2 Conversion Performed by Email to News Gateway.
-
-In this case, the mailing list name is not copied to a "To:" header in
-netnews, since it gives the same information which the "Newsgroups:"
-header gives in netnews. The email message before conversion:
-
-   Received: from ietf.org (ietf.org [132.151.1.19])
-             by info.dsv.su.se (8.8.5/8.8.5) with SMTP
-             id QAA00061 for <jpalme@dsv.su.se>;
-             Mon, 2 Jun 1997 16:23:10 +0200 (MET DST)
-   Received: from ietf.org by ietf.org id aa05468; 2 Jun 97 9:50 EDT
-   Received: from ietf.ietf.org by ietf.org id aa04922; 2 Jun 97 9:28
-             EDT
-   Mime-Version: 1.0
-   Content-Type: Multipart/Mixed; Boundary="NextPart"
-   To: IETF-Announce@ietf.org
-   Sender: ietf-announce-request@ietf.org
-   From: Internet-Drafts@ietf.org
-   Reply-to: Internet-Drafts@ietf.org
-   Subject: I-D ACTION:draft-leiba-imap-idle-02.txt
-   Date: Mon, 02 Jun 1997 09:28:44 -0400
-   X-Orig-Sender: cclark@ietf.org
-   Message-ID: <9706020928.aa04922@ietf.org>
-
-   A Revised Internet-Draft is available from the on-line Internet-
-   Drafts directories.
-
-The same message after gatewaying to netnews:
-
-   Mime-Version: 1.0
-   Content-Type: Multipart/Mixed; Boundary="NextPart"
-   Newsgroups: comp.standards.ietf.announcements
-   Sender: ietf-announce-request@ietf.org
-   From: Internet-Drafts@ietf.org
-   Reply-to: Internet-Drafts@ietf.org
-   Subject: I-D ACTION:draft-leiba-imap-idle-02.txt
-   Date: Mon, 02 Jun 1997 09:28:44 -0400
-   X-Orig-Sender: cclark@ietf.org
-   Message-ID: <9706020928.aa04922@ietf.org>
-
-   A Revised Internet-Draft is available from the on-line
-   Internet-Drafts directories.
-
-
-A.3 Conversion Performed by News to Email Gateway.
-
-Original netnews article:
-
-   Newsgroups: comp.sys.mac
-   From: PHLLB@leeds.ac.uk (L. Burkholder)
-   Subject: cocoa (formerly kidsim)
-   Message-ID: <4p1ul5$88k_001@leeds.ac.uk>
-   NNTP-Posting-Host: woolhouse_pc37.leeds.ac.uk
-   Organization: University of Leeds
-   Date: Tue, 4 Jun 1996 19:16:24 +0100 (BST)
-   X-Newsreader: News Xpress Version 1.0 Beta #4
-
-   Does anyone know how to get a copy of the recently announced Apple
-   visual programming language Cocoa (formerly called Kidsim)?
-
-The same message after gatewaying to email:
-
-   Posted-To: comp.sys.mac
-   To: info-mac@sumex-aim.stanford.edu
-   From: PHLLB@leeds.ac.uk (L. Burkholder)
-   Subject: cocoa (formerly kidsim)
-   Message-ID: <4p1ul5$88k_001@leeds.ac.uk>
-   NNTP-Posting-Host: woolhouse_pc37.leeds.ac.uk
-   Organization: University of Leeds
-   Date: Tue, 4 Jun 1996 19:16:24 +0100 (BST)
-   X-Newsreader: News Xpress Version 1.0 Beta #4
-
-   Does anyone know how to get a copy of the recently announced Apple
-   visual programming language Cocoa (formerly called Kidsim)?
-
-
-Appendix B: Algorithm for Assigning Message-IDs to Messages in Gateways
-from Email to Netnews
-
-The intention of the following algorithm is to make it likely that the
-same message will get the same Message-ID even if it is gatewayed in
-more than one place from email to news, and to make it very unlikely
-that two different messages get the same Message-ID. This algorithm is
-only intended for gateways from email to netnews, and only when
-gatewaying messages which do not have a Message-ID.
-
-Step 1: Remove all headers except From, Date, Sender, Subject.
-
-Step 2: Compute an MD5 checksum using the algorithm described in [1].
-
-Step 3: Encode the checksum using BASE64 encoding as specified in [2].
-
-Step 4: Concatenate the string "@MD5.net" to the encoded string.
-
-Note: If the message does not have any Date header, this algorithm
-should not be attempted, instead an algorithm giving a globally unique
-Message-ID based on a domain controlled by the gateway should be used.
-
-
-Appendix C: Example of two partially overlapping threads
-
-THREAD A:                            THREAD B:
-
-Subject: The beatles<-------+        Subject: Abba
-Message-ID: a1@foo.bar       \       Message-ID: b1@foo.bar
-          ^                   \                ^
-          |                    \               |
-References: a1@foo.bar          \    References: b1@foo.bar
-Subject: Re: The beatles         \   Subject: Re: Abba
-Message-ID: a2@foo.bar            \  Message-ID: b2@foo.bar
-          ^                        \           ^
-          |                         \          |   THREADS A+B:
-          |                          \         |
-References: a1@foo.bar, a2@foo.bar   References: a1@foo.bar, b1@foo.bar,
-Subject: Re: The beatles                        b2@foo.bar
-Message-ID: a3@foo.bar               Subject: Re: Abba and the beatles
-          ^                          Message-ID: ab1@foo.bar
-          |                                    ^
-          |                                    |
-References: a1@foo.bar, a2@foo.bar,  References: a1@foo.bar, b1@foo.bar,
-            a3@foo.bar                           b2@foo.bar, ab1@foo.bar
-Subject:    Re: The beatles          Subject: Re: Abba and the beatles
-Message-ID: a4@foo.bar               Message-ID: ab2@foo.bar
-
diff --git a/Documentation/en/I-D/draft-palme-select-00.txt b/Documentation/en/I-D/draft-palme-select-00.txt
deleted file mode 100644
index 7e61238b..00000000
--- a/Documentation/en/I-D/draft-palme-select-00.txt
+++ /dev/null
@@ -1,3880 +0,0 @@
-Network Working Group                                      Jacob Palme
-Internet Draft                                Stockholm University/KTH
-draft-palme-select-00.txt                                  Johan Kaers
-Intended-for: Proposed standard                                Starlab
-Expires: December 2000                                       June 2000
-
-
-
-
-
-The SELECT Protocol for Rating and Filtering
-
-
-
-
-Status of this Document
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time.  It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 2000. All Rights Reserved.
-
-Abstract
-
-The SELECT protocol allows Internet users to supply their ratings of
-Internet documents, and to use ratings provided by other users to
-filter and select what to read In particular, SELECT supports so-called
-collaborative filtering. By this is meant that the filtering and
-selection for a particular user is made based on ratings provided by
-special groups of raters, such as peer groups, people with similar
-values, interests and expertise as the person for whom the selecting
-and filtering is done.
-
-The SELECT functionality is downwards compatible with PICS [PICS 1,
-PICS 2], but a major difference is that while PICS is mainly oriented
-towards keeping out unsuitable information from children
-(blackballing), SELECT is mainly oriented towards helping people find
-the best and most valuable information for them on the Internet
-(goldballing). A syntactical difference from PICS is that the encodings
-in SELECT are using the XML encoding format.
-
-More information
-
-More information and links to the most recent versions of this document
-can be found at http://dsv.su.se/jpalme/ietf/selprot.html. A mailing
-list will be started in the middle of June 2000, for information on how
-to subscribe see the above URL.
-
-Table of Contents
-
-1.   Terminology
-2.   Definitions
-3.   Protocol elements summary table
-4.   Handling of anonymous ratings
-5.   Style sheet information in XML encodings
-6.   Submission points
-7.   Protocol elements full specifications
-     7.1 Validation of XML Encodings
-     7.2 The DTD for an atomic rating
-     7.3 Get-Service-Description-List (XML)
-     7.4 Get-Service-Description
-     7.5 Send-Rating
-     7.6 Set-Profile
-     7.7 Get-Profile
-     7.8 Login
-     7.9 Logout
-     7.10Get-Atomic-Ratings
-     7.11Simple-Search Operation
-     7.12Advanced-Search Operation (Not yet ready)
-     7.13Evaluate Operation
-     7.14Exchange-Ratings-Data (not yet ready)
-8.   The SELECT general service description
-     8.1 Example
-9.   Example of file structure on a SELECT server
-10.  Issues for further study
-11.  The SELECT Agent protocol
-12.  Protocol Implemtation Status
-13.  Security considerations
-14.  Copyright
-15.  Acknowledgments
-16.  References
-17.  Author's Addresses
-
-
-1.    Terminology
-
-Term              Description
-----              -----------
-
-Aggregate rating  A rating, which is computed based on one or more
-                  atomic ratings, combined in some way. A SELECT
-                  server may provide several different aggregate
-                  ratings, computed in different ways, for example
-                  based on only non-anonymous ratings, based on only
-                  ratings by certain experts or members of a
-                  specific peer group. Also different aggregation
-                  methods can be used, such as average, median or
-                  lower quartile. (Using the lower quartile will
-                  favour controversial documents, which may
-                  sometimes be desirable.)
-
-Anonymous rating  A rating, where the rater is not idenfied. See
-                  chapter 4.
-
-Atomic rating     A rating provided by one user on one document.
-                  Several atomic ratings of the same document can be
-                  combined to produce an aggregate rating. See
-                  chapter 7.2.
-
-Collaborative     A rating provider for a user, based on ratings
-rating            made by other users in a peer group, which has
-                  shown itself to have the same rating values as the
-                  user getting the rating.
-                  '
-ML                Machine Learning: Technology where a computer
-                  program learns by itself by observation of
-                  reality, for example by observation of human
-                  behaviour.
-
-NLP               Natural Language Processing: Processing of natural
-                  language text with programs, which can in some way
-                  analyze it, for example derive genre information
-                  from the text style.
-
-Non-anonymous     A rating, where the rater has to log in and
-rating            identify itself before being allowed to provide a
-                  non-anonymous rating. See chapter 4.
-
-Rating            Ratings are collections of descriptors of
-                  resources, which can be used as a basis for
-                  filtering.
-
-
-User              An agent providing ratings or using SELECT
-                  services. Can represent a user, but ratings may
-                  also be provided by other ways than direct user
-                  input, such as observation of user behaviour or
-                  linguistic analysis of documents.
-
-2.    Definitions
-
-Any occurence of "http://select/" in this document should in actual
-usage be replaced by the URL of a particular SELECT service.
-
-
-3.    Protocol elements summary table
-
-The SELECT protocols allow a SELECT server to keep a data base of
-ratings made my many different people on a resource, lika a web page.
-This data base can be used to find the aggregate ratings on resources
-and to search, using the aggregate rating as search criterium. Every
-server decides which and how many rating categories it provides.
-
-In addition to manually added ratings, the SELECT data base can also
-store ratings made by a machine, such as an NLP engine, and by
-automatic observation of user behaviour.
-
-The SELECT protocol can be used by Internet User Agents to submit
-ratings, get ratings, search and filter for a user. Such User Agents
-can be user-oriented servers, news servers and clients, web browsers,
-and plug-ins and client-side and server-side proxies.
-
-The SELECT protocol can also be used by autonomous agents, which can
-perform services like NLP rating, finding news of special interest to a
-particular user and e-mailing the user with this, etc.
-
-Name            Task                         Client(s)
-----            ----                         ---------
-
-Get             Find out which rating        Input reader ratings /
-service-descri  services are handled by      Another SELECT version
-ption-list      this server.                 1.0 server / A
-                                             filtering process, a
-                                             user or manager
-
-
-Get-service-de  Find out which rating        Input reader ratings /
-scription       descriptors are handled by   Another SELECT version
-                this rating service.         1.0 server / A
-                                             filtering process, a
-                                             user or manager
-
-
-Send-rating     Send a new atomic rating on  Input reader ratings /
-                a resource.                  Automatic rating agents
-
-
-Set-profile     Self-register a rater with   Input reader ratings, a
-                a server, as well as         user or manager
-                registering someone else as
-                a rater for a closed
-                server, or modifying the
-                profile of an existing
-                user.
-
-
-Get-profile     Get the profile of another   Input reader ratings, a
-                user, subject to access      user or manager
-                controls.
-
-
-Login           Establish credentials for a  All of the above
-                user.
-
-
-Logout          Waive credentials for a      All of the above
-                user.
-
-
-Get-atomic-rat  Get the ratings made by one  All of the above
-ings            or more named users on one
-                or more resources.
-
-
-Simple-Search   Make a search for rated      Rating search client, a
-                resources, HTML search       user.
-                query form.
-
-
-Advanced-Searc  Make a search for            Rating search client,
-h               resources, XML query form.   NLP module (to find
-                                             items which need NLP
-                                             ratings)
-
-
-Evaluate        Get the ratings for a list   Rating search client,
-                of resources.                news client, news
-                                             server, a user.
-
-
-Exchange-ratin  Mirror ratings data between  One SELECT version 1.0
-gs-data         two SELECT version 1.0       server.
-                servers.
-
-
-4.    Handling of anonymous ratings
-
-Ratings can be either identified or anonymous.
-
-All SELECT services may not allow anonymous ratings.
-
-Anonymous ratings are fully anonymous, no raterid of any kind is
-specified.
-
-Anonymous ratings are sent to a different URL (see chapter 6),
-containing /id/, than the URL for non-anonymous ratings. For anonymous
-ratings, the "raterid" has the special value "anonymous".
-
-When combining atomic ratings to aggregate ratings, different weight
-may be given to identified, anonymous ratings, including the weight
-zero to anonymous ratings.
-
-When retrieving atomic ratings, you will get identified ratings only
-for yourself. Other ratings are not returned or are returned only
-unidentifiable format.
-
-
-5.    Style sheet information in XML encodings
-
-The XML encodings produced by SELECT agents may contain style sheet
-information. An agent which does not use this information, should
-ignore it. Such an agent must be capable of receiving and ignoring
-style sheet information, but need not do any other processing of style
-sheet information.
-
-Such style sheet information may be:
-
-(a) A style sheet reference in the processing instruction head of an
-XML document.
-
-(b) A style sheet reference in the DTD file (not valid today, August
-1999, but may become valid in the future).
-
-Example: The following two XML data are semantically equal:
-
-Version 1:                       Version 2:
----------                        ---------
-
-
-<?xml version="1.0"?>            <?xml version="1.0"?>
-
-<!DOCTYPE send-rating-response   <?xml-stylesheet
-SYSTEM                           href="mystyle.css"
-"http://select/v1.0/send-rating- type="text/css">
-response.dtd">
-                                 <!DOCTYPE send-rating-response
-<send-rating-response            SYSTEM
-accepted="false"                 "http://select/v1.0/send-rating-re
-refuse-reason="accesscontrol"/>  sponse.dtd">
-
-                                 <send-rating-response
-                                 accepted="false"
-                                 refuse-reason="accesscontrol"
-                                 class="error"/>
-
-
-6.    Submission points
-
-Below are shown the entry points for access to the SELECT general
-service. For a specialised service, the word "general" below should be
-replaced by the subdirectory for that service.
-
-Operation          Service      Submission point
-
-Get-Service-Descri All          http://select/v1.0/select-service-description
-ption-List         services     s.xml
-
-Get-Service-Descri General      http://select/general/get-services.xml
-ption              service
-
-Send-Rating        General      http://select/v1.0/general/id/input-ratings
-                   service
-                                Note: For use by ratings supplied by
-                                identified raters.
-
-Send-Rating        General      http://select/v1.0/general/id/input-ratings
-                   service
-                                Note: For use for ratings supplied by
-                                identified raters.
-
-Send-Rating        General      http://ano.select/v1.0/general/input-ratings
-                   service      http://id.select/v1.0/general/input-ratings
-
-                                Note: ano.select is used to record anonymous
-                                ratings, id.select to record non-anonymous
-                                ratings. The different domain names are
-                                needed to keep the cookies different.
-
-Set-Profile        General      http://select/v1.0/general/id/profiles
-                   service
-
-Get-Profile        General      http://select/v1.0/general/id/profiles
-                   service
-
-Login              General      http://select/v1.0/general/id/login
-                   service
-
-Logout             General      http://select/v1.0/general/id/logout
-                   service
-
-Get-Atomic-Ratings General      http://select/v1.0/general/id/evaluator
-                   service
-
-Simple-Search      General      http://select//v1.0/general/simple-search
-                   service
-
-Advanced-Search    General      http://select/search
-                   service
-
-Evaluate           General      http://select/evaluator
-                   service
-
-7.    Protocol elements full specifications
-
-7.1   Validation of XML Encodings
-
-The DTDs and XML code in this specification has been validated using
-the XML validation service at
-http://www.stg.brown.edu/cgi-bin/xmlvalid/xmlvalid.pl.
-
-
-7.2   The DTD for an atomic rating
-
-Explanation                          Format of information sent
------------                          --------------------------
-                                     (http://select/v1.0/atomic-rating.dtd)
-
-                                     <!ELEMENT atomic-rating (rating-value+)>
-
-Start of attribute list for          <!ATTLIST atomic-rating
-atomic-rating.
-
-Identification of the rater. For a     raterid-or-pseudonym CDATA #REQUIRED
-pseudonymous rating, the pseudonym
-is specified, for an identified
-user the raterid is supplied. For
-an anonymous rating, the special
-name "anonymous" is entered.
-
-Note: when retrieving ratings made
-by other people than yourself, the
-raterid is given the special value
-"suppressed". You will then get
-ratings with the raterid changed to
-"suppressed" and with only the year
-in the date field.
-
-For aggregate ratings, the
-raterid-or-pseudonym has the
-special value "derived".
-
-IP adress of machine that generates    rated-from-host CDATA #REQUIRED
-the rating.
-
-Identification of the software         rating-engine CDATA #REQUIRED
-which formatted this rating in the
-format of an URL of a page
-describing this rating-engine.
-
-The URI of the rated resource          location CDATA #REQUIRED
-
-The date of the rating. If no date     rating-date CDATA #IMPLIED
-is specified, the server will give
-the record the current date when
-storing it. When returning ratings
-with the Get-Atomic-Ratings
-operation, ratings for other people
-than yourself are supplied with
-only year, not month or day or
-time-of-day.
-
-For aggregate ratings, this date
-has as value the last time its
-value was re-computed.
-
-The rater-competence is an           rater-competence ( author | expert |
-enumerated XML attribute, which can  user | pseudonymous | anonymous |
-only take specified values. The      un-known | multiple ) 'un-known'
-default value, if no tag is
-specified, is "un-nown".
-
-"multiple" is used for aggregate
-ratings based on multiple user's
-atomic ratings.
-
-The verification info for this       rater-trust ( signed | registered |
-rater, default is "anonymous"        pseudonymous | anonymous | multiple )
-                                     'anonymous'
-"multiple" is used for aggregate
-ratings based on multiple user's
-atomic ratings.
-
-Type of agent producing this rating  rater-type (computed | observed |
-value.                               manual) 'manual'
-
-Rating is limited to this context.   context (general | business | leisure |
-                                     shopping | research | politics | all |
-                                     not-available) 'not-available'
-
-The sender can give a globally       message-id CDATA #IMPLIED
-unique message-id to the rating
-sent. If the sender does not give
-such an ID, then the recipient will
-assign such an ID when storing the
-rating.
-
-Note: This is not the Message-ID of
-the rated resource, it is the ID of
-this rating.
-
-End of the list of XML attributes.   >
-
-The value for one rating             <!ELEMENT rating-value EMPTY>
-descriptor.
-
-                                     <!ATTLIST rating-value
-The transmit-as or short-name of       type CDATA #REQUIRED
-the rating category. Note: Only
-descriptors which are defined for
-the rating service, to which the
-connection is made, are allowed!
-
-The value of the rating in the         Value CDATA #REQUIRED
-format specified for this rating
-descriptor. Note: If a user
-specifies more than one keywords
-for a resource, then each keyword
-is sent as a separate rating-value.
-
-End of the list of XML attributes.   >
-
-
-
-7.3   Get-Service-Description-List (XML)
-
-The Get service-description-list operation retrieves a list of SELECT
-version 1.0 service descriptions and their URIs, but does not retrieve
-the actual service descriptions. This will not necessarily be a list of
-all SELECT services over the world, it may usually be a list of SELECT
-services on this particular host, or a list of services recommended by
-the manager of this host.
-
-
-7.3.1 Query format (get service description-list):
-
-An HTTP GET operation is performed on a URI established to return
-SELECT version 1.0 service descriptions.
-
-Example:
-
-This description can be requested from at:
-http://select/v1.0/select-service-descriptions
-
-Explanation                 Information sent
------------                 ----------------
-
-Get the file named          GET /v1.0/select-service-descriptions HTTP/1.1
-"sel-1/select-service-desc
-riptions". Preferred
-language is in English,
-second choice Italian
-
-From the HTTP server        Host: select
-"select" port 80.
-
-Only files in the format    Accept: application/xml
-application/xml are
-accepted.
-
-This user has connected to  Cookie: session="1234567890123456"
-this server before, and a
-cookie identifies the
-session.
-
-
-
-7.3.2 Response format (get service description-list):
-
-Explanation                 Information sent
------------                 ----------------
-
-Standard reply header       HTTP ...
-
-                            <?xml version="1.0"?>
-                            <!DOCTYPE send-rating SYSTEM "services-list.dtd">
-                            <services-list>
-                              <services-list-item
-                                 id         = "test"
-                                 URI        =
-                            "http://samson.aszi.sztaki.hu/SELECT"
-                                 server     = "samson.aszi.sztaki.hu"
-                                 maintainer = "micsik@sztaki.hu" />
-                                 <description language = "en"
-                                              text     = "SELECT service">
-                                 </description>
-                              </services-list-item>
-                            </services-list>
-
-DTD of replied message      <!ELEMENT services-list-item (description+)>
-                            <!ATTLIST services-list-item
-                               id          CDATA #REQUIRED
-                               URI         CDATA #REQUIRED
-                               Server      CDATA #REQUIRED
-                               Maintainer  CDATA #REQUIRED
-                            >
-                            <!ELEMENT description EMPTY>
-                            <!ATTLIST description
-                               language CDATA #REQUIRED
-                               text     CDATA #REQUIRED
-                            >
-
-7.4   Get-Service-Description
-
-Summary: The Get service-description operation will query a SELECT
-version 1.0 server to get a description of some services. The main
-components of this description is a list of descriptors and scales used
-by this service.
-
-Access control: None.
-
-Input data: The names of the services.
-
-Output data: A description of the service, and a list of the
-descriptors supported for ratings in that group.
-
-Base protocol: HTTP combined with XML.
-
-7.4.1 Query format (get service-description):
-
-An HTTP GET operation is performed on a certainURI.
-
-Example (get service-description):
-
-This example retrieves the service description at the URI:
-http://select/v1.0/get-service-descriptions
-
-Explanation                        Information sent
------------                        ----------------
-
-Get the file named                 GET /v1.0/get-service-descriptions HTTP/1.1
-"general/select-service-descripti
-on" which contains a description
-of the SELECT version 1.0 general
-service. The SELECT version 1.0
-general service is a service
-available to everyone, as
-different for service for special
-user groups.
-
-Get the file from the HTTP server  Host: select
-"select" port 80.
-
-Only files in the format           Accept: application/xml
-application/xml are accepted.
-
-This user has connected to this    Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-Request of SELECT test service     <?xml version="1.0"?>
-                                   <!DOCTYPE get-services SYSTEM
-                                   "get-services.dtd">
-                                   <get-services>
-                                      <service-name name = "test"/>
-                                      <service-name name = "iscn"/>
-                                   </get-services>
-
-DTD of message                     <?xml version="1.0" encoding="UTF-8" ?>
-                                   <!ELEMENT get-services (service-name+)>
-                                   <!ELEMENT service-name EMPTY>
-                                   <!ATTLIST service-name
-                                     name  CDATA #REQUIRED
-                                   >
-
-
-7.4.2 Response format (get-service-description):
-
-The response is an XML [XML1], [XML2] resource, containing a SELECT
-version 1.0 service description. The XML Resource Type Declaration for
-this XML page is described in chapter 0
-The SELECT general service description.
-
-
-7.5   Send-Rating
-
-Summary: The send-rating operation will send one or more ratings to a
-SELECT version 1.0 server. This operation can be used both for explicit
-ratings provided by users, for implicit ratings derived by observing
-user behaviour, and for ratings derived through automatic analysis of
-documents using NLP methods.
-
-Access control: If the rater is not identified by a cookie (created by
-a login operation), then either this rating will be handled as
-anonymous or the user will be instructed to login first, or to send the
-ratings to the separate entry-point for anonymous ratings. Some SELECT
-servers may not accept anonymous ratings.
-
-Input data: Information about the rated resource, the rater and the
-rating values.
-
-Output data: Acceptance or rejection.
-
-Base protocol: XML transported through HTTP.
-
-7.5.1 Transmit-Format (send-rating):
-
-A HTTP POST operation, with the content the XML-formatted rating.
-
-The send-rating is an HTTP POST operation, whose body is an XML
-resource containing the rating. Below is a POST sent to the URI
-http://select/v1.0/general/input-ratings
-
-Explanation                        Information sent
------------                        ----------------
-
-Connect to the SELECT server. The  POST /v1.0/general/id/input-ratings
-URI used identifies the rating     HTTP/1.1
-service, to which this rating is
-sent.
-
-To the HTTP server "select" port   Host: select
-80.
-
-Only files in the format           Accept: application/xml
-application/xml are accepted.
-
-The format of the query is XML.    Content-Type: Application/xml
-
-This user has connected to this    Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-The body of the query is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is as follows. Note
-that no Rater-ID is included, because this ID can be derived from the
-Cookie. And no rating-service-description is referred to, because the
-URI, to which this rating is sent, implies a particular rating-service.
-
-Explanation                          Format of information sent
------------                          ---------------------------
-                                     (http://select/v1.0/send-rating.dtd)
-
-Reference to data structure defined  <!ENTITY % atomic-rating SYSTEM
-in a separate DTD file. Further
-information, see section 7.2         "http://select/v1.0/atomic-rating.dtd">
-
-
-A list of ratings are sent.          <!ELEMENT send-rating (atomic-rating+)>
-
-Import DTD from separate DTD file    %atomic-rating;
-atomic-rating.dtd.
-
-Example (send-rating):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/send-rating.xml)
-
-HTTP header                     POST /v1.0/general/id/input-ratings  HTTP/1.1
-                                Host: select
-                                Accept: application/xml
-                                Content-Type: Application/xml
-                                Cookie: session="1234567890123456"
-
-A blank line to mark the end of
-the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE send-rating SYSTEM
-Declaration (DTD) file           "http://select/v1.0/send-rating.dtd">
-specifying the syntax for this
-XML resource.
-                                <send-rating>
-Start with information about    <atomic-rating
-the resource rated and about      raterid-or-pseudonym="jpalme@dsv.su.se"
-the rater.                        rating-engine="http://select/proxy-1"
-                                  location="http://www.body.com/eyes"
-                                  rating-date="31 Jul 1999"
-                                  rater-competence="user"
-                                  rater-type="manual"
-                                  rater-trust="registered"
-                                  message-id="990815113350*jpalme@dsv.su.se">
-
-First rating descriptor         <rating-value
-                                  type="select-reader-interest-rating"
-                                  value="good"/>
-
-Second rating descriptor, note  <rating-value
-that decimal values are allowed   type="select-reader-quality-rating"
-                                  value="1.5"/>
-
-Third rating descriptor         <rating-value
-                                  type="adult"
-                                  value="false"/>
-
-Fourth rating descriptor        <rating-value
-                                  type="context"
-                                  value="leisure"/>
-
-End of data                     </atomic-rating></send-rating>
-
-
-7.5.2 Response format (send-rating-response):
-
-The response is an XML [XML1], [XML2] resource. The XML Resource Type
-Declaration for this XML resource is:
-
-Explanation             Format of information sent
------------             --------------------------
-                        (http://select/v1.0/send-rating-response.dtd)
-
-The evaluations are     <!ELEMENT send-rating-response  (rating-value*)>
-returned, one rating
-service at a time.
-
-Whether all the rating  <!ATTLIST send-rating-response
-labels were accepted,     accepted (all | some | none) 'all'
-or some of them, or
-none of them.
-
-ID of the set-rating.     Message-id CDATA #REQUIRED
-If no message-id was
-given in the
-set-rating operation,
-this ID will tell the
-client which ID the
-set-rating operation
-got assigned by the
-server.
-
-If rating was             Refuse-reason (accepted | bad-syntax |
-rejected, explanation     Missing-info |  unknown-descriptors | wrongtype |
-why. See chapter          Wrong-competence | wrong-trust | wrong-rater-type |
-7.5.2.1 Refusal           Wrong-context | access-control | other |
-reasons for the           Wrong-type) 'accepted'
-send-rating operation.
-
-End of XML attribute    >
-list
-
-If only some of the     <!ELEMENT rating-value EMPTY>
-rating values were
-rejected, this element
-is used to list the
-rejected rating
-values.
-
-                        <!ATTLIST rating-value
-
-See send-rating           type CDATA #REQUIRED
-operation.
-
-See send-rating           value CDATA #REQUIRED
-operation
-
-End of XML attribute    >
-list
-
-
-7.5.2.1     Refusal reasons for the send-rating operation
-
-The following refusal reasons may be used in rejecting a send-rating
-operation by a SELECT server:
-
-Refuse-reason           Explanation
--------------           -----------
-
-none                    Operation was not rejected.
-
-bad-syntax              Wrong syntax of HTTP header or XML data sent.
-
-missing-info            Mandatory-information missing from sent data.
-
-unknown-descriptors     Trying to store a rating for a descriptor not
-                        supported by this server.
-
-wrongtype               Wrong type of a descriptor value, for example text
-                        for a descriptor which must have a numerical value.
-
-wrong-competence        This rater is not allowed to send ratings with this
-                        competence to this service.
-
-wrong-trust             This rater is not allowed to send ratings with this
-                        trust to this service.
-
-wrong-rater-type        This service does not accept ratings of this
-                        rater-type from this user.
-
-wrong-context           This service does not accept ratings with this
-                        context from this user.
-
-access-control          This user is not allowed to send ratings to this
-                        service. (There are no operations in this
-                        specification to give people access rights. Some
-                        SELECT services may want to give only certain people
-                        the right to perform various operations, such as send
-                        ratings. How to do this is not described in this
-                        specification.)
-
-not-logged-in           The user performed an operation which requires login,
-                        but was not logged in.
-
-other                   Other errors.
-
-Example 1 (positive send-rating response):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/send-rating-1.xml)
-
-HTTP response header            HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format
-
-References the Resource Type    <!DOCTYPE send-rating-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/send-rating-response.dtd"
-specifying the syntax for this  >
-XML resource.
-
-Accepted is default.            <send-rating-response
-                                message-id="990815113350*jpalme@dsv.su.se"/>
-
-Example 2 (negative send-rating response):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/send-rating-2.dtd)
-
-HTTP response header.           HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE send-rating-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/send-rating-response.dtd"
-specifying the syntax for this  >
-XML resource.
-
-All ratings were not accepted.  <send-rating-response accepted="some"
-                                refuse-reason="wrong-context"
-                                message-id="990815113350*jpalme@dsv.su.se">
-
-Rating-label rejected, this     <rating-value
-server does not accept ratings    type="context"
-in the leisure context.           value="leisure"/>
-
-End of send-rating-response.    </send-rating-response>
-
-
-7.6   Set-Profile
-
-Summary: The set-profile operation can be used for a rater to register
-him/herself (for services which allow this) and can be used by
-administrators to register raters (for services which do not allow
-self-registration). It can also be used to modify existing
-registrations.
-
-Issues: The format of interest-profile is not specified. The format of
-reward-account is not specified.
-
-Access control: The profile of a person is not modifiable by other
-people, only by that person him/herself, or an agent for that person,
-or certain certified SELECT processes, who will not divulge the profile
-to other people. A SELECT administrator may also usurp super-user
-privileges and perform this operation on anyone.
-
-Input data: User identification and some profile attributes to be set
-or changed.
-
-Output data: Accepted or rejected.
-
-Base protocol: XML
-
-7.6.1 Transmit format (set-profile):
-
-The set-profile operation is an HTTP POST operation, whose body is an
-XML resource containing the profile, sent to the profiles cgi-script in
-the server for this particular rating service. Example:
-"http://select/v1.0/general/id/profiles/".
-
-Note that a user, who is registered in more than one rating service,
-has a separate profile and a separate cookie for each of them.
-
-Explanation                         Information sent
------------                         ----------------
-
-Connect to the SELECT server        POST /v1.0/general/id/set-profile
-                                    HTTP/1.1
-
-To the HTTP server "select" port    Host: select
-80.
-
-Only files in the format            Accept: application/xml
-application/xml are accepted.
-
-The format of the query is XML.     Content-Type: Application/xml
-
-This user has connected to this     Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-The body of the operation is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is:
-
-Explanation                         Format of information sent
------------                         --------------------------
-                                    (http://select/v1.0/set-profile.dtd)
-
-Reference to data structure         <!ENTITY % profile SYSTEM
-defined in a separate DTD file.       "http://select/v1.0/profile.dtd">
-Further information, see section
-7.6.2 The XML DTD for the user
-profile.
-
-The set-profile consists of a       <!ELEMENT set-profile (profile)>
-profile plus two attributes.
-
-Start of XML attribute list.        <!ATTLIST set-profile
-
-Is this a new registration of a       new (true | false) 'false'
-not-yet-registered user?
-
-Whether you are setting the           self (true | false ) 'true'
-registration for yourself, or,
-since you are a superuser, for
-someone else.
-
-                                    >
-
-Profile is taken from the external  %profile;
-ENTITY declared in the first row.
-Further information, see section
-section 7.6.2 The XML DTD for the
-user profile.
-
-
-Note: All attributes of a user profile are not settable for ordinary
-users (example: no-of-docs-rated). They should thus not be used when
-setting a profile.
-
-Pseudonym should include the domain name of the SELECT server. Thus, if
-a user wants the pseudonym foobar, the user should request the
-pseudonym foobar@select when connecting to any of the SELECT servers at
-select. Note that this means that the same pseudonym is not allowed in
-more than one SELECT service, if all the services are on the same
-server. The SELECT server must check suggested pseudonyms in a data
-base which is common to all SELECT services on a particular host.
-
-
-7.6.2 The XML DTD for the user profile
-
-Profile is an XML [XML1], [XML2] resource. The XML Resource Type
-Declaration for profile:
-
-Explanation                        Format of information sent
------------                        --------------------------
-                                   (http://select/v1.0/profile.dtd)
-
-                                   <!ELEMENT profile (language*,
-                                   keyword-manual*, keyword-automatic*,
-                                   interest-profile?, query-history*,
-                                   reward-account*)>
-
-                                   <!ATTLIST profile
-
-E-mail address of the rater. This    raterid CDATA #IMPLIED
-can be omitted for a person who
-is only going to submit
-pseudonymous ratings. One of the
-two values raterid and pseudonym
-must be specified.
-
-A globally unique identification     pseudonym CDATA #IMPLIED
-of the rater, from which the real
-person cannot be found except
-through the SELECT server data
-base. (Such lookups are forbidden
-except when needed to fight
-illegal or harmful usage.)
-
-Password is mandatory except that    password CDATA #IMPLIED
-a new user can omit the password
-at registration, the server will
-then assign a password to that
-user and send it back.
-
-A question to answer for a user      remember-phrase-question CDATA #IMPLIED
-who has forgotten his/her
-password, example "What is my
-mother's maiden name".
-
-The correct answer to this           remember-phrase-answer CDATA #IMPLIED
-question.
-
-A non-unique, user-friendly name     name CDATA #IMPLIED
-of this rater.
-
-Wanted maximum validity time of a    cookie-life-time CDATA #IMPLIED
-session before time out, in
-seconds. Both the client and the
-server are responsible for not
-allowing further interactions
-before logout when the validity
-time has expired. This value is
-dependent on the setting, which
-the user makes on a "Remember my
-password" checkbox in the user
-profile settings user interface.
-
-Open key for signatures. May be      signature-open-key CDATA #IMPLIED
-mandatory, optional or not used,
-depending on SELECT service.
-
-URL of certificate authority,        certificate-authority  CDATA #IMPLIED
-with which the signature-open-key
-can be verified.
-
-A user does not have to specify      birthyear CDATA #IMPLIED
-birthyear or gender. Some SELECT
-services may however require such
-specifications. Birthyear is the
-year AD (counted from the
-commonly assumed birthyear of
-Christ).
-
-                                     gender (male | female ) #IMPLIED
-
-Some users may not have              mayrate (true | false) 'true'
-permission to rate.
-
-Whether other people can search      secret (true | false) 'false'
-for this user's name in the
-SELECT data base.
-
-Latest date when this rater made     latest-rating-date CDATA #IMPLIED
-any rating in this rating
-service.
-
-Number of docs rated by this         no-of-docs-rated CDATA #IMPLIED
-rater in this rating service.
-
-Algorithm not yet defined for how    average-ratings-given CDATA #IMPLIED
-to compute this.
-
-End of the list of XML attributes  >
-
-Language code of languages         <!ELEMENT language (#PCDATA)>
-understood by this user in
-priority order. May be repeated
-once for every language. Language
-codes are taken from RFC 1766 and
-ISO 639.
-
-Keywords specified by this user    <!ELEMENT keyword-manual (#PCDATA)>
-to identify his/her interests.
-
-Keywords automatically derived by  <!ELEMENT keyword-automatic (#PCDATA)>
-observation of this user to
-identify his/her interests.
-
-This syntax is preliminary. We     <!ELEMENT interest-profile (#PCDATA)>
-may assign a more complex syntax
-to this later on, with defined
-subelements and structure like a
-set of instructions in some
-filtering language.
-
-List of previous queries made by   <!ELEMENT query-history (#PCDATA)>
-this user. May influence
-filtering procedure.
-
-To be defined.                     <!ELEMENT reward-account (#PCDATA)>
-
-
-Example (set-profile):
-
-Explanation                  Information sent
------------                  ----------------
-                             (http://select/v1.0/set-profile.xml)
-
-HTTP header.                 POST /v1.0/general/id/set-profile  HTTP/1.1
-                             Host: select
-                             Accept: application/xml
-                             Content-Type: Application/xml
-                             Cookie: session="012345678901234354"
-
-A blank line to mark the
-end of the HTTP header.
-
-Identifies that this is in   <?xml version="1.0"?>
-XML format.
-
-References the Resource      <!DOCTYPE set-profile SYSTEM
-Type Declaration (DTD) file   "http://select/v1.0/set-profile.dtd">
-specifying the syntax for
-this XML resource.
-
-Setting the profile for      <set-profile self="false">
-someone else.
-
-Start of the profile to be   <profile
-set.
-
-List of attributes and         raterid="jpalme@dsv.su.se"
-values.                        pseudonym="xavier-xantico"
-                               password="foobar"
-                               remember-phrase-question="mother's maiden name"
-                               remember-phrase-answer="von Vegesack"
-                               name="Jacob Palme"
-                               cookie-life-time="999999999"
-                               birthyear="1941"
-                               gender="male"
-
-End of profile attributes    >
-
-Embedded elements            <keyword-manual>standards</keyword-manual>
-                             <keyword-manual>computers </keyword-manual>
-                             <keyword-manual>fiction </keyword-manual>
-                             <keyword-automatic>psychiatry
-                             </keyword-automatic>
-                             <interest-profile> Do not filter away any
-                             document containing "IETF"</interest-profile>
-
-End of set-profile           </profile></set-profile>
-
-
-7.6.3 Response format (set-profile):
-
-Explanation                        Format of information sent
------------                        --------------------------
-                                   (http://select/v1.0/set-profile-response.dt
-                                   d)
-
-The evaluation are returned, one   <!ELEMENT set-profile-response
-rating service at a time.
-
-Whether all the new user settings  <!ATTLIST set-profile-response
-were accepted, or some of them,      accepted (all | some | none) 'all'
-or none of them.
-
-XML attributes for refuse-reason.  reason   (cannot-set-for-yourself |
-                                   cannot-set-for-other-user |
-                                   raterid-or-pseudonym-in-use |
-                                   invalid-session-id | not-logged-in |
-                                   database-error | failure | success)
-                                   'failure'
-
-Example 1 (positive set-profile response):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/set-profile-response-1.xm
-                                l)
-
-HTTP response header.           HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE set-profile-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/set-profile-response.dtd"
-specifying the syntax for this  >
-XML resource.
-
-The set-profile was accepted.   <set-profile-response
-                                  accepted = "all"
-                                  reason = "none"
-                                />
-
-Example 2 (negative set-profile response):
-
-Explanation                     Information sent
------------                     ----------------
-                                (http://select/v1.0/set-profile-response-2.xm
-                                l)
-
-HTTP response header.           HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE set-profile-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/set-profile-response.dtd"
-specifying the syntax for this  >
-XML resource.
-
-The set-profile was not fully   <set-profile-response
-accepted.                         accepted="none"
-                                  reason="raterid-or-pseudonym-in-use"
-                                />
-
-
-7.7   Get-Profile
-
-Summary: The get-profile operation can be used to get the profile
-settings for a particular user in a particular SELECT server. It can be
-used to retrieve a profile, and then send in a modified profile using
-(to the extent this is allowed) using the set-profile operation.
-Filtering agents may use get profile to get information used in the
-filtering for a certain user. ML algorithms may automatically modify a
-user's profile, the profile may indicate limits on what ML algorithms
-may do to it. (Example: "ML may not filter out any articles in
-newsgroup X, since it is very important to me".)
-
-Access control: The profile of a person is not accessible by other
-people, only by that person him/herself, or an agent for that person,
-or certain certified SELECT processes, who will not divulge the profile
-to other people. A SELECT administrator may also usurp super-user
-privileges and perform this operation on anyone.
-
-Input data: Identification of the user or search-info for the user,
-whose profile is wanted.
-
-Output data: The profile of this user, or a rejection error.
-
-Base protocol: application/x-www-form-urlencoded for the request, XML
-for the response.
-
-7.7.1 Query format (get-profile):
-
-The get-profile operation is an HTTP GET operation, with an HTML form:
-
-
-
-<html>
-<head>
-<title>SELECT Login</title>
-<meta http-equiv="Content-Type" content="text/html;
-charset=iso-8859-1">
-</head>
-<body bgcolor="#FFFFFF">
-<h1><font>Get SELECT User
-  Info </h1>
-<form method="get" action="http://www.dsv.su.se/~jpalme/">
-  <table border="0" cellpadding="5">
-    <tr>
-      <td rowspan="2">Fill
-        in either an e-mail<br>
-        address or a search string:</td>
-      <td>
-        <div align="right">The
-          e-mail address<br>
-          of the user:</div>
-      </td>
-      <td>
-        <input type="text" name="e-mail-address"
-               size="50" maxlength="80">
-      </td>
-    </tr>
-    <tr>
-      <td>
-        <div align="right">Search
-          string:</div>
-      </td>
-      <td>
-        <input type="text" name="search-string"
-               size="50" maxlength="80">
-      </td>
-    </tr>
-    <tr>
-      <td>&nbsp;</td>
-      <td>&nbsp;</td>
-      <td>
-        <input type="submit" name="Get" value="Get user info">
-        &nbsp;<font face="Verdana, Arial, Helvetica" size="2">
-        Response format:
-        <input type="radio" name="responseformat" value="html"
-               checked>
-        HTML
-        <input type="radio" name="responseformat" value="xml">
-        XML </td>
-    </tr>
-  </table>
-   </form>
-</body>
-</html>
-
-Example: "http://select/v1.0/general/id/profiles?e-mail-address=&search
-string=Donald+Duck&Get=Get+user+info&responseformat=html".
-
-Example (get-profile):
-
-Explanation                        Information sent
------------                        ----------------
-
-Connect to the SELECT server.      GET
-                                   /v1.0/general/id/profiles?raterid=jpalme
-                                   HTTP/1.1
-
-To the HTTP server "select" port   Host: select
-80.
-
-Only files in the format           Accept: application/xml
-application/xml are accepted.
-
-
-
-7.7.2 Response format (get-profile):
-
-Explanation                  Format of information sent
------------                  --------------------------
-                             (http://select/v1.0/get-profile-response.dtd)
-
-Reference to data structure  <!ENTITY %profile SYSTEM
-defined in a separate DTD      "http://select/v1.0/profile.dtd">
-file. Further information,
-see section 0.
-
-The evaluation are           <!ELEMENT get-profile-response  ( profile+ |
-returned, one rating         error )>
-service at a time.
-
-                             <!ATTLIST get-profile-response
-
-Partial means that some,       success ( full | partial | none ) 'full'
-but not all the requested
-data is returned.
-
-                             >
-
-Profile is taken from the    %profile;
-external ENTITY declared in
-the first row. Further
-information, see section 0.
-Profile may be incomplete,
-in case only some
-attributes are retrievable
-for this requestor (if you
-get profile for someone
-else than yourself).
-
-                             <!ELEMENT error (#PCDATA)>
-
-                             <!ATTLIST error
-
-Reject reason, no default      reason ( not-logged-in | bad-syntax |
-value.                         not-found | authorisation-failure |
-Note: Data for secret          other-reason )
-users, whom the requestor      #IMPLIED
-are not allowed to see, are
-treated as non-existing. A
-search for such a user
-might thus return
-"not-found".
-
-                             >
-
-Example 1 (positive get-profile response):
-
-Explanation                  Information sent
------------                  ----------------
-                             (http://select/v1.0/get-profile-response-1.xml)
-
-HTTP response header.        HTTP/1.1 200 OK
-                             Content-Length: 569
-                             Content-Type: application/xml
-                             Server: Select 1.0
-                             Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate
-the end of the HTTP header.
-
-Identifies that this is in   <?xml version="1.0"?>
-XML format.
-
-References the Resource      <!DOCTYPE get-profile-response SYSTEM
-Type Declaration (DTD) file  "http://select/v1.0/get-profile-response.dtd">
-specifying the syntax for
-this XML resource.
-
-The get-profile was          <get-profile-response>
-accepted.
-
-Start of the profile to be   <profile
-set.
-
-List of attributes and         raterid="jpalme@dsv.su.se"
-values.                        pseudonym="xavier-xantico"
-Note: Password is never        remember-phrase-question="mother's maiden name"
-returned.                      remember-phrase-answer="von Vegesack"
-                               name="Jacob Palme"
-                               cookie-life-time="999999999"
-                               birthyear="1941"
-                               gender="male"
-
-End of profile attributes    >
-
-Embedded elements            <keyword-manual>standards</keyword-manual>
-                             <keyword-manual>computers </keyword-manual>
-                             <keyword-manual>fiction </keyword-manual>
-                             <keyword-automatic>psychiatry
-                             </keyword-automatic>
-                             <interest-profile> Do not filter away any
-                             document containing "IETF"</interest-profile>
-
-End of get-profile           </profile></get-profile-response>
-
-Example 2 (negative get-profile response):
-
-Explanation                      Information sent
------------                      ----------------
-                                 (http://select/v1.0/get-profile-response-2.x
-                                 ml)
-
-HTTP response header.            HTTP/1.1 200 OK
-                                 Content-Length: 569
-                                 Content-Type: application/xml
-                                 Server: Select 1.0
-                                 Date: 17 August 1999 12:22:46 +0200
-
-A blank line to indicate the end
-of the HTTP header.
-
-Identifies that this is in XML   <?xml version="1.0"?>
-format.
-
-References the Resource Type     <!DOCTYPE get-profile-response SYSTEM
-Declaration (DTD) file           "http://select/v1.0/get-profile-response.dtd
-specifying the syntax for this   ">
-XML resource.
-
-The get-profile did not succeed. <get-profile-response success="none">
-                                 <error reason="not-logged-in">
-                                 You cannot do this without first logging in.
-                                 </error></get-profile-response>
-
-
-7.8   Login
-
-Summary: The login operation is used to identify a user, and cause a
-cookie value to be set, which allows this user to perform certain
-access-controlled operations during the validity time of this cookie.
-
-Access control: E-mail address and password. May not be required for
-sending anonymous ratings.
-
-Input data: User identification by either e-mail address or pseudonym
-combined with password or an IMAP authentication.
-
-Output data: Acceptance or rejection.
-
-Base protocol: application/x-www-form-urlencoded for the request, HTML
-or XML for the response.
-
-7.8.1 Query format (login):
-
-The same as if the user has filled in the following HTML form:
-
-
-
-<html>
-<head>
-<title>SELECT Login</title>
-<meta http-equiv="Content-Type" content="text/html;
-charset=iso-8859-1">
-</head>
-<body bgcolor="#FFFFFF">
-<h1>SELECT Login </h1>
-<form method="get" action="http://www.dsv.su.se/~jpalme/">
-  <table border="0" cellpadding="5">
-    <tr>
-      <td>
-        <div align="right">Your e-mail address<br>or pseudonym:</div>
-      </td><td>
-        <input type="text" name="e-mail-address" size="50"
-maxlength="80">
-      </td>
-    </tr>
-    <tr>
-      <td>
-        <div align="right">Your password:</div>
-      </td><td>
-        <input type="password" name="password">
-      </td>
-    </tr>
-    <tr>
-      <td>&nbsp;</td>
-      <td>
-        <input type="submit" name="Submit" value="Login">&nbsp;
-        Response format:
-        <input type="radio" name="responseformat" value="html" checked>
-        HTML
-        <input type="radio" name="responseformat" value="xml">
-        XML
-      </td>
-    </tr>
-  </table>
-   </form>
-</body>
-</html>
-
-Example (login):
-
-Explanation                      Information sent
------------                      ----------------
-
-Connect to the SELECT server     GET /v1.0/general/id/login?e-mail-address=jp
-                                 alme@dsv.su.se&password=select  HTTP/1.1
-
-To the HTTP server "select" port Host: select
-80.
-
-Only files in the format         Accept: application/xml
-application/xml are accepted.
-
-
-
-7.8.2 Response format (login):
-
-Explanation                     Format of information sent
------------                     --------------------------
-                                (http://select/v1.0/login.dtd)
-
-Response to a login             <!ELEMENT login-response  EMPTY>
-
-If ok                           <!ATTLIST login-response
-Session-id for the newly          accepted (ok | wrong_password |unknown_user
-created session                             | failed) 'failed'
-Rater-id of the newly logged in   session-id CDATA #REQUIRED
-user                              rater-id   CDATA #REQUIRED
-
-End of XML attribute list       >
-
-Example (login response):
-
-Explanation             Information sent
------------             ----------------
-                        (http://select/v1.0/login-response.xml)
-
-HTTP header.            HTTP/1.1 200 OK
-                        Date: Sun, 25 Jul 1999 13:32:18 +0200
-                        Server: Apache/1.2.4
-                        Last-Modified: Sun, 25 Jul 1999 13:32:18 +0200
-                        ETag: "437e5-98-3531f2e3"
-                        Content-Length: 152
-                        Accept-Ranges: bytes
-                        Connection: close
-                        Content-Type: application/xml
-
-Set the cookie.         Set-cookie: session="1234567890123456";Domain="select
-                        ";Path="/v1.0/general/id/"
-
-A blank line to mark
-the end of the HTTP
-header.
-
-Identifies that this    <?xml version="1.0"?>
-is in XML format.
-
-References the          <!DOCTYPE login-response SYSTEM
-Resource Type           "http://select/v1.0/login-response.dtd">
-Declaration (DTD) file
-specifying the syntax
-for this XML resource.
-
-Start and end of        <login-response
-login-response for a       accepted="true"
-rejected login.            session-id="1234567890123456"
-                           rater-id = "jpalme"
-                        />
-
-
-7.9   Logout
-
-Summary: The logout operation removes the cookie, which gave the user
-privileges to perform certain commands in logged-in state.
-
-7.9.1 Query format (logout):
-
-The same as if a user clicks on an HTML link:
-
-<A HREF="http://select/v1.0/general/id/logout;">Log out</A>
-
-Example (logout):
-
-Explanation                           Information sent
------------                           ----------------
-                                      (http://select/v1.0logout-response.dtd)
-
-An ordinary HTTP connection.          GET /v1.0/general/id/logout;
-
-To the HTTP server "select" port 80.  Host: select
-
-Only files in the format              Accept: application/xml
-application/xml are accepted.
-
-This user has connected to this       Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-
-
-7.9.2 Response format (logout):
-
-Explanation                      Format of information sent
------------                      --------------------------
-                                 (http://select/v1.0/logout.dtd)
-
-The evaluation are returned, one <!ELEMENT logout-response  EMPTY>
-rating service at a time.
-
-Whether all the rating labels    <!ATTLIST logout-response
-were accepted, or some of them,    accepted (true | false) 'true'
-or none of them.
-
-You tried to logout, but you       not-logged-in (true | false) 'false'
-were not logged in.
-
-End of XML attribute list        >
-
-
-Example (logout response):
-
-Explanation                  Information sent
------------                  ----------------
-                             (http://select/v1.0/logout-response.xml)
-
-HTTP header                  HTTP/1.1 200 OK
-                             Date: Sun, 25 Jul 1999 13:32:18 +0200
-                             Server: Apache/1.2.4
-                             Last-Modified: Sun, 25 Jul 1999 13:32:18 +0200
-                             ETag: "437e5-98-3531f2e3"
-                             Content-Length: 152
-                             Accept-Ranges: bytes
-                             Connection: close
-                             Content-Type: application/xml
-
-Max-age="0" resets the       Set-cookie: session="1234567890123456";Domain="se
-cookie.                      lect";Path="/v1.0/general/id/";Max-age="0"
-
-A blank line to mark the
-end of the HTTP header.
-
-Identifies that this is in   <?xml version="1.0"?>
-XML format.
-
-References the Resource      <!DOCTYPE logout-response SYSTEM
-Type Declaration (DTD) file  "http://select/v1.0/logout-response.dtd">
-specifying the syntax for
-this XML resource.
-
-Start and end of             <logout-response accepted="false"/>
-login-response for a
-rejected login.
-
-
-7.10  Get-Atomic-Ratings
-
-Summary: The get-atomic-ratings operation retrieves atomic ratings done
-by one or more named raters on one or more resources. It can be used by
-a user agent to find out if this user has already rated this resource.
-It might also be used in peer rating, where person A wants to find
-items rated highly by named individuals B and C.
-
-Access control: The ratings made by a certain user can only be seen by
-that user, i.e. after logging in as that user. A person may however, in
-his/her personal profile, specify that other people can see his/her
-ratings. Get-atomic-ratings on a list of people may only be done in the
-following cases (i) all the people have specified in their profile that
-their ratings may be seen by other people, or (ii) the requestor is a
-certified filtering agent which will not divulge the personal ratings
-to a person, or (iii) the list of users is larger than ten, in this
-case, the atomic ratings are returned without identification of who
-made which rating.
-
-Input data: A URI for the rated resource, and a list of one or more
-people, whose atomic ratings on this resource are wanted.
-
-Output data: A list of atomic ratings, with or without identification
-of who made them, or an error code.
-
-Base protocol: XML.
-
-7.10.1      Query format (get-atomic-ratings):
-
-The get-atomic-ratings query is an HTTP POST operation, whose body is
-an XML resource containing the query, sent to
-http://select/v1.0/general/id/evaluator.
-
-Note: You must be logged in, to perform this operation, even if you
-only are going to retrieve anonymous ratings.
-
-Explanation                   Information sent
------------                   ----------------
-
-Connect to the SELECT server  POST /v1.0/general/id/get-ratings HTTP/1.1
-
-To the HTTP server "select"   Host: select
-port 80.
-
-Only files in the format      Accept: application/xml
-application/xml are
-accepted.
-
-The format of the query is    Content-Type: Application/xml
-XML.
-
-This user has connected to    Cookie: session="1234567890123456"
-this server before, and a
-cookie identifies the
-session.
-
-The body of the query is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is:
-
-Explanation                                 Format of information sent
------------                                 --------------------------
-                                            (http://select/v1.0/get-atomic-ra
-                                            tings.dtd)
-
-                                            <!ELEMENT get-atomic-ratings
-                                            (location+, rater+, labelname*)>
-
-Start of attribute list for                 <!ATTLIST get-atomic-ratings
-get-atomic-ratings.
-
-Restrict the retrieval to only ratings        context (general | business |
-done in a certain context.                    leisure | shopping | research |
-                                              politics | all) 'all'
-Whether only ratings made by this rater       whose-ratings ( own | all )
-(identified or pseudonymous) can be         'own'
-retrieved. Note: If you set this setting
-to "all" then you will get back ratings
-without identity or date on them.
-
-End of the list of XML attributes.          >
-
-Each URI to be evaluated is a free text     <!ELEMENT location EMPTY>
-field containing the URI of the resource
-to be evaluated.
-
-Start of attribute list for rater.          <!ATTLIST location
-
-Raterid or pseudonym. If Raterid is given,    uri CDATA #REQUIRED
-only ratings made non-anonymously for this
-user are returned, if pseudonym is given,
-only ratings made under this pseudonym are
-returned. Thus, raterid and pseudonym are
-treated as two different raters. One
-exception: A rater has access rights to
-retrieve own ratings made both anonymously
-and non-anonymously, but the rater must
-then list both raters in two "rater"
-elements in the request.
-
-Note: Possibly, processes with special
-privileges may be allowed to retrieve
-ratings made by different people and
-anonymous ratings?
-
-End of the list of XML attributes.          >
-
-Identify whose ratings are requested.       <!ELEMENT rater EMPTY>
-
-Start of attribute list for rater. Omitted  <!ATTLIST rater
-if you want all ratings, made by anyone,
-in un-identified format.
-
-Raterid or pseudonym or the fixed string      raterid CDATA #REQUIRED
-"anonymous" to retrieve anonymous ratings.
-If Raterid is given, only ratings made
-non-anonymously for this user are
-returned, if pseudonym is given, only
-ratings made under this pseudonym are
-returned. Thus, raterid and pseudonym are
-treated as two different raters. One
-exception: A rater has access rights to
-retrieve own ratings made both anonymously
-and non-anonymously, but the rater must
-then list both raters in two "rater"
-elements in the request.
-
-End of the list of XML attributes.          >
-
-List of requested rating descriptors. If    <!ELEMENT labelname EMPTY>
-no list is specified, this means that all
-available ratings are requested.
-
-Start of attribute list for rater.          <!ATTLIST labelname
-
-Raterid or pseudonym. If Raterid is given,    name CDATA #REQUIRED
-only ratings made non-anonymously for this
-user are returned, if pseudonym is given,
-only ratings made under this pseudonym are
-returned. Thus, raterid and pseudonym are
-treated as two different raters. One
-exception: A rater has access rights to
-retrieve own ratings made both anonymously
-and non-anonymously, but the rater must
-then list both raters in two "rater"
-elements in the request.
-
-To retrieve ratings made by other people
-in de-identified format, enter the name as
-the string "other".
-
-End of the list of XML attributes.          >
-
-Example of a body (get-atomic-ratings):
-
-Explanation             Information sent
------------             ----------------
-                        (http://select/v1.0/get-atomic-ratings.dtd)
-
-Start.                  <?xml version="1.0"?>
-                        <!DOCTYPE get-atomic-ratings SYSTEM
-                        "http://select/v1.0/get-atomic-ratings.dtd">
-                        <get-atomic-ratings context="leisure">
-
-List of locations, for  <location uri="http://www.body.com/toes"/>
-which ratings are       <location uri="http://www.face.com/eyes"/>
-retrieved.
-
-Raters, whose ratings   <rater raterid="jpalme@dsv.su.se"/>
-are requested.          <rater raterid="father.christmas@northpole.com"/>
-
-Which rating labels     <labelname name="select-reader-interest-rating"/>
-are requested.          <labelname name="keywords"/>
-
-End of                  </get-atomic-ratings>
-get-atomic-ratings.
-
-
-7.10.2      Response format (get-atomic-ratings-response):
-
-The response is an XML [XML1], [XML2] document. The XML Resource Type
-Declaration for this XML resource is:
-
-Explanation                      Format of information sent
------------                      --------------------------
-                                 (http://select/v1.0get-atomic-ratings-respon
-                                 se.dtd)
-
-Reference to data structure      <!ENTITY % atomic-rating SYSTEM
-defined in a separate DTD file.    "http://select/v1.0/atomic-rating.dtd">
-Further information, see section
-7.2.
-
-Import DTD from separate DTD     %atomic-rating;
-file atomic-rating.dtd.
-
-The evaluation are returned, one <!ELEMENT get-atomic-ratings-response
-rating service at a time.        (rejection+ | atomic-rating+)>
-
-If only some of the settings     <!ELEMENT rejection (#PCDATA)>
-were accepted, here is a list of
-those not accepted. The #PCDATA
-can contain a human-readable
-description of the refusal
-reason in the preferred language
-of the user doing the
-registration (not always the
-language of the user being
-registered).
-
-XML attributes for               <!ATTLIST rejection
-refuse-reason.
-
-Why the attribute was rejected.    refuse-reason (
-                                   authorisation | bad-syntax |
-                                   no-such-attribute | no-ratings-available |
-                                   not-logged-in | other-reason
-End of refuse-reason.              ) #REQUIRED
-
-Refused value of this attribute.   refused-value CDATA #IMPLIED
-
-End of XML attribute list.       >
-
-Example 1 (get-atomic-ratings-response):
-
-Note: This response is sent in the case where the ISCN server had no
-ratings for any of the resources requested, so that only ratings from
-the select general ratings server are returned.
-
-Explanation             Information sent
------------             ----------------
-
-HTTP response header    HTTP/1.1 200 OK
-                        Content-Length: 569
-                        Content-Type: application/xml
-                        Server: Select 1.0
-                        Date: 7 July 1999 19:58:23 +0200
-
-A blank line to
-indicate the end of
-the HTTP header
-
-Identifies that this    <?xml version="1.0"?>
-is in XML format.
-
-References the          <!DOCTYPE get-atomic-ratings-response SYSTEM
-Resource Type           "http://select/v1.0/get-atomic-ratings-response.dtd">
-Declaration (DTD) file
-specifying the syntax
-for this XML resource.
-
-Start of                <get-atomic-ratings-response>
-get-atomic-ratings-res
-ponse for one
-resource.
-
-First rating returned.  <atomic-rating
-                          raterid-or-pseudonym="jpalme@dsv.su.se"
-                          rating-engine="select/select-proxy-1"
-                          location="http://www.body.com/eyes"
-                          rating-date="31 Jul 1999"
-                          rater-competence="user"
-                          rater-type="manual"
-                          rater-trust="registered"
-                          message-id="990815113350*jpalme@dsv.su.se">
-
-First rating            <rating-value
-descriptor.               type="select-reader-interest-rating"
-                          value="good"/>
-
-Second rating           <rating-value
-descriptor.               type="adult"
-                          value="false"/>
-
-Third rating            <rating-value
-descriptor.               type="context"
-                          value="leisure"/>
-
-End of data.            </atomic-rating>
-
-Second rating           <atomic-rating
-returned.
-                        raterid-or-pseudonym="father.christmas@northpole.com"
-                          rating-engine="select/select-proxy-1"
-                          location="http://www.body.com/eyes"
-                          rating-date="17 Aug 1999"
-                          rater-competence="expert"
-                          rater-type="manual"
-                          rater-trust="registered"
-                          message-id="990815113350*jpalme@dsv.su.se">
-
-First rating            <rating-value
-descriptor.               type="select-reader-interest-rating"
-                          value="87"/>
-
-Second rating           <rating-value
-descriptor.               type="adult"
-                          value="false"/>
-
-Third rating            <rating-value
-descriptor.               type="context"
-                          value="leisure"/>
-
-End of data             </atomic-rating>
-                        </get-atomic-ratings-response>
-
-Example 2 (get-atomic-ratings-response rejection):
-
-Explanation                         Information sent
------------                         ----------------
-
-HTTP response header.               HTTP/1.1 200 OK
-                                    Content-Length: 569
-                                    Content-Type: application/xml
-                                    Server: Select 1.0
-                                    Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the end
-of the HTTP header.
-
-Identifies that this is in XML      <?xml version="1.0"?>
-format.
-
-References the Resource Type        <!DOCTYPE get-atomic-ratings-response
-Declaration (DTD) file specifying   SYSTEM
-the syntax for this XML resource.   "http://select/v1.0/get-atomic-ratings-res
-                                    ponse.dtd">
-Start of server list.               <get-atomic-ratings-response>
-
-Start of ratings for one resource   <rejection refuse-reason="not-logged-in"/>
-to be rated.
-
-End of evaluate-response report     </get-atomic-ratings-response>
-and end of file.
-
-
-7.11  Simple-Search Operation
-
-Issue: Should this really be in the standard? Is this not a user
-interface issue, since it is specified as an HTML search form below?
-
-Summary: Find web pages satisfying a query and which are highly rated.
-
-Access control: No access control for basic rating. Rating based on a
-particular users interest and values may be available only if preceded
-by a login operation for this particular user.
-
-Input data: The user specifies the query by filling in a query form.
-Simple search, when the personalised checkbox is unchecked, is always
-made on the general-rating derived descriptor. When the Personalized
-search checkbox is checked, the general-rating is made using a default
-personal-rating derived descriptor, which actually returns different
-values for each user. If the user is unknown, Personalized search will
-return an error message.
-
-Output data: A HTML page or an XML document with a list of found pages
-sorted according to rating and relevance.
-
-Base protocol: HTML application/x-www-form-urlencoded for the request,
-and HTML or XML for the response.
-
-7.11.1      Query format (simple-search-query):
-
-The simple-search query is an HTTP GET operation with the query after
-"?" in the URI.
-
-The query is the same as would be sent with the following HTML form:
-
-
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
-<HTML>
-<HEAD>
-<TITLE>SELECT Search Query</TITLE>
-<style type="text/css">
-<!--
-p {  font-family: Verdana, Arial, Helvetica, Geneva, sans-serif;
-font-size: 10pt}
-td {  font-family: Verdana, Arial, Helvetica, Geneva, sans-serif;
-font-size: 10pt}
--->
-</style></HEAD>
-<BODY bgcolor="#FFFFFF">
-<FORM ACTION="http://www.dsv.su.se/~jpalme/test/echo.cgi" METHOD=get
-NAME="searchform">
-  <table border="0" cellspacing="0" cellpadding="2" align="center">
-    <tr bgcolor="#6633CC" align="center">
-      <td rowspan=5 valign="top" width="121" align="center">
-        <div align="left"><font color='white'> Search: <br>
-          <input type="checkbox" name="search"
-                 value="internet" checked>
-          Internet <br>
-          <input type="checkbox" name="search" value="select"
-                 checked>
-          Select directory <br>
-          <input type="checkbox" name="search" value="news"
-                 checked>
-          News </font></div>
-        <font color='white'>
-        <hr width="70" align="left">
-        <div align="left">
-          <input type="checkbox" name="unseen" value="yes">
-          Only unseen</div>
-        </font></td>
-      <td colspan=5 rowspan="2"><font color='white'>
-          &nbsp; Search query:
-        <INPUT SIZE=54 MAXLENGTH=256 NAME="query" value="">
-        &nbsp;
-        <input type="submit" name="Search" value="Search">
-        </font></td>
-    </tr>
-    <tr bgcolor="#FFFFCC">
-      <td width="21"><font color="#FFFFFF"></font></td>
-    </tr>
-    <tr bgcolor="#CCFF99">
-      <td valign="top" width="163" align="center" > Limit to
-Country:<br>
-        <input type="text" name="textfield">
-      </td>
-      <td valign="top" width="122" > <b>Limit to Language:</b><br>
-        <select name="lang" size=1>
-          <option value="world" selected>Any
-          <option value="welsh">Cymraeg
-          <option value="dansk">Dansk
-          <option value="deutsch">Deutsch
-          <option value="english">English
-          <option value="espa&ntilde;ol">Espa&ntilde;ol
-          <option value="fran&ccedil;ais">Fran&ccedil;ais
-          <option value="italiano">Italiano
-          <option value="magyar">Magyar
-          <option value="nederlands">Nederlands
-          <option value="norsk">Norsk
-          <option value="portugu&ecirc;s">Portugu&ecirc;s
-          <option value="suomi">Suomi
-          <option value="svenska">Svenska
-        </select>
-      </td>
-      <td valign="top" width="109" >
-        <p align="center"> <b>Result format:</b><br>
-          <input type="radio" name="resultformat"
-                 value="html" checked>
-          HTML
-          <input type="radio" name="resultformat" value="xml">
-          XML </p>
-      </td>
-      <td valign="top" width="24">
-        <div align="right">
-          <input type="checkbox" name="personalized" value="yes">
-        </div>
-      </td>
-      <td valign="top" width="145" >
-        <p>Peer search</p>
-        <p><b>Max no of docs:</b>
-          <input type="text" name="maxno" size="4"
-                 maxlength="20" value="50">
-        </p>
-      </td>
-      <td width="21" bgcolor="#FFFFFF"> </td>
-    </tr>
-    <tr bgcolor="#FFFFCC">
-      <td valign="middle" colspan="5" align="center"> Context:
-        <input type="checkbox" name="context" value="yes" checked>
-        general
-        <input type="checkbox" name="business" value="yes" checked>
-        business
-        <input type="checkbox" name="leisure" value="yes" checked>
-        leisure
-        <input type="checkbox" name="shopping" value="yes" checked>
-        shopping
-        <input type="checkbox" name="research" value="yes" checked>
-        research
-        <input type="checkbox" name="politics" value="yes" checked>
-        politics<br>
-      </td>
-      <td width="21" rowspan="2"><font color="#FFFFFF"></font></td>
-    </tr>
-    <tr bgcolor="#FFFFCC">
-      <td valign="middle" colspan="5" align="center"
-          bgcolor="#6633CC"> <font color="#FFFFFF">
-        <input type="checkbox" name="Use my keywords"
-               value="Keyworduse" checked>
-        Use my interest profile&nbsp;&nbsp;
-        <input type="checkbox" name="usekeywords"
-               value="usemykeywords" checked>
-        &nbsp;Use my keywords&nbsp;&nbsp;
-        <input type="checkbox" name="onlymanual"
-               value="onlymanual">
-        &nbsp;Use only manual keywords and profile</font></td>
-    </tr>
-  </table>
-</FORM>
-</BODY></HTML>
-
-If the user check to "Use my interest profile" or "Use my keywords",
-then that user can, but need not fill in any "Search query". If the
-user does not fill in any "Search Query" but checks "Only unseen" and
-"Use my interest profile" or "Use my keywords", then this will be a
-search for highly-rated new, by this user unseen information. Note that
-by checking "News", a search for news articles is done and the result
-may be presented on the web, even though the rating of these web
-articles was done through a newsreader and not through a web interface.
-
-By "Peer search" is meant search, where higher value is given to
-ratings provided by people with similar interests and values as
-yourself.
-
-Example of query string:
-
-(filter OR "SELECT rating") AND EU&domain=world&language=world
-
-which with URI encoding will become:
-
-search=internet&search=select&search=news&query=%28filter+OR+%22SELECT+
-rating%22%29+AND+EU&Search=Search&textfield=&lang=world&resultformat=ht
-ml&context=yes&business=yes&leisure=yes&shopping=yes&research=yes&polit
-ics=yes
-
-Example of a simple-search query
-
-Query is sent to the following URL for the SELECT general service:
-
-http://select/v1.0/general/simple-search?query=
-
-Explanation             Information sent
------------             ----------------
-
-Connect to the SELECT   GET /v1.0/general/simple-search?search=internet&searc
-server                  h=select&search=news&query=%28filter+OR+%22SELECT+rat
-                        ing%22%29+AND+EU&Search=Search&textfield=&lang=world&
-"format" can be either  resultformat=html&context=yes&business=yes&leisure=ye
-"xml" or "html" and     s&shopping=yes&research=yes&politics=yes HTTP/1.1
-specifies in which
-format the response is
-to be delivered
-
-To the HTTP server      Host: select
-"select" port 80.
-
-Only files in the       Accept: application/xml
-format application/xml
-are accepted.
-
-This user has           Cookie: session="1234567890123456"
-connected to this
-server before, and a
-cookie identifies the
-session.
-
-
-
-7.11.2      Response format (simple-search-response):
-
-The simple-search response can be in either XML or HTML format
-depending on the request. If no format was specified in the request,
-HTML is the default format. The response contains a list of resources
-matching the query and sorted by rating-value. This standard only
-specifies the XML response format, the HTML response format is not
-standardized.
-
-The XML Resource Type Declaration for this XML resource is:
-
-Explanation                     Format of information sent
------------                     --------------------------
-                                (http://select/v1.0/simple-search-response.dt
-                                d)
-
-The evaluation are returned,    <!ELEMENT simple-search-response
-one rating service at a time.   (error | resource+)>
-
-                                <!ELEMENT error (#PCDATA)>
-
-                                <!ATTLIST error
-
-If rating was rejected,           refuse-reason ( bad-syntax |
-explanation why. See              access-control | other) 'access-control'
-
-Refusal reasons, chapter
-7.5.2.1.
-
-End of XML attribute list.      >
-
-If only some of the rating      <!ELEMENT resource (#PCDATA)>
-values were rejected, this
-element is used to list the
-rejected rating values. The
-#PCDATA contains the summary or
-keywords or some other
-description of the found
-resource.
-
-                                <!ATTLIST resource
-
-Some kind of computed rating      rating CDATA #REQUIRED
-value.
-
-                                  title CDATA #IMPLIED
-
-URI of the found resource.        uri CDATA #REQUIRED
-
-End of XML attribute list.      >
-
-
-Example 1 (positive simple-search response):
-
-Explanation                     Information sent
------------                     ----------------
-
-HTTP response header            HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE simple-search-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/simple-search-response.dt
-specifying the syntax for this  d">
-XML resource.
-
-                                <simple-search-response>
-
-                                <resource rating="88"
-                                  title="Kenyan flowers"
-                                  uri="http://www.flowers.com/kenya/">
-
-                                An overview of flowers found in Kenya.
-
-                                </resource>
-
-                                <resource rating="78"
-                                  title="Kiwi flowers"
-                                  uri="http://www.flowers.com/kiwi/">
-
-                                An overview of flowers found in Kiwi.
-
-                                </resource>
-
-                                </simple-search-response>
-
-Example 2 (negative simple-search response):
-
-Explanation                     Information sent
------------                     ----------------
-
-HTTP response header.           HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE simple-search-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/simple-search-response.dt
-specifying the syntax for this  d">
-XML resource.
-
-All ratings were not accepted.  <simple-search-response>
-
-Rating-label rejected, this     <error>You are not allowed to make this
-server does not accept ratings  search.</error>
-in the leisure context.
-
-End of simple-search-response.  </simple-search-response>
-
-
-
-7.12  Advanced-Search Operation (Not yet ready)
-
-Summary: Find web pages satisfying a query and which are highly rated.
-
-Access control: No access control for basic rating. Rating based on a
-particular users interest and values may be available only if preceded
-by a login operation for this particular user.
-
-Input data: Some general-purpose search format, based on SQL or some
-other search language. The advanced search should especially allow the
-needs of other modules.
-
-Required functionality:
-
-1.  It should be possible to search on all derived and
-    atomic ratings. Example of use: The NLP modules need
-    a way of getting a list of which documents are to be
-    rated by the NLP modules. Can this be done through a
-    variant of the advanced-search operation?
-
-2.  It should be possible to retrieve all ratings on
-    resources with a particular author, including ratings
-    with a particular author sent to a particular
-    newsgroup.
-
-Output data: A HTML page or an XML document with a list of found pages
-sorted according to rating and relevance.
-
-Base protocol: HTML application/x-www-form-urlencoded for the request,
-and HTML or XML for the response.
-
-
-7.12.1      Query format (advanced-search-query):
-
-The advanced-search query is an HTTP POST operation, whose body is an
-XML resource containing the profile, sent to the profiles cgi-script in
-the server for this particular rating service. Example:
-"http://select/v1.0/general/id/search".
-
-Explanation                         Information sent
------------                         ----------------
-
-Connect to the SELECT server        POST /v1.0/general/id/search HTTP/1.1
-
-To the HTTP server "select" port    Host: select
-80.
-
-Only files in the format            Accept: application/xml
-application/xml are accepted.
-
-The format of the query is XML.     Content-Type: Application/xml
-
-This user has connected to this     Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-
-The body of the operation is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is:
-
-Explanation             Format of information sent
------------             --------------------------
-                        (http://select/v1.0/advanced-search.dtd)
-
-Not yet ready
-
-Example of a advanced-search query
-
-Explanation             Format of information sent
------------             --------------------------
-                        (http://select/v1.0/advanced-search.dtd)
-HTTP header.            POST /v1.0/general/id/advanced-search  HTTP/1.1
-                        Host: select
-                        Accept: application/xml
-                        Content-Type: Application/xml
-                        Cookie: session="012345678901234354"
-
-A blank line to mark
-the end of the HTTP
-header.
-
-Identifies that this    <?xml version="1.0"?>
-is in XML format.
-
-References the          <!DOCTYPE advanced-search SYSTEM
-Resource Type            "http://select/v1.0/advanced-search.dtd">
-Declaration (DTD) file
-specifying the syntax
-for this XML resource.
-
-Not yet ready
-
-
-7.12.2      Response format (advanced-search-response):
-
-The response format for the advanced-search is the same as the response
-format for the simple search, described in section 0.
-
-
-7.13  Evaluate Operation
-
-Summary: Get the ratings for a list of URIs.
-
-Access control: No access control for basic rating. Rating based on a
-particular user's interest and values may be available only if preceded
-by a login operation for this particular user.
-
-Input data: A list of URIs and a list of services. For each service, a
-list of aggregate rating labels are listed. Note that only aggregate
-ratings, not atomic ratings, can be found with  this operation. If N
-URIs, M services and V label types are listed, then NxMxV rating labels
-are returned.
-
-Output data: A list of rating labels.
-
-Base protocol: HTTP and XML.
-
-Issue: Is a "streaming" version of this operation needed? By streaming
-is meant a version in which the URIs to process are sent to the server
-in parallel with the server returning responses, so that responses for
-the first URIs are returned before the last URIs have been sent to the
-server for evaluation.
-
-
-7.13.1      Query format (evaluate-query):
-
-The evaluate query is an HTTP POST operation, whose body is an XML
-resource containing the query, sent to
-http://select/v1.0/general/evaluator
-
-Explanation                        Information sent
------------                        ----------------
-
-Connect to the SELECT server.      POST /v1.0/general/evaluator  HTTP/1.1
-
-To the HTTP server "select" port   Host: select
-80.
-
-Only files in the format           Accept: application/xml
-application/xml are accepted.
-
-The format of the query is XML.    Content-Type: Application/xml
-
-This user has connected to this    Cookie: session="1234567890123456"
-server before, and a cookie
-identifies the session.
-
-
-The body of the query is an XML [XML1], [XML2] resource. The XML
-Resource Type Declaration for this XML resource is:
-
-Explanation                    Format of information sent
------------                    --------------------------
-                               (http://select/v1.0/evaluate-query.dtd)
-
-A list of locations to be      <!ELEMENT evaluate-query (location+,
-evaluated, followed by a list  service+)>
-of services to evaluate these
-locations. The returned
-response will be L x S rating
-labels, if L is the number of
-locations and S the number of
-services.
-
-Start of attribute list for    <!ATTLIST evaluate-query
-evaluate-query.
-
-Whether rating are to be         personal (true | false)'false'
-personalised by comparison to
-other people with similar
-views to myself.
-
-True means that the responses    sort (true | false)'true'
-are sorted in rating priority
-order. False means that the
-responses are returned in the
-order they were given in the
-request.
-
-Restrict the evaluation to       context (general | business | leisure
-only ratings done in a          shopping | research | politics | all) 'all'
-certain context.
-
-End of the list of XML         >
-attributes.
-
-Each URI to be evaluated is a  <!ELEMENT location (#PCDATA)>
-free text field containing
-the URI of the resource to be
-evaluated.
-
-Each service description is a  <!ELEMENT service (label* | collection-name)>
-free text field containing
-the URI of the service.
-
-Start of attribute list for    <!ATTLIST service
-service.
-
-Identification of the service    location CDATA #REQUIRED
-by its URI.
-
-End of the list of XML         >
-attributes.
-
-List of requested              <!ELEMENT label (#PCDATA)>
-descriptors. If no list is
-specified, this means that
-all available descriptors are
-requested. Only aggregate
-ratings can be requested, not
-atomic ratings.
-
-Start of attribute list for    <!ATTLIST label
-label.
-
-If match is true, then  all      match ( false | true ) 'false'
-labels whose name begin with
-the given string are
-retrieved. For example, with
-match=true and the label
-value "keywords", labels of
-derived descriptors like
-"keywords-tropical" and
-"keywords-flowers" might be
-retrieved.
-
-End of the list of XML         >
-attributes.
-
-Instead of listing the labels  <!ELEMENT collection-name EMPTY>
-to be retrieved, it is
-possible to just specify the
-name of a collection, to
-retrieve the labels specified
-in this collection.. The
-collection must be a
-collection specified in the
-service-description of the
-service used.
-
-                               <!ATTLIST collection-name
-                                 name CDATA #REQUIRED >
-
-Example of a body (evaluate-query):
-
-Explanation             Information sent
------------             ----------------
-                        (http://select/v1.0/evaluate-query.xml)
-
-Start.                  <?xml version="1.0"?>
-                        <!DOCTYPE evaluate-query SYSTEM
-                        "http://select/v1.0/evaluate-query.dtd">
-                        <evaluate-query>
-
-List of locations to    <location>http://www.body.com/toes</location>
-be evaluated.           <location>http://www.face.com/eyes</location>
-
-List of services whose  <service
-evaluations are
-requested. For each     location="http://select/v1.0/general/general-service-
-service, the            description.xml">
-descriptors requested   <label>select-reader-quality-rating</label>
-are listed. For the     <label>select-reader-interest-rating</label>
-general service,        <label match="true">keywords</label>
-reader-quality and      </service>
-reader-interest-rating  <service
-s are requested, for
-the iscn service, all   location="http://select/v1.0/general/iscn-service-des
-available descriptors   cription.xml"
-are requested.          />
-                        <service
-
-                        location="http://select/v1.0/general/flower-lovers-se
-                        rvice-description.xml">
-                        <collection-name name="instant-ratings"/>
-                        </service>
-
-End of evaluate-query.  </evaluate-query>
-
-
-7.13.2      Response format (evaluate-response):
-
-The response is an XML [XML1], [XML2] document. The XML Resource Type
-Declaration for this XML resource is:
-
-Explanation                  Format of information sent
------------                  --------------------------
-                             (http://select/v1.0/evaluate-response.dtd)
-
-The evaluation are           <!ELEMENT evaluate-response (rejection |
-returned, one rating         resource+)>
-service at a time.
-
-Start of list of attributes  <!ATTLIST evaluate-response
-for the evaluate-service
-element.
-
-URI of the service, only       service CDATA #IMPLIED
-used if all ratings
-returned are from the same
-service.
-
-Whether rating are to be       personal (true | false) 'false'
-personalised by comparison
-to other people with
-similar views to myself.
-
-True means that the            sort (true | false) 'true'
-responses are sorted in
-rating priority order.
-False means that the
-responses are returned in
-the order they were given
-in the request.
-
-End of the list of XML       >
-attributes.
-
-                             <!ELEMENT rejection EMPTY>
-                             <!ATTLIST rejection
-Reject reason, no default      reject-reason ( not-logged-in | bad-syntax |
-value.                         not-found | authorisation-failure |
-                             other-reason )
-                               #IMPLIED
-End of XML attributes for    >
-"rejection".
-
-                             <!ELEMENT resource (label*)>
-
-URI of the rated resource.   <!ATTLIST resource
-                               location CDATA #REQUIRED
-
-End of XML attributes for    >
-"resource".
-
-Start of a ratings label.    <!ELEMENT label EMPTY>
-Note: If no label is
-available, then no labels
-are specified.
-
-Start of attribute list for  <!ATTLIST label
-label.
-
-URI of the service             service CDATA #IMPLIED
-providing this label.
-This attribute may be
-omitted in the following
-two cases:
-
-(a) if all ratings come
-from the same service, and
-this service was specified
-as an attribute to the
-evaluate-response.
-
-(b) in a series of labels
-from the same service on
-the same resource, only the
-first need specify the
-service.
-
-Default descriptor format      format (numerical | words | text | date)
-is numerical. Alternative    'numerical'
-descriptors are words (list
-of keywords etc.) or text
-(any plain UTS-8 text) or
-date (in mail header
-format, for example "29 Jul
-1999".
-
-Name of a descriptor,          name CDATA #REQUIRED
-either its transmit-as or
-short-form name, as
-specified in the rating
-service description for the
-rating service used.
-
-The format of the value        value CDATA #REQUIRED
-depends on the type, as
-specified in the rating
-service description.
-
-The confidence (number of      confidence CDATA #IMPLIED
-evaluators) behind this
-value.
-
-This rating value is only      context ( general | business | leisure |
-valid in a certain context.    shopping | research | politics | all )'all'
-
-End of attribute list.       >
-
-
-Example 1 (evaluate response):
-
-Note: This response is sent in the case where the ISCN server had no
-ratings for any of the resources requested, so that only ratings from
-the select general ratings server are returned.
-
-Explanation                     Information sent
------------                     ----------------
-
-HTTP response header            HTTP/1.1 200 OK
-                                Content-Length: 569
-                                Content-Type: application/xml
-                                Server: Select 1.0
-                                Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the
-end of the HTTP header.
-
-Identifies that this is in XML  <?xml version="1.0"?>
-format.
-
-References the Resource Type    <!DOCTYPE evaluate-response SYSTEM
-Declaration (DTD) file          "http://select/v1.0/evaluate-response.dtd">
-specifying the syntax for this
-XML resource.
-
-Start of evaluate-response for  <evaluate-response>
-one resource.
-
-Start of ratings for one        <resource
-resource to be rated.           location="http://www.body.com/toes">
-
-One rating descriptor value for <label
-this resource.
-
-                                service="http://select/v1.0/general/general-s
-                                ervice-description.xml"
-Confidence of this value.         confidence="12"
-
-Type of label value.              format="numerical"
-
-Name of this label (either        name="select-reader-quality-rating"
-transmit-as or short-name).
-
-Value of this descriptor.         value="88"
-
-Restricted context of this        context="leisure"
-rating value.
-
-End of this label.              />
-
-Another rating descriptor       <label
-value.
-
-Confidence of this label.         confidence="57"
-
-Type of label value.              format="numerical"
-
-A derived attribute containing    name="keywords-tropical"
-a frequency count.
-
-Number of people who have         value="3"
-assigned the keyword "tropical"
-to this resource.
-
-Restricted context of this        context="leisure"
-rating value.
-
-End of this label.              />
-
-Another rating descriptor       <label
-value.
-
-Confidence of this label.         confidence="33"
-
-Type of label value.              format="numerical"
-
-Name of this label (either        name="select-reader-interest-rating"
-transmit-as or short-name).
-
-Value of this label.              value="78"
-
-Restricted context of this        context="leisure"
-rating value.
-
-End of this label.              />
-
-One rating descriptor value for <label
-this resource.
-
-                                service="http://select/v1.0/general/iscn-serv
-                                ice-description.xml"
-
-Type of label value.              format="numerical"
-
-Confidence of this value.         confidence="12"
-
-Name of this label (either        name="scientific-relevance"
-transmit-as or short-name).
-
-Value of this descriptor.         value="88"
-
-Restricted context of this        context="research"
-rating value.
-
-End of this label.              />
-
-End of list of all labels for   </resource>
-this resource.
-
-Start of ratings for one        <resource
-resource to be rated.           location="http://www.body.com/toes">
-
-One rating descriptor value.    <label
-
-                                service="http://select/v1.0/general/general-s
-                                ervice-description.xml"
-
-Confidence of this label.         confidence="55"
-
-Type of label value.              format="numerical"
-
-Name of this label (either        name="select-reader-quality-rating"
-transmit-as or short-name)
-Value of this label.              value="88"
-
-End of this label.              />
-
-One rating descriptor value.    <label
-
-Confidence of this label.         confidence="33"
-
-Default descriptor format is      format="numerical"
-numerical. Alternative
-descriptors are words (list of
-keywords etc.) or text (any
-plain UTS-8 text) or date (in
-mail header format, for example
-"29 Jul 1999".
-
-Name of this label (either        name="select-reader-interest-rating"
-transmit-as or short-name).
-
-Value of this label.              value="78"
-
-End of this label.              />
-
-End of list of all labels for   </resource>
-this resource.
-
-End of evaluate-response report </evaluate-response>
-and end of file.
-
-
-Example 2 (evaluate response rejection):
-
-Explanation                         Information sent
------------                         ----------------
-
-HTTP response header.               HTTP/1.1 200 OK
-                                    Content-Length: 569
-                                    Content-Type: application/xml
-                                    Server: Select 1.0
-                                    Date: 7 July 1999 19:58:23 +0200
-
-A blank line to indicate the end
-of the HTTP header.
-
-Identifies that this is in XML      <?xml version="1.0"?>
-format.
-
-References the Resource Type        <!DOCTYPE evaluate-response SYSTEM
-Declaration (DTD) file specifying   "http://select/v1.0/evaluate-response.dtd"
-the syntax for this XML resource.   >
-
-Start of server list.               <evaluate-response>
-
-Start of ratings for one resource   <rejection reject-reason="not-logged-in"/>
-to be rated.
-
-End of evaluate-response report     </evaluate-response>
-and end of file.
-
-
-
-7.14  Exchange-Ratings-Data (not yet ready)
-
-Summary: This operation is used between two select servers, in order to
-replicate information in their data bases.
-
-Issues:
-
-Access control:
-
-Input data:
-
-Output data:
-
-Base protocol:
-
-
-7.14.1      Query format (exchange-ratings-data):
-
-Example (replicate-ratings):
-
-Explanation                    Information sent
------------                    ----------------
-
-Not ready
-
-
-7.14.2      Response format (exchange-ratings-data):
-
-Explanation             Format of information sent
------------             --------------------------
-                        (http://select/v1.0/exchange-ratings-data.dtd)
-
-Not ready
-Example (replicate-ratings response):
-
-Explanation             Information sent
------------             ----------------
-
-Not ready
-
-8.    The SELECT general service description
-
-A SELECT general service description file contains
-
--  A list of services
--  Per service
--  Admistrative information about the service accessible on the
-   server
--  Name
--  Maintainer
--  Website about the service
--  Textual description in natural language (possible in multiple
-   languages)
--  A list of categories
--  Per category
--  A textual description of the category (possible in multiple
-   languages)
--  A name for the category
--  Rater type (human or computer generated rating)
--  The datatype of the ratings for this category (a label,
-   keyword, value or derived category)
--  Depending on the datatype
--  Value:
-   How the category should be displayed on screen ("none" if not
-   possible)
-   The calculationmethod used to calculate the instant rating
-   value of a resource for this category
-   A minimum and maximum value for the rating values in this
-   category
--  Label :
-   How the category should be displayed on screen ("none" if
-   not possible)
-   The calculationmethod used to calculate the instant rating
-   value of a resource for this category
-   A list of labels for the category. Per Label
--  A value that corresponds to the description contained in the
-   textual or iconic labels.
--  A list of Textual and/or Iconic labels (possible in multiple
-   languages)
--  Derived:
-   The calculationmethod used to calculate the instant rating
-   value of a resource for this category
-   A number of categories from which the value of an instant
-   rating of this category is derived.
-   A list of labels that describe how to map the value of an
-   instant rating of this category back to natural language.
-   Per label
--  A minumum and maximum value. If the rating falls between these
-   2 values, the associated textual label is selected.
--  Keyword:
-   The calculationmethod used to calculate the instant rating
-   value of a resource for this category
--  A list of imported categories : categories of other services
-   that are imported into this service
--  The classname of the Java class that starts the agents
-   associated with the service.
-
-All this translates to the XML document type definition looks like
-this:
-
-<?xml version="1.0" encoding="UTF-8" ?>
-<!ELEMENT services (service*)>
-<!ELEMENT description EMPTY>
-<!ATTLIST description
-   language CDATA #REQUIRED
-   text     CDATA #REQUIRED
->
-<!ELEMENT import EMPTY>
-<!ATTLIST import
-   service  CDATA #REQUIRED
-   category CDATA #REQUIRED
->
-<!ELEMENT service (description+, category+, import*, agentinit?)>
-<!ATTLIST service
-   id          CDATA #REQUIRED
-   URI         CDATA #REQUIRED
-   server      CDATA #REQUIRED
-   maintainer  CDATA #REQUIRED
-   anonymous   (allowed | forbidden) 'allowed'
->
-<!ELEMENT agentinit EMPTY>
-<!ATTLIST agentinit
-  classname CDATA #REQUIRED
->
-<!ELEMENT category (description+, (labelcategory | valuecategory |
-keywordcategory | derivedcategory))>
-<!ATTLIST category
-   id         CDATA #REQUIRED
-   rater-type (human | computer) 'computer'
-   type       (label | value | keyword | derived) 'label'
->
-<!ELEMENT labelcategory (label+)>
-<!ATTLIST labelcategory
-   gui         (buttons | radiobuttons | list | icons | none) 'none'
-   calculation CDATA #REQUIRED
->
-<!ELEMENT label (description*, icon*)>
-<!ATTLIST label
-   value  CDATA #REQUIRED
->
-<!ELEMENT icon EMPTY>
-<!ATTLIST icon
-   language CDATA #REQUIRED
-   text     CDATA #REQUIRED
->
-<!ELEMENT valuecategory EMPTY>
-<!ATTLIST valuecategory
-   gui         (slider | buttons | none) 'none'
-   min         CDATA #IMPLIED
-   max         CDATA #IMPLIED
-   upperlimit  (yes | no) 'no'
-   calculation CDATA #REQUIRED
->
-<!ELEMENT keywordcategory EMPTY>
-<!ATTLIST keywordcategory
-   calculation CDATA #REQUIRED
->
-<!ELEMENT derivedcategory (derivedfrom+, derivedlabel*)>
-<!ATTLIST derivedcategory
-   calculation CDATA #REQUIRED
->
-<!ELEMENT derivedfrom EMPTY>
-<!ATTLIST derivedfrom
-   service    CDATA #REQUIRED
-   category   CDATA #REQUIRED
->
-<!ELEMENT derivedlabel (description*)>
-<!ATTLIST label
-   min  CDATA #REQUIRED
-   max  CDATA #REQUIRED
->
-
-
-8.1   Example
-
-An example of all this is the service description file of the SELECT
-test server:
-
-<?xml version="1.0"?>
-<!DOCTYPE services SYSTEM "services.dtd">
-<services>
-  <!-- The SELECT test service -->
-  <!-- *********************** -->
-  <service
-     id         = "test"
-     URI        = "http://samson.aszi.sztaki.hu/SELECT"
-     server     = "samson.aszi.sztaki.hu"
-     maintainer = "micsik@sztaki.hu"
-     anonymous  = "allowed">
-     <description language = "en" text = "SELECT test service">
-     </description>
-     <description language = "nl" text = "SELECT test dienst">
-     </description>
-     <!-- Quality of the document according to the user -->
-     <category
-        id         = "contents"
-        rater-type = "human"
-        type       = "label">
-        <description language = "en"
-        text = "Quality of the content of the document">
-       </description>
-        <description language = "nl"
-        text = "Kwaliteit van de inhoud van het document">
-       </description>
-        <labelcategory
-           gui         = "buttons"
-           calculation = "average">
-           <label value = "1">
-              <description language = "en"
-              text = "Awful"></description>
-              <description language = "nl" text = "Verschikkelijk">
-              </description>
-              <icon        language = "en" text =
-              "http://samson.aszi.s ztaki.hu/SELECT/icons/1star.gif">
-             </icon>
-           </label>
-           <label value = "2">
-              <description language = "en"
-              text = "Mediocre"></description>
-              <description language = "nl"
-              text = "Middelmatig">
-              </description>
-              <icon        language = "en" text =
-              "http://samson.aszi.sztaki.hu/SELECT/icons/2star.gif">
-             </icon>
-           </label>
-           <label value = "3">
-              <description language = "en" text = "OK"></description>
-              <description language = "nl" text = "OK"></description>
-              <icon        language = "en" text =
-              "http://samson.aszi.sztaki.hu/SELECT/icons/3star.gif">
-             </icon>
-           </label>
-           <label value = "4">
-              <description language = "en" text = "Good"></description>
-              <description language = "nl" text = "Goed"></description>
-              <icon        language = "en" text =
-              "http://samson.aszi.sztaki.hu/SELECT/icons/4star.gif">
-             </icon>
-           </label>
-           <label value = "5">
-              <description language = "en" text = "Great">
-             </description>
-              <description language = "nl" text = "Geweldig">
-             </description>
-              <icon        language = "en" text =
-             "http://samson.aszi.sztaki.hu/SELECT/icons/5star.gif">
-             </icon>
-           </label>
-        </labelcategory>
-     </category>
-     <!-- Style of the document according to NLP -->
-     <category
-        id         = "style"
-        rater-type = "computer"
-        type       = "value">
-        <description language = "en" text =
-        "The quality of the document according to the NLP modules">
-        </description>
-        <description language = "nl" text =
-        "De kwaliteit van het document volgen de NLP modules">
-        </description>
-        <valuecategory
-            gui         = "none"
-            min         = "0"
-            max         = "10"
-            upperlimit  = "yes"
-            calculation = "NLP"/>
-     </category>
-     <!-- Time spent reading the document -->
-     <category
-        id         = "readtime"
-        rater-type = "computer"
-        type       = "value">
-        <description language = "en" text =
-        "The time spent reading this document in seconds">
-        </description>
-        <description language = "nl" text =
-        "De tijd waarin het document gelezen werd in seconden">
-        </description>
-        <valuecategory
-           gui         = "none"
-           min         = "0"
-           max         = "600"
-           upperlimit  = "no"
-           calculation = "median"/>
-     </category>
-     <!-- Human added keywords -->
-     <category
-        id         = "keywords"
-        rater-type = "human"
-        type       = "keyword">
-        <description language = "en"
-        text = "Human added keywords"></description>
-        <description language = "nl"
-        text = "Kernwoorden die door de gebruiker werden toegevoegd">
-        </description>
-        <keywordcategory
-           calculation = "count"/>
-     </category>
-     <!-- Overall quality of the document -->
-     <category
-        id         = "quality"
-        rater-type = "computer"
-        type       = "derived">
-        <description language = "en"
-        text = "Overall quality of the document"></description>
-        <description language = "nl" text =
-       "Algemene kwaliteit van het document"></description>
-        <derivedcategory
-           calculation = "statistics">
-           <derivedfrom service = "test" category = "contents"/>
-           <derivedfrom service = "test" category = "style"/>
-           <derivedlabel min = "0" max = "1">
-              <description language = "en"
-              text = "Awful"></description>
-              <description language = "nl"
-              text = "Verschrikkelijk"></description>
-           </derivedlabel>
-           <derivedlabel min = "1" max = "2">
-              <description language = "en"
-              text = "Mediocre"></description>
-              <description language = "nl"
-              text = "Middelmatig"></description>
-           </derivedlabel>
-           <derivedlabel min = "2" max = "3">
-              <description language = "en" text = "OK"></description>
-              <description language = "nl" text = "OK"></description>
-           </derivedlabel>
-           <derivedlabel min = "3" max = "4">
-              <description language = "en" text = "Good"></description>
-              <description language = "nl" text = "Goed"></description>
-           </derivedlabel>
-           <derivedlabel min = "4" max = "5">
-              <description language = "en"
-              text = "Great"></description>
-              <description language = "nl"
-              text = "Geweldig"></description>
-           </derivedlabel>
-        </derivedcategory>
-     </category>
-     <!-- The Java class that will start the Agents associated
-     with the service -->
-     <agentinit classname = "select.agent.test.TestInit">
-     </agentinit>
-  </service>
-  <!-- The ISCN test service -->
-  <!-- ************************* -->
-  <service
-     id         = "iscn"
-     URI        = "http://www.iscn.com/"
-     server     = "samson.aszi.sztaki.hu"
-     maintainer = "micsik@sztaki.hu"
-     anonymous  = "allowed">
-     <description language = "en" text = "ISCN test
-service"></description>
-     <!-- A simple category -->
-     <category
-        id         = "contents"
-        rater-type = "human"
-        type       = "value">
-        <description language = "en" text = "Example
-category"></description>
-        <valuecategory
-            gui         = "slider"
-            format      = "integer"
-            min         = "1"
-            max         = "5"
-            calculation = "mean"/>
-     </category>
-     <!-- Imported categories -->
-     <import service = "test" category = "quality"/>
-  </service>
-</services>
-
-
-9.    Example of file structure on a SELECT server
-
-Here is an example of a file structure for a SELECT server:
-
-URL                                         Content
----                                         -------
-
-http://select/v1.0/                         Repository of XML format
-                                            specifications (DTDs)
-                                            for SELECT version 1.
-
-http://select/v1.0/services.dtd             XML  format the list of
-                                            services.
-
-http://select/v1.0/service.dtd              XML format for the
-                                            description of one
-                                            SELECT service.
-
-http://select/v1.0/send-rating.dtd          XML format  for the
-                                            send-rating operation.
-
-http://select/v1.0/send-rating-response.dt  XML format for the
-d                                           responses of the
-                                            send-rating operation.
-
-http://select/v1.0/evaluate-query.dtd       XML format for the
-                                            evaluate query request.
-
-http://select/v1.0/evaluate-response.dtd    XML format for the
-                                            response of the evaluate
-                                            operation.
-
-http://select/v1.0/select-service-descript  List of SELECT services
-ions.xml                                    in version 1 of SELECT,
-                                            see 0
-                                            The SELECT general
-                                            service description on
-                                            page 73.
-
-http://select/v1.0/general/                 Version 1 of the select
-                                            general service.
-
-http://select/v1.0/general/common-service-  Description of common
-description.xml                             descriptors to several
-                                            SELECT services.
-
-http://select/v1.0/general/general-service  Description of the
--description.xml                            general SELECT service.
-                                            The general service is
-                                            for everyone, not for
-                                            specialised groups.
-
-http://select/v1.0/general/id/input-rating  Entry point for incoming
-s                                           non-anonymous
-                                            (registered or
-                                            pseudonymous) ratings to
-                                            the select general
-                                            service.
-
-http://select/v1.0/general/ano/input-ratin  Entry point for incoming
-gs                                          anonymous ratings to the
-                                            select general service.
-
-http://select/v1.0/general/search?query=    Entry point for the
-                                            web-based search
-                                            operation.
-
-http://select/v1.0/general/evaluator        Entry point for the
-                                            evaluate operation.
-
-http://select/v1.0/iscn/                    Version 1 of the select
-                                            ISCN service.
-
-http://select/v1.0/iscn/iscn-service-descr  Description of the
-iption.xml                                  special SELECT service
-                                            for ISCN.
-
-
-10.   Issues for further study
-
-These issues are items which are not needed for the base system
-implementations, and which may be modified by experience from the first
-implementation efforts.
-
-  1.    The Advanced Search facility should be specified, based on query
-       by example, SQL or some other standard query language methodology.
-
-  2.    The format of the personal interest profile, and keywords is not
-       ready. In particular, should there be a split between profile set by
-       the user him/herself and set by automatic methods, such as ML
-       algorithms on the user's rating and behaviour. Also, to what extent
-       should this profile be specified in a formal, logical language, like
-       "If newsgroup is alt.culture.sweden then do not filter away anything",
-       etc. In the first implementations, we will just use a simple set of
-       unordered keywords as the personal profile.
-
-  3.    Is security enough? Do we need more security features? If so,
-       which and how?
-
-  4.    Is there a need for NNTP versions of some or all of the
-       operations?
-
-  5.    Is a streaming version needed for the evaluate operation?
-
-  6.    Privacy and security issues for Get-Atomic-Ratings.
-
-  7.    Is more needed for ML support?
-
-  8.    Is more needed for NLP support?
-
-  9.    Exchange-Ratings-Data not ready. No great priority.
-
-  10.   Set-Service-Description not ready. No great priority. Can be done
-       using local or web-based interface.
-
-  11.   Is more needed for thesauri support?
-
-  12.   Should the SELECT protocols be based on SOAP in order to base it
-       on something existing? SOAP is described at
-       http://msdn.microsoft.com/xml/general/soap_white_paper.asp (quick
-       intrduction), and http://www.develop.com/soap/ (useful links).
-
-
-11.   The SELECT Agent protocol
-
-The advanced SELECT platform now supports an agent architecture that
-makes it easy to integrate collaborative or information filtering
-algorithms. The agents can run in the Select server or on a client
-machine over the Network and can perform tasks as maintaining
-datastructures that can speed-up collaborative filtering algorithms,
-perform collaborative filtering, notifying other agents of a change in
-the Select database or using machine learning at the client to derive
-useful user-profile information. The agents can communicate with one
-another and with the Select server using an extension of the original
-XML Select protocol. They can request certain services to be executed
-or can send a notification about the occurrence of a certain event.
-
-The introduction of agent means that the protocol had to be extended to
-support this. This appendix gives an overview of the necessary
-extensions.
-
-
-11.1.1      Entry points
-
-Following new entry points in the Select server have been made:
-
-Entry                              Function
------                              --------
-
-/agent/register-agent.xml          Register an agent with the AgentList
-/agent/deregister-agent.xml        Deregister an agent with the
-                                   AgentList
-/agent/list-agents.xml             Request a remote AgentList
-
-In addition to this, every remote agent and the server have the
-following entry points:
-
-Entry                            Function
------                            --------
-
-/agent/request/"name"            Request an agent a service
-                                 "name" is the name of the agent
-/agent/notify/"name"             Notify an agent of an event.
-                                 "name" is the name of the agent
-
-
-11.1.2      XML Extensions
-
-This is an overview of the new XML document type definitions.
-Registering an agent with the server-side AgentList.
-
-              Register Agent Request (register-agent.dtd)
-
-
-<!ELEMENT register-agent (notification*)>
-                                           name of the agent
-<!ATTLIST register-agent                   network location for
-                                           notifications and requests
-    id            CDATA #REQUIRED          description of the request
-                                           parameters (not used)
-    URL           CDATA #REQUIRED
-                                           name of the notification
-    parameters    CDATA #REQUIRED          type of notification
-
->                                          depends on the type e.g. if
-                                           type is
-<!ELEMENT notification EMPTY>              "update-in-category" it's a
-                                           string of format
-<!ATTLIST notification                     "service,category". If type
-                                           is "changing-profile" it's
-    id        CDATA #REQUIRED              the raterid of the user
-                                           whose profile is monitored
-    type      (new-rate-in-category |
-new-rate-by-user | changing-profile |
-update-in-category | alarm ) 'alarm'
-
-    typedata  CDATA #REQUIRED
-
->
-
-            Register Agent Reply (register-agent-reply.dtd)
-
-<!ELEMENT register-agent-reply EMPTY>
-                                           Positive or negative
-<!ATTLIST register-agent-reply             outcome of the register
-                                           operation
-    ok (yes | no) 'no'
-
->
-
-Deregister an agent with the server-side AgentList
-
-            Deregister Agent Request (deregister-agent.dtd)
-
-
-<!ELEMENT deregister-agent EMPTY>
-                                           Name of the agent to
-<!ATTLIST deregister-agent                 deregister
-
-    id CDATA #REQUIRED
-
->
-
-          Deregister Agent Reply (deregister-agent-reply.dtd)
-
-<!ELEMENT deregister-agent-reply EMPTY>
-                                           Possible or negative
-<!ATTLIST deregister-agent-reply           outcome of the deregister
-                                           operation
-    ok (yes | no) 'no'
-
->
-
-
-Get a remote AgentList for use in a remote agent
-             List Agents Request (list-agents-request.dtd)
-
-<!ELEMENT list-agents-request (session+)>  A list of one or more
-                                           session identifiers
-<!ELEMENT session EMPTY>
-
-<!ATTLIST session                          Identifier of a session
-
-    id CDATA #REQUIRED
-
->
-
-                  List Agents Reply (list-agents.dtd)
-
-<!ELEMENT list-agents (agent*)>            A list of data for one or
-                                           more agents
-<!ELEMENT agent EMPTY>
-
-<!ATTLIST agent
-                                           name of the agent
-    id           CDATA #REQUIRED           network location
-
-    URL          CDATA #REQUIRED           description of the request
-                                           parameters (not used)
-    parameters   CDATA #REQUIRED
-                                           session-id of the owner of
-    session-id   CDATA #REQUIRED           the agent
-
->
-Notify a remote agent of the occurrence of a certain event
-
-                Notify Agent Request (notify-agent.dtd)
-
-<!ELEMENT notify-agent EMPTY>
-
-                                           name of the agent
-<!ATTLIST notify-agent
-                                           name of the notification
-    agent-id  CDATA #REQUIRED
-                                           data of the notification
-    notify-id CDATA #REQUIRED              (depends on type)
-
-    data      CDATA #REQUIRED
-
->
-Request an agent for some service
-
-                   Agent Request (agent-request.dtd)
-
-<!ELEMENT agent-request EMPTY>
-                                           name of the agent
-<!ATTLIST agent-request
-                                           request string (depends on
-    id           CDATA #REQUIRED           type of agent)
-
-    request      CDATA #REQUIRED           request parameters (depends
-                                           on type of agent)
-    parameters   CDATA #REQUIRED
-                                           e.g. request    =
->                                          "get-n-closest-neighbors"
-
-                                                parameters = "raterid"
-
-                     Agent Reply (agent-reply.dtd)
-
-<!ELEMENT agent-reply EMPTY>
-                                           Agent request was
-<!ATTLIST agent-reply                      successful or not
-
-    ok   (yes | no) 'no'                   if ok is "yes" then data
-                                           contains the requested data
-    data CDATA #REQUIRED                   (depends on type of agent)
-
->
-
-
-
-
-11.1.3      Privacy and security policy for agents
-
-When dealing with an architecture where agents can run on the Select
-server or client machines and can communicate and request services of
-one another, it is necessary to have a system in place that limits the
-access to the agents in order to avoid abuse of machine resources
-(server or client) or the exposure of personal profile or other
-database information to unauthorized persons.
-
-First of all, remote agents can only be registered and controlled by
-users that are registered with the Select Server. The user first logs
-in and receives a session-id. This ID is associated with every agent
-the user registers with the AgentList. It's used for authentication in
-a number of cases:
-
--  A remote agent only accepts requests if the requesting agent
-   knows this agent's session id.
-
--  When a remote agent requests a remote AgentList, it must include
-   the session-id(s) of the agents it wants access to. This way, the
-   server only returns information about agents for which the remote
-   agent has proven it's authority of access.
-
-Local agents can be "private" or "public". Private local agents do not
-accept requests from remote agents, only from other local agents.
-Public local agents can accept requests from remote agents. Both local
-agent types can themselves request information from remote agents.
-
--  A public local agent only accepts request when the session-id
-   associated with the request is present in the server. This means
-   that the session that created the agent has not ended yet.
-
-
-12.   Protocol Implemtation Status
-
-Here we provide an overview of the implementation status of the SELECT
-protocol as done by the SELECT EU project.
-
-Get-Service-Description-List
-
-Compelety implemented
-
-Get-Service-Description
-
-Completely implemented
-
-Send-Rating
-
-Completely implemented exept for the
-
-rater-competence
-rater-trust
-message-id
-
-fields of the rating. These are not used anywhere.
-
-Set-Profile
-
-Implemented except for
-
--  The pseudonymous related thing. Pseudonyms are never used in the
-   present system.
-
--  Multiple profiles per user. Every user has 1 profile for all the
-   services, it contains its unique data (name, password,...,languages
-   spoken, reward account) and some data for the SELECT test service
-   filtering algorithms (keywords,...)
-
--  The reward account that is never used.
-
--  A profile must always be replaced as a whole. Single fields
-   cannot be changed separately.
-
-Get-Profile
-
-Completely implemented.
-
-Login & Logout
-
-Completely implemented?
-
-Get Atomic Ratings
-
-Implemented except the only the first combination of rater/URL/category
-is used in the lookup.
-
-All other requested combinations are ignored.
-
-Simple-Search Operation
-
-Completely implemented but the search query is a regular expression.
-This gets matched against the keywords stored with the rated URI's and
-the ones with the best instant ratings are returned.
-
-Evaluator
-
-Implemented except the
-
-personal
-context
-sort
-collection-name
-
-fields that are ignored and used nowhere
-
-
-13.   Security considerations
-
-Not yet ready.
-
-
-14.   Copyright
-
-Copyright (C) The Internet Society 2000. All Rights Reserved.
-
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it or
-assist in its implementation may be prepared, copied, published and
-distributed, in whole or in part, without restriction of any kind,
-provided that the above copyright notice and this paragraph are
-included on all such copies and derivative works. However, this
-document itself may not be modified in any way, such as by removing the
-copyright notice or references to the Internet Society or other
-Internet organizations, except as needed for the purpose of developing
-Internet standards in which case the procedures for copyrights defined
-in the Internet Standards process must be followed, or as required to
-translate it into languages other than English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
-NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
-NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE.
-
-
-15.   Acknowledgments
-
-Michel Claude, Christopher Lueg, David Mason, Andras Micsik, Massimo
-Vanocchi and Richard Wheeler have participated in the production of
-this document. An earlier attempt to encode PICS in XML format was made
-by O. Lassila as described in [PICS3].
-
-
-16.   References
-
-
-Ref.         Author, title
----------    --------------------------------------------------------
-
-
-[PICS1]      Rating Services and Rating Systems (and Their Machine
-             Readable Descriptions) http://www.w3.org/PICS/services.html
-
-[PICS2]      PICS Distribution Label Syntax and Communication Protocols
-             http://www.w3.org/PICS/labels.html.
-
-[COOKIES]    RFC 2109 HTTP State Management Mechanism. D. Kristol, L.
-             Montulli. February 1997.
-             ftp://sunic.sunet.se/rfc/rfc2109.txt
-[HTTP]       RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1. R.
-             Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee.
-             January 1997. ftp://sunic.sunet.se/rfc/rfc2068.txt
-
-[IMAP]       IMAP4 Authentication Mechanisms. J. Myers. December 1994,
-             RFC 1731.
-
-[IMAP]       RFC 2045-2049 Multipurpose Internet Mail Extensions (MIME).
-             N. Freed & N. Borenstein, November 1996.
-             ftp://sunic.sunet.se/rfc/rfc2045.txt, rfc2046.txt, rfc2047,
-             rfc2048, rfc2049
-
-[URI]        RFC 1738 Uniform Resource Locators (URI).T. Berners-Lee et
-             al, December 1994. ftp://sunic.sunet.se/rfc/rfc1738.txt
-
-[XML1]       Extensible Markup Language (XML) 1.0. W3C REC-xml-19980210,
-             T. Bray, J. Paoli, C.M. Sperberg-McQueen.
-             http://www.w4.org/TR/1998/REC-xml-19980210
-
-[XML2]       A Technical Introduction to XML, N. Walsh, Oct 1998,
-             http://www.xml.com/xml/pub/98/10/guide0.html
-
-[PICS3]      PICS-NG Metadata Model and Label Syntax, O. Lassila,
-             http://www.w3.org/TR/NOTE-pics-ng.metadata
-
-[SELFUNC]    SELECT, Telematics Application Programme, RE4008,
-             Deliverable 2.1 Draft, Functional Specifications Report, by
-             Roland Alton-Scheidl and Richard Wheeler.
-
-[SELARCH]    SELECT System Architecture, by Richard Wheeler
-
-
-17.   Author's Addresses
-
-Jacob Palme                           Phone: +46-8-16 16 67
-Stockholm University and KTH          Fax: +46-8-783 08 29
-Electrum 230                          Email: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
-Johan Kaers                           Phone: +32-2-7400794
-S T A R L A B Research Laboratories   Fax: +32 2 7429654
-Sint-Michielslaan 47                  Email: johan@starlab.net
-B-1040 Etterbeek (Brussels), Belgium
diff --git a/Documentation/en/I-D/draft-palme-supersedes-00.txt b/Documentation/en/I-D/draft-palme-supersedes-00.txt
deleted file mode 100644
index 68f9b8a6..00000000
--- a/Documentation/en/I-D/draft-palme-supersedes-00.txt
+++ /dev/null
@@ -1,412 +0,0 @@
-INTERNET-DRAFT                                    Jacob Palme
-Network Working Group                Stockholm University/KTH
-draft-palme-supersedes-00.txt                          Sweden
-Expires August 1999                             February 1999
-
-
-
-
-The Supersedes or Replaces Header in E-mail
-
-
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time.  It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright (C) The Internet Society 1998. All Rights Reserved.
-
-
-Abstract
-
-This memo introduces one new e-mail header, Supersedes.  This
-document may, if accepted by the IESG, become a proposed
-standard, at some time in the future.
-
-Differences from draft-ietf-mailext-new-fields-14.txt
-
-Most of these changes are to agree with a similar
-specification by Charles Lindsey on the Supersedes and
-Replaces headers in Usenet News, which is being developed as
-part of the IETF USEFOR working group, and by other
-suggestions made in the USEFOR mailing list.
-
-Parameters "noshow", "show" and "repost" have been added to
-the "Supersedes" header, in accordance with discussions in the
-usefor mailing list.
-
-A parameter "version=<decimal-version-number>" might also be
-considered, but has not been added.
-
-The discussion in chapter 1.2.1 Who may supersede a
-message/article? has been extended to more fully explain the
-reasons for the recommended practices for implementing hard
-supersedes.
-
-A discussion note has been added to chapter 1.2.4 When to use
-soft and hard supersedes to explain why the author of a
-message may want hard superseding of a message in certain
-cases.
-
-
-Table of contents
-
-1.   Supersedes
- 1.1   Syntax
- 1.2   Semantics
-   1.2.1  Who may supersede a message/article?
-   1.2.2  Semantic variant 1: Soft supersedes
-   1.2.3  Semantic variant 2: Hard supersedes
-   1.2.4  When to use soft and hard supersedes
-   1.2.5  Multiple field values
-2.   Security considerations
-3.   Copyright
-4.   Acknowledgments
-5.   References
-6.   Author's address
-
-
-1.    Supersedes
-
-1.1   Syntax
-
-    Supersedes-field          = "Supersedes:" CFWS identifier
-                                *(identifier)
-                                optional-parameter-list
-                                [CFWS] CRLF
-
-    optional-parameter-list   = *( ";" LWSP parameter )
-
-    parameter                 = parameter-name [ "="
-                                parameter-value ]
-
-    parameter-name            = "noshow" / "show" / "repost"
-                                private-parameter /
-                                future-parameter
-
-Note: There is no comma between multiple values, and that each
-Message-ID value is to be surrounded by angle brackets.
-
-Warning: Some software may not work correctly with comments in
-header fields, especially comments in other places than at the
-beginning and end of the field value.
-
-Warning: This header MUST be spelled "Supersedes" and not
-"Supercedes".
-
-1.2   Semantics
-
-The Supersedes header identifies previous correspondence,
-which this message supersedes. Different messaging agents such
-as user agents, mailing list expanders and mailing list
-archives. A user agent is expected to handle this field in
-much the same way as the In-Reply-To and References header.
-
-Note: The Message-ID of a superseding message MUST be
-different from the Message-ID of the superseded message. The
-Message-ID of the superseded message is used as value in the
-"Supersedes:" header, not in the Message-ID of the superseding
-message.
-
-Parameters:
-
-noshow   In the opinion of the sender, this message makes such
-         a minor change to the superseded version, that a
-         recipient, who has already seen the previous verson,
-         will probably not want to see the new version, unless
-         the user explicitly asks for it.
-
-show     In the opinion of the sender, this message makes such
-         a large change to the superseded version, that a
-         recipient, who has already seen the previous version,
-         will probably want to see the new version, too.
-
-repost   This document is a document which is repeatedly, at
-         regular or irregular intervals, reposted, such as
-         FAQs or mailing list monthly information.
-
-None of these parameters have values. The "noshow" and the
-"show" parameters are mutually exclusive, but both of them can
-occur together with the "repost" parameter.
-
-1.2.1 Who may supersede a message/article?
-
-Agents receiving superseding messages MAY ignore, or issue a
-warning, for the Supersedes header, if the author of the
-message is not approved. Approved authors of superseding
-messages MAY be:
-
-(1) The author of the message being superseded.
-
-(2) For moderated mailing lists, the moderator. Note that a
-    moderator may only supersede messages/articles in groups,
-    for which the moderator is responsible, and such a
-    moderator SHOULD not send superseding messages/articles to
-    other groups.
-
-        Discussion: There are two kinds of moderated lists,
-        pre-moderated and post-moderated. In pre-moderated
-        lists, the moderator approves all contributions
-        before they are sent out to list members.
-        In post-moderated lists, contributions are sent
-        out immediately, but the moderator can supersede
-        inappropriate contributions afterwards. The
-        advantage with pre-moderated lists is that no
-        inappropriate contributions will ever be sent out.
-        The advantage with post-moderated list is faster
-        turnaround time in discussion threads.
-
-(3) Other users given the authority to supersede messages.
-    Such authority is often local to one particular server
-    only.
-
-        Discussion: A server administrator may be legally
-        required to supersede illegal messages, if these
-        are available for download by people who have
-        not yet received them.
-
-An agent MAY ignore or issue a warning for Supersedes headers
-if the Superseding message does not have a verifyable digital
-signature of its author or another agent who the agent owner
-thinks should be allowed to supersede this message. Digital
-signatures are separately standardized (like SMIME [9] and PGP
-[10] or other standards for digital signatures) and their
-format and semantics are not specified in this standard.
-
-1.2.2 Semantic variant 1: Soft supersedes
-
-(a) With soft supersedes this header does not imply any
-    mandatory deletion of the previous correspondence in
-    mailboxes and user agent databases. The user is still able
-    to view old versions of superseded messages.
-
-(b) Agents which provide user commands for getting from a
-    reply to the replied-to message (or for getting from a
-    replied-to message to its replies), MAY provide similar
-    commands for getting from a superseding message to the
-    superseded message (or for getting from a superseded
-    message to its superseding version).
-
-(c) Agents MAY normally show the recipient both the previous
-    and the superseding message. If, however, both the
-    previous and the superseding message have arrived, both
-    having the same author, but the user has not yet seen
-    either of them, a user agent MAY show only the superseding
-    message, but also show a mark to inform the recipient that
-    this message supersedes a previous message.
-
-1.2.3 Semantic variant 2: Hard supersedes
-
-With hard supersedes, the arrival of a superseding message or
-article will cause the deletion of the superseded message. The
-new message will however still have a new Message-ID and will
-not take over the Message-ID of the superseded
-message/article.
-
-1.2.4 When to use soft and hard supersedes
-
-Hard and soft supersedes are differentiated by the receiving
-client, not the sender. There is no format difference in the
-header between hard and soft supersedes.
-
-Mail stores under the control of an individual user (for
-example, POP or IMAP mail boxes) SHOULD implement soft
-supersedes but MAY implement hard supersedes, possibly only as
-an (off by default) option.  (Please read the security
-considerations if you plan to implement this). Multi-user
-message archives and servers MAY implement HARD supersedes.
-
-    Discussion: A person, who has by mistake written an
-    illegal message, may be legally required to hard supersede
-    the illegal message, in places where it is available for
-    download by people who have not yet received it.
-
-Note: In Usenet News, servers commonly implement hard
-supersedes.
-
-If the handler of a message/article storage has a mechanism
-for automatic purging of old messages, the fact that there is
-a superseding message may be a component in the decision of
-when to purge the previous version.
-
-1.2.5 Multiple field values
-
-When this is written (1999) some Usenet News softwares cannot
-handle Supersedes with more than one previous articles listed
-as parameters. This can be expected to change, but until then,
-a gateway from e-mail to news MAY because of this delete all
-but the first parameter of this attribute when conveying
-messages from e-mail to news.
-
-
-2.    Security considerations
-
-
-If a server or receiving user agent suppresses showing of
-superseded messages, the "Supersedes:" feature might be used
-maliciously to suppress messages written by other people. To
-reduce the risk for this, it is RECOMMENDED that user agents
-give a warning to the recipient when a superseding message has
-a different "From:" name than the superseded message.
-
-A moderately clever forger can of course circumvent this by
-sending messages with falsified "From:" field and even
-falsified SMTP senders. User agents supporting S/MIME [9] or
-PGP [10] or other standards for digital signature can require
-and check digital signatures to reduce also this risk (see
-section 1.2.1 above).
-
-Even more reduction of security problems can be achieved if
-user agents handle "Supersedes:" exactly in the same way as
-"In-Reply-To:" and "References:", i.e. show both versions of
-the message, and only use the "Supersedes:" header as
-information to readers of messages of the relation between
-different messages.
-
-Another possible risk with "Supersedes:" is that it allows
-people to "change their minds", possibly changing the meaning
-of replies to them. Example: A message with the text "Do you
-like your mother" gets the reply "Yes, very much", and then
-the original message might be changed to "Do you like Hitler",
-changing the meaning of the reply. Note, however, that the
-"In-Reply-To" or "References" headers in the reply refers to
-the Message-ID of the original message, not of the superseding
-message. Thus, a user agent can avoid this problem by
-designing the user interface so that replies are not shown as
-referring to the superseding message, when they use the
-Message-ID of the superseded message.
-
-Also, since "Supersedes:" in e-mail is meant to not actually
-cause deletion of the superseded message, recipients can look
-up the superseded message to see if the author has changed his
-mind. In general, it is not illegal or unethical to change
-your mind, rather, it shows your openness to new ideas and
-willingness to listen to the arguments of other people.
-
-The fact that some implementations of Supersedes cause
-deletion of the Superseded message (hard supersedes, section
-1.2.3 above), but others do not (soft supersedes, section
-1.2.2 above), may cause security problems. To reduce this
-problem, a server should clarify its policy on this to its
-users and follow the recommendations in section 1.2.4 above.
-
-
-3.    Copyright and disclaimer
-
-The IETF takes no position regarding the validity or scope of
-any intellectual property or other rights that might be
-claimed to pertain to the implementation or use of the
-technology described in this document or the extent to which
-any license under such rights might or might not be available;
-neither does it represent that it has made any effort to
-identify any such rights. Information on the IETF's procedures
-with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims
-of rights made available for publication and any assurances of
-licenses to be made available, or the result of an attempt
-made to obtain a general license or permission for the use of
-such proprietary rights by implementors or users of this
-specification can be obtained from the IETF Secretariat."
-
-The IETF invites any interested party to bring to its
-attention any copyrights, patents or patent applications, or
-other proprietary rights which may cover technology that may
-be required to practice this standard. Please address the
-information to the IETF Executive Director.
-
-This document and translations of it may be copied and
-furnished to others, and derivative works that comment on or
-otherwise explain it or assist in its implmentation may be
-prepared, copied, published and distributed, in whole or in
-part, without restriction of any kind, provided that the above
-copyright notice and this paragraph are included on all such
-copies and derivative works. However, this document itself may
-not be modified in any way, such as by removing the copyright
-notice or references to the Internet Society or other Internet
-organizations, except as needed for the purpose of developing
-Internet standards in which case the procedures for copyrights
-defined in the Internet Standards process must be followed, or
-as required to translate it into languages other than English.
-
-The limited permissions granted above are perpetual and will
-not be revoked by the Internet Society or its successors or
-assigns.
-
-
-4.    Acknowledgments
-
-Many people have helped with the production of this document.
-Of special value have been R. Allbery, H. T. Alvestrand, A.
-Bowesman, B. Franz, P. Hoffman, S. Kille, S. Lyall, K. Moore,
-P. Overell, U. Paz, E. Sommarskog, H. Spencer, J. Stanley, B.
-Templeton, K. Weide and R. Zellich
-
-
-5.    References
-
-[1]  D. Crocker: "Standard for the format of ARPA Internet
-     text messages." STD 11, RFC 822, August 1982.
-
-[2]  S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO
-     10021 and RFC 822",  RFC 1327 May 1992.
-
-[3]  ISO/ITU: "Message Handling Systems", ISO international
-     standard 10021, ITU  recommendation X.400.
-
-[4]  ISO/ITU: "Message Handling Systems, Part 7: Interpersonal
-     Messaging System, ISO international standard 10021-7, ITU
-     recommendation X.420.
-
-[5]  N. Freed, N. Borenstein, "Multipurpose Internet Mail
-     Extensions (MIME) Part One: Format of Internet Message
-     Bodies", RFC 2045, December 1996
-
-[6]  K. Moore, G. Vaudreuil, "An Extensible Message Format for
-     Delivery Status Notifications", RFC 1894, January 1996.
-
-[7]  K. Moore, "SMTP Service Extension for Delivery Status
-     Notifications", RFC 1891, January 1996.
-
-[8]  M.R. Horton, R. Adams: "Standard for interchange of
-     USENET messages", RFC 1036, December 1987.
-
-[9]  B. Ramsdell: S/MIME Version 3 Message Specification. Work
-     in progress.
-
-[10] J. Callas, L. Donnerhacke, H. Finney, R. Thayer: OpenPGP
-     Message Format. Work in progress.
-
-[11] J. Palme: "Advise on the implementation of In-Reply-To,
-     References and Supersedes e-mail and netnews headers",
-     draft-palme-newfields-info-02.doc, March 1998.
-
-[12] D. Crocker: Augmented BNF for Syntax Specifications:
-     ABNF, RFC 2234, November 1997.
-
-
-6.    Author's address
-
-Jacob Palme                          Phone: +46-8-16 16 67
-Stockholm University/KTH             Fax: +46-8-783 08 29
-Skeppargatan 73                      E-mail: jpalme@dsv.su.se
-S-115 30 Stockholm, Sweden
-