import a few mail related drafts, regen index

3 files changed, 2389 insertions, 130 deletions

diff --git a/Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt b/Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt
new file mode 100644
index 00000000..4217b315
--- /dev/null
+++ b/Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt
@@ -0,0 +1,784 @@
+
+
+Network Working Group                                           G. Klyne
+Internet-Draft                                         MIMEsweeper Group
+Expires: July 5, 2002                                        Jan 4, 2002
+
+
+              Registration procedures for message headers
+                     draft-klyne-msghdr-registry-01
+
+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 Internet-Draft will expire on July 5, 2002.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This specification defines registration procedures for the message
+   headers used by Internet mail, newsgroup feeds, HTTP and other
+   Internet applications.
+
+Discussion of this document
+
+   Please send comments to <ietf-822@imc.org>.  To subscribe to this
+   list, send a message with the body 'subscribe' to <ietf-822-
+   request@imc.org>.
+
+
+
+
+
+
+Klyne                     Expires July 5, 2002                  [Page 1]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.1   Structure of this document . . . . . . . . . . . . . . . . .  3
+   1.2   Document terminology and conventions . . . . . . . . . . . .  4
+   2.    Message headers  . . . . . . . . . . . . . . . . . . . . . .  4
+   2.1   Standard and non-standard headers  . . . . . . . . . . . . .  4
+   2.2   Definitions of message headers . . . . . . . . . . . . . . .  5
+   2.2.1 Application-specific message headers . . . . . . . . . . . .  5
+   3.    Registration procedure . . . . . . . . . . . . . . . . . . .  5
+   3.1   Header specification . . . . . . . . . . . . . . . . . . . .  6
+   3.2   Registration templates . . . . . . . . . . . . . . . . . . .  6
+   3.2.1 Normative header template  . . . . . . . . . . . . . . . . .  6
+   3.2.2 Provisional header template  . . . . . . . . . . . . . . . .  7
+   3.3   Submission of registration . . . . . . . . . . . . . . . . .  8
+   3.4   Change control . . . . . . . . . . . . . . . . . . . . . . .  8
+   3.5   Comments on header definitions . . . . . . . . . . . . . . .  8
+   3.6   Location of message header registry  . . . . . . . . . . . .  9
+   4.    Initial registrations  . . . . . . . . . . . . . . . . . . .  9
+   5.    IANA considerations  . . . . . . . . . . . . . . . . . . . .  9
+   6.    Security considerations  . . . . . . . . . . . . . . . . . .  9
+   7.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
+         References . . . . . . . . . . . . . . . . . . . . . . . . .  9
+         Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
+   A.    Revision history . . . . . . . . . . . . . . . . . . . . . . 12
+   A.1   draft-klyne-msghdr-registry-01 . . . . . . . . . . . . . . . 12
+   A.2   draft-klyne-msghdr-registry-00 . . . . . . . . . . . . . . . 12
+   B.    Todo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+         Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne                     Expires July 5, 2002                  [Page 2]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+1. Introduction
+
+   This specification defines registration procedures for the message
+   headers used by Internet mail, newsgroup feeds, HTTP and other
+   Internet applications.
+
+   Benefits of a central registry for message headers include:
+
+   o  to provide a single point of reference for standardized headers;
+
+   o  to provide a central point of discovery for established headers,
+      and easy location of their defining documents;
+
+   o  to discourage multiple definitions of a header name for different
+      purposes;
+
+   o  to help those proposing new headers discern established trends and
+      conventions, and avoid names that might be confused with existing
+      ones;
+
+   o  to encourage convergence of header name usage across multiple
+      applications/protocols.
+
+   The primary specification for Internet message headers is the
+   Internet mail message format specification, RFC 2822 [22], but there
+   are many other Internet standards track documents that define
+   additional headers within the same namespace, notably MIME [7] and
+   related specifications.  Other Internet applications that use MIME,
+   such as newsgroup feeds (RFC 1036 [1]) and HTTP web access (RFC 2616
+   [19]), also use many of the same headers.
+
+   Although in principle each application defines its own set of valid
+   headers, exchange of messages between applications (e.g.  mail to
+   news gateways), common use of MIME encapsulation, and the possibility
+   of common processing for various message types (e.g.  a common
+   message archive and retrieval facility) makes it desirable to have a
+   single point of reference for standardized headers.  The message
+   header registry defined here serves that purpose.
+
+1.1 Structure of this document
+
+   Section Section 2 discusses the purpose of this specification, and
+   indicates some sources of information about defined message headers.
+
+   Section Section 3 defines the message header registry, and sets out
+   requirements and procedures for creating entries in it.
+
+
+
+
+
+Klyne                     Expires July 5, 2002                  [Page 3]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+1.2 Document terminology and conventions
+
+   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 [10].
+
+      NOTE: indented comments like this provide additional nonessential
+      information about the rationale behind this document.
+
+   [[[Editorial comments and questions about outstanding issues are
+   provided in triple brackets like this.  These working comments should
+   be resolved and removed prior to final publication.]]]
+
+2. Message headers
+
+2.1 Standard and non-standard headers
+
+   Many message headers are defined in standards-track documents, which
+   means they have been subjected to a process of community review and
+   achieved consensus that they provide a useful and well-founded
+   capability.  Many other headers have been defined and adopted for
+   private use; some of these have found widespread use.
+
+   The registry defined here is intended to cater for all of these
+   headers, while maintaining a clear distinction and status for those
+   which have community consensus.  To this end, the registry is defined
+   in two parts (or maybe as two separate registries):
+
+   o  Normative Message Headers, intended for headers defined in IETF
+      standards-track documents, or those that have achieved a
+      comparable level of community review.  The assignment policy for
+      such registration is "IETF Consensus", as defined by RFC 2434
+      [18].
+
+   o  Provisional Message Headers, intended for any header proposed by
+      any developer, without making any claim about the usefulness
+      quality of its definition.  The assignment policy for registration
+      of these is "Private Use", per RFC 2434 [18].
+
+   Note that there exist at least two other sources information about
+   message headers:
+
+   o  RFC 2076 [8], as updated [25], contains a list of commonly used
+      message headers, and
+
+   o  Dan Bernstein maintains a list of standard and non-standard mail
+      message headers [26].
+
+
+
+
+Klyne                     Expires July 5, 2002                  [Page 4]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+2.2 Definitions of message headers
+
+   RFC 2822 [22] defines a general syntax for Internet message headers.
+   It also defines a number of headers for use with Internet mail.
+   Additional header names are defined in a variety of standards-track
+   RFC documents, including: RFC 1036 [1], RFC 1496 [2], RFC 1505 [3],
+   RFC 1766 [5], RFC 1864 [6], RFC 2156 [12], RFC 2183 [13], RFC 2045
+   [7], RFC 2110 [9], RFC 2298 [14], RFC 2369 [15], RFC 2421 [17], RFC
+   2616 [19], RFC 2821 [21], RFC 2912 [23] and RFC 2919 [24].
+
+2.2.1 Application-specific message headers
+
+   Internet applications that use message headers include Internet mail
+   [21][22], NNTP newsgroup feeds [1], HTTP web access [19] and any
+   other that uses MIME [7] encapsulation of message content.
+
+   In some cases (notably HTTP [19]), the header syntax and usage is
+   redefined for the specific application.  This registration is
+   concerned only with the allocation and specification of header names,
+   and not with the details of header implementation in specific
+   protocols.
+
+   In some cases, the same header name may be specified differently (by
+   different documents) for use with different application protocols
+   [[[example?]]].  In other cases, a header name may have a common
+   specification across multiple protocols (ignoring protocol-specific
+   lexical and character set conventions);  e.g.  this is generally the
+   case for MIME headers with names of the form 'Content-*'.
+
+   Thus, we need to accommodate application-specific headers, while
+   recognizing the commonality of other headers across multiple
+   applications.  Common registries are used for all applications, and
+   each registered header specifies the application protocol(s) for
+   which the registered definition applies.  A given header name may
+   have multiple registry entries for different protocols; in the
+   Normative Message Headers registry, a given header name may be
+   registered only once for any given protocol.
+
+3. Registration procedure
+
+   The procedure for registering a message header is:
+
+   1.  Construct a header specification
+
+   2.  Prepare a registration template
+
+   3.  Submit the registration template
+
+
+
+
+Klyne                     Expires July 5, 2002                  [Page 5]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+3.1 Header specification
+
+   Registration of a new message header starts with construction of a
+   proposal that describes the syntax, semantics and intended use of the
+   header.  This proposal MUST be published as an RFC.
+
+   A registered header name MUST conform at least to the syntax defined
+   by RFC 2822, section 3.6.8, for "field name".
+
+   Further, the "." character is reserved to indicate a naming sub-
+   structure and MUST NOT be included in any registered header name.
+   Currently, no specific sub-structure is defined; if used, any such
+   structure MUST be defined by a standards track RFC document.
+
+   It is further RECOMMENDED that characters in a registered message
+   header name are restricted to those characters that can be used
+   without escaping in a URI [16] or URN [11], namely upper- or lower-
+   case ASCII letters, decimal digits, "(", ")", "+", ",", "-", "=",
+   "@", ";", "$", "_", "!", "*" and "'".  Of course, a header name must
+   also conform to any applicable rules of the protocol(s) with which it
+   may be used.  Many headers names may find some use in conjunction
+   with XML, in which case the name characters should be further
+   restricted to just letters, digits, hyphen ('-') and underscore ('_')
+   characters, with the first character being a letter or underscore.
+
+3.2 Registration templates
+
+   The registration template for a message header may be contained in
+   the defining document, or prepared separately.
+
+3.2.1 Normative header template
+
+   An header registered as a Normative Message Header MUST be defined
+   according to "IETF Consensus" rules (per RFC 2434 [18]), and MUST
+   have a name which is unique among all the Normative Message Headers
+   that may be used with the same application protocol(s).  The header
+   name MUST NOT start with "X-" or "x-".
+
+   The registration template contains the following information:
+
+   NORMATIVE HEADER REGISTRATION TEMPLATE:
+
+   Header name:
+      The name requested for the new header.  This MUST conform to the
+      header specification details above.
+
+   Applicable protocol(s):
+      Specify "mail", "news", "http", or cite any other standards-track
+
+
+
+Klyne                     Expires July 5, 2002                  [Page 6]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+      RFC defining the protocol with which the header is intended to be
+      used.
+      Alternatively, specify "any" to indicate that there is no
+      specified restriction on the protocol with which the registered
+      header may be used; in this case, the header name must be unique
+      within the Normative Message Header registry.
+
+   Specification document(s):
+      Reference to the RFC(s) that specify the header for use with the
+      indicated protocol(s).
+
+   Related information:
+      Optionally, citations to additional documents containing further
+      relevant information.
+
+
+3.2.2 Provisional header template
+
+   Registration as a Provisional Message Header does not imply any kind
+   of endorsement by the IETF, IANA or any other body.
+
+   The only requirement for a header to be registered as a Provisional
+   Message Header is that it MUST have a citable specification.
+
+   The registration template contains the following information:
+
+   PROVISIONAL HEADER REGISTRATION TEMPLATE:
+
+   Header name:
+      The name requested for the new header.  This SHOULD conform to the
+      header specification details above.
+
+   Applicable protocol(s):
+      Specify "mail", "news", "http", or cite any other standards-track
+      RFC defining the protocol with which the header is intended to be
+      used.
+      Alternatively, specify "any" to indicate that there is no
+      specified restriction on the protocol with which the registered
+      header may be used.
+
+   Specification document(s):
+      Reference to document(s) that specifies the header for use with
+      the indicated protocol(s).
+
+   Related information:
+      Optionally, citations to additional documents containing further
+      relevant information.
+
+
+
+
+Klyne                     Expires July 5, 2002                  [Page 7]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+
+      The name and email address of the author, and person who may
+      authorize changes to or retraction of the registration.
+
+
+3.3 Submission of registration
+
+   The registration is submitted for incorporation in the IANA message
+   header registry by one of the following means:
+
+   o  An IANA considerations section in a defining RFC, calling for
+      registration of the message header and referencing the
+      registration template within the same document.  Registration of
+      the header is processed as part of the RFC publication process.
+
+   o  Sending the registration template in an email to the designated
+      email address [27].  IANA will register the message header if the
+      requested name and the specification document meet the criteria
+      stated.
+
+
+3.4 Change control
+
+   Change control of a header registration is subject to the same
+   condition as the initial registration; i.e.  publication of an IESG-
+   approved RFC for a Normative Message Header, or on request of the
+   indicated author/cgange controller for a Provisional Message Header.
+
+   In addition, retraction of Provisional Message Header registration
+   may be requested by the IESG.
+
+   It is intended that entries in the Normative Header Registry may be
+   used in the construction of URNs (per RFC 2141 [11]) which have
+   particular requirements for uniqueness and persistence (per RFC 1737
+   [4]).  Therefore, once an entry is made in the Normative Message
+   Header registry, the combination of the header name and any
+   applicable protcol MUST NOT subsequently be registered for any other
+   purpose.  (This is not to preclude revision of the applicable
+   specification(s) within the appropriate IETF Consensus rules, and
+   corresponding updates to the specification citation in the header
+   registration.)
+
+3.5 Comments on header definitions
+
+   [[[Review this]]]
+
+   Comments on registered Normative Message Headers should be sent to
+   the IETF-822 email discussion list [27].
+
+
+
+Klyne                     Expires July 5, 2002                  [Page 8]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+   Comments on proposed message headers should preferably be sent to the
+   discusion forum for the specification concerned.  They may also be
+   sent to the IETF-822 list [27] if they concern wider implications
+   than are addressed by the specification document.
+
+3.6 Location of message header registry
+
+   The message header registry is accessible from IANA's web site [28].
+
+4. Initial registrations
+
+   [[[I am currently minded to prepare two companion documents that
+   template the normative and provisional headers from RFC 2076, rather
+   than try to have them all in this document.]]]
+
+   This specification calls for initial registration of all message
+   headers defined in existing standards-track documents.  A list of
+   such headers can be found in RFC 2076 [8] and updates [25].  Section
+   Section 2.2 of this document contains a list of standards-track
+   specifications that define message headers.
+
+   [[[Need to provide list of headers+documents here for initial
+   registration?]]]
+
+5. IANA considerations
+
+   This specification calls for:
+
+   o  A new two-part IANA registry for message headers per section
+      Section 3 of this document.  The policies for inclusion in the
+      registry are described in sections Section 3.1 and Section 3.2.
+
+   o  [[[Details TBD: Initial message header registrations, per section
+      Section 4 of this document.]]]
+
+
+6. Security considerations
+
+   No security considerations are introduced by this specification
+   beyond those already inherrent in the use of message headers.
+
+7. Acknowledgements
+
+   The author gratefully acknowledges the contributions of: Charles
+   Lindsey, [[[...]]]
+
+References
+
+
+
+
+Klyne                     Expires July 5, 2002                  [Page 9]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+   [1]   Horton, M. and R. Adams, "Standard for interchange of USENET
+         messages", RFC 1036, December 1987.
+
+   [2]   Alvestrand, H., Jordan, K. and J. Romaguera, "Rules for
+         downgrading messages from X.400/88 to X.400/84 when MIME
+         content-types are present in the messages", RFC 1496, August
+         1993.
+
+   [3]   Costanzo, A., Robinson, D. and R. Ullmann, "Encoding Header
+         Field for Internet Messages", RFC 1505, August 1993.
+
+   [4]   Masinter, L. and K. Sollins, "Functional Requirements for
+         Uniform Resource Names", RFC 1737, December 1994.
+
+   [5]   Alvestrand, H., "Tags for the Identification of Languages", RFC
+         1766, March 1995.
+
+   [6]   Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC
+         1864, October 1995.
+
+   [7]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One: Format of Internet Message Bodies",
+         RFC 2045, November 1996.
+
+   [8]   Palme, J., "Common Internet Message Headers", RFC 2076,
+         February 1997.
+
+   [9]   Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
+         Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
+         1997.
+
+   [10]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [11]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [12]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
+         between X.400 and RFC 822/MIME", RFC 2156, January 1998.
+
+   [13]  Moore, K., Troost, R. and S. Dorner, "Communicating
+         Presentation Information in Internet Messages: The Content-
+         Disposition Header Field", RFC 2183, August 1997.
+
+   [14]  Fajman, R., "An Extensible Message Format for Message
+         Disposition Notifications", RFC 2298, March 1998.
+
+   [15]  Baer, J. and G. Neufeld, "The Use of URLs as Meta-Syntax for
+         Core Mail List Commands and their Transport through Message
+
+
+
+Klyne                     Expires July 5, 2002                 [Page 10]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+         Header Fields", RFC 2369, July 1998.
+
+   [16]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
+         1998.
+
+   [17]  Parsons, G. and G. Vaudreuil, "Voice Profile for Internet Mail
+         - version 2", RFC 2421, September 1998.
+
+   [18]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [19]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
+         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+   [20]  Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
+         August 1999.
+
+   [21]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
+         2001.
+
+   [22]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [23]  Klyne, G., "Indicating Media Features for MIME Content", RFC
+         2912, September 2000.
+
+   [24]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field and
+         Namespace for the Identification of Mailing Lists", RFC 2919,
+         April 2001.
+
+   [25]  Palme, J., "Common Internet Message Header Fields", Internet
+         draft draft-palme-mailext-headers-05, May 2001,
+         <http://search.ietf.org/internet-drafts/draft-palme-mailext-
+         headers-05.txt>.
+
+   [26]  Bernstein, D., "Internet mail field name index",
+         <http://cr.yp.to/immhf/index.html>.
+
+   [27]  "Mail address for submission of header registration template",
+         <mailto:[[[ietf-message-headers]]]@iana.org>.
+
+   [28]  "IANA list of registered message headers",
+         <http://www.iana.org/[[[ToBeDefined]]]>.
+
+
+
+
+
+
+Klyne                     Expires July 5, 2002                 [Page 11]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+Author's Address
+
+   Graham Klyne
+   MIMEsweeper Group
+   1310 Waterside
+   Arlington Business Park
+   Theale, Reading  RG7 4SA
+   UK
+
+   Phone: +44 118 903 8000
+   Fax:   +44 118 903 9000
+   EMail: Graham.Klyne@MIMEsweeper.com
+
+Appendix A. Revision history
+
+   (This section to be removed on final publication)
+
+A.1 draft-klyne-msghdr-registry-01
+
+   01a 04-Jan-2002:
+
+      *  In response to feedback from interested parties, expanded the
+         registry to cover Normative and Provisional message header
+         registrations.
+
+      *  Defined a formal role for the applicable protocol(s) in the
+         registry:  the combination of header name and any applicable
+         protocol must be unique for a Normative Message Header.
+
+      *  Noted further constraints to the header name format for XML
+         name compatibility.
+
+      *  Fixed registration policy for a Normative Message Header to be
+         "IETF Consensus".
+
+
+A.2 draft-klyne-msghdr-registry-00
+
+   00a 27-Sep-2001:
+
+      *  Document initially created.
+
+
+Appendix B. Todo
+
+   (This section to be removed on final publication)
+
+   o  Finalize initial registrations.
+
+
+
+Klyne                     Expires July 5, 2002                 [Page 12]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+   o  Finalize email address for submission of registration templates.
+
+   o  Finalize web address for registry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne                     Expires July 5, 2002                 [Page 13]
+
+Internet-Draft         Message header registration              Jan 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne                     Expires July 5, 2002                 [Page 14]
+
diff --git a/Documentation/en/I-D/draft-palme-mhtml-info-01.txt b/Documentation/en/I-D/draft-palme-mhtml-info-01.txt
new file mode 100644
index 00000000..6535bacd
--- /dev/null
+++ b/Documentation/en/I-D/draft-palme-mhtml-info-01.txt
@@ -0,0 +1,1446 @@
+Network Working Group                        Jacob Palme
+Internet Draft                                 Stockholm
+draft-palme-mhtml-info-01.txt             University/KTH
+                                            December 2001
+Category-to-be:
+Informational
+Expires: June 2001
+
+
+
+              Sending HTML in MIME,
+     an informational supplement to the RFC:
+     MIME Encapsulation of Aggregate Documents,
+              such as HTML (MHTML)
+
+
+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.
+
+
+1.   Abstract
+
+The memo "MIME Encapsulation of Aggregate Documents, such
+as HTML (MHTML)" [RFC 2557] specifies how to send packaged
+aggregate HTML objects in MIME format. This memo is an
+accompanying informational document, intended to be an aid
+to developers. This document is not an Internet standard.
+
+Issues discussed are implementation methods, caching
+strategies, problems with rewriting of URIs, making
+messages suitable both for mailers which can and which
+cannot handle Multipart/related and handling recipients
+which do not have full Internet connectivity.
+
+
+2.   Table of Contents
+
+1.  Abstract
+2.  Table of Contents
+3.  Introduction
+4.  Implementation Methods
+4.1   Method 1: Combining Viewer And MIME Receiving Program
+4.2   Method 2: Rewriting The HTML
+4.3   Method 3: Using A Translation Table
+4.4   Method 4: Using A Proxy HTTP Server To Retrieve
+       Referenced Body Parts
+4.5   Method 5: Putting The Mail Client Into A Proxy HTTP
+       Server
+4.6   Other Methods
+4.7   Combined Methods
+4.8   Communication Between Document Viewer And Mail Client
+5.  Problems with Rewriting URIs when Copying HTML
+     Documents
+6.  Caching of Body Parts
+7.  "Save as" Command
+8.  Recipients which cannot Handle the Multipart/related
+     Content-Type
+9.  Use of the Content-Type: Multipart/alternative
+9.1   Multipart/alternative inside Multipart/related
+9.2   Multipart/alternative outside Multipart/related
+9.3   Comparing the Two Methods
+9.4   Reducing the Download Time
+10. Writing Readable HTML
+11. Textual Alternatives to HTML Forms
+11.1  Form in HTML Format
+11.2  The same Form In Textual Format
+12. Recipient may not have Full Internet Connectivity
+13. Encoding of Non-Ascii Characters
+14. Conversion from HTTP to MIME
+15. Default Font Size
+16. Copyright and Disclaimer
+17. Acknowledgments
+18. References
+19. Author's Address
+
+
+Mailing List Information
+
+Further discussion on this document should be done through
+the mailing list MHTML@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/lists/MHTML/
+The archives are also available by email. Send a message to
+LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get
+a list of the archive files, and then a new message "GET
+<file name>" to retrieve the archive files.
+
+Comments on less important details may also be sent to the
+editor, Jacob Palme <jpalme@dsv.su.se>.
+
+More information may also be available at URL:
+HTTP://dsv.su.se/jpalme/ietf/mhtml.html
+
+
+3.   Introduction
+
+[MHTML] specifies how to send packaged aggregate HTML
+objects in MIME multipart format. This memo is an
+accompanying informational document, intended to be an aid
+to developers. This document is not an Internet standard.
+
+The latest revised version of this document can be find in
+plain text
+and HTML format at
+http://dsv.su.se/jpalme/ietf/mhtml.html#info.
+
+
+4.   Implementation Methods
+
+The [MHTML] standard has been intentionally written to be
+implementable both in cases where a HTML document viewer
+(web browser) and a program receiving MIME objects, such as
+an email program, are combined, and when they are separate
+programs. Implementation is of course easier if the
+document viewer is combined with the MIME receiving client.
+
+Below are described different implementation methods. Real
+implementations may sometimes combine ideas from more than
+one of the different methods described below.
+
+Note: Some document viewers can take a whole document of
+"Content-Type: message" or "Content-Type: multipart" as one
+single file to be displayed. When such viewers are known to
+be used, the problems described below become much easier to
+handle, just submit the whole combined MIME message as a
+single file to the viewer.
+
+4.1  Method 1: Combining Viewer And MIME Receiving Program
+
+This is the architecturally simplest approach. A
+web-browser with a built in MIME receiving program (such as
+an email program) will be able to use its own document
+viewer capabilities to display HTML-formatted messages.
+Since it is the same program, that program will more easily
+be able to connect a URL in the HTML text to a body part in
+the message.
+
+4.2  Method 2: Rewriting The HTML
+
+     +----------+                          +--------+
+     | Document |                          | Mail   |
+     | viewer   |                          | client |
+     +-------+--+                          +-+------+
+             |                               |
+          +--+-------------------------------+--+
+          | +----------+  +--+  +--+            |
+          | | Start    |  |  |  |  | Related    |    Figure 1
+          | | HTML     |  |  |  |  | body part  |
+          | | document |  |  |  |  | parts      |
+          | +----------+  +--+  +--+            |
+          +-------------------------------------+
+
+If the document viewer is separate from the MIME receiving
+client, the MIME client might turn over the HTML body part
+to the document viewer and ask it to display it (Figure 1).
+One way of doing this is to store the HTML body part in a
+file, and ask the document viewer to display this file. If
+multipart/related is used, this can be implemented by
+storing all the body parts within the multipart/related in
+an otherwise empty folder/directory.
+
+The mail client may have to rewrite the HTML, replacing
+URI-s with (possibly relative) URL-s which the Document
+viewer can resolve as file names in the same
+directory/folder where the HTML document itself is stored
+when turning it over to the Document viewer. Problems with
+such rewriting of URIs is discussed in section 5 below.
+
+4.3  Method 3: Using A Translation Table
+
+     +----------+                         +--------+
+     | Document |                         | Mail   |
+     | viewer   |                         | client |
+     +-------+--+                         +-+------+
+             |                              |
+          +--+------------------------------+-+
+          | +--------+  +--+  +--+            |
+          | | Trans-
+  |  |  |  |  | Related    |        Figure 2
+          | | lation |  |  |  |  | body part  |
+          | | table  |  |  |  |  | parts      |
+          | +--------+  +--+  +--+            |
+          +-----------------------------------+
+
+An alternative to rewriting the HTML file before turning it
+over to the Document viewer may be to use a translation
+table, in case the Document viewer has the capability to
+use such a table to rewrite URL-s on the fly while
+displaying the document (Figure 2). This requires that the
+Document viewer is capable of receiving CID: URL-s and
+resolving them using this translation table in the same way
+as for other URL-s.
+
+4.4  Method 4: Using A Proxy HTTP Server To Retrieve
+Referenced Body Parts
+
+     +--------+       +-----------+       +--------+
+     | Proxy  |       | Data base |       | Mail   |
+     | web    |-------| of cached |-------| server |
+     | server |       | objects   |       |        |
+     +----+---+       +-----------+       +----+---+
+          |                                    |
+     +----+-----+                         +----+---+
+     | Document |                         | Mail   |
+     | viewer   |                         | client |
+     +-------+--+                         +-+------+
+             |                              |
+          +--+------------------------------+-+
+          |         Start HTML object         |  Figure 3
+          +-----------------------------------+
+
+Yet another method is to use a proxy web server, to which
+the document viewer requests are sent, and which will then
+use the cached body parts instead of normal web retrieval
+from the network (Figure 3). If the Document viewer is set
+to use this proxy server for all URL-s, including CID
+URL-s, no rewriting of the HTML will be necessary.
+
+4.5  Method 5: Putting The Mail Client Into A Proxy HTTP
+Server
+
+      +--------+--------+
+      | Proxy  | Mail   |
+      |  HTTP  | client |
+      | server |        |
+      +--------+--------+
+               |
+         HTTP protocol              Figure 4
+               |
+          +----+-----+
+          | Document |
+          | Viewer   |
+          +----------+
+
+A mail client can also be included in an HTTP server
+(Figure 4). The user will then not have to install any mail
+client software in his personal computer; all the mail
+functionality is mapped on HTTP and HTML elements.
+
+4.6  Other Methods
+
+The mail client and the document viewer can of course
+communicate in other ways, such as using inter-process
+communication.
+
+4.7  Combined Methods
+
+Several of the methods described above can also be
+combined. The mailer might for example display simpler HTML
+documents itself, but automatically or manually transfer
+the HTML documents to a separate HTML viewer for more
+complex documents.
+
+A common practice in HTML viewers is to simply ignore all
+markups which the viewer does not understand. This
+practice, if implemented in a mailer with limited HTML
+viewing capabilities, might mean that the user is shown a
+very incomplete message without any warning that
+information is missing. In this case, it is better to give
+the user some kind of warning, combined with a command to
+view the letter with a separate HTML viewer, or turn the
+document over automatically to a separate viewer when the
+document contains markup which the mailer cannot render
+itself.
+
+4.8  Communication Between Document Viewer And Mail Client
+
+Many document viewers (web browsers) have API-s to allow
+other programs to communicate with them. There is however
+no accepted real or de-facto standard for such API-s, which
+means that a mail program which relies on such API-s will
+only be able to use those document viewers, whose API they
+support.
+
+Note however, that most of the methods described above can
+be implemented with a very minimal such API. The only API
+function needed is to be able to tell a document viewer,
+when it is started, to open a particular file. And this API
+function is a standardized part of the operating system on
+most platforms. In particular, method 1 and 3 above uses
+the functionality that a relative URL is resolved with the
+location of the base document as base. This means that if
+the base document is a file, relative URL-s will be
+resolved as FILE URL-s in the same directory/folder where
+the HTML document itself is placed.
+
+There is a need for buttons in the Web page which the user
+can use to get back to the mail program again after reading
+the mail with the document viewer. A common technique to
+achieve this is to define a new MIME data type for this
+button. The document viewer is then configured to transfer
+control to the mail client when the user pushes this
+button; i.e. downloads a file of this new MIME type.
+
+
+5.   Problems with Rewriting URIs when Copying HTML
+Documents
+
+Sending of HTML-formatted messages is based on the
+assumption that an HTML documents, together with in-line
+objects like images, applets and frames, can be copied into
+a MIME message. Such copying may require rewriting of URIs
+containing references between the different message parts.
+The MHTML standard [MHTML] has been carefully prepared to
+allow existing web pages to be copied without such
+rewriting, through the use of the Content-Location MIME
+content heading field.
+
+There is however a problem if the source HTML document
+contains relative URIs in parameters to objects and
+applets, such as in the example below:
+From: foo1@bar.net
+To: foo2@bar.net
+Subject: A simple example
+Mime-Version: 1.0
+Content-Type: multipart/related;
+boundary="boundary-example-1";
+                  type=Text/HTML
+Content-Base: "http://www.ietf.cnri.reston.va.us"
+
+--boundary-example 1
+Content-Type: Text/HTML; charset=US-ASCII
+
+   ... text of the HTML document...
+<OBJECT
+    CLASSID = "clsid:5220cb21-c88d-11cf-b347-00aa00a28331">
+    <PARAM NAME="imageurl" VALUE="image.gif">
+</OBJECT>
+...etc...
+
+--boundary-example-1
+Content-Location: "image.gif"
+Content-Type: IMAGE/GIF
+Content-Transfer-Encoding: BASE64
+
+R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk
+5
+..etc...
+
+--boundary-example-1--
+
+From: foo1@bar.net
+To: foo2@bar.net
+Subject: A simple example
+Mime-Version: 1.0
+Content-Type: multipart/related;
+boundary="boundary-example-1";
+                  type=Text/HTML
+Content-Base: "http://www.ietf.cnri.reston.va.us"
+
+--boundary-example 1
+Content-Type: Text/HTML; charset=US-ASCII
+
+   ... text of the HTML document...
+<OBJECT
+    CLASSID = "clsid:5220cb21-c88d-11cf-b347-00aa00a28331">
+    <PARAM NAME="imageurl" VALUE="image.gif">
+</OBJECT>
+...etc...
+
+--boundary-example-1
+Content-Location: "image.gif"
+Content-Type: IMAGE/GIF
+Content-Transfer-Encoding: BASE64
+
+R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk
+5
+..etc...
+
+--boundary-example-1--
+
+
+
+Only the object might know that the imageurl parameter is
+a relative URI. It's nearly impossible for the HTML parser
+to understand that the parameter is a relative URI.  Simply
+searching for "image.gif" is not robust, as the string
+"image.gif" may be used elsewhere. URIs in scripts can also
+have similar problems.
+
+One might envisage even more difficult cases, an applet
+might take a parameter "subject" and another parameter
+"range" and when subject="auto" and range="1-5" it could
+compute, and try to use auto1.gif, auto2.gif ... auto5.gif
+as relative URLs.
+
+Some implementation methods described in section 4 above,
+for example method 2 described in section 4.2, may require
+rewriting of the URIs in the HTML document.
+
+There is no perfect solution to this problem.
+
+One way of alleviating the problem is to produce the
+original document using only absolute URIs, preferably of
+the CID type, since they are more easily identifiable.
+
+Another way of alleviating the problem is to make all URIs
+and Content-Locations into simple relative URIs containing
+file names only (without paths, preferably using a file
+name format common to most platforms, i.e. 1-6 ascii
+letters or digits, a period, and 1-3 extension ascii
+letters or digits). An implementation using method 2
+described in section 4.2 above can then just store the
+parts as files in an empty directory on the recipient
+computer with the Content-Locations as file names. It can
+then turn the start HTML file over to a document viewer,
+and need not rewrite the URIs at all. This simple variant
+of use of the MHTML standard is probably most robust, and
+those implementors who can control the production of the
+HTML documents to be sent are thus recommended to use this
+variant.
+
+
+6.   Caching of Body Parts
+
+Suppose a message contains body parts with the
+Content-Location header as defined in [MHTML]. A receiving
+agent might then put this body part into a web cache, with
+the URI in the Content-Location as its name, so that later
+retrievals of this URI use the cached body parts. There is
+however no guarantee that such a cached item is correct.
+Such caching is thus not recommended for use in other ways
+than for resolution of links within one particular MIME
+message.
+
+The MHTML standard does not cover links between different
+messages, but if you want to implement this, use of Content-
+ID and/or Message-ID, rather than Content-Location, is
+recommended.
+
+If incoming messages are stored in a store where messages
+can be automatically deleted (purged), purging of body
+parts should not occur before purging of the whole message,
+to which they belong.
+
+If an incoming message contains a body part which is linked
+via Content-Location, then no HTTP lookup should be
+performed to check if the body part is recent. The message
+should thus still contain the old HTML document, even if
+the HTTP-available document has been revised. (Example:
+"Here is the weather map of October 29, 1997"). Exception
+from this is:
+
+(a) If the linked document is not enclosed in the message,
+but referred
+     to via Content-Type: message/external-body, then the
+latest version
+     should be shown using ordinary HTTP caching
+conventions.
+
+(b) If a new message is sent with a Supersedes reference to
+the old
+     message, the old message should still show the old
+version of all
+     the body parts, but it might be wise to inform the user
+that a
+     superseding message is available.
+
+
+7.   "Save as" Command
+
+Many HTML viewers have a "Save as" command to save an HTML
+document in a local file. Usually, this command has two
+variants, "Save as text" which converts the HTML document
+to plain text before saving it, and "Save as source" which
+saves the HTML document as an HTML-formatted document.
+
+These two variants may not be enough in the case of MHTML
+documents. There is a third option, which might be named
+"Save as aggregate". This option would save the HTML plus
+all related parts in a file with the Content-Type:
+Multipart/related. The file would thus begin with the
+heading of the Multipart/related body part.
+
+There are two variants of this: Saving the document as it
+looked like when you got it, or saving the document
+including all inline body parts, even those you had to
+retrieve from the Internet when showing the message to the
+user. The second format is of special value, because it
+provides an archiving format of the full document, allowing
+the user to view it in the future as it looked like at one
+particular time, even though web content may change in the
+future.
+
+Finally, a user may also want to save the e-mail or http
+heading fields of an incoming message. This is sometimes
+the same as "Save as aggregate", but may include additional
+body parts before or outside of the mulitpart/related
+aggregate.
+
+To indicate whether such a saved document was received by e-
+mail or http, it might be saved with an additional
+surrounding body part of content-type message/rfc822 or
+message/http.
+
+Example, suppose you receive by e-mail the following
+message:
+
+    MAIL FROM:<alice@bar.net>
+    RCPT TO:<bob@foo.net>
+    DATA
+    From: Alice <alice@bar.net>
+    To: Bob <bob2@foo.net>
+    Date: 23 Jan 1998 10:51
+    Subject: A simple example
+    Mime-Version: 1.0
+    Content-Type: multipart/related; boundary="boundary-example-1";
+                  type="text/html"; start=<foo3@foo1@bar.net>
+
+    --boundary-example-1
+       Content-Type: text/html;charset=US-ASCII
+       Content-ID: <foo3@foo1@bar.net>
+
+       Here is the IETF logo with white background:
+       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
+        ietflogo.gif"
+        ALT="IETF logo with white background">
+       And here is the IETF logo with transparent background:
+       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
+        ietflogo2e.gif"
+       <ALT="IETF logo with transparent background">
+
+    --boundary-example-1
+        Content-Location: ietflogo.gif
+        Content-Base: http://www.ietf.cnri.reston.va.us/images/
+       Content-Type: IMAGE/GIF
+       Content-Transfer-Encoding: BASE64
+
+
+       R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+
+       NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+       etc...
+
+    --boundary-example-1--
+
+
+
+Saving the above message as text might give the following
+file:
+
+    From: Alice <alice@bar.net>
+    To: Bob <bob2@foo.net>
+    Date: 23 Jan 1998 10:51
+    Subject: A simple example
+
+       Here is the IETF logo with white background:
+       IETF logo with white background
+       And here is the IETF logo with transparent
+background:
+       IETF logo with transparent background
+
+Saving the same text as html source might give the
+following file:
+
+       Here is the IETF logo with white background:
+       <IMG
+SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
+        ALT="IETF logo with white background">
+       And here is the IETF logo with transparent background:
+       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
+        ietflogo2e.gif"
+       <ALT="IETF logo with transparent background">
+
+Saving the same text as aggregate might give the following
+file
+
+    From: Alice <alice@bar.net>
+    To: Bob <bob2@foo.net>
+    Date: 23 Jan 1998 10:51
+    Subject: A simple example
+    Mime-Version: 1.0
+    Content-Type: multipart/related; boundary="boundary-example-1";
+                  type="text/html"; start=<foo3@foo1@bar.net>
+
+    --boundary-example-1
+       Content-Type: text/html;charset=US-ASCII
+       Content-ID: <foo3@foo1@bar.net>
+
+       Here is the IETF logo with white background:
+       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
+        ietflogo.gif"
+        ALT="IETF logo with white background">
+       And here is the IETF logo with transparent background:
+       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
+        ietflogo2e.gif"
+       <ALT="IETF logo with transparent background">
+
+    --boundary-example-1
+        Content-Location: ietflogo.gif
+        Content-Base: http://www.ietf.cnri.reston.va.us/images/
+       Content-Type: IMAGE/GIF
+       Content-Transfer-Encoding: BASE64
+
+
+       R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+       NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+       etc...
+
+    --boundary-example-1--
+
+
+
+Saving the same text as archiving aggregate might give the
+following file (where the missing body part is fetched
+through http and added to the saved file):
+
+    From: Alice <alice@bar.net>
+    To: Bob <bob2@foo.net>
+    Date: 23 Jan 1998 10:51
+    Subject: A simple example
+    Mime-Version: 1.0
+    Content-Type: multipart/related; boundary="boundary-example-1";
+                  type="text/html"; start=<foo3@foo1@bar.net>
+
+    --boundary-example-1
+       Content-Type: text/html;charset=US-ASCII
+       Content-ID: <foo3@foo1@bar.net>
+
+       Here is the IETF logo with white background:
+       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
+        ietflogo.gif"
+        ALT="IETF logo with white background">
+       And here is the IETF logo with transparent background:
+       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
+        ietflogo2e.gif"
+       <ALT="IETF logo with transparent background">
+
+    --boundary-example-1
+        Content-Location: ietflogo.gif
+        Content-Base: http://www.ietf.cnri.reston.va.us/images/
+       Content-Type: IMAGE/GIF
+       Content-Transfer-Encoding: BASE64
+
+
+       R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+       NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+       etc...
+
+    --boundary-example-1
+      Content-Location: ietflogo2e.gif
+      Content-Base: http://www.ietf.cnri.reston.va.us/images/
+      Content-Type: IMAGE/GIF
+      Content-Transfer-Encoding: BASE64
+
+
+      R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4
+      SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa
+      etc...
+
+    --boundary-example-1--
+
+
+
+Saving the same message as message might give the following
+file:
+
+    from:<alice@bar.net>
+    To:<bob@foo.net>
+    Mime-Version: 1.0
+    Content-Type: Message/rfc822;
+          boundary="boundary-example-2"
+
+    --boundary-example-2
+    From: Alice <alice@bar.net>
+    To: Bob <bob2@foo.net>
+    Date: 23 Jan 1998 10:51
+    Subject: A simple example
+    Mime-Version: 1.0
+    Content-Type: multipart/related;
+boundary="boundary-example-1";
+                  type="text/html"; start=<foo3@foo1@bar.net>
+
+    --boundary-example-1
+       Content-Type: text/html;charset=US-ASCII
+       Content-ID: <foo3@foo1@bar.net>
+
+       Here is the IETF logo with white background:
+       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
+        ietflogo.gif"
+        ALT="IETF logo with white background">
+       And here is the IETF logo with transparent background:
+       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/
+        ietflogo2e.gif"
+       <ALT="IETF logo with transparent background">
+    --boundary-example-1
+        Content-Location: ietflogo.gif
+        Content-Base: http://www.ietf.cnri.reston.va.us/images/
+       Content-Type: IMAGE/GIF
+       Content-Transfer-Encoding: BASE64
+
+       R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+       NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+       etc...
+
+    --boundary-example-1--
+    --boundary-example-2--
+
+
+
+8.   Recipients which cannot Handle the Multipart/related
+Content-Type
+
+A message sent according to the specifications in [MHTML]
+may have recipients, whose mailers cannot handle the
+Multipart/related Content-Type in the way specified in
+[MHTML].
+
+According to [MIME1] a mailer which encounters an unknown
+subtype to Multipart, should handle this as
+Multipart/mixed.
+
+To improve this, Multipart/alternative can be used as
+discussed in section 9 of this memo.
+
+Content-Disposition, as specified in [CONDISP] and in
+[MHTML], section 10, can also be used as an aid to mailers
+which do not understand Multipart/related.
+
+Captions on images, which are included in the HTML text,
+might for non-HTML-capable recipients be found in the
+Content-Description header [CONDISP]. Do not assume,
+however, that HTML-capable user agents will display the
+Content-Description header, they may assume that this
+information is included in the HTML text instead.
+
+
+9.   Use of the Content-Type: Multipart/alternative
+
+If the message is sent to recipients, all of which may not
+have mailers capable of handling the Text/HTML
+content-type, then the "Content-Type:
+Multipart/Alternative" [MIME1] can be used in two ways:
+
+9.1  Multipart/alternative inside Multipart/related
+
+The Multipart/alternative is put inside the "Content-Type
+Multipart/related", body parts can be specified with
+"Content-Type: Text/plain" as the first choice, and
+"Content-Type: Text/HTML" as the second choice.
+
+Example:
+
+    Content-Type: Multipart/related;
+boundary="boundary-example-1";
+                  type=MULTIPART/ALTERNATIVE
+
+       --boundary-example 1
+       Content-Type: MULTIPART/ALTERNATIVE
+       Boundary: boundary-example-2
+
+          --boundary-example-2
+          Content-Type: Text/plain
+
+          ... plain text version of the document for recipients
+          whose mailers cannot handle Text/HTML ...
+
+          --boundary-example-2
+          Content-Type: Text/HTML; charset=US-ASCII
+          Content-ID: content-id-example@example.host
+
+          ... text of the HTML document ...
+
+          --boundary-example-2--
+       --boundary-example-1
+       Content-Type: Image/GIF
+
+       ... a body part, to which the HTML document has a link  ...
+       --boundary-example-1--
+
+
+
+Note that the type parameter of Multipart/related in this
+case should be Multipart/alternative and not Text/HTML.
+
+
+9.2  Multipart/alternative outside Multipart/related
+
+The multipart/alternative is put outside the
+Multipart/Related, with Multipart/Related as one
+alternative and Multipart/Mixed as the other alternative.
+Note however that the [MHTML] does not recommend links from
+inside Multipart/Related to objects outside of the
+Multipart/Related, so putting inline images outside the
+Multipart/Related is not suitable. Instead, such inline
+images may have to repeated in both branches of the
+multipart/alternative with this method.
+
+Example:
+
+    Content-Type: MULTIPART/ALTERNATIVE
+    Boundary: boundary-example-1
+
+    --boundary-example-1
+       Content-Type: Multipart/mixed; boundary="boundary-example-3"
+
+       --boundary-example-3
+          Content-Type: Text/plain; charset=US-ASCII
+
+          ... plain text version of the message for recipients
+          whose mailers cannot handle Text/HTML ...
+
+       --boundary-example-3
+       Content-Type: Image/GIF
+
+          ... A picture associated with the plain text message  ...
+       --boundary-example-3--
+
+    --boundary-example-1
+       Content-Type: Multipart/related; boundary="boundary-example-1";
+                     type=Text/HTML
+
+       --boundary-example 2
+          Content-Type: Text/HTML; charset=US-ASCII
+          Content-ID: content-id-example@example.host
+
+          ... text of the HTML document ...
+
+       --boundary-example-2
+       Content-Type: Image/GIF
+
+          ... a body part, to which the HTML document has a link  ...
+       --boundary-example-2--
+    --boundary-example-1--
+
+
+9.3  Comparing the Two Methods
+
+When choosing between these two methods of employing
+multipart/alternative, note the following:
+
+  (1)  Clients which do not support Multipart/related,
+       and which thus will interpret it as
+       Multipart/mixed, will with choice 9.1 display the
+       inline objects. Thus, a recipient whose mailer
+       can handle image/gif but not multipart/related
+       will still be shown the images, they will not be
+       suppressed by being inside a suppressed branch of
+       the Multipart/alternative.
+
+(2)   Choice 9.2 will not show inline images in the
+       Multipart/Related, unless this information is
+       repeated in both branches of the
+       Multipart/Alternative.
+
+A general warning: Some mailers do not support
+"Content-Type: Multipart/alternative", and may then
+interpret it as Multipart/mixed, even though support of
+multipart/alternative is required for MIME conformance.
+
+
+9.4  Reducing the Download Time
+
+If a message is sent as multipart/alternative, this would
+normally mean that the mail client downloads both variants,
+and then shows only one of the to the user. This will thus
+increase the download time. A way of avoiding this problem
+is to use the FETCH command of IMAP, which allows a client
+to download only certain body parts from a multipart
+message.
+
+
+10.  Writing Readable HTML
+
+An alternative to use of multipart/alternative is to
+produce HTML code which is is easy to read as it is. This
+alternative only works if you restrict the use of HTML
+features, for example if you have a special program to
+generate the HTML text.
+
+Below is an example of such a readable HTML text:
+
+<p>   This is an example of HTML code, which is written
+       so as to be readable for people who read it as
+       plain text.
+
+<p>   Here is the second paragraph, which contains a
+          <a href="cid:456*foo@bar.net"> link
+</a>  to a separate body part.
+<p>   Here is an embedded picture:
+
+<p>      <img src="cid:123*foo@bar.net" width="13" height="13">
+
+<p>   End of this HTML-formatted message.
+
+
+
+11.  Textual Alternatives to HTML Forms
+
+One important usage of HTML in e-mail is to send forms,
+which the recipients fill in and return. It is then
+problematic how to handle recipients whose mailers do not
+support HTML. One way is to use textual encoding of the
+forms. This encoding is done so that the user action needed
+to send in the form is made simple also for those who have
+only textual e-mail systems. Important is that the textual
+users are not forced to write complex commands in special
+command languages. Instead, the form should be written so
+that the user need only make simple changes to the form
+before sending it back, like deleting or adding single
+characters.
+
+Below is an example which shows how this can be done. The
+main principle is that every line beginning with ";" is an
+explanation for the reader, and every line beginning with
+"!" is a text, which the user can convert into a command by
+just deleting the "!" in front of the line.
+
+The users will thus have to learn a very simple rule of
+filling in forms: Just delete the "!" in front of your
+selections.
+
+Technically, the recipient of a filled-in textual form
+should regard all lines beginning with ";" or "!" as
+comment, and interpret all other lines as commands.
+
+11.1 Form in HTML Format
+
+<FORM action="mailto:meeting-scheduling@ietf.org"
+method="POST">
+
+<P>Which meeting date do you prefer?
+
+<P>1 December 1997 <SELECT NAME="19971201">
+    <OPTION>Very good
+    <OPTION>Good
+    <OPTION>Acceptable
+    <OPTION>Bad
+    <OPTION>Very bad
+</SELECT>
+
+<P>7 December 1997 <SELECT NAME="19971207">
+    <OPTION>Very good
+    <OPTION>Good
+    <OPTION>Acceptable
+    <OPTION>Bad
+    <OPTION>Very bad
+</SELECT>
+
+<P>14 December 1997 <SELECT NAME="19971214">
+    <OPTION>Very good
+    <OPTION>Good
+    <OPTION>Acceptable
+    <OPTION>Bad
+    <OPTION>Very bad
+</SELECT>
+
+<P>21 December 1997 <SELECT NAME="19971221">
+    <OPTION>Very good
+    <OPTION>Good
+    <OPTION>Acceptable
+    <OPTION>Bad
+    <OPTION>Very bad
+</SELECT>
+
+<P>Who should be the chairman?
+
+<P><INPUT TYPE="radio" NAME="chairman" VALUE="Mary">Mary
+
+<P><INPUT TYPE="radio" NAME="chairman" VALUE="John">John
+
+<P>Do you want simultaneous translation during the meeting?
+
+<P><INPUT TYPE="checkbox" NAME="translation"
+VALUE="English">To and
+from English
+
+<P><INPUT TYPE="checkbox" NAME="translation"
+VALUE="French">To and
+from French
+
+<P><INPUT TYPE="checkbox" NAME="translation"
+VALUE="Japanese">To and
+from Japanese
+
+<P>Please propose issues to discuss during the meeting:
+
+<P><TEXTAREA NAME="issues" ROWS=7 COLS=66></TEXTAREA>
+
+<P><INPUT TYPE="submit" NAME="Submit"
+VALUE="Submit"><INPUT TYPE="reset" VALUE="Reset">
+
+
+11.2 The same Form In Textual Format
+
+; This is a computer-generated form. Please fill it in and return it
+; to meeting-scheduler@ietf.org. To fill in the form, just copy its
+; text into your reply and remove the exclamation mark (!) in front
+; of your choices.
+
+; If your mailer adds ">" or "> " in front of lines, you can keep
+; these or remove them as you prefer.
+
+Question 1: Which meeting date do you prefer?
+
+Option 1.1: 1 December 1997
+! Very good
+! Good
+! Acceptable
+! Bad
+! Very bad
+
+Option 1.2: 7 December 1997
+! Very good
+! Good
+! Acceptable
+! Bad
+! Very bad
+
+Option 1.3: 14 December 1997
+! Very good
+! Good
+! Acceptable
+! Bad
+! Very bad
+
+Option 1.4: 21 December 1997
+! Very good
+! Good
+! Acceptable
+! Bad
+! Very bad
+
+Question 2: Who should be the chairman?
+! Mary
+! John
+
+Question 3: Do you want simultaneous translation during the
+meeting?
+
+Option 3.1: To and from English
+! Yes
+! No
+
+Option 3.2: To and from French
+! Yes
+! No
+
+Option 3.3: To and from Japanese
+! Yes
+! No
+
+Question 4: Please propose issues to discuss during the
+meeting.
+Write your proposal on the empty lines below.
+
+
+
+
+
+
+-- End of Question 4
+
+
+
+12.  Recipient may not have Full Internet Connectivity
+
+The recipient of a message sent by email may not always
+have full Internet connectivity. The recipient may be
+behind a gateway or firewall which prohibits or restricts
+Internet connectivity.
+
+This means that the recipient may not be able to resolve
+URI-s in an email message, unless the referred-to documents
+are included in the email message itself. Thus, it is often
+suitable to include in an email message all documents which
+are referred to (directly or indirectly) by URI-s in the
+message. This may of course not always be possible, in some
+cases the set of referred-to documents (directly or
+indirectly) may be the whole WWW document space, i.e.
+millions of documents. A choice must then be made how much
+to include. Of course, it is most important to include all
+inline objects, i.e. objects linked by such hyperlinks as
+IMG, etc., which specify that the linked objects are to be
+shown to the user immediately.
+
+In the case of ACTION elements in HTML forms, by making
+these ACTION elements of the "mailto:" URL type, rather
+than the "http:" URL type, you will enable also recipients
+without full Internet connectivity to fill in and send in
+your forms. The HTML specification [HTML2] allows default
+action when no ACTION element is included, but this default
+action may not be suitable when sending the HTML document
+via email. Thus, it is better to always put an explicit
+ACTION element into HTML forms sent by email.
+
+A disadvantage with the "mailto:" URL as ACTION, however,
+is that this may not work if the user has not specified his
+e-mail address in the preferences of this HTML viewer. This
+is common for multi-user workstations.
+
+Including URLs, which have to resolved over the Internet,
+typically referring to 1x1 pixel transparent images, is a
+known method for spammers to get information about the
+recipient of e-mail. It is possible that some mailers will
+restrict or disallow this in order to stop this method of
+information-gathering by spammers.
+
+
+Encoding of Non-Ascii Characters
+
+          Displayed text                        Displayed text
+                |                                     ^
+                V                                     |
+          +-------------+                       +----------------+
+          | HTML editor |                       | HTML viewer    |
+          |             |                       | or Web browser |
+          +-------------+                       +----------------+
+              |                                       ^
+              V                                       |
+          HTML markup                             HTML markup
+              |                                       ^
+              V                                       |
+   +---------+ +---------------+       +-------------+ +---------------+
+   | MIME    | | MIME content- |       | MIME        | | MIME content- |
+   | encap-  | | transfer-     |       | heading     | | transfer-     |
+   | sulator | | encoder       |       | interpreter | | decoder       |
+   +---------+ +---------------+       +-------------+ +---------------+
+     |              |                            ^              ^
+     V              V         +-----------+      |              |
+MIME heading + MIME content->| Transport |->MIME heading + MIME content
+                              +-----------+
+
+                                Figure 5
+
+Definitions (see Figure 5):
+
+Displayed     A visual representation of the intended
+text          text.
+
+HTML markup   A sequence of characters formatted
+               according to the HTML specification
+               [HTML2].
+
+MIME content  A sequence of octets physically forwarded
+               via email, may use MIME content-transfer-
+               encoding as specified in [MIME1].
+
+HTML editor   Software used to produce HTML markup.
+
+MIME content- Software used to encode non-US-ASCII
+transfer-     charactersr as specified in [MIME1].
+encoder
+
+MIME content- Software used to decode non-US-ASCII
+transfer-     characters as specified in [MIME1].
+decoder
+
+MIME heading  Software used to interpret the information
+interpreter   in MIME  headings.
+
+HTML viewer   Software used to display HTML documents to
+               recipients.
+
+Some implementations may have a choice of whether to
+represent non-ascii characters at the HTML layer (using "&"
+entity references or numeric character references as
+defined in [HTML2] section 3.2.1) or at the MIME layer
+(using Content-Transfer-Encoding as defined in [MIME1]
+section 5).
+
+In choosing between these two representation methods, note
+the following effects:
+
+(1)   Modifying HTML markup may disrupt security content
+       integrity  checksums. If the checksums are computed
+       between the HTML editor  and the MIME encapsulator,
+       then making the encoding in the MIME  encapsulator
+       will not break the checksums.
+
+(2)   The choice of modifying HTML markup may be more
+       suitable for  recipients whose mailers do not
+       support MIME.
+
+(3)   Using MIME Content-Transfer-Encoding may be more
+       suitable for  recipients who have MIME-compliant
+       mailers but do pass the text over  to a document
+       viewer (web browser).
+
+
+14.  Conversion from HTTP to MIME
+
+Information received or retrieved using HTTP cannot always
+be sent unchanged as email using the "Content-Type:
+Text/HTML", because of the restrictions which MIME places
+on the format of "Content-Type: Text/HTML". The same
+problem may occur for documents retrieved via HTTP, which
+are in other textual formats than HTML. In particular, note
+the following:
+
+(a)  Content-encodings allowed in HTTP, but not allowed in
+      MIME, must  be removed.
+
+(b)  HTTP allows line breaks as bare CRs or bare LFs or
+      something  else, while MIME only allows line breaks as
+      CRLF in subtypes  of the Text content-type.
+
+(c)  HTTP allows character sets like Unicode-1-1, which do
+      not  represent line breaks as CRLFs, such text may have
+      to be  rewritten to character sets like
+      Unicode-1-1-UTF-7 in which  line breaks are represented
+      as CRLFs.
+
+A good overview of the differences, with regard to the use
+of "Content-Type: Text", between MIME and HTTP, can be
+found in [HTTP] appendix C.
+
+If you want to provide web documents, which can be sent
+through e-mail without modification (which might break
+integrity checksums), then you SHOULD provide them up in
+the canonical form, with line breaks as CRLF, and avoid
+lines longer than 76 characters/line.
+
+If you want to send HTTP unchanged via email, you might
+consider using the "Content-Type: Message/HTTP" instead of
+the "Content-Type: Text/HTML". Note that with this Content-
+Type, the whole object, as sent through HTTP, can be
+encoded as a single object with, for example, BASE64
+encoding. After decoding of the BASE64, the resulting
+object can have HTTP peculiar formats, like single LF or
+single CR between lines. However, some mailers may not be
+capable of handling the Message/HTTP Content-Type.
+
+Example, the binary part of the following message
+
+    Content-Type: message/http
+    Content-Transfer-Encoding: base64
+
+
+SFRUUC8xLjEgMjAwIE9LDURhdGU6IFNhdCwgMTQgRmViIDE5OTggMTM6MDM
+6MzggR01U
+
+DVNlcnZlcjogQXBhY2hlLzEuMi40DUxhc3QtTW9kaWZpZWQ6IFdlZCwgMjM
+gSnVsIDE5
+    ... ... ...
+
+
+might, when the base64 encoding above is decoded, yield:
+
+    HTTP/1.1 200 OK
+    Date: Sat, 14 Feb 1998 13:03:38 GMT
+    ETag: "43788-124-33d658c5"
+    Content-Length: 292
+    Accept-Ranges: bytes
+    Content-Type: text/html
+
+    ... <HTML data with only LF between lines> ...
+
+
+
+15.  Default Font Size
+
+Many HTML editors and viewers allow the user to specify the
+size of the default font (<FONT SIZE=3> or <FONT SIZE="+0">
+according to personal wishes, for example 10 pt or 12 pt or
+14 pt depending on eye sight and screen distance. This
+setting should *not* cause a change in the FONT SIZE= value
+in the generated HTML which is produced and sent. The
+reason for this is that otherwise users may inadvertently
+send whole letters with the text in <FONT SIZE=1> or <FONT
+SIZE=2>, which may be easy to read for the sender but
+difficult to read for some recipients.
+
+Similarly, a user choice of default FONT, to for example
+GENEVA or ARIAL, should not cause <FONT FACE=GENEVA> or
+<FONT FACE=ARIAL> to be sent. User who wish to send e-mail
+with <FONT SIZE=2> or <FONT FACE=GENEVA> must explicitly
+specify this, for example using a FONT command in their
+HTML editor or e-mail text editor.
+
+
+16.  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.
+
+
+17.  Acknowledgments
+
+Harald Tveit Alvestrand, Richard Baker, Dave Crocker,
+Martin J. Duerst, Roy Fielding, Lewis Geer, Al Gilman, Paul
+Hoffman, Alexander Hopmann, Mark K. Joseph, Greg Herlihy,
+Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay
+Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin
+Nicol, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie
+Zawinski and several other people have helped us with
+preparing this memo. I alone take responsibility for any
+errors which may still be in the memo.
+
+
+18.  References
+
+Temporary note: This list contains some references to
+Internet drafts. It is anticipated that these Internet
+drafts will become RFC-s before this memo. The references
+will then in this memo be changed to refer to the
+corresponding RFC instead. This list also includes some
+RFC-s which are not up to date, and which will be replaced
+by new memos presently in ietf draft status.
+
+Ref.       Author, title
+---        -------------
+
+[CONDISP]  R. Troost, S. Dorner: "Communicating
+            Presentation Information in Internet Messages:
+            The Content- Disposition Header", RFC 1806, June
+            1995.
+
+[HOSTS]    R. Braden (editor): "Requirements for Internet
+            Hosts -- Application and Support", STD-3, RFC
+            1123, October 1989.
+
+[HTML2]    T. Berners-Lee, D. Connolly: "Hypertext Markup
+            Language - 2.0", RFC 1866, November 1995.
+
+[HTTP]     J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
+            Berners-Lee: 2616 Hypertext Transfer Protocol --
+            HTTP/1.1. R. Fielding, J. Gettys, RFC 2616, June
+            1999.
+
+[MHTML]    J. Palme, A. Hopmann, N. Shelness: MIME
+            Encapsulation of Aggregate Documents, such as
+            HTML (MHTML). RFC 2557, March 1999.
+
+[MIDCID]   E. Levinson.: Content-ID and Message-ID Uniform
+            Resource Locators. RFC 2392, August 1998.
+
+[MIME1]    N. Freed & N. Borenstein: "MIME (Multipurpose
+            Internet Mail Extensions) Part One: Mechanisms
+            for Specifying and Describing the Format of
+            Internet Message Bodies", RFC 2045, November
+            1996.
+
+[MIME2]    N. Freed & N. Borenstein: "Multipurpose Internet
+            Mail Extensions (MIME) Part Two: Media Types".
+            RFC 2046, November 1996.
+
+[NEWS]     M.R. Horton, R. Adams: "Standard for interchange
+            of USENET messages", RFC 1036, December 1987.
+
+[REL]      E. Levinson.: The MIME Multipart/Related Content-
+            type. RFC 2387, August 1998.
+
+[RELURL]   R. Fielding: "Relative Uniform Resource
+            Locators", RFC 1808, June 1995.
+
+[MSGFMT]   P. Resnick: "Internet Message Format" STD 11,
+            RFC 2822, April 2001.
+
+[SMTP]     J. Klensin: "Simple Mail Transfer Protocol", RFC
+            2821, April 2001.
+
+[URL]      T. Berners-Lee, L. Masinter, M. McCahill:
+            "Uniform Resource Locators (URL)", RFC 1738,
+            December 1994.
+
+[URLBODY]  N. Freed and Keith Moore: "Definition of the URL
+            MIME External-Body Access-Type", RFC 2017,
+            October 1996.
+
+19.  Author's Address
+
+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
+
+Working group chairman:
+
+Einar Stefferud <stef@nma.com>
diff --git a/Documentation/en/I-D/index.html b/Documentation/en/I-D/index.html
index 4bdcd528..862dd8a6 100644
--- a/Documentation/en/I-D/index.html
+++ b/Documentation/en/I-D/index.html
@@ -1,13 +1,6 @@
 <UL>
 <LI> A (autosub)
 <UL>   <LI>
-   <A HREF="draft-palme-autosub-07.txt">
-   draft-palme-autosub-07.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
    <A HREF="draft-palme-autosub-03.txt">
    draft-palme-autosub-03.txt
    </A>
@@ -17,6 +10,13 @@
 	    Loop control for the Auto-Submitted e-mail header
 
 
+   <LI>
+   <A HREF="draft-palme-autosub-07.txt">
+   draft-palme-autosub-07.txt
+   </A>
+	This Internet-Draft has been deleted.
+
+
 </UL><LI> B (bsmtp)
 <UL>   <LI>
    <A HREF="draft-freed-bsmtp-02.txt">
@@ -55,6 +55,13 @@
 
 
    <LI>
+   <A HREF="draft-ietf-drums-mail-followup-to-01.txt">
+   draft-ietf-drums-mail-followup-to-01.txt
+   </A>
+	This Internet-Draft has been deleted.
+
+
+   <LI>
    <A HREF="draft-ietf-drums-smtpupd-09.txt">
    draft-ietf-drums-smtpupd-09.txt
    </A>
@@ -64,16 +71,6 @@
 
 
    <LI>
-   <A HREF="draft-ietf-drums-mail-followup-to-00.txt">
-   draft-ietf-drums-mail-followup-to-00.txt
-   </A>
-	Internet Draft                                 Stockholm University/KTH
-	draft-ietf-drums-mail-followup-to-00.txt
-	Expires: May 1998                                         November 1997
-	The ''Mail-Followup-To'' header
-
-
-   <LI>
    <A HREF="draft-ietf-drums-smtpupd-13.txt">
    draft-ietf-drums-smtpupd-13.txt
    </A>
@@ -86,14 +83,13 @@
    <A HREF="draft-palme-e-mail-translation-03.txt">
    draft-palme-e-mail-translation-03.txt
    </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-bernstein-eplf-06.txt">
-   draft-bernstein-eplf-06.txt
-   </A>
-	This Internet-Draft has been deleted.
+	Internet Draft                                   Stockholm
+	draft-palme-e-mail-translation-03.txt       University/KTH
+	                                                     Sweden
+	Category-to-be: Proposed standard      Date: December 2001
+	                                         Expires: June 2001
+	                   Support for Language Translation
+	                        in E-Mail and Netnews
 
 
    <LI>
@@ -104,16 +100,8 @@
 
 
    <LI>
-   <A HREF="draft-melnikov-esmtp-lang-00.txt">
-   draft-melnikov-esmtp-lang-00.txt
-   </A>
-	Internet Draft

-	                          SMTP Language Extension

-
-
-   <LI>
-   <A HREF="draft-ward-esmtp-slide-04.txt">
-   draft-ward-esmtp-slide-04.txt
+   <A HREF="draft-bernstein-eplf-06.txt">
+   draft-bernstein-eplf-06.txt
    </A>
 	This Internet-Draft has been deleted.
 
@@ -126,26 +114,23 @@
    <A HREF="../rfc/rfc3030.txt">RFC3030</A>
 
 
-</UL><LI> F (fax)
-<UL>   <LI>
-   <A HREF="draft-ietf-fax-esmtp-conneg-01.txt">
-   draft-ietf-fax-esmtp-conneg-01.txt
+   <LI>
+   <A HREF="draft-ward-esmtp-slide-04.txt">
+   draft-ward-esmtp-slide-04.txt
    </A>
-	Internet Draft                       D. Crocker, Brandenburg
-	  draft-ietf-fax-esmtp-conneg-01.txt           November 2001
-	Expires: May 2002
-	                   SMTP Service Extension
-	           for Content Negotiation of Internet Fax
+	This Internet-Draft has been deleted.
 
 
    <LI>
-   <A HREF="draft-ietf-fax-smtp-capabilities-01.txt">
-   draft-ietf-fax-smtp-capabilities-01.txt
+   <A HREF="draft-melnikov-esmtp-lang-00.txt">
+   draft-melnikov-esmtp-lang-00.txt
    </A>
-	This Internet-Draft has been deleted.
+	Internet Draft

+	                          SMTP Language Extension

 
 
-   <LI>
+</UL><LI> F (fax)
+<UL>   <LI>
    <A HREF="draft-ietf-fax-smtp-session-04.txt">
    draft-ietf-fax-smtp-session-04.txt
    </A>
@@ -158,6 +143,24 @@
 	                   draft-ietf-fax-smtp-session-04.txt
 
 
+   <LI>
+   <A HREF="draft-ietf-fax-smtp-capabilities-01.txt">
+   draft-ietf-fax-smtp-capabilities-01.txt
+   </A>
+	This Internet-Draft has been deleted.
+
+
+   <LI>
+   <A HREF="draft-ietf-fax-esmtp-conneg-01.txt">
+   draft-ietf-fax-esmtp-conneg-01.txt
+   </A>
+	Internet Draft                       D. Crocker, Brandenburg
+	  draft-ietf-fax-esmtp-conneg-01.txt           November 2001
+	Expires: May 2002
+	                   SMTP Service Extension
+	           for Content Negotiation of Internet Fax
+
+
 </UL><LI> H (hcmssc)
 <UL>   <LI>
    <A HREF="draft-bernstein-hcmssc-02.txt">
@@ -233,7 +236,7 @@
 	                Anti-UBE and Anti-UCE Keywords in SMTP Banners
 
 
-</UL><LI> M (mail mailext maillist mhregistry mpls msgtrk)
+</UL><LI> M (mail mailext maillist mhregistry mhtml mpls msghdr msgtrk)
 <UL>   <LI>
    <A HREF="draft-bernstein-mail-loops-war-02.txt">
    draft-bernstein-mail-loops-war-02.txt
@@ -249,6 +252,14 @@
 
 
    <LI>
+   <A HREF="draft-ietf-mailext-mail-attributes-07.txt">
+   draft-ietf-mailext-mail-attributes-07.txt
+   </A>
+	A new Request for Comments is now available in online RFC libraries.
+   <A HREF="../rfc/rfc2076.txt">RFC2076</A>
+
+
+   <LI>
    <A HREF="draft-palme-mailext-headers-06.txt">
    draft-palme-mailext-headers-06.txt
    </A>
@@ -261,14 +272,6 @@
 
 
    <LI>
-   <A HREF="draft-ietf-mailext-mail-attributes-07.txt">
-   draft-ietf-mailext-mail-attributes-07.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2076.txt">RFC2076</A>
-
-
-   <LI>
    <A HREF="draft-palme-maillist-01.txt">
    draft-palme-maillist-01.txt
    </A>
@@ -286,46 +289,36 @@
 
 
    <LI>
-   <A HREF="draft-bernstein-mpls-sonet-01.txt">
-   draft-bernstein-mpls-sonet-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-ietf-msgtrk-smtpext-03.txt">
-   draft-ietf-msgtrk-smtpext-03.txt
+   <A HREF="draft-palme-mhtml-info-01.txt">
+   draft-palme-mhtml-info-01.txt
    </A>
-	Internet Draft                                               E. Allman
-	draft-ietf-msgtrk-smtpext-03.txt                        Sendmail, Inc.
-	Valid for six months                                         T. Hansen
-	Updates: RFC 1891                                    AT&T Laboratories
-	                                                      November 2, 2001
-	                        SMTP Service Extension
-	                         for Message Tracking
-	                  <draft-ietf-msgtrk-smtpext-03.txt>
+	Internet Draft                                 Stockholm
+	draft-palme-mhtml-info-01.txt             University/KTH
+	                                            December 2001
+	Category-to-be:
+	Informational
+	Expires: June 2001
+	              Sending HTML in MIME,
+	     an informational supplement to the RFC:
+	     MIME Encapsulation of Aggregate Documents,
+	              such as HTML (MHTML)
 
 
    <LI>
-   <A HREF="draft-ietf-msgtrk-trkstat-03.txt">
-   draft-ietf-msgtrk-trkstat-03.txt
+   <A HREF="draft-bernstein-mpls-sonet-01.txt">
+   draft-bernstein-mpls-sonet-01.txt
    </A>
-	Internet Draft                                               E. Allman
-	draft-ietf-msgtrk-trkstat-03.txt                        Sendmail, Inc.
-	Valid for six months                                  November 2, 2001
-	Updates: RFC 1893
-	              The Message/Tracking-Status MIME Extension
-	                  <draft-ietf-msgtrk-trkstat-03.txt>
+	This Internet-Draft has been deleted.
 
 
    <LI>
-   <A HREF="draft-jones-msgtrk-def-02.txt">
-   draft-jones-msgtrk-def-02.txt
+   <A HREF="draft-klyne-msghdr-registry-01.txt">
+   draft-klyne-msghdr-registry-01.txt
    </A>
-	This Internet-Draft has expired and is no longer available.
-	Unrevised documents placed in the Internet-Drafts directories have a
-	maximum life of six months. After that time, they must be updated, or
-	they will be deleted. This document was deleted on March 20, 2000.
+	Internet-Draft                                         MIMEsweeper Group
+	Expires: July 5, 2002                                        Jan 4, 2002
+	              Registration procedures for message headers
+	                     draft-klyne-msghdr-registry-01
 
 
    <LI>
@@ -368,6 +361,42 @@
 
 
    <LI>
+   <A HREF="draft-jones-msgtrk-def-02.txt">
+   draft-jones-msgtrk-def-02.txt
+   </A>
+	This Internet-Draft has expired and is no longer available.
+	Unrevised documents placed in the Internet-Drafts directories have a
+	maximum life of six months. After that time, they must be updated, or
+	they will be deleted. This document was deleted on March 20, 2000.
+
+
+   <LI>
+   <A HREF="draft-ietf-msgtrk-trkstat-03.txt">
+   draft-ietf-msgtrk-trkstat-03.txt
+   </A>
+	Internet Draft                                               E. Allman
+	draft-ietf-msgtrk-trkstat-03.txt                        Sendmail, Inc.
+	Valid for six months                                  November 2, 2001
+	Updates: RFC 1893
+	              The Message/Tracking-Status MIME Extension
+	                  <draft-ietf-msgtrk-trkstat-03.txt>
+
+
+   <LI>
+   <A HREF="draft-ietf-msgtrk-smtpext-03.txt">
+   draft-ietf-msgtrk-smtpext-03.txt
+   </A>
+	Internet Draft                                               E. Allman
+	draft-ietf-msgtrk-smtpext-03.txt                        Sendmail, Inc.
+	Valid for six months                                         T. Hansen
+	Updates: RFC 1891                                    AT&T Laboratories
+	                                                      November 2, 2001
+	                        SMTP Service Extension
+	                         for Message Tracking
+	                  <draft-ietf-msgtrk-smtpext-03.txt>
+
+
+   <LI>
    <A HREF="draft-ietf-msgtrk-protocol-05.txt">
    draft-ietf-msgtrk-protocol-05.txt
    </A>
@@ -421,34 +450,34 @@
 
 
    <LI>
-   <A HREF="draft-bernstein-nrudt-06.txt">
-   draft-bernstein-nrudt-06.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
    <A HREF="draft-bernstein-nrudt-02.txt">
    draft-bernstein-nrudt-02.txt
    </A>
 	Notice-Requested-Upon-Delivery-To (NRUDT)
 
 
-</UL><LI> O (owner)
-<UL>   <LI>
-   <A HREF="draft-bernstein-owner-hack-05.txt">
-   draft-bernstein-owner-hack-05.txt
+   <LI>
+   <A HREF="draft-bernstein-nrudt-06.txt">
+   draft-bernstein-nrudt-06.txt
    </A>
 	This Internet-Draft has been deleted.
 
 
-   <LI>
+</UL><LI> O (owner)
+<UL>   <LI>
    <A HREF="draft-bernstein-owner-hack-01.txt">
    draft-bernstein-owner-hack-01.txt
    </A>
 	The Owner Hack
 
 
+   <LI>
+   <A HREF="draft-bernstein-owner-hack-05.txt">
+   draft-bernstein-owner-hack-05.txt
+   </A>
+	This Internet-Draft has been deleted.
+
+
 </UL><LI> P (palme pirp)
 <UL>   <LI>
    <A HREF="draft-ietf-palme-select-00.txt">
@@ -477,17 +506,17 @@
 
 </UL><LI> Q (qmtp qsbmf)
 <UL>   <LI>
-   <A HREF="draft-bernstein-qmtp-01.txt">
-   draft-bernstein-qmtp-01.txt
+   <A HREF="draft-bernstein-qmtp-05.txt">
+   draft-bernstein-qmtp-05.txt
    </A>
-	Quick Mail Transfer Protocol (QMTP)
+	This Internet-Draft has been deleted.
 
 
    <LI>
-   <A HREF="draft-bernstein-qmtp-05.txt">
-   draft-bernstein-qmtp-05.txt
+   <A HREF="draft-bernstein-qmtp-01.txt">
+   draft-bernstein-qmtp-01.txt
    </A>
-	This Internet-Draft has been deleted.
+	Quick Mail Transfer Protocol (QMTP)
 
 
    <LI>
@@ -506,22 +535,22 @@
 
 </UL><LI> R (rfc2487bis)
 <UL>   <LI>
-   <A HREF="draft-hoffman-rfc2487bis-00.txt">
-   draft-hoffman-rfc2487bis-00.txt
+   <A HREF="draft-hoffman-rfc2487bis-06.txt">
+   draft-hoffman-rfc2487bis-06.txt
    </A>
 	Internet Draft                                          Paul Hoffman
-	<draft-hoffman-rfc2487bis-00.txt>           Internet Mail Consortium
-	April 15, 1999
+	draft-hoffman-rfc2487bis-06.txt             Internet Mail Consortium
+	November 4, 2001
 	            SMTP Service Extension for Secure SMTP over TLS
 
 
    <LI>
-   <A HREF="draft-hoffman-rfc2487bis-06.txt">
-   draft-hoffman-rfc2487bis-06.txt
+   <A HREF="draft-hoffman-rfc2487bis-00.txt">
+   draft-hoffman-rfc2487bis-00.txt
    </A>
 	Internet Draft                                          Paul Hoffman
-	draft-hoffman-rfc2487bis-06.txt             Internet Mail Consortium
-	November 4, 2001
+	<draft-hoffman-rfc2487bis-00.txt>           Internet Mail Consortium
+	April 15, 1999
 	            SMTP Service Extension for Secure SMTP over TLS
 
 
@@ -541,6 +570,13 @@
 
 
    <LI>
+   <A HREF="draft-bose-smtp-integrity-00.txt">
+   draft-bose-smtp-integrity-00.txt
+   </A>
+	        CHECKING OF MESSAGE INTEGRITY DURING SMTP TRANSACTIONS
+
+
+   <LI>
    <A HREF="draft-hoffman-smtp-ssl-09.txt">
    draft-hoffman-smtp-ssl-09.txt
    </A>
@@ -551,13 +587,6 @@
 
 
    <LI>
-   <A HREF="draft-bose-smtp-integrity-00.txt">
-   draft-bose-smtp-integrity-00.txt
-   </A>
-	        CHECKING OF MESSAGE INTEGRITY DURING SMTP TRANSACTIONS
-
-
-   <LI>
    <A HREF="draft-khanna-smtp-mail-transfer-reliability-01.txt">
    draft-khanna-smtp-mail-transfer-reliability-01.txt
    </A>
@@ -644,18 +673,17 @@
 
 
    <LI>
-   <A HREF="draft-ietf-vpim-pndn-01.txt">
-   draft-ietf-vpim-pndn-01.txt
+   <A HREF="draft-ema-vpim-pndn-04.txt">
+   draft-ema-vpim-pndn-04.txt
    </A>
 	This Internet-Draft has been deleted.
 
 
    <LI>
-   <A HREF="draft-burger-vpim-pc-01.txt">
-   draft-burger-vpim-pc-01.txt
+   <A HREF="draft-ietf-vpim-pndn-01.txt">
+   draft-ietf-vpim-pndn-01.txt
    </A>
-	This document has been replaced by draft-ietf-vpim-hint-00.txt.

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

+	This Internet-Draft has been deleted.
 
 
    <LI>
@@ -681,10 +709,11 @@
 
 
    <LI>
-   <A HREF="draft-ema-vpim-pndn-04.txt">
-   draft-ema-vpim-pndn-04.txt
+   <A HREF="draft-burger-vpim-pc-01.txt">
+   draft-burger-vpim-pc-01.txt
    </A>
-	This Internet-Draft has been deleted.
+	This document has been replaced by draft-ietf-vpim-hint-00.txt.

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

 
 
 </UL></UL>