rfc2110.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/3 页

     ; multipart MIME object.

    --boundary-example-1

    Part 1:
    Content-Type: Text/HTML; charset=US-ASCII
    Content-ID: <foo2*[e-mail]>
    Content-Location: http://www.ietf.cnir.reston.va.us/images/foo1.bar1
    ;  This Content-Location must contain an absolute URI, since no base
    ;  is valid here.

    --boundary-example-1

    Part 2:
    Content-Type: Text/HTML; charset=US-ASCII
    Content-ID: <foo4*[e-mail]>
    Content-Location: foo1.bar1   ; The Content-Base below applies to
                                  ; this relative URI
    Content-Base: http://www.ietf.cnri.reston.va.us/images/

    --boundary-example-1--

4.3 The Content-Location Header

   The Content-Location header specifies the URI that corresponds to the
   content of the body part in whose heading the header is placed. Its
   value CAN be an absolute or relative URI. Any URI or URL scheme may
   be used, but use of non-standardized URI or URL schemes might entail
   some risk that recipients cannot handle them correctly.

   The Content-Location header can be used to indicate that the data
   sent under this heading is also retrievable, in identical format,
   through normal use of this URI. If used for this purpose, it must
   contain an absolute URI or be resolvable, through a Content-Base



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


   header, into an absolute URI. In this case, the information sent in
   the message can be seen as a cached version of the original data.

   The header can also be used for data which is not available to some
   or all recipients of the message, for example if the header refers to
   an object which is only retrievable using this URI in a restricted
   domain, such as within a company-internal web space. The header can
   even contain a fictious URI and need in that case not be globally
   unique.

   Example:

   Content-Type: Multipart/related; boundary="boundary-example-1";
                    type=Text/HTML

      --boundary-example-1

      Part 1:
      Content-Type: Text/HTML; charset=US-ASCII

      ... ... <IMG SRC="fiction1/fiction2"> ... ...

      --boundary-example-1

      Part 2:
      Content-Type: Text/HTML; charset=US-ASCII
      Content-Location: fiction1/fiction2

      --boundary-example-1--

4.4 Encoding of URIs in e-mail headers

   Since MIME header fields have a limited length and URIs can get quite
   long, these lines may have to be folded. If such folding is done, the
   algorithm defined in [URLBODY] section 3.1 should be employed.

5. Base URIs for resolution of relative URIs

   Relative URIs inside contents of MIME body parts are resolved
   relative to a base URI. In order to determine this base URI, the
   first-applicable method in the following list applies.

     (a) There is a base specification inside the MIME body part
          containing the link which resolves relative URIs into absolute
          URIs. For example, HTML provides the BASE element for this.

     (b) There is a Content-Base header (as defined in section 4.2),
          specifying the base to be used.



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


     (c) There is a Content-Location header in the heading of the body
          part which can then serve as the base in the same way as the
          requested URI can serve as a base for relative URIs within a
          file retrieved via HTTP [HTTP].

   When the methods above do not yield an absolute URI the procedure in
   section 8.2 for matching relative URIs MUST be followed.

6. Sending documents without linked objects

   If a document, such as an HTML object, is sent without other objects,
   to which it is linked, it MAY be sent as a Text/HTML body part by
   itself.  In this case, multipart/related need not be used.

   Such a document may either not include any links, or contain links
   which the recipient resolves via ordinary net look up, or contain
   links which the recipient cannot resolve.

   Inclusion of links which the recipient has to look up through the net
   may not work for some recipients, since all e-mail recipients do not
   have full internet connectivity. Also, such links may work for the
   sender but not for the recipient, for example when the link refers to
   an URI within a company-internal network not accessible from outside
   the company.

   Note that documents with links that the recipient cannot resolve MAY
   be sent, although this is discouraged. For example, two persons
   developing a new HTML page may exchange incomplete versions.

7. Use of the Content-Type: Multipart/related

   If a message contains one or more MIME body parts containing links
   and also contains as separate body parts, data, to which these links
   (as defined, for example, in RFC 1866 [HTML2]) refers, then this
   whole set of body parts (referring body parts and referred-to body
   parts) SHOULD be sent within a multipart/related body part as defined
   in [REL].

   The root body part of the multipart/related SHOULD be the start
   object for rendering the object, such as a text/html object, and
   which contains links to objects in other body parts, or a
   multipart/alternative of which at least one alternative resolves to
   such a start object.  Implementors are warned, however, that many
   mail programs treat multipart/alternative as if it had been
   multipart/mixed (even though MIME [MIME1] requires support for
   multipart/alternative).





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


   [REL] requires that the type attribute of the "Content-Type:
   Multipart/related" statement be the type of the root object, and this
   value can thus be "multipart/alternative". If the root is not the
   first body part within the multipart/related, [REL] further requires
   that its Content-ID MUST be given in a start parameter to the
   "Content-Type: Multipart/related" header.

   When presenting the root body part to the user, the additional body
   parts within the multipart/related can be used:

       (a) For those recipients who only have e-mail but not full
           Internet access.

       (b) For those recipients who for other reasons, such as firewalls
           or the use of company-internal links, cannot retrieve the
           linked body parts through the net.

          Note that this means that you can, via e-mail, send HTML which
           includes URIs which the recipient cannot resolve via HTTPor
           other connectivity-requiring URIs.

       (c) For items which are not available on the web.

       (d) For any recipient to speed up access.

   The type parameter of the "Content-Type: Multipart/related" MUST be
   the same as the Content-Type of its root.

   When a sending MUA sends objects which were retrieved from the WWW,
   it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs
   into some other URI form prior to transmitting them. This will allow
   the receiving MUA to both verify MICs included with the email
   message, as well as verify the documents against their WWW
   counterpoints.

   In certain special cases this will not work if the original HTML
   document contains URIs as parameters to objects and applets. In such
   a case, it might be better to rewrite the document before sending it.
   This problem is discussed in more detail in the informational RFC
   which will be published as a supplement to this standard.

   This standard does not cover the case where a multipart/related
   contains links to MIME body parts outside of the current
   multipart/related or in other MIME messages, even if methods similar
   to those described in this standard are used. Implementors who
   provide such links are warned that mailers implementing this standard
   may not be able to resolve such links.




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


   Within such a multipart/related, ALL different parts MUST have
   different Content-Location or Content-ID values.

8. Format of Links to Other Body Parts

8.1 General principle

   A body part, such as a text/HTML body part, may contain hyperlinks to
   objects which are included as other body parts in the same message
   and within the same multipart/related content. Often such linked
   objects are meant to be displayed inline to the reader of the main
   document; for example, objects referenced with the IMG tag in HTML
   [RFC 1866=HTML2].  New tags with this property are proposed in the
   ongoing development of HTML (example: applet, frame).

   In order to send such messages, there is a need to indicate which
   other body parts are referred to by the links in the body parts
   containing such links. For example, a body part of Content-Type:
   Text/HTML often has links to other objects, which might be included
   in other body parts in the same MIME message. The referencing of
   other body parts is done in the following way: For each body part
   containing links and each distinct URI within it, which refers to
   data which is sent in the same MIME message, there SHOULD be a
   separate body part within the current multipart/related part of the
   message containing this data. Each such body part SHOULD contain a
   Content-Location header (see section 8.2) or a Content-ID header (see
   section 8.3).

   An e-mail system which claims conformance to this standard MUST
   support receipt of multipart/related (as defined in section 7) with
   links between body parts using both the Content-Location (as defined
   in section 8.2) and the Content-ID method (as defined in section
   8.3).

8.2 Use of the Content-Location header

   If there is a Content-Base header, then the recipient MUST employ
   relative to absolute resolution as defined in RFC 1808 [RELURL] of
   relative URIs in both the HTML markup and the Content-Location header
   before matching a hyperlink in the HTML markup to a Content-Location
   header. The same applies if the Content-Location contains an absolute
   URI, and the HTML markup contains a BASE element so that relative
   URIs in the HTML markup can be resolved.

   If there is NO Content-Base header, and the Content-Location header
   contains a relative URI, then NO relative to absolute resolution
   SHOULD be performed. Matching the relative URI in the Content-
   Location header to a hyperlink in an HTML markup text is in this case



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


   a two step process. First remove any LWSP from the relative URI which
   may have been introduced as described in section 4.4. Then perform an
   exact textual match against the HTML URIs. For this matching process,
   ignore BASE specifications, such as the BASE element in HTML. Note
   that this only applies for matching Content-Location headers, not for
   URL-s in the HTML document which are resolved through network look up
   at read time.

   The URI in the Content-Location header need not refer to an object
   which is actually available globally for retrieval using this URI
   (after resolution of relative URIs). However, URI-s in Content-
   Location headers (if absolute, or resolvable to absolute URIs) SHOULD
   still be globally unique.

8.3 Use of the Content-ID header and CID URLs

   When CID (Content-ID) URLs as defined in RFC 1738 [URL] and RFC 1873
   [MIDCID] are used for links between body parts, the Content-Location
   statement will normally be replaced by a Content-ID header. Thus, the
   following two headers are identical in meaning:

   Content-ID: [e-mail]
   Content-Location: CID: [e-mail]

   Note: Content-IDs MUST be globally unique [MIME1]. It is thus not
   permitted to make them unique only within this message or within this
   multipart/related.

9 Examples

9.1 Example of a HTML body without included linked objects

   The first example is the simplest form of an HTML email message. This
   is not an aggregate HTML object, but simply a message with a single
   HTML body part. This message contains a hyperlink but does not
   provide the ability to resolve the hyperlink. To resolve the
   hyperlink the receiving client would need either IP access to the
   Internet, or an electronic mail web gateway.

      From: [e-mail]
      To: [e-mail]
      Subject: A simple example
      Mime-Version: 1.0
      Content-Type: Text/HTML; charset=US-ASCII







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


      <HTML>
      <head></head>
      <body>
      <h1>Hi there!</h1>
      An example of an HTML message.<p>
      Try clicking <a href="http://www.resnova.com/">here.</a><p>
      </body></HTML>

9.2 Example with absolute URIs to an embedded GIF picture

    From: [e-mail]
    To: [e-mail]
    Subject: A simple example
    Mime-Version: 1.0
    Content-Type: Multipart/related; boundary="boundary-example-1";
                  type=Text/HTML; start=foo3*[e-mail]

    --boundary-example-1
       Content-Type: Text/HTML;charset=US-ASCII
       Content-ID: <foo3*[e-mail]>

       ... text of the HTML document, which might contain a hyperlink
       to the other body part, for example through a statement such as:
       <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
        ALT="IETF logo">

    --boundary-example-1
       Content-Location:
             http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
       Content-Type: IMAGE/GIF
       Content-Transfer-Encoding: BASE64

       R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
       NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A