Network Working Group                                  Jacob Palme
Internet Draft                    Stockholm University/KTH, Sweden
draft-ietf-drums-MHRegistry-03.txt                   January  1998
Category-to-be: Informational                  Expires August 1998





        Mail and Netnews Header field Registration Procedure

                    Status of this Memo



  This document is an Internet-Draft.  Internet-Drafts are working
  documents of the Internet Engineering Task Force (IETF), its
  areas, and its working groups.  Note that other groups may also
  distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time.  It is inappropriate to use Internet-
  Drafts as reference material or to cite them other than as
  ``work in progress.''

  To learn the current status of any Internet-Draft, please check
  the ``1id-abstracts.txt'' listing contained in the Internet-
  Drafts Shadow Directories on ftp.is.co.za (Africa),
  nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

  This memo provides information for the Internet community.
  This memo does not specify an Internet standard of any kind.
  Distribution of this memo is unlimited.

  Copyright (C) The Internet Society 1998. All Rights Reserved.


Abstract

Various IETF standards and http, e-mail and netnews software
products use various http, e-mail and netnews header fields. This
document specifies a procedure for the registration of http,
e-mail and netnews header field names, to reduce the risk that two
different products use the same header field name in different
ways (homonyms) or that several different header field names are
used with identical meaning (synonyms).


Changes from version 02 of this draft

Also http header fieldss are now included in the registry, not as
before only e-mail and netnews header fields.

Added text that also fields from Internet drafts can be registered
on a temporary basis, such registration expires with the Internet
draft:

   3.1 Registration of headers from Internet drafts

   Headers in Internet drafts can be registered on a temporary
   basis, so that the header registry can be used to find also
   such headers. If the IETF draft expires, such headers must
   either be removed from the registry, or changed to reflect
   their new status (as an IETF standard or as a non-standard
   documented separately from IETF).

   Expiration month: (For a header field from an Internet draft,
   this must be the expiration date of the draft. After this
   time, the registration must either be removed or changed. The
   word "unlimited" can be used for fields without an expiration
   month.)


Changed paragraph about "X-" headers:

   Because of this, an IANA registry for http, e-mail and
   Netnews header field names is needed. This registry can
   contain header fields starting with "X-", even though such
   header fields cannot be specified in IETF standards. The
   registry can also contain header fields not starting with
   "X-", even though such fields are not part of IETF standards.
   There is no promise that such non-standard field names, not
   starting with "X-", will not be used in future standards, but
   normally future standards can be expected not to use field
   names from the header registry in ways which are incompatible
   with existing usage of such fields as specified in the
   registry.

Added text that the IESG can change any header registration.

   Minor changes to registered headers, which will not cause
   problems for those who have already implemented the header,
   can be done by the person or organisation who has change
   control for the header. This person or organisation can also
   add to the register advance notice about future changes under
   development. The IESG additionally has the right to modify an
   header field registration, even without permission from the
   change controller. This right for the IESG should of course
   be used with great caution.

The name of the mailing list has been changed from "mail-headers"
to "message-headers" to allow also http and netnews header fields.

Table of contents

1. Introduction
2. Which Header fields are Registered
3. Who can Register a Header field Name
     3.1 Registration of headers from Internet drafts
4. Registration Procedure
     4.1 Registration Template
     4.2 Present the Request for Registration to the
     Community
     4.3 Submit the Header field name to the IANA for
     Registration
     4.4 Changes to registered headers
5. Clarifications On Specific Issues
     5.1 Requirements for a Limited Number of Header
     Fields
     5.2 Header field Status
     5.3 Requirements for a Published Specification
     5.4 Identification of Security Considerations
     5.5 Recommendations and Standards Status
6. Security Considerations
7. Acknowledgments
8. Copyright
9. References
10. Author's address
11. Appendix: Examples of the publication format of the
header registry
     11.1 Header registry when published as plain
     formatted text
     11.2 Header registry when published in HTML format
     11.3 Header registry when published as a
     tab-separated table

1.    Introduction

Many different Internet standards, other RFCs and http, e-mail and
netnews software products define header fields which may occur on
http headings, Internet mail headings and/or Netnews headings.
There is an obvious risk for

Honomyns: The same header field name is used in different ways by
          different software products.

Synonyms: Several different header fields for exactly the same
          use.

The solution, to allow header field names beginning with "X-" for
non-standard header field names has several drawbacks. One is that
it does not preclude two different products using the same "X-"
header field name with different semantic meaning. Another is that
if an "X-" header field gets popular and much used, and is to
become a standard, there is a problem with removing the "X-" in
front of an already much used header field.

Because of this, an IANA registry for http, e-mail and Netnews
header field names is needed. This registry can contain header
fields starting with "X-", even though such header fields cannot
be specified in IETF standards. The registry can also contain
header fields not starting with "X-", even though such fields are
not part of IETF standards. There is no promise that such
non-standard field names, not starting with "X-", will not be used
in future standards, but normally future standards can be expected
not to use field names from the header registry in ways which are
incompatible with existing usage of such fields as specified in
the registry.

The following words are used in this memo with the meaning
specified below:

heading           Formatted text at the top of a message, ended
                  by CRLFCRLF

header field      One field in the heading, beginning with a
                  header field name, colon, and followed by the
                  field value(s). Other words sometimes used
                  for this is "header" or "heading field".


2.    Which Header fields are Registered

The header field name registry can contain header fields from the
following sources:

- Internet standards
- RFCs which are not Internet standards
- Non-Internet standards
- Other commonly used header fields
- Headers implemented in new products
- Sometimes used header fields whose use is discouraged. The use
  of a header field name may be discouraged because it is badly
  defined, ambigous or used in different ways by different
  software. The purpose of registering discouraged header fields
  is to avoid their use in their present or any other future
  semantic meaning.

The registry can contain header fields used in e-mail message
headings, MIME content headings, http headings and Netnews article
headings.


3.    Who can Register a Header field Name

Header field names from Internet standards are registered (or the
registration modified) by IETF together with the standard
specifying the header field.

Header fields in other RFCs are registered (or the registration
modified) when the RFCs are published.

Anyone can propose the registry of additional header fields, but
such header fields should be approved by the IETF application area
managers before accepted in the registry. This approval should be
given if the header field seems reasonable and not in conflict
with current usage or other header fields in ways which might
cause problem. It is not necessary for approval that the area
manager likes the header field or wants it to be progressed into
an IETF standard. The procedure described in this memo is followed
by the IANA for review and approval of new http, e-mail and
netnews header fields. This is not a formal standards process, but
rather an administrative procedure intended to allow community
comment and sanity checking without excessive time delay.

3.1   Registration of headers from Internet drafts

Headers in Internet drafts can be registered on a temporary basis,
so that the header registry can be used to find also such headers.
If the IETF draft expires, such headers must either be removed
from the registry, or changed to reflect their new status (as an
IETF standard or as a non-standard documented separately from
IETF).

4.    Registration Procedure

4.1   Registration Template

     To: message-headers@segate.sunet.se
     Subject: Registration of header field: XXX

     Header field name:

     Header field status (choices, see section
     5.2 Header field Status below)

     Applicability:
     (One of COMMON, LIMITED USE or OBSOLETE)

     What is the header field used for:

     Who can set or modify the header field:

     Protocols which use this header field:
     (One or more of E-MAIL MESSAGE HEADING,
     E-MAIL CONTENT HEADING, HTTP HEADING,
     USENET NEWS HEADING)

     Application programs which use this header field:

     Encoding considerations:

     Security considerations:

     Interoperability considerations:

     Published specification:

     Person & email address to contact for further information:

     Author/Change controller:

     Expiration month: (For a header field from an Internet draft,
     this must be the expiration date of the draft. After this
     time, the registration must either be removed or changed. The
     word "unlimited" can be used for fields without an expiration
     month.)

     (Any other information that the author deems interesting may
     be added below this line.)


4.2   Present the Request for Registration to the Community

Send a proposed header field to the
"message-headers@segate.sunet.se" mailing list. This mailing list
has been established for the sole purpose of reviewing proposed
e-mail, netnews and http header fields. You can subscribe to the
list by sending a message to "listserv@segate.sunet.se" containing
in the text a line with
"subscribe message-headers " followed by your name (not your
e-mail address), and unsubscribe with a message "unsubscribe
message-headers". You can also subscribe through the WWW to
http://segate.sunet.se/archives/message-headers.html

Archives of this list are available
by anonymous FTP from
   ftp://segate.sunet.se/lists/message-headers/

by HTTP from
   http://segate.sunet.se/archives/message-headers.html

by E-MAIL
   send a message to
   LISTSERV@SEGATE.SUNET.SE with the text "INDEX message-headers"
   to get a list of the archive files, and then a new message
   "GET <file name>" to retrieve the archive files.

The FTP and E-MAIL archives are best if you want to retrieve all
messages during a month or more, while the HTTP archives are
better if you want to browse and find particular messages to
download.

The intent of the public posting is to solicit comments and
feedback on the choice of header field name, the unambiguity of
the references with respect to versions and external profiling
information, the choice of which OIDs to use, and a review of the
security considerations section. It should be noted that the
proposed header field name does not need to make sense for every
possible application. If the header field name is intended for a
limited or specific use, this should be noted in the submission.


4.3   Submit the Header field name to the IANA for Registration

After at least two weeks, submit the proposed header field to the
IANA for registration. The request and supporting documentation
should be sent to "iana@isi.edu". IANA will ask the application
area directors for approval. If approved, IANA will register the
header field, assign an OID under the IANA branch, and make the
header field registration available to the community.

IANA should keep a data base of registered header fields. IANA
should regularly publish the contents of this data base in the
following formats, which can be generated automatically from the
data base:

(1) In plain formatted ASCII text as shown in section 11.1.

(2) In HTML format as shown in section 11.2.

(3) As ASCII text with HTAB between fields and CRLF between lines
    as shown in section 11.3.

Format (1) and (2) are good for human reading, format (3) is good
for input to a data base.

The header field will be listed in the periodically issued
"Assigned Numbers" RFC [2]. The header field description may be
published as an Informational RFC by sending it to
"rfc-editor@isi.edu" (please follow the instructions to RFC
authors [3]).

4.4   Changes to registered headers

Minor changes to registered headers, which will not cause problems
for those who have already implemented the header, can be done by
the person or organisation who has change control for the header.
This person or organisation can also add to the register advance
notice about future changes under development. The IESG
additionally has the right to modify an header field registration,
even without permission from the change controller. This right for
the IESG should of course be used with great caution.

Changes made by an revised version of an IETF standard should be
made at the same time as the publication of the revised standard.

Other changes require the same approval procedure as for
registration of new headers.

5.    Clarifications On Specific Issues

5.1   Requirements for a Limited Number of Header Fields

Issue: In the asynchronous mail environment, where information on
the capabilities of the remote mail agent is not available to the
sender, maximum interoperability is attained by restricting the
number of header fields used to those "common" header fields
expected to be widely implemented. This was asserted as a reason
to limit the number of possible header fields and resulted in a
registration process with a significant hurdle and delay for those
registering header fields.


5.2   Header field Status

Any header field in the registry should be marked with a status,
which has one of the values specified below:

IETF standard           Specified in an IETF standard.

IETF draft standard     Specified in an IETF draft standard.

IETF proposed           Specified in an IETF proposed standard.
standard

IETF experimental       Specified in an IETF experimental
standard                standard.

Internet draft          Header from an Internet draft. If/when
                        the Internet draft expires, the header
                        registry must be changed to indicate its
                        new defining document, for example an
                        IETF standard.

X.400.                  Used to mark header fields which are
                        defined in RFC 1327 and other standards
                        for use in messages from or to Internet
                        mail/X.400 gateways, and which have not
                        been standardized for general usage in
                        the exchange of messages between
                        Internet mail-based systems.

Other standard          Defined in standard developed by another
                        standards making body than IETF.

Non-standard            This header field is not specified in
                        any of the RFCs which define Internet
                        protocols, including Internet Standards,
                        Draft Standards, Proposed Standards and
                        Experimental Standards. The header field
                        appears here because it sometimes
                        appears in http, e-mail or Netnews.
                        Usage of these header fields is not in
                        general recommended. Some header field
                        proposed in ongoing IETF standards
                        development work, but not yet accepted,
                        are also marked in this way.

discouraged             This header field, which is non-standard
                        or historical, is known to create
                        problems and should not be generated.
                        Handling of such header fields in
                        incoming mail should be done with great
                        caution.

controversial           The meaning and usage of this header
                        field is controversial, i.e. different
                        implementors have chosen to implement
                        the header field in different ways.
                        Because of this, such header fields
                        should be handled with caution and
                        understanding of the different possible
                        interpretations.


5.3   Requirements for a Published Specification

If header fields registered are specified in a separate document,
this document should be published as an RFC. Other specifications
can in some cases also be accepted if they are publicly available
on the Internet.

The information specified in section 4.1 Registration Template
above should be provided.


5.4   Identification of Security Considerations

The registration process requires the identification of any known
security problems with the header field name.

It is not required that the header field be secure or that it be
free from risks, but that the known risks be identified.
Publication of a header field name does not require an exhaustive
security review.


5.5   Recommendations and Standards Status

Issue: The registration of a header field does not imply
endorsement, approval, or recommendation by IANA or IETF or even
certification that the specification is adequate.


6.    Security Considerations

This memo does not address specific security issues but outlines a
security review process for header fields.


7.    Acknowledgments

Harald Tveit Alvestrand, Ned Freed, Olle Järnefors, Larry
Masinter, Keith Moore, Nick Smith and several other people have
helped in developing this document. I alone take responsibility
for any errors which may still be in it.


8.    Copyright

"Copyright (C) The Internet Society (date). All Rights Reserved.

This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE."


9.    References

Ref.  Author, title                               IETF status
                                                  (July 1996)
----  ------------------------------------------  -------------
-
[1]   J. Postel: "Simple Mail Transfer            Standard,
      Protocol", STD 10, RFC 821, August 1982.    Recommended

[2]   D. Crocker: "Standard for the format of     Standard,
      ARPA Internet text messages." STD 11, RFC   Recommended
      822, August 1982.

[3]   M.R. Horton, R. Adams: "Standard for        Not an
      interchange of USENET messages", RFC 1036,  offi-cial IETF
      December 1987.                              standard, but
                                                  in reality a
                                                  de-facto
                                                  standard for
                                                  Netnews

[4]   M. Sirbu: "A Content-Type header field for  Standard,
      internet messages", RFC 1049, March 1988.   Recommended,
                                                  but can in the
                                                  future be
                                                  expected to be
                                                  replaced by
                                                  MIME

[5]   R. Braden (editor): "Requirements for       Standard,
      Internet Hosts -- Application and           Required
      Support", STD-3, RFC 1123, October 1989.

[6]   D. Robinson, R. Ullman: "Encoding Header    Non-standard
      field for Internet Messages", RFC 1154,
      April 1990.

[7]   S. Hardcastle-Kille: "Mapping between       Proposed
      X.400(1988) / ISO 10021 and RFC 822",  RFC  standard,
      1327 May 1992.                              elective

[8]   H. Alvestrand & J. Romaguera: "Rules for    Proposed
      Downgrading Messages from X.400/88 to       standard,
      X.400/84 When MIME Content-Types are        elective
      Present in the Messages", RFC 1496, August
      1993.

[9]   A. Costanzo: "Encoding Header field for     Non-standard
      Internet Messages", RFC 1154, April 1990.

[10]  A. Costanzo, D. Robinson: "Encoding Header  Experimental
      field for Internet Messages", RFC 1505,
      August 1993.

[11]  N. Borenstein & N. Freed: "MIME             Draft Standard,
      (Multipurpose Internet Mail Extensions)     elective
      Part One: Mechanisms for Specifying and
      Describing the Format of Internet Message
      Bodies", RFC 1521, Sept 1993.

[12]  H. Alvestrand: "Tags for the                Proposed
      Identification of Languages", RFC 1766,     standard,
      February 1995.                              elective

[13]  J. Palme: "Electronic Mail", Artech House   Non-standard
      publishers, London-Boston January 1995.

[14]  R. Troost, S. Dorner: "Communicating        Experimental
      Presentation Information in Internet
      Messages: The Content-Disposition Header
      field", RFC 1806, June 1995.

[15]  B. Kantor, P. Lapsley, "Network News        Proposed
      Transfer Protocol: "A Proposed Standard     standard
      for the Stream-Based Transmission of
      News", RFC 977, January 1986.
[16]  1848  PS   S. Crocker, N. Freed, J.         Proposed
      Galvin, S. Murphy, "MIME Object Security    standard
      Services", RFC 1848, March 1995.

[17]  J. Myers, M. Rose: The Content-MD5 Header   Draft standard
      field, RFC 1864, October 1995.

[18]  M. Horton, UUCP mail interchange format     Not an official
      standard, RFC 976, Januari 1986.            IETF standard,
                                                  but in reality
                                                  a de-facto
                                                  standard for
                                                  Netnews

[19]  R. Fielding, J. Gettys, J. Mogul, H.        Proposed
      Frystyk. T. Berners-Lee: Hypertext          standard
      Transfer Protocol -- HTTP/1.1, RFC 2068,
      January 1997.

[20]  G. Vaudreuil: Voice Profile for Internet    Experimental
      Mail, RFC 1911, February 1996.

[21]  H. Spencer: News Article Format and         Not even an
      Transmission, June 1994,                    RFC, but still
      FTP://zoo.toronto.edu/pub/news.ps.Z         widely used and
      FTP://zoo.toronto.edu/pub/news.txt.Z        partly almost a
                                                  de-facto
      This document is often referenced under     standard for
      the name "son-of-RFC1036".                  Netnews

[22]  J. Palme: Common Internet Message Header    Informational
      fields.
      draft-ietf-mailext-mail-attributes-07.txt.
      January 1997.

[23]  PICS Label Distribution Label Syntax and    Other standard
      Communication Protocols, World Wide Web
      Consortium, October 1996.

[24]  Eudora Pro Macintosh User Manual, Qualcomm  Non-standard
      Inc., 1988-1995.



10.   Author's address

Jacob Palme                          Phone: +46-8-16 16 67
Stockholm University/KTH             Fax: +46-8-783 08 29
Electrum 230                         E-mail: jpalme@dsv.su.se
S-164 40 Kista, Sweden


11.   Appendix: Examples of the publication format of the header
registry

11.1  Header registry when published as plain formatted text

Header name:             Content-Location:
Header status:           IETF Proposed Standard
Applicability:           COMMON
Use:                     Gives an URL corresponding to a content
                         part. The content part may, but need not,
                         be retrievable using this URL. Used when
                         sending HTML combined with related
                         objects as aggregate MIME objects.
Who can set or modify:   Creator of aggregate MIME object
Protocols which use it:  E-MAIL MESSAGE HEADING, E-MAIL CONTENT
                         HEADING, HTTP HEADING, USENET NEWS
                         HEADING
Applications which use   Several e-mail clients and web browsers
it:
Encoding                 MIME (RFC 2047) and URLBODY (RFC 2017)
considerations:
Security                 Various, none serious. Can be avoided by
considerations:          careful impelementation. See RFC 2110 for
                         details.
Interoperability         Can interoperate with non-compliant
software,
considerations:          body part will be provided without its
URL.
Published                RFC 2110: MIME Encapsulation of Aggregate
specification:           Documents, such as HTML (MHTML), March
1997.
Contact person:          Jacob Palme <jpalme@dsv.su.se> and Alex
                         Hopmann <alexhop@microsoft.com>
Change controller:       IETF (MHTML working group), chair Einar
                         Stefferud <stef@nma.com>
Other information:       IETF is working on a revision of RFC
                         2110. See URL
                         http://www.dsv.su.se/~jpalme/ietf/
                         mhtml.html for more information.

11.2  Header registry when published in HTML format

The HTML document below can also be found at URL
http://www.dsv.su.se/~jpalme/ietf/iana-header-field-registry.html

<H2><A NAME="html-format"></A>Header registry in HTML format</H2>
<H3>Table of contents</H3>
<P><I>(Not yet complete)</I>
<MENU>
   <LI>Content-Base
   <LI>Content-Conversion
   <LI>Content-Description
   <LI>Content-Disposition
   <LI>Contetn-ID
   <LI>Content-Identifier
   <LI>Content-Language
   <LI>Content-Length
   <LI><A HREF="#Content-Location">Content-Location</A>
   <LI>Content-MD5
   <LI>Content-Return
   <LI>Content-SGML-Entity
   <LI>Content-Transfer-Encoding
   <LI>Content-Type
</MENU>
<H4>Content-Location</H4>
<P><TABLE BORDER=1>
   <TR>
      <TD>
         <P><A NAME="Content-Location"></A>Header name:
      </TD><TD>
         <P>Content-Location:
      </TD></TR>
   <TR>
      <TD>
         <P>Header status:
      </TD><TD>
         <P>IETF Proposed Standard
      </TD></TR>
   <TR>
      <TD>
         <P>Applicability:
      </TD><TD>
         <P>COMMON
      </TD></TR>
   <TR>
      <TD>
         <P>Use:
      </TD><TD>
         <P>Gives an URL corresponding to a content part. The
          content part may, but need not, be retrievable using
          this URL. Used when sending HTML combined with related
          objects as aggregate MIME objects.
      </TD></TR>
   <TR>
      <TD>
         <P>Who can set or modify:
      </TD><TD>
         <P>Creator of aggregate MIME object
      </TD></TR>
   <TR>
      <TD>
         <P>Protocols which use it:
      </TD><TD>
         <P>E-MAIL MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP
         HEADING, USENET NEWS HEADING
      </TD></TR>
   <TR>
      <TD>
         <P>Applications which use it:
      </TD><TD>
         <P>Several e-mail clients and web browsers
      </TD></TR>
   <TR>
      <TD>
         <P>Encoding considerations:
      </TD><TD>
         <P>MIME (RFC 2047) and URLBODY (RFC 2017)
      </TD></TR>
   <TR>
      <TD>
         <P>Security considerations:
      </TD><TD>
         <P>Various, none serious. Can be avoided by careful
         impelementation. See RFC 2110 for details.
      </TD></TR>
   <TR>
      <TD>
         <P>Interoperability considerations:
      </TD><TD>
         <P>Can interoperate with non-compliant software, body
         part will be provided without its URL.
      </TD></TR>
   <TR>
      <TD>
         <P>Published specification:
      </TD><TD>
         <P>RFC 2110: MIME Encapsulation of Aggregate Documents,
         such as HTML (MHTML), March 1997.
      </TD></TR>
   <TR>
      <TD>
         <P>Contact person:
      </TD><TD>
         <P>Jacob Palme &lt;jpalme@dsv.su.se&gt; and Alex Hopmann
         &lt;alexhop@microsoft.com&gt;
      </TD></TR>
   <TR>
      <TD>
         <P>Change controller:
      </TD><TD>
         <P>IETF (MHTML working group), chair Einar Stefferud
         &lt;stef@nma.com&gt;
      </TD></TR>
   <TR>
      <TD>
         <P>Other information:
      </TD><TD>
         <P>IETF is working on a revision of RFC 2110. See URL
         <A HREF=
         "http://www.dsv.su.se/~jpalme/ietf/mhtml.html">
         http://www.dsv.su.se/~jpalme/ietf/mhtml.html</A>
         for more information.
      </TD></TR>
</TABLE>

11.3  Header registry when published as a tab-separated table

To agree with the allowed formats for RFCs, the section below is
encoded with the quoted-printable encoding method. This means that
the Horizontal Tab (HT) character is replaced by the string "=09"
and that all occurences of "=" followed by End-Of-Line should be
deleted from the text below to get the actual format. The IANA
published document should *not* be encoded with quoted-printable.

Header name:=09Header status:=09Applicability:=09Use:=09Who =
can set or modify:=09Protocols which use it:=09Applications =
which use it:=09Encoding considerations:=09Security =
considerations:=09Interoperability considerations:=
=09Published specification:=09Contact person:=09Change =
controller:=09Other information:
Content-Location:=09IETF Proposed Standard=09COMMON=09Gives an=
 URL corresponding to a content part. The content part may,=
 but need not, be retrievable using this URL. Used when=
 sending HTML combined with related objects as aggregate=
 MIME objects.=09Creator of aggregate MIME object=09E-MAIL=
 MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP HEADING, USENET=
 NEWS HEADING=09Several e-mail clients and web browsers=09MIME=
 (RFC 2047) and URLBODY (RFC 2017)=09Various, none serious. Can=
 be avoided by careful impelementation. See RFC 2110 for=
 details.=09Can interoperate with non-compliant software, body=
 part will be provided without its URL.=09RFC 2110: MIME=
 Encapsulation of Aggregate Documents, such as HTML (MHTML),=
 March 1997.=09Jacob Palme <jpalme@dsv.su.se> and Alex Hopmann=
 <alexhop@microsoft.com>=09IETF (MHTML working group), chair=
 Einar Stefferud <stef@nma.com>=09IETF is working on a revision=
 of RFC 2110. =
See URL http://www.dsv.su.se/~jpalme/ietf/mhtml.html for more=
 information.


