rfc2557.txt

RFC 的详细文档！

   VRML                  See Virtual Reality Markup Language [VRML].









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


3.  Overview

   An aggregate document is a MIME-encoded message that contains a root
   resource (object) as well as other resources linked to it via URIs.
   These other resources may be required to display a multimedia
   document based on the root resource (inline pictures, style sheets,
   applets, etc.), or be the root resources of other multimedia
   documents. It is important to keep in mind that aggregate documents
   need to satisfy the differing needs of several audiences.

   Mail sending agents might send 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. Also with other
   protocols such as HTTP or FTP, there may sometimes be a need to
   retrieve aggregate documents. Receiving agents also have several
   differing needs. Some 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 transmitted and displayed without breaking the message
   integrity (MIC) checksum that is part of the signature.

4.  The Content-Location MIME Content Header

4.1 MIME content headers

   In order to resolve URI references to resources in other body parts,
   one MIME content header is defined, Content-Location. This header can
   occur in any message or content heading.

   The syntax for this header is, using the syntax definition tools from
   [ABNF]:

   quoted-pair      =   ("\" text)

   text             =   %d1-9 / ; Characters excluding CR and LF
                        %d11-12 /
                        %d14-127

   WSP              =   SP / HTAB ; Whitespace characters




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


   FWS              =   ([*WSP CRLF] 1*WSP) ; Folding white-space

   ctext            =   NO-WS-CTL / ; Non-white-space controls
                        %d33-39 / ; The rest of the US-ASCII
                        %d42-91 / ; characters not including "(",
                        %d93-127 ; ")", or "\"

   comment          =  "(" *([FWS] (ctext / quoted-pair / comment))
                        [FWS] ")"

   CFWS             =   *([FWS] comment) (([FWS] comment) / FWS)

   content-location =   "Content-Location:" [CFWS] URI [CFWS]

   URI              =   absoluteURI | relativeURI

   where URI is restricted to the syntax for URLs as defined in Uniform
   Resource Locators [URL] until IETF specifies other kinds of URIs.

4.2 The Content-Location Header

   A Content-Location header specifies an URI that labels the content of
   a body part in whose heading it is placed. Its value CAN be an
   absolute or a 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.

   An URI in a Content-Location header need not refer to an resource
   which is globally available 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.

   A Content-Location header can thus be used to label a resource which
   is not retrievable by some or all recipients of a message. For
   example a Content-Location header may label an object which is only
   retrievable using this URI in a restricted domain, such as within a
   company-internal web space. A Content-Location header can even
   contain a fictitious URI. Such an URI need not be globally unique.

   A single Content-Location header field is allowed in any message or
   content heading, in addition to a Content-ID header (as specified in
   [MIME1]) and, in Message headings, a Message-ID (as specified in
   [RFC822]). All of these constitute different, equally valid body part
   labels, and any of them may be used to satisfy a reference to a body
   part. Multiple Content-Location header fields in the same message
   heading are not allowed.




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


   Example of a multipart/related structure containing body parts with
   both Content-Location and Content-ID labels:

      Content-Type: multipart/related; boundary="boundary-example";
                    type="text/html"

      --boundary-example

      Content-Type: text/html; charset="US-ASCII"

      ... ... <IMG SRC="fiction1/fiction2"> ... ...
      ... ... <IMG SRC="cid:[e-mail]"> ... ...

      --boundary-example
      Content-Type: image/gif
      Content-ID: <[e-mail]>
      Content-Location: fiction1/fiction2

      --boundary-example
      Content-Type: image/gif
      Content-ID: <[e-mail]>
      Content-Location: fiction1/fiction3

      --boundary-example--

4.3 URIs of MHTML aggregates

   The URI of an MHTML aggregate is not the same as the URI of its root.
   The URI of its root will directly retrieve only the root resource
   itself, even if it may cause a web browser to separately retrieve
   in-line linked resources. If a Content-Location header field is used
   in the heading of a multipart/related, this Content-Location SHOULD
   apply to the whole aggregate, not to its root part.

   When an URI referring to an MHTML aggregate is used to retrieve this
   aggregate, the set of resources retrieved can be different from the
   set of resources retrieved using the Content-Locations of its parts.
   For example, retrieving an MHTML aggregate may return an old version,
   while retrieving the root URI and its in-line linked objects may
   return a newer version.

4.4 Encoding and decoding of URIs in MIME header fields

4.4.1 Encoding of URIs containing inappropriate characters

   Some documents may contain URIs with characters that are
   inappropriate for an RFC 822 header, either because the URI itself
   has an incorrect syntax according to [URL] or the URI syntax standard



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


   has been changed to allow characters not previously allowed in MIME
   headers. These URIs cannot be sent directly in a message header. If
   such a URI occurs, all spaces and other illegal characters in it must
   be encoded using one of the methods described in [MIME3] section 4.
   This encoding MUST only be done in the header, not in the HTML text.
   Receiving clients MUST decode the [MIME3] encoding in the heading
   before comparing URIs in body text to URIs in Content-Location
   headers.

   The charset parameter value "US-ASCII" SHOULD be used if the URI
   contains no octets outside of the 7-bit range. If such octets are
   present, the correct charset parameter value (derived e.g. from
   information about the HTML document the URI was found in) SHOULD be
   used. If this cannot be safely established, the value "UNKNOWN-8BIT"
   [RFC 1428] MUST be used.

   Note, that for the matching of URIs in text/html body parts to URIs
   in Content-Location headers, the value of the charset parameter is
   irrelevant, but that it may be relevant for other purposes, and that
   incorrect labeling MUST, therefore, be avoided. Warning: Irrelevance
   of the charset parameter may not be true in the future, if different
   character encodings of the same non-English filename are used in
   HTML.

4.4.2 Folding of long URIs

   Since MIME header fields have a limited length and long URIs can
   result in Content-Location headers that exceed this length, Content-
   Location headers may have to be folded.

   Encoding as discussed in clause 4.4.1 MUST be done before such
   folding.  After that, the folding can be done, using the algorithm
   defined in [URLBODY] section 3.1.

4.4.3 Unfolding and decoding of received URLs in MIME header fields

   Upon receipt, folded MIME header fields should be unfolded, and then
   any MIME encoding should be removed, to retrieve the original URI.

5.  Base URIs for resolution of relative URIs

   Relative URIs inside the contents of MIME body parts are resolved
   relative to a base URI using the methods for resolving relative URIs
   described in [RELURL]. In order to determine this base URI, the
   first-applicable method in the following list applies.






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


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

   (b) There is a Content-Location header in the immediately surrounding
       heading of the body part and it contains an absolute URI. This
       URI can serve as a base in the same way as a requested URI can
       serve as a base for relative URIs within a file retrieved via
       HTTP [HTTP].

   (c) If necessary, step (b) can be repeated recursively to find a
       suitable Content-Location header in a surrounding multi-part or
       message heading.

   (d) If the MIME object is returned in a HTTP response, use the URI
       used to initiate the request

   (e) When the methods above do not yield an absolute URI, a base URL
       of "thismessage:/" MUST be employed. This base URL has been
       defined for the sole purpose of resolving relative references
       within a multipart/related structure when no other base URI is
       specified.

   This is also described in other words in section 8.2 below.

6.  Sending documents without linked objects

   If a text/html resource (object) is sent without subsidiary
   resources, to which it refers, it MAY be sent by itself. In this
   case, embedding it in a multipart/related structure is not necessary.