VRML                  See Virtual Reality Markup Language [VRML].Palme, et al.               Standards Track                     [Page 5]RFC 2557       MIME Encapsulation of Aggregate Documents      March 19993.  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 Header4.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 charactersPalme, 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:97116092811xyz@foo.bar.net"> ... ...      --boundary-example      Content-Type: image/gif      Content-ID: <97116092511xyz@foo.bar.net>      Content-Location: fiction1/fiction2      --boundary-example      Content-Type: image/gif      Content-ID: <97116092811xyz@foo.bar.net>      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 fields4.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 standardPalme, 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.