rfc2110.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          J. Palme
Request for Comments: 2110                     Stockholm University/KTH
Category: Standards Track                                    A. Hopmann
                                                  Microsoft Corporation
                                                             March 1997


 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)

Status of this Document

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   Although HTML [RFC 1866] was designed within the context of MIME,
   more than the specification of HTML as defined in RFC 1866 is needed
   for two electronic mail user agents to be able to interoperate using
   HTML as a document format. These issues include the naming of objects
   that are normally referred to by URIs, and the means of aggregating
   objects that go together. This document describes a set of guidelines
   that will allow conforming mail user agents to be able to send,
   deliver and display these objects, such as HTML objects, that can
   contain links represented by URIs. In order to be able to handle
   inter-linked objects, the document uses the MIME type
   multipart/related and specifies the MIME content-headers "Content-
   Location" and "Content-Base".

Table of Contents

   1. Introduction..............................................  2
   2. Terminology...............................................  3
      2.1 Conformance requirement terminology...................  3
      2.2 Other terminology.....................................  4
   3. Overview..................................................  5
   4. The Content-Location and Content-Base MIME Content Headers  6
      4.1 MIME content headers..................................  6
      4.2 The Content-Base header...............................  7
      4.3 The Content-Location Header...........................  7
      4.4 Encoding of URIs in e-mail headers....................  8
   5. Base URIs for resolution of relative URIs.................  8
   6. Sending documents without linked objects..................  9
   7. Use of the Content-Type: Multipart/related................  9
   8. Format of Links to Other Body Parts....................... 11



Palme & Hopmann             Standards Track                     [Page 1]

RFC 2110                         MHTML                        March 1997


      8.1 General principle..................................... 11
      8.2 Use of the Content-Location header.................... 11
      8.3 Use of the Content-ID header and CID URLs............. 12
   9 Examples................................................... 12
      9.1 Example of a HTML body without included linked objects 12
      9.2 Example with absolute URIs to an embedded GIF picture  13
      9.3 Example with relative URIs to an embedded GIF picture  13
      9.4 Example using CID URL and Content-ID header to an
          embedded GIF picture.................................. 14
   10. Content-Disposition header............................... 15
   11. Character encoding issues and end-of-line issues......... 15
   12. Security Considerations.................................. 16
   13. Acknowledgments.......................................... 17
   14. References............................................... 18
   15. Author's Address......................................... 19

Mailing List Information

   Further discussion on this document should be done through the
   mailing list [e-mail].

   To subscribe to this list, send a message to
      [e-mail]
   which contains the text
   SUB MHTML <your name (not your e-mail address)>

   Archives of this list are available by anonymous ftp from
      FTP://SEGATE.SUNET.SE/lists/mHTML/
   The archives are also available by e-mail. Send a message to
   [e-mail] 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 <[e-mail]>.

   More information may also be available at URL:
   HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.HTML

1. Introduction

   There are a number of document formats, HTML [HTML2], PDF [PDF] and
   VRML for example, which provide links using URIs for their
   resolution. There is an obvious need to be able to send documents in
   these formats in e-mail [RFC821=SMTP, RFC822]. This document gives
   additional specifications on how to send such documents in MIME [RFC
   1521=MIME1] e-mail messages. This version of this standard was based
   on full consideration only of the needs for objects with links in the



Palme & Hopmann             Standards Track                     [Page 2]

RFC 2110                         MHTML                        March 1997


   Text/HTML media type (as defined in RFC 1866 [HTML2]), but the
   standard may still be applicable also to other formats for sets of
   interlinked objects, linked by URIs. There is no conformance
   requirement that implementations claiming conformance to this
   standard are able to handle URI-s in other document formats than
   HTML.

   URIs in documents in HTML and other similar formats reference other
   objects and resources, either embedded or directly accessible through
   hypertext links. When mailing such a document, it is often desirable
   to also mail all of the additional resources that are referenced in
   it; those elements are necessary for the complete interpretation of
   the primary object.

   An alternative way for sending an HTML document or other object
   containing URIs in e-mail is to only send the URL, and let the
   recipient look up the document using HTTP. That method is described
   in [URLBODY] and is not described in this document.

   An informational RFC will at a later time be published as a
   supplement to this standard. The informational RFC will discuss
   implementation methods and some implementation problems. Implementors
   are recommended to read this informational RFC when developing
   implementations of the MHTML standard. This informational RFC is,
   when this RFC is published, still in IETF draft status, and will stay
   that way for at least six months in order to gain more implementation
   experience before it is published.

2. Terminology

2.1 Conformance requirement terminology

   This specification uses the same words as RFC 1123 [HOSTS] for
   defining the significance of each particular requirement. These words
   are:

   MUST    This word or the adjective "required" means that the item is
           an absolute requirement of the specification.

   SHOULD  This word or the adjective "recommended" means that there may
           exist valid reasons in particular circumstances to ignore this
           item, but the full implications should be understood and the
           case carefully weighed before choosing a different course.








Palme & Hopmann             Standards Track                     [Page 3]

RFC 2110                         MHTML                        March 1997


   MAY     This word or the adjective "optional" means that this item is
           truly optional. One vendor may choose to include the item
           because a particular marketplace requires it or because it
           enhances the product, for example; another vendor may omit
           the same item.

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST requirements for the protocols it implements. An
   implementation that satisfies all the MUST and all the SHOULD
   requirements for its protocols is said to be "unconditionally
   compliant"; one that satisfies all the MUST requirements but not all
   the SHOULD requirements for its protocols is said to be
   "conditionally compliant."

2.2 Other terminology

   Most of the terms used in this document are defined in other RFCs.

   Absolute URI,         See RFC 1808 [RELURL].
   AbsoluteURI

   CID                   See [MIDCID].

   Content-Base          See section 4.2 below.

   Content-ID            See [MIDCID].

   Content-Location      MIME message or content part header with the
                         URI of the MIME message or content part body,
                         defined in section 4.3 below.

   Content-Transfer-Enco Conversion of a text into 7-bit octets as
   ding                  specified in [MIME1].

   CR                    See [RFC822].

   CRLF                  See [RFC822].

   Displayed text        The text shown to the user reading a document
                         with a web browser. This may be different from
                         the HTML markup, see the definition of HTML
                         markup below.

   Header                Field in a message or content heading specifying
                         the value of one attribute.






Palme & Hopmann             Standards Track                     [Page 4]

RFC 2110                         MHTML                        March 1997


   Heading               Part of a message or content before the first
                         CRLFCRLF, containing formatted fields with
                         attributes of the message or content.

   HTML                  See RFC 1866 [HTML2].

   HTML Aggregate        HTML objects together with some or all objects,
                         to objects which the HTML object contains
                         hyperlinks.

   HTML markup           A file containing HTML encodings as specified
                         in [HTML] which may be different from the
                         displayed text which a person using a web
                         browser sees. For example, the HTML markup
                         may contain "&lt;" where the displayed text
                         contains the character "<".

   LF                    See [RFC822].

   MIC                   Message Integrity Codes, codes use to verify
                         that a  message has not been modified.

   MIME                  See RFC 1521 [MIME1], [MIME2].

   MUA                   Messaging User Agent.

   PDF                   Portable Document Format, see [PDF].

   Relative URI,         See RFC 1866 [HTML2] and RFC 1808[RELURL].
   RelativeURI

   URI, absolute and     See RFC 1866 [HTML2].
   relative

   URL                   See RFC 1738 [URL].

   URL, relative         See [RELURL].

   VRML                  Virtual Reality Markup Language.

3. Overview

   An aggregate document is a MIME-encoded message that contains a root
   document as well as other data that is required in order to represent
   that document (inline pictures, style sheets, applets, etc.).
   Aggregate documents can also include additional elements that are
   linked to the first object.  It is important to keep in mind the
   differing needs of several audiences. Mail sending agents might send



Palme & Hopmann             Standards Track                     [Page 5]

RFC 2110                         MHTML                        March 1997


   aggregate documents as an encoding of normal day-to-day electronic
   mail. Mail sending agents might also send aggregate documents when a
   user wishes to mail a particular document from the web to someone
   else. Finally mail sending agents might send aggregate documents as
   automatic responders, providing access to WWW resources for non-IP
   connected clients.

   Mail receiving agents also have several differing needs. Some mail
   receiving agents might be able to receive an aggregate document and
   display it just as any other text content type would be displayed.
   Others might have to pass this aggregate document to a browsing
   program, and provisions need to be made to make this possible.

   Finally several other constraints on the problem arise. It is
   important that it be possible for a document to be signed and for it
   to be able to be transmitted to a client and displayed with a minimum
   risk of breaking the message integrity (MIC) check that is part of
   the signature.

4. The Content-Location and Content-Base MIME Content Headers

4.1 MIME content headers

   In order to resolve URI references to other body parts, two MIME
   content headers are defined, Content-Location and Content-Base. Both
   these headers can occur in any message or content heading, and will
   then be valid within this heading and for its content.

   In practice, at present only those URIs which are URLs are used, but
   it is anticipated that other forms of URIs will in the future be
   used.

   The syntax for these headers is, using the syntax definition tools
   from [RFC822]:

       content-location ::= "Content-Location:" ( absoluteURI |
                            relativeURI )

       content-base ::= "Content-Base:" absoluteURI

   where URI is at present (June 1996) restricted to the syntax for URLs
   as defined in RFC 1738 [URL].

   These two headers are valid only for exactly the content heading or
   message heading where they occurs and its text. They are thus not
   valid for the parts inside multipart headings, and are thus
   meaningless in multipart headings.




Palme & Hopmann             Standards Track                     [Page 6]

RFC 2110                         MHTML                        March 1997


   These two headers may occur both inside and outside of a
   multipart/related part.

4.2 The Content-Base header

   The Content-Base gives a base for relative URIs occurring in other
   heading fields and in HTML documents which do not have any BASE
   element in its HTML code. Its value MUST be an absolute URI.

   Example showing which Content-Base is valid where:

    Content-Type: Multipart/related; boundary="boundary-example-1";
                  type=Text/HTML; start=foo2*[e-mail]
     ; A Content-Base header cannot be placed here, since this is a