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.





 
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*foo3@bar2.net
     ; A Content-Base header cannot be placed here, since this is a
     ; multipart MIME object.

    --boundary-example-1

    Part 1:
    Content-Type: Text/HTML; charset=US-ASCII
    Content-ID: <foo2*foo3@bar2.net>
    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*foo5@bar2.net>
    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




 
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.