rfc2557.txt

RFC 的详细文档！

   Such a text/html resource may either contain no URIs, or URIs which
   the recipient is expected to retrieve (if possible) via a URI
   specified protocol. A text/html resource may also be sent with
   unresolvable links in special cases, such as when two authors
   exchange drafts of unfinished resources.

   Inclusion of URIs referencing resources which the recipient has to
   retrieve via an URI specified protocol may not work for some
   recipients. This is because not all e-mail recipients have full
   Internet connectivity, or because URIs which work for a sender will
   not work for a recipient. This occurs, for example, when an URI
   refers to a resource within a company-internal network that is not
   accessible from outside the company.






Palme, et al.               Standards Track                    [Page 10]

RFC 2557       MIME Encapsulation of Aggregate Documents      March 1999


7.  Use of the Content-Type "multipart/related"

   If a message contains one or more MIME body parts containing URIs and
   also contains as separate body parts, resources, to which these URIs
   (as defined, for example, in HTML 2.0 [HTML2]) refer, then this whole
   set of body parts (referring body parts and referred-to body parts)
   SHOULD be sent within a multipart/related structure as defined in
   [REL].

   Even though headers can occur in a message that lacks an associated
   multipart/related structure, this standard only covers their use for
   resolution of URIs between body parts inside a multipart/related
   structure. This standard does cover the case where a resource in a
   nested multipart/related structure contains URIs that reference MIME
   body parts in another  multipart/related structure, in which it is
   enclosed. This standard does not cover the case where a resource in a
   multipart/related structure contains URIs that reference MIME body
   parts in another parallel or nested multipart/related structure, or
   in another MIME message, even if methods similar to those described
   in this standard are used. Implementers who employ such URIs are
   warned that receiving agents implementing this standard may not be
   able to process such references.

   When the start body part of a multipart/related structure is an
   atomic object, such as a text/html resource, it SHOULD be employed as
   the root resource of that multipart/related structure. When the start
   body part of a multipart/related structure is a multipart/alternative
   structure, and that structure contains at least one alternative body
   part which is a suitable atomic object, such as a text/html resource,
   then that body part SHOULD be employed as the root resource of the
   aggregate document.  Implementers are warned, however, that some
   receiving agents treat multipart/alternative as if it had been
   multipart/mixed (even though MIME [MIME1] requires support for
   multipart/alternative).

   [REL] specifies that a type parameter is mandatory in a "Content-
   Type:  multipart/related" header, and requires that it be employed to
   specify the type of the multipart/related start object. Thus, the
   type parameter value shall be "multipart/alternative", when the start
   part is of "Content-type multipart/alternative", even if the actual
   root resource is of type "text/html". In addition, if the
   multipart/related start object is not the first body part in a
   multipart/related structure, [REL] further requires that its
   Content-ID MUST be specified as the value of a start parameter in the
   "Content-Type:  multipart/related" header.






Palme, et al.               Standards Track                    [Page 11]

RFC 2557       MIME Encapsulation of Aggregate Documents      March 1999


   When rendering a resource in a multipart/related structure, URI
   references within that resource can be satisfied by body parts within
   the same multipart/related structure (see section 8.2 below). This is
   useful:

   (a) For those recipients who only have email 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 URI referenced
       resources via URI specified protocols.

       Note, that this means that you can, via e-mail, send text/html
       objects which includes URIs which the recipient cannot resolve
       via HTTP or other connectivity-requiring URIs.

   (c) To send a document whose content is preserved even if the
       resources to which embedded URIs refer are later changed or
       deleted.

   (d) For resources which are not available for protocol based
       retrieval.

   (e) To speed up access.

   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 message, as
   well as verify the documents against their WWW counterpoints, if this
   is appropriate.

   In certain cases this will not work - for example, if a resource
   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.

   Within a multipart/related structure, each body part MUST have, if
   assigned, a different Content-ID header value and a Content-Location
   header field values which resolve to a different URI.

   Two body parts in the same multipart/related structure can have the
   same relative Content-Location header value, only if when resolved to
   absolute URIs they become different.





Palme, et al.               Standards Track                    [Page 12]

RFC 2557       MIME Encapsulation of Aggregate Documents      March 1999


8.  Usage of Links to Other Body Parts

8.1 General principle

   A body part, such as a text/html body part, may contain URIs that
   reference resources which are included as body parts in the same
   message -- in detail, as body parts within the same multipart/related
   structure. Often such URI linked resources are meant to be displayed
   inline to the viewer of the referencing body part; for example,
   objects referenced with the SRC attribute of the IMG element in HTML
   2.0 [HTML2]. New elements and attributes with this property are
   proposed in the ongoing development of HTML (examples: applet, frame,
   profile, OBJECT, classid, codebase, data, SCRIPT). A sender might
   also want to send a set of HTML documents which the reader can
   traverse, and which are related with the attribute href of the A
   element.

   If a user retrieves and displays a web page formed from a text/html
   resource, and the subsidiary resources it references, and merely
   saves the text/html resource, that user may not at a later time be
   able to retrieve and display the web page as it appeared when saved.
   The format described in this standard can be used to archive and
   retrieve all of the resources required to display the web page, as it
   originally appeared at a certain moment of time, in one aggregate
   file.

   In order to send or store complete such messages, there is a need to
   specify how a URI in one body part can reference a resource in
   another body part.

8.2 Resolution of URIs in text/html body parts

   The resolution of inline, retrieval and other kinds of URIs in
   text/html body parts is performed in the following way:

   (a) Unfold multiple line header values according to [URLBODY]. Do NOT
       however translate character encodings of the kind described in
       [URL]. Example: Do not transform "a%2eb/c%20d" into "a/b/c d".

   (b) Remove all MIME encodings, such as content-transfer encoding and
       header encodings as defined in MIME part 3 [MIME3] Do NOT however
       translate character encodings of the kind described in [URL].
       Example: Do not transform "a%2eb/c%20d" into "a/b/c d".

   (c) Try to resolve all relative URIs in the HTML content and in
       Content-Location headers using the procedure described in chapter
       5 above. The result of this resolution can be an absolute URI, or
       an absolute URI with the base "thismessage:/" as specified in



Palme, et al.               Standards Track                    [Page 13]

RFC 2557       MIME Encapsulation of Aggregate Documents      March 1999


       chapter 5.

   (d) For each referencing URI in a text/html body part, compare the
       value of the referencing URI after resolution as described in (a)
       and (b), with the URI derived from Content-ID and Content-
       Location headers for other body parts within the same or a
       surrounding Multipart/related structure. If the strings are
       identical, octet by octet, then the referencing URI references
       that body part. This comparison will only succeed if the two URIs
       are identical. This means that if one of the two URIs to be
       compared was a fictitious absolute URI with the base
       "thismessage:/", the other must also be such a fictitious
       absolute URI, and not resolvable to a real absolute URI.

   (e) If (d) fails, try to retrieve the URI referenced resource
       hyperlink through ordinary Internet lookup. Resolution of URIs of
       the URL-types "mid" or "cid" to other content-parts, outside the
       same multipart/related structure, or in other separately sent
       messages, is not covered by this standard, and is thus neither
       encouraged nor forbidden.

8.3 Use of the Content-ID header and CID URLs

   When URIs employing a CID (Content-ID) scheme as defined in [URL] and
   [MIDCID] are used to reference other body parts in an MHTML
   multipart/related structure, they MUST only be matched against
   Content-ID header values, and not against Content-Location header
   with CID: values. Thus, even though the following two headers are
   identical in meaning, only the Content-ID value will be matched, and
   the Content-Location value will be ignored.

      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 a message or within a
   single multipart/related structure.

9.  Examples

   Warning: The examples are provided for illustrative purposes only. If
   there is a contradiction between the explanatory text and the
   examples in this standard, then the explanatory text is normative.

   Notation: The examples contain indentation to show the structure, the
   real objects should not be indented in this way.





Palme, et al.               Standards Track                    [Page 14]

RFC 2557       MIME Encapsulation of Aggregate Documents      March 1999


9.1 Example of a HTML body without included linked objects

   The first example is the simplest form of an HTML email message. This
   message does not contain an aggregate HTML object, but simply a
   message with a single HTML body part. This body part contains a URI
   but the messages does not contain the resource referenced by that
   URI. To retrieve the resource referenced by the URI 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="iso-8859-1"
      Content-Transfer-Encoding: 8bit

      <HTML>
      <head></head>
      <body>
      <h1>Acute accent</h1>
      The following two lines look have the same screen rendering:<p>
      E with acute accent becomes