Network Working Group                                       Jacob Palme
Internet Draft                                 Stockholm University/KTH
draft-ietf-mhtml-rev-00.txt
draft-ietf-mhtml-rev-01.txt                           Alexander Hopmann
IETF status: Standards track status to be: Proposed standard              Microsoft Corporation
Revises: RFC 2110
Expires: March 1998                                      September 1997

MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)

Status of this Document

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

   Although HTML [RFC 1866] was designed within the context of MIME,
   more than the specification of HTML as defined in RFC 1866 is needed
   for two electronic mail user agents to be able to interoperate using
   HTML as a document format. These issues include the naming of
   objects that are normally referred to by URIs, and the means of
   aggregating objects that go together. This document describes a set
   of guidelines that will allow conforming mail user agents to be able
   to send, deliver and display these objects, such as HTML objects,
   that can contain links represented by URIs. In order to be able to
   handle inter-linked objects, the document uses the MIME type
   multipart/related
   'multipart/related' and specifies the MIME content-headers
   "Content-Location"
   'Content-Location' and "Content-Base".

Temporary note

This is a revision of RFC 2110 to take into account problems which have
cropped up by developers when developing software adhering 'Content-Base'.

   Differences compared to RFC 2110.
RFC 2110 is an IETF Proposed Standard, and the intention is that previous version of this
document, possibly after more revisions, will either be submitted as a
revised Proposed Standard or as a Draft Standard. proposed
   standard, published in RFC 2110, are summarized in chapter 13.

Table of Contents

1. Introduction
2. Terminology
   2.1 Conformance requirement terminology
   2.2 Other terminology
3. Overview
4. The Content-Location and Content-Base MIME Content Headers
   4.1 MIME content headers
   4.2 The Content-Base header
   4.3 The Content-Location Header
   4.3 The Content-Base header
   4.4 Encoding of URIs in e-mail MIME headers
5. Base URIs for resolution of relative URIs
6. Sending documents without linked objects
7. Use of the Content-Type: Multipart/related "multipart/related"
8. Format Usage of Links to Other Body Parts
   8.1 General principle
   8.2 Use Resolution of the Content-Location header hyperlinks in text/HTML body parts
   8.3 Use of the Content-ID header and CID URLs
   8.4 Conformance requirement on receipt
9. Examples
   9.1 Example of a HTML body without included linked objects
   9.2 Example with absolute URIs to an embedded GIF picture
   9.3 Example with relative URIs to an embedded GIF picture
   9.4 Example with relative URIs and no BASE available
   9.5 Example using a BASE on the Multipart
   9.6 Example using CID URL and Content-ID header to an embedded GIF
       picture
10. Content-Disposition header
11. Character encoding issues and end-of-line issues
12. Security Considerations
13. Robustness Principle
   13.1 Content of the "type" parameter to Content-Type:
        Multipart/related
   13.2 Quoting of the "type" parameter to Content-Type:
        Multipart/related
   13.3 Quoting of the "start" parameter Differences as compared to Content-Type:
        Multipart/related and the value previous version of the Message-ID and Content-
        ID header
   13.4 Content-Base and Content-Location on Multipart Content
        headings this proposed
   standard in RFC 2110
14. Acknowledgments
15. References
16. Author's Addresses

Mailing List Information

To write contributions

     Further discussion on this document should be done through the
     mailing list MHTML@SEGATE.SUNET.SE.

     Comments on less important details may also be sent to the editor,
     Jacob Palme <jpalme@dsv.su.se>.

To subscribe

     To subscribe to this list, send a message to
     LISTSERV@SEGATE.SUNET.SE
     which contains the text
     SUB MHTML <your name (not your e-mail address)>

To unsubscribe

     To unsubscribe to this list, send a message to
     LISTSERV@SEGATE.SUNET.SE
     which contains the text
     UNS MHTML

To access mailing list archives

     Archives of this list are available for bulk downloading by
     anonymous ftp from
     FTP://SEGATE.SUNET.SE/lists/mhtml/

     The archives are available for browsing from
     HTTP://segate.sunet.se/archives/mhtml.html

     and in searchable format from

     http://www.reference.com/cgi-bin/pn/
     listarch?list=MHTML@segate.sunet.se

     Finally, thhe the archives are available by e-mail. Send a message to
     LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get a list
     of the archive files, and then a new message "GET <file name>" to
     retrieve the archive files.

More information

     Information about the IETF work in developing this standard may
     also be available at URL:
     HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#mhtml
     HTTP://www.dsv.su.se/~jpalme/ietf/mhtml.html

     It is the intention to set up a collection of test messages at the
     above URL, but no such test collection exists when this is written
     (August 1997).

1.    Introduction

There are a number of document formats, Hypertext Markup Language
[HTML2], Portable Document format [PDF] and Virtual Reality Markup
Language [VRML] for example, which provide links using URIs for their
resolution. There is an obvious need to be able to send documents in
these formats in e-mail [SMTP], [RFC822]. This document gives
additional specifications on how to send such documents in MIME [MIME1
to MIME5] e-mail messages. This version of this standard was based on
full consideration only of the needs for objects with links in the
Text/HTML media type (as defined in [HTML2]), but the standard may
still be applicable also to other formats for sets of interlinked
objects, linked by URIs. There is no conformance requirement that
implementations claiming conformance to this standard are able to
handle URI-s in other document formats than HTML.

URIs in documents in HTML and other similar formats reference other
objects and resources, either embedded or directly accessible through
hypertext links. When mailing such a document, it is often desirable to
also mail all of the additional resources that are referenced in it;
those elements are necessary for the complete interpretation of the
primary object.

An alternative way for sending an HTML document or other object
containing URIs in e-mail is to only send the URL, and let the
recipient look up the document using HTTP. That method is described in
[URLBODY] and is not described in this document.

An informational RFC will at a later time be published as a supplement to this
standard. The informational RFC will discuss implementation methods and
some implementation problems. Implementors are recommended to read this
informational RFC when developing implementations of the MHTML
standard. This informational RFC is, when this RFC is published, still
in IETF draft status, and will stay that way for at least six
months in order to gain more implementation experience before it is
published. status.

2.    Terminology

2.1   Conformance requirement terminology

This specification uses the same words as the Requirement for Internet
Hosts [HOSTS] for defining the significance of each particular
requirement. These words are:

MUST    This word or the adjective "required" means that the item is
        an absolute requirement of the specification.

SHOULD  This word or the adjective "recommended" means that there may
        exist valid reasons in particular circumstances to ignore this
        item, but the full implications should be understood and the
        case carefully weighed before choosing a different course.

MAY     This word or the adjective "optional" means that this item is
        truly optional. One vendor may choose to include the item
        because a particular marketplace requires it or because it
        enhances the product, for example; another vendor may omit the
        same item.

An implementation is not compliant if it fails to satisfy one or more
of the MUST requirements for the protocols it implements. An
implementation that satisfies all the MUST and all the SHOULD
requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but not all
the SHOULD requirements for its protocols is said to be "conditionally
compliant."

2.2   Other terminology

Most of the terms used in this document are defined in other RFCs.

Absolute URI,         See Relative Uniform Resource Locators [RELURL].
AbsoluteURI

CID                   See Message/External Body Content-ID [MIDCID].

Content-Base          See section 4.2 below.

Content-ID            See Message/External Body Content-ID [MIDCID].

Content-Location      MIME message or content part header with the URI of
                      the MIME message or content part body, defined in
                      section 4.3 below.

Content-Transfer-Enco

Content-Transfer-     Conversion of a text into 7-bit octets as specified
ding
Encoding              in [MIME1] chapter 6.

CR                    See [RFC822].

CRLF                  See [RFC822].

Displayed text        The text shown to the user reading a document with
                      a web browser. This may be different from the HTML
                      markup, see the definition of HTML markup below.

Header                Field in a message or content heading specifying
                      the value of one attribute.

Heading               Part of a message or content before the first
                      CRLFCRLF, containing formatted fields with
                      attributes of the message or content.

HTML                  See HTML 2 specification [HTML2].

HTML Aggregate        HTML objects together with some or all objects, to
objects               which the HTML object contains hyperlinks.

HTML markup           A file containing HTML encodings as specified in
                      [HTML] which may be different from the displayed
                      text which a person using a web browser sees. For
                      example, the HTML markup may contain "&lt;" where
                      the displayed text contains the character "<".

LF                    See [RFC822].

MIC                   Message Integrity Codes, codes use to verify that a
                      message has not been modified.

MIME                  See the MIME specifications [MIME1 to MIME5].

MUA                   Messaging User Agent.

PDF                   Portable Document Format, see [PDF].

Relative URI,         See HTML 2 [HTML2] and RFC 1808[RELURL].
RelativeURI

URI, absolute and     See RFC 1866 [HTML2].
relative

URL                   See RFC 1738 [URL].

URL, relative         See Relative Uniform Resource Locators [RELURL].

VRML                  See Virtual Reality Markup Language [VRML].

3.    Overview

An aggregate document is a MIME-encoded message that contains a root
document as well as other data that is required in order to represent
that document (inline pictures, style sheets, applets, etc.). Aggregate
documents can also include additional elements that are linked to the
first object.  It is important to keep in mind 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.

Mail receiving agents also have several differing needs. Some mail
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 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 immediate content.

These two headers are valid only for exactly the content heading or message heading
where they occur and its text. They are thus not valid
for the parts inside If they occur in multipart headings. They are allowed, but cannot headings,
they apply to its body parts only in that they can be used to derive a
base for resolution, when they occur relative URIs in multipart headings. the body parts, but only if no such base is
provided in the body part itself.

These two headers may occur both inside and outside of a
Multipart/related part, on any message or content heading, but
their usage for handling HTML links hyperlinks between body parts in a message
SHOULD only occur inside Multipart/related. the same "multipart/related".

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 Unform Resource Locators [URL].

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 is allowed here, but is not valid
   ; for resolution of relative URL-s in Part 1 and Part 2.
   ; A Content-Base header here would thus be rather meaningless.

   --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/foo1.bar1
   ;  This Content-Location must contain an absolute URI, since no base
   ;  is valid here. A combination of Content-Base with an absolute
   ;  URL and a Content-Location with a relative URL would also be
   ;  allowed here.

   <FRAME NAME=topwindow src="/frames/foo2.bar2">

   --boundary-example-1

   Part 2:
   Content-Type: Text/HTML; charset=US-ASCII
   Content-ID: <foo4*foo5@bar2.net>
   Content-Location: foo2.bar2   ; The Content-Base below applies to
                                 ; this relative URI
   Content-Base: http://www.ietf.cnri.reston.va.us/frames/

   <A HREF="http://www.ietf.cnir.reston.va.us/foo1.bar1">
   To top window </A>

   --boundary-example-1--

Note: If there is both a Content-ID and a Content-Location header on
the same body parts, then these will indicate two different, equally
valid references for this body part, and any of them may be used in
other body parts within the Multipart/related to refer to such a body
part.

4.3   The Content-Location Header 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 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 URI in the Content-Location header may, but 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.

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:

There MUST only be a single Content-Location header in each message or
content-heading, and its value is a single URI. Note however, that both
one Content-Location and one Content-ID or Message-ID header are
allowed. In such a case, these will indicate two different, equally
valid references for this body part, and any of them may be used in
other body parts within one "multipart/related" to refer to this body
part.

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

4.3   The Content-Base header fields have

The Content-Base gives 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 base 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 occurring 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 other
fields in section 4.2), the same content heading and in the immediately surrounding body text covered by this
content heading, specifying if the base
       to be used.

  (c) There text is a Content-Location header HTML documents which does not have
any BASE element in the immediately
       surrounding heading its HTML code. Its value MUST be an absolute URI.
The full text of the body part which can then serve Content-Base header is used as the
       base a base, even if it
does not end in the same way as the requested URI can serve as a base "/". Thus: "Content-Base: http://foo.bar/" and
"Content-Base: http://foo.bar" are identical.

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 is allowed here, and can be used
   ; for resolution of relative URIs within a file retrieved via HTTP [HTTP].

When the methods above do URL-s in Part 1 and Part 2,
   ; if these did not yield have any absolute base of their own.
   ; However, both part 1 and part 2 below have an absolute URI the procedure
   ; base, in
section 8.2 part 1 through an absolute Content-Location header,
   ; in part 2 through a Content-Base header, and thus a Content-
   ; base up here would not be used for matching resoultion of relative URIs MUST
   ; URLs within the body parts 1 and 2.

   --boundary-example-1

   Part 1:
   Content-Type: Text/HTML; charset=US-ASCII
   Content-ID: <foo2*foo3@bar2.net>
   Content-Location: http://www.ietf.cnri.reston.va.us/foo1.bar1
   ;  Since this Content-Location contains an absolute URL, it
   ;  does not need to be followed.

6.    Sending documents without linked objects

If resolved using any Content-Base header.
   ;  A combination of a document, such as Content-Location with a relative URL
   ;  and a Content-Base with an HTML object, is sent without other objects,
to which it is linked, it MAY absolute URL would also be sent valid,
   ;  as well as only a Text/HTML body part by
itself. In this case, multipart/related need not be used.

Such Content-Location with a document may either not include any links, or contain links
which relative URL
   ;  and resolved through the recipient resolves via ordinary net look up, or contain links
which Content-Base in the recipient cannot resolve.

Inclusion surrounding
   ;  multipart heading.

   <FRAME NAME=topwindow src="/frames/foo2.bar2">

   --boundary-example-1

   Part 2:
   Content-Type: Text/HTML; charset=US-ASCII
   Content-ID: <foo4*foo5@bar2.net>
   Content-Location: foo2.bar2   ; The Content-Base below applies to
                                 ; this relative URI
   Content-Base: http://www.ietf.cnri.reston.va.us/frames/

   <A HREF="http://www.ietf.cnri.reston.va.us/foo1.bar1">
   To top window </A>

   --boundary-example-1--

4.4   Encoding of links which URIs in MIME headers

4.4.1 Handling of URIs containing inappropriate characters

Some documents may contain URIs with characters that are inappropriate
for an RFC 822 header, either because the recipient URI itself has an incorrect
syntax according to look up through [URL] or the net
may not work for some recipients, since all e-mail recipients do URI syntax standard has been changed
to allow characters not
have full internet connectivity. Also, previously allowed in MIME headers. These URIs
cannot be sent directly in a mail header. There are two approaches that
can be taken when encountering such links may work for a URI as the
sender but not for text to be placed in a
Content-Location or Content-Base header:

a) In some situations, an implementation might be able to replace the recipient,
URL with one that can be sent directly. This might be accomplished, for example when
example, by using the link refers encoding method of [URL] to
an URI replace inappropriate
characters within a company-internal network not accessible from outside the company.

Note that documents URL with links that ones encoded using the recipient cannot resolve MAY %nn encoding.
This replacement MUST in that case be
sent, although this is discouraged. For example, two persons developing
a new HTML page may exchange incomplete versions.

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

If a message contains one or more MIME body parts containing links header and
also contains as separate body parts, data, to which these links (as
defined, for example, in
the HTML 2.0 [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 text which
contains links to objects in other body parts, or has a
multipart/alternative of hyperlink which at least one alternative resolves is 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).

[REL] specifies that match the type attribute header. Since
the change is mandatory done in Content-Type:
Multipart/related" headers, both places, a receiving mailer need not decode
it, and requires that MUST NOT decode [URL]-encoding before matching hyperlinks to
body parts.

b) The URL might be encoded using the this attribute method described in [MIME3]. This
replacement MUST only be done in the
type of header, not in the root object, and this HTML text.
Receiving clients must decode the [MIME3] encoding in the heading
before comparing hyperlinks in body text to URLs in Content-Location
headers.

With method (b), the charset parameter value shall thus for example "US-ASCII" SHOULD be
"multipart/alternative", if the root part is of Content-type
"multipart/alternative", even used
if one of the subparts URL contains no octets outside of the
"multipart/alternative" is of type "text/html". 7-bit range. If such
octets are present, the root is not correct charset parameter value (derived e.g.
from information about the
first body part within HTML document the multipart/related, [REL] further requires
that its Content-ID URL was found in) SHOULD
be used. If this cannot be safely established, the value "UKNOWN-8BIT"
[RFC 1428] MUST be given used.

Note that for the MHTML processing of (matching URLs in a start parameter body text to
URL in) Content-Location headers the
"Content-Type: Multipart/related" header.

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

    (a) For those recipients who only have e-mail charset parameter is
irrelevant, but not full
        Internet access.

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

       Note that purposes, and incorrect
labeling MUST therefore be avoided.

Caution should be taken in using method (a), since, in general, this means
encoding can not be applied safely to characters that you can, via e-mail, send HTML which
        includes URIs which are used for
reserved purposes within the recipient cannot resolve via HTTPor
        other connectivity-requiring URIs.

    (c) For items URL scheme. In addition, changing the HTML
body which are not available on contains the web.

    (d) For any recipient to speed up access.

The type parameter URL might invalidate a message integrity check.
Because of the "Content-Type: Multipart/related" MUST these problems, this method SHOULD only be used if it is
performed in cooperation with the
same as author/owner of the Content-Type documents
involved.

4.4.2 Folding of its root.

When long URIs

Since MIME header fields have a sending MUA sends objects which were retrieved from the WWW, it
SHOULD maintain their WWW URIs. It SHOULD not transform these limited length and URIs into
some other URI form prior to transmitting them. This will allow the
receiving MUA can get quite
long, these lines may have to both verify MICs included with the email message, as
well be folded.

Encoding as verify discussed in clause 4.4.1 must be done before such folding.
After that, the documents against their WWW counterpoints.

In certain special cases this will not work if folding can be done, using the original HTML
document contains URIs as parameters algorithm defined in
[URLBODY] section 3.1.

5.    Base URIs for resolution of relative URIs

Relative URIs inside contents of MIME body parts are resolved relative
to objects and applets. In such a
case, it might be better to rewrite base URI using the document before sending it.
This problem is discussed in more detail methods for resolving relative URIs described
in the informational RFC which
will be published as a supplement [RELURL]. In order to determine this standard.

This standard does not cover base URI, the case where first-applicable
method in the following list applies.

(a) There is a multipart/related
contains links to base specification inside the MIME body parts outside of part containing
    the current
multipart/related or 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 other MIME messages, even if methods similar to
those described section 4.2), in this standard are used. Implementors who provide
such links are warned that mailers implementing this standard may not
be able the
    immediately surrounding content heading, specifying the base to resolve such links.

Within such be
    used.

(c) There is a multipart/related, ALL different parts MUST have
different Content-ID values or Content-Location headers which resolve
to different URLs.

8.    Format header in the immediately surrounding
    heading of Links to Other Body Parts

8.1   General principle

A body part, such as a text/HTML the body part, may contain hyperlinks to
objects part which are included contains an absolute URI and can
    then serve as other body parts the base in the same message and
within way as the same multipart/related content. Often such linked objects
are meant to be displayed inline to the reader of the main document; requested URI can
    serve as a base for example, objects referenced with the IMG tag in HTML 2.0 [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 relative URIs within a need to indicate which other
body parts are referred to by the links file retrieved via HTTP
    [HTTP].

(d) Step (b) and (c) can be repeated recursively on Content-Base and
    Content-Location headers in the body parts containing
such links. For example, surrounding multi-part headings.
    However, a body part of Content-Type: Text/HTML often
has links to other objects, which might be included base from an absolute Content-Location in other body parts an inner
    heading takes precedence over a base from a Content-Base or a
    Content-Location in a surrounding heading.

When the same MIME message. The referencing methods above do not yield an absolute URI matching of two
relative URIs against each other body parts can still be done for matches within a
multipart/related. This matching is done
in as if they had been given as
base an imaginary URL "This_message:/", which exists for the following way: For each body part containing links and each
distinct URI sole
purpose of resolving relative references within it, which refers a multipart entitity.

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

6.    Sending documents without linked objects

If a document, such as an HTML object, is sent without other objects,
to data which it is sent in the same
MIME message, there SHOULD linked, it MAY be sent as a separate Text/HTML body part within the current
multipart/related part of the message containing by
itself. In this data. Each such
body part SHOULD contain case, "multipart/related" need not be used.

Such a Content-Location header (see section 8.2) document may either not include any links, 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 contain links
between body parts using both the Content-Location (as defined in
section 8.2) and
which the Content-ID method (as defined in section 8.3).

8.2   Use of recipient resolves via ordinary net look up, or contain links
which the Content-Location header

8.2.1 Matching recipient cannot resolve.

Inclusion of URL-s links which can be resolved to absolute URL-s

If there is a Content-Base header, then the recipient MUST employ
relative has to absolute resolution as defined in Relative Uniform Resource
Locators [RELURL] of relative URIs in both look up through the HTML markup and 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
Content-Location header before matching a hyperlink in
sender but not for the HTML markup
to a Content-Location header. The same applies if recipient, for example when the Content-Location
contains link refers to
an absolute URI, or if the HTML markup contains URI within a <BASE>
element so company-internal network not accessible from outside
the company.

Note that documents with links that relative URIs in the HTML markup can be resolved.
<BASE> elements inside HTML markup MUST not be used to recipient cannot resolve URI-s in
the Content-Heading which contains MAY be
sent, although this is discouraged. For example, two persons developing
a new HTML markup.

8.2.2 Matching page may exchange incomplete versions.

7.    Use of URL-s which cannot be resolved to absolute URL-s the Content-Type: "multipart/related"

If there is NO Content-Base header, a message contains one or more MIME body parts containing links and the Content-Location header
also contains a relative URI, then NO relative to absolute resolution SHOULD
be performed. Matching the relative URI in the Content-Location header as separate body parts, data, to a hyperlink which these links (as
defined, for example, in an HTML markup text is in 2.0 [HTML2]) refers, then this case whole set
of body parts (referring body parts and referred-to body parts) SHOULD
be sent within a two step
process. First remove any LWSP from the relative URI which may have
been introduced "multipart/related" body part as described in section 4.4. Then perform an exact
textual match against the HTML URIs. For this matching process, ignore
any <BASE> element defined in the HTML markup. By "exact textual match" means
case sensitive matching [REL].

Even though Content-Location and no Content-Base can occur without
multipart/related, this standard only covers their use for resolution
of encodings like
"file%20name" to "file name". (Note that the string "file name" is an
illegal URL, since unquoted spaces are not allowed in URLs.)

Note: If there are two links between body parts, one with a base, parts inside one with only a
relative URL and no base, then multipart/related. This standard
does not cover links from one of them cannot refer multipart/related to the other,
since another
multipart/related in a non-resolved relative URI cannot match an absolute URI.

8.2.3 Must the URL refer to an existing WWW object? message containing multiple multipart/related
objects.

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

8.3   Use of the Content-ID header and CID URLs

When CID (Content-ID) URLs start
object for rendering the object, such as defined in [URL] a text/html object, and [MIDCID] are used
for which
contains links between to objects in other body parts, the Content-Location statement will
normally be replaced by or a Content-ID header. Thus, the following two
headers
multipart/alternative of which at least one alternative resolves to
such a start object. Implementors are identical in meaning:

Content-ID: <foo@bar.net>
Content-Location: CID: foo@bar.net

Note: Content-IDs MUST be globally unique [MIME1]. It warned, however, that some mail
programs treat multipart/alternative as if it had been multipart/mixed
(even though MIME [MIME1] requires support for multipart/alternative).

[REL] specifies that the type attribute is thus not
permitted to make them unique only within this message or within mandatory in Content-Type:
"multipart/related" headers, and requires that this
multipart/related.

9.    Examples

9.1   Example attribute be the
type of a HTML body without included linked objects

The first the root object, and this value shall thus for example be
"multipart/alternative", if the root part is of Content-type
"multipart/alternative", even if one of the simplest form subparts of an HTML email message. This the
"multipart/alternative" is of type "text/html". If the root is not an aggregate HTML object, but simply a message with a single
HTML the
first body part. This message contains a hyperlink but does not provide part within the ability "multipart/related", [REL] further requires
that its Content-ID MUST be given in a start parameter to resolve the hyperlink. To resolve the hyperlink
"Content-Type: "multipart/related" header.

When presenting the
receiving client would need either IP access root body part to the Internet, or an
electronic mail web gateway.

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: Text/HTML; charset=US-ASCII

   <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: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: Multipart/related; boundary="boundary-example-1";
                 type="Text/HTML"; start=<foo3*foo1@bar.net>

   --boundary-example-1
      Content-Type: Text/HTML;charset=US-ASCII
      Content-ID: <foo3*foo1@bar.net>

      ... text of the HTML document, which might contain a hyperlink
      to user, the other additional body part,
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 example through a statement other reasons, 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
      etc...

   --boundary-example-1--

9.3   Example with relative URIs to an embedded GIF picture

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: Multipart/related; boundary="boundary-example-1";
                 type="Text/HTML"

   --boundary-example-1
      Content-Base: http://www.ietf.cnri.reston.va.us
      Content-Type: Text/HTML; charset=ISO-8859-1
      Content-Transfer-Encoding: QUOTED-PRINTABLE

      ... text 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 document, which might contain
    includes URIs which the recipient cannot resolve via HTTPor other
    connectivity-requiring URIs.

(c) To send a hyperlink document in a format which is preserved even if the
    object to which the other body part, for example hyperlinks refer through a statement such as:
      <IMG SRC="/images/ietflogo.gif" ALT="IETF logo">
      Example HTTP is later changed
    or deleted.

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

(e) For any recipient to speed up access.

The type parameter of a copyright sign encoded with Quoted-Printable: =A9
      Example the "Content-Type: "multipart/related" MUST be
the same as the Content-Type of its root.

When a copyright sign mapped onto HTML markup: &#168;

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

      R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
      NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
      etc...

   --boundary-example-1--

9.4   Example using CID URL and Content-ID header to an embedded GIF
picture

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: Multipart/related; boundary="boundary-example-1";
                 type="Text/HTML"

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

      ... text of the HTML document, sending MUA sends objects which might contain a hyperlink
      to were retrieved from the WWW, it
SHOULD maintain their WWW URIs. It SHOULD not transform these URIs into
some other body part, for example through a statement such as:
      <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">

   --boundary-example-1
      Content-ID: <foo4*foo1@bar.net>
      Content-Type: IMAGE/GIF
      Content-Transfer-Encoding: BASE64

      R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
      NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
      etc...

   --boundary-example-1--

10.   Content-Disposition header

Note URI form prior to transmitting them. This will allow the specification in [REL] on
receiving MUA to both verify MICs included with the relations between
Content-Disposition and multipart/related.

11.   Character encoding issues and end-of-line issues

For email message, as
well as verify the encoding of characters in HTML documents and other text documents into a MIME-compatible octet stream, against their WWW counterpoints.

In certain special cases this will not work if the following mechanisms
are relevant:

- original HTML [HTML2], [HTML-I18N]
document contains URIs as an application of SGML [SGML] allows
  characters parameters to be denoted by character entities as well as by numeric
  character references (e.g. "Latin small letter objects and applets. In such a with acute accent"
  may
case, it might be represented by "&aacute;" or "&#225;") in better to rewrite the HTML markup.

- HTML documents, document before sending it.
This problem is discussed in more detail in common with other documents of the MIME
  "Content-Type text", can informational RFC which
will be represented in published as a supplement to this standard.

This standard does not cover the case where a "multipart/related"
contains links to MIME using one body parts outside of several
  character encodings. The the current
"multipart/related" or in other MIME Content-Type "charset" parameter 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.

Within a "multipart/related", ALL different parts MUST have different
Content-ID values or Content-Location headers which resolve to
different URLs.

Two body parts in the same multipart/related can have the same relative
URI as value
  indicates of their Content-Location headers only if there are
headers contain a different Content-Base header, so that the particular encoding used. For absolute
URI after resolution against the exact meaning and
  use Content-Base header is different.

8.    Usage 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 "charset" parameter, please see [MIME2] chapter 4.

  Note that same message and
within the "charset" parameter refers only same "multipart/related" content. Often such linked objects
are meant to be displayed inline to the MIME character
  encoding. For reader of the main document;
for example, objects referenced with the string "&aacute;" can be sent IMG tag in MIME HTML 2.0 [HTML2].
New tags with "charset=US-ASCII", while this property are proposed in the raw character "Latin small letter ongoing development of
HTML (example: applet, frame).

In order to send such messages, there is a with acute accent" cannot.

The above mechanisms need to indicate which other
body parts are well defined and documented, and therefore not
further explained here. In sending a message, all referred to by the above mentioned
mechanisms MAY be used, and any mixture of them MAY occur when sending links in the document via e-mail. Receiving mail user agents (together with any
Web browser they may use body parts containing
such links. For example, a body part of Content-Type: Text/HTML often
has links to display the document) MUST other objects, which might be capable included in other body parts
in the same MIME message.

8.2   Resolution of
handling any combinations hyperlinks in text/HTML body parts

The resolution of these mechanisms.

Also note that:

- Any documents including HTML documents that contain octet values
  outside hyperlinks in text/HTML body parts is performed in
the 7-bit range need a content-transfer-encoding applied
  before transmission over certain transport protocols [MIME1, chapter
  5].

- The MIME standard [MIME2] requires that documents following way:

(a) Unfold multipl-eline header values according to [URLBODY]. Do NOT
however translate character encodings of "Content-Type:
  Text MUST be the kind described in canonical form before Content-Transfer-Encoding,
  i.e. that line breaks are encoded as CRLFs, [URL].
Example: Do not transform "a%2eb/c%20d" into "a/b/c d".

(b) Remove all MIME encodings, such as bare CRs or bare
  LFs or something else. This is content-transfer encoding and
header encodings as defined in contrast 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 [HTTP] where section
  3.6.1 allows other representations resolve all relative URIs in the HTML content and in Content-
Location headers using the procedure described in chapter 5 above. The
result of line breaks.

Note this resolution can be an absolute URI, or a fictiuous
absolute URI with the base "This_message:/" as specified in chapter 5.

(d) For each hyperlink in any HTML body, compare the value of the
hyperlink 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 Multipart/related. If the strings are identical,
octet by octet, then this hyperlink is resolved by the body part with
the same URI. 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
fictituous absolute URI with the base "This_message:/", the other must
also be such a fictituous absolute URI, and not resolvable to a real
absolute URI.

(e) If (c) fails, try to resolve the hyperlink through ordinary
Internet lookup. Resolution of hyperlinks of the URL-types "mid" or
"cid" to other content-parts, outside multipart/related, 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 CID (Content-ID) URLs as defined in [URL] and [MIDCID] are used
for links between body parts, the Content-ID header MUST be used
instead of the Content-Location header. Thus, even though the following
two headers are identical in meaning, only the Content-ID variant MUST
be used, and all "Content-Location: CID:" should be ignored.

Content-ID: <foo@bar.net>
Content-Location: CID: foo@bar.net

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".

8.4   Conformance requirement on receipt

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).

9.    Examples

Warning: If there is a contradiction between the explanatory text and
the examples in this standard, then the explanatory text, not the
examples are normative.

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: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: Text/HTML; charset=US-ASCII

   <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: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: "multipart/related"; boundary="boundary-example-1";
                 type="Text/HTML"; start=<foo3*foo1@bar.net>

   --boundary-example-1
      Content-Type: Text/HTML;charset=US-ASCII
      Content-ID: <foo3*foo1@bar.net>

      ... 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
      etc...

   --boundary-example-1--

9.3   Example with relative URIs to an embedded GIF picture

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: "multipart/related"; boundary="boundary-example-1";
                 type="Text/HTML"

   --boundary-example-1
      Content-Base: http://www.ietf.cnri.reston.va.us
      Content-Type: Text/HTML; charset=ISO-8859-1
      Content-Transfer-Encoding: QUOTED-PRINTABLE

      ... text of the HTML document, which might cause problems contain a hyperlink
      to the other body part, for example through a statement such as:
      <IMG SRC="/images/ietflogo.gif" ALT="IETF logo">
      Example of a copyright sign encoded with integrity checks based Quoted-Printable: =A9
      Example of a copyright sign mapped onto HTML markup: &#168;

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

      R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
      NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
      etc...

   --boundary-example-1--

9.4   Example with relative URIs and no BASE available

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: "multipart/related"; boundary="boundary-example-1";
                 type="Text/HTML"

   --boundary-example-1
      Content-Type: Text/HTML; charset=ISO-8859-1
      Content-Transfer-Encoding: QUOTED-PRINTABLE

      ... text of the HTML document, which might contain a hyperlink
      to the other body part, for example through a statement such as:
      <IMG SRC="ietflogo.gif" ALT="IETF logo">
      Example of a copyright sign encoded with Quoted-Printable: =A9
      Example of a copyright sign mapped onto HTML markup: &#168;

   --boundary-example-1
      Content-Location: ietflogo.gif
      Content-Type: "IMAGE/GIF"
      Content-Transfer-Encoding: BASE64

      R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
      NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
      etc...

   --boundary-example-1--

9.5   Example using a BASE on
checksums, the Multipart

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: "multipart/related"; boundary="boundary-example-1";
                 type="Text/HTML"
   Content-Base: http://www.ietf.cnri.reston.va.us/

   --boundary-example-1
      Content-Type: Text/HTML; charset=ISO-8859-1
      Content-Transfer-Encoding: QUOTED-PRINTABLE

      ... text of the HTML document, which might contain a hyperlink
      to the other body part, for example through a statement such as:
      <IMG SRC="ietflogo.gif" ALT="IETF logo">
      Example of a copyright sign encoded with Quoted-Printable: =A9
      Example of a copyright sign mapped onto HTML markup: &#168;

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

      R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
      NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
      etc...

   --boundary-example-1--

9.6   Example using CID URL and Content-ID header to an embedded GIF
picture

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: "multipart/related"; boundary="boundary-example-1";
                 type="Text/HTML"

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

      ... text of the HTML document, which might not be preserved when moving contain a document from the
HTTP hyperlink
      to the MIME environment. If other body part, for example through a document has to be converted in statement such
a way that a checksum integrity check becomes invalid, then as:
      <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">

   --boundary-example-1
      Content-Location: CID:something@else ; this
integrity check header SHOULD be removed from is disregarded
      Content-ID: <foo4*foo1@bar.net>
      Content-Type: "IMAGE/GIF"
      Content-Transfer-Encoding: BASE64

      R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
      NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
      etc...

   --boundary-example-1--

10.   Content-Disposition header

Note the document.

Other sources of problems are Content-Encoding used specification in HTTP but not
allowed [REL] on the relations between
Content-Disposition and "multipart/related".

11.   Character encoding issues and end-of-line issues

For the encoding of characters in MIME, HTML documents and charsets that other text
documents into a MIME-compatible octet stream, the following mechanisms
are not able relevant:

-     HTML [HTML2], [HTML-I18N] as an application of SGML [SGML] allows
characters to represent line
breaks be denoted by character entities as CRLF. A good overview well as by numeric
character references (e.g. "Latin small letter a with acute accent" may
be represented by "&aacute;" or "&#225;") in the HTML markup.

-     HTML documents, in common with other documents of the differences between HTTP and MIME with regards to "Content-Type: Text"
"Content-Type text", can be found represented in [HTTP],
appendix C.

If MIME using one of several
character encodings. The MIME Content-Type "charset" parameter value
indicates the original document has line breaks in particular encoding used. For the canonical form (CRLF),
then exact meaning and use
of the document SHOULD remain unconverted so "charset" parameter, please see [MIME2] chapter 4.

      Note that integrity check
sums are not invalidated.

A provider of HTML documents who wants his documents the "charset" parameter refers only to the MIME
character encoding. For example, the string "&aacute;" can be transferable
via both HTTP and SMTP without invalidating checksum integrity checks,
should always provide original documents sent in
MIME with "charset=US-ASCII", while the canonical form raw character "Latin small
letter a with
CRLF for line breaks.

Some transport acute accent" cannot.

The above mechanisms may specify are well defined and documented, and therefore not
further explained here. In sending a default "charset" parameter if
none is supplied [HTTP, MIME1]. Because the default differs for
different mechanisms, when HTML is transferred through mail, message, all the
charset parameter SHOULD above mentioned
mechanisms MAY be included, rather than relying on the
default.

12.   Security Considerations

Some Security Considerations include used, and any mixture of them MAY occur when sending
the potential to document via e-mail. Receiving mail someone an
object, and claim that it is represented by a particular URI (by giving
it a Content-Location header). There can user agents (together with any
Web browser they may use to display the document) MUST be no assurance capable of
handling any combinations of these mechanisms.

Also note that:

-     Any documents including HTML documents that contain octet values
outside the 7-bit range need a WWW
request for content-transfer-encoding applied before
transmission over certain transport protocols [MIME1, chapter 5].

-     The MIME standard [MIME2] requires that same URI would normally result documents of
"Content-Type: Text MUST be in canonical form before
Content-Transfer-Encoding, i.e. that line breaks are encoded as CRLFs,
not as bare CRs or bare LFs or something else. This is in contrast to
[HTTP] where section 3.6.1 allows other representations of line breaks.

Note that same object. It this might cause problems with integrity checks based on
checksums, which might not be unsuitable preserved when moving a document from the
HTTP to cache the data MIME environment. If a document has to be converted in such
a way that the cached
data can be used for retrieval of a checksum integrity check becomes invalid, then this URI
integrity check header SHOULD be removed from other messages or
message parts than those included in the same message as the
Content-Location header. Because document.

Other sources of this problem, receiving User Agents
SHOULD not cache this data problems are Content-Encoding used in the same way that data that was retrieved
through an HTTP or FTP request might be cached.

URLs, especially File URLs, may in their name contain company-internal
information, which may then inadvertently be revealed to recipients of
documents containing such URLs.

One way of implementing messages with linked body parts is to handle
the linked body parts but not
allowed in a combined mail and WWW proxy server. The mail
client is only given the start body part, which it passes to a web
browser. This web browser requests the linked parts from the proxy
server. If this method is used, MIME, and if the combined server is used by
more than one user, then methods must be employed to ensure that body
parts of a message to one person is not retrievable by another person.
Use of passwords (also known as tickets or magic cookies) is one way of
achieving this. Note charsets that some caching WWW proxy servers may are not
distinguish able to represent line
breaks as CRLF. A good overview of the differences between cached objects from e-mail HTTP and HTTP, which may be a
security risk.

In addition, by allowing people
MIME with regards to mail aggregate objects, we are
opening "Content-Type: Text" can be found in [HTTP],
appendix C.

If the door to other potential security problems original document has line breaks in the canonical form (CRLF),
then the document SHOULD remain unconverted so that until now
were only problems for WWW users. For example, some integrity check
sums are not invalidated.

A provider of HTML documents now
either themselves contain executable content (JavaScript) or contain
links who wants his documents to executable content (The "INSERT" specification, Java). It
would be exceedingly dangerous transferable
via both HTTP and SMTP without invalidating checksum integrity checks,
should always provide original documents in the canonical form with
CRLF for line breaks.

Some transport mechanisms may specify a receiving User Agent to execute
content received default "charset" parameter if
none is supplied [HTTP, MIME1]. Because the default differs for
different mechanisms, when HTML is transferred through a mail message without careful attention to
restrictions mail, the
charset parameter SHOULD be included, rather than relying on the capabilities of that executable content.
default.

12.   Security Considerations

Some WWW applications hide passwords and tickets (access tokens Security Considerations include the potential to
information which may not mail someone an
object, and claim that it is represented by a particular URI (by giving
it a Content-Location header). There can be no assurance that a WWW
request for that same URI would normally result in that same object. It
might be available unsuitable to anyone) and other sensitive
information in hidden fields in cache the web documents or data in on-the-fly
constructed URLs. If a person gets such a document, and forwards it via
e-mail, the person may inadvertently disclose sensitive information.

13.   Robustness Principle

The Internet Hosts requirements [HOSTS] section 1.2.2 states the very
important Internet Standards Robustness Principle:

                "Be liberal in what you accept, and
                 conservative in what you send"

This principle is of special importance when working with HTML, since
accepted practice is way that HTML readers should accept all kinds the cached
data can be used for retrieval of
faulty this URI from other messages or illegal HTML codes and make
message parts than those included in the best possible use of them.

Here is a (not complete) list same message as the
Content-Location header. Because of ways in which this principle problem, receiving User Agents
SHOULD be
implemented as applied to not cache this standard.

13.1  Content of the "type" parameter to Content-Type:
Multipart/related

What you send: Always include the "type" parameter data in the "Content-
type: Multipart/relative" header, and always make it identical to the
Content-type of the root as specified same way that data that was retrieved
through an HTTP or FTP request might be cached.

URLs, especially File URLs, may in RFC 2112.

What you accept: Regard the "type" parameter only as a hint, whose
value their name contain company-internal
information, which may then inadvertently be wrong. Also accept input where this parameter is omitted.

13.2  Quoting of the "type" parameter revealed to Content-Type:
Multipart/related

What you send: Always quote this parameter if it contains any recipients of the
characters  "(" / ")" / "<" / ">" / "@" /, "," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "=" as required by [MIME1] section 5.1.

What you accept: Accept this parameter, even if it contains these
characters without quoting.

13.3  Quoting
documents containing such URLs.

One way of the "start" parameter implementing messages with linked body parts is to Content-Type:
Multipart/related and the value of the Message-ID and Content-ID header

What you send: Always surround the Message-ID in handle
the Message-ID and
Content-ID value and linked body parts in a combined mail and WWW proxy server. The mail
client is only given the start parameter of Content-Type
Multipart/related with "<" and ">" as specified in  [REL] and [RFC822].

What you accept: Accept these values without surrounding "<" ">", and
treat them as if they had been surrounded by angle brackets.

13.4  Content-Base and Content-Location on Multipart Content headings

What you send: Do not use body part, which it passes to a web
browser. This web browser requests the Content-Base or linked parts from the Content-Location
header on a Multipart/related proxy
server. If this method is used, and if you expect the combined server is used by
more than one user, then methods must be employed to ensure that this Content-Base body
parts of a message to one person is not retrievable by another person.
Use of passwords (also known as tickets or
Content-Location magic cookies) is to one way of
achieving this. Note that some caching WWW proxy servers may not
distinguish between cached objects from e-mail and HTTP, which may be used for any URI resolution. These headers a
security risk.

In addition, by allowing people to mail aggregate objects, we are meant
opening the door to convey information other potential security problems that until now
were only problems for this particular body parts,
not for its subparts, and thus cannot WWW users. For example, some HTML documents now
either themselves contain executable content (JavaScript) or contain
links to executable content (The "INSERT" specification, Java). It
would be used exceedingly dangerous for resolution of URLs
inside a receiving User Agent to execute
content received through a mail message without careful attention to
restrictions on the subparts capabilities of that executable content.

Some WWW applications hide passwords and tickets (access tokens to
information which may not be available to anyone) and other sensitive
information in hidden fields in the multipart.

What you accept: web documents or in on-the-fly
constructed URLs. If a message you receive has person gets such a Content-Base or
Content-Location, document, and lacks forwards it via
e-mail, the person may inadvertently disclose sensitive information.

13.   Differences as compared to the previous version of this information on a subpart, so that you
cannot resolve URIs proposed
standard in the subpart,  you might try RFC 2110

In order to use agree with [RELURL], Content-Base headers in multipart
Content-Headings can now be used to resolve relative URLs in their
component parts, but only if no base URL can be derived from the
component part itself. Base URLs in inner headings, both in Content-
Base and Content-Location to resolve URIs headers, have precedence over base URls in
outer multipart headings.

Specification added that a Content-Heading cannot contain more than one
Content-Location header.

A section 4.4.1 has been added, specifying how to handle the case of
sending a body part whose URI does not agree with the subpart. correct URI
syntax.

The handling of relative and absolute URIs for matching between body
parts have been merged into a single description, by specifying that
relative URIs which cannot be resolved otherwise should be handled as
if they had been given imaginary URL "This_message:/".

14.   Acknowledgments

Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin
J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul
Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg
Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt,
Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W. Peck,
Pete Resnick, Nick Shelness, Jon Smirl, Einar Stefferud, Jamie
Zawinski, Steve Zilles and several other people have helped us with
preparing this document. I alone take responsibility for any errors
which may still be in the document.

15.   References

Ref.            Author, title
---------       --------------------------------------------------------

[CONDISP]       R. Troost, S. Dorner: "Communicating Presentation
                Information in Internet Messages: The
                Content-Disposition Header", RFC 1806, June 1995.

[HOSTS]         R. Braden (editor): "Requirements for Internet Hosts --
                Application and Support", STD-3, RFC 1123, October 1989.

[HTML-I18N]     F. Yergeau, G. Nicol, G. Adams, & M. Duerst:
                "Internationalization  of the Hypertext Markup
                Language". RFC 2070, January 1997.

[HTML2]         T. Berners-Lee, D. Connolly: "Hypertext Markup Language
                - 2.0", RFC 1866, November 1995.

[HTTP]          T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext
                Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.

[MD5]           R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321,
                April 1992.

[MIDCID]        E. Levinson: "Message/External-Body
                "

                Message/External-Body Content-ID Access"Message/External-
                Body Content-ID and Message-ID Uniform Resource
                Locators", RFC 2111, February 1997.
                %%% This must be replaced by a reference to the new IETF
                draft which replaces RFC 2111 %%%
[MIME1]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part One: Format of Internet Message
                Bodies", RFC 2045, December 1996 1996.
                .
[MIME-IMB]      N. Freed & N. Borenstein
                :: "Multipurpose Internet Mail Extensions (MIME) Part
                One: Format of Internet Message Bedies". RFC 2045,
                November 1996.

[MIME2]         N. Freed, N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part Two:  Media Types", RFC 2046,
                December 1996.

[MIME3]         K. Moore, "MIME (Multipurpose Internet Mail Extensions)
                Part Three:  Message Header Extensions for Non-ASCII
                Text", RFC 2047, December 1996.

[MIME1]         N. Borenstein & N. Freed: "MIME (Multipurpo
                N. Borenstein & N. Freed:se Internet Mail Extensions)
                Part One: Mechanisms for Specify
                One: Mechanisms for Specifying and ing and Describing
                the Format of Internet Message Bodies", RFC 1521, Sept
                1993.

[MIME4]          N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
                Mail Extensions (MIME) Part Four:  Registration
                Procedures", RFC 2048, January 1997.

[MIME5]         "Multipurpose Internet Mail Extensions (MIME) Part Five:
                Conformance Criteria and Examples", RFC 2049, December
                1996.

[NEWS]          M.R. Horton, R. Adams: "Standard for interchange of
                USENET messages", RFC 1036, December 1987.

[PDF]           Tim Bienz and Richar Cohn: "Portable Document Format
                Reference Manual", Addison-Wesley, Reading, MA, USA,
                1993, ISBN 0-201-62628-4.

[REL]           Edward Levinson: "The MIME Multipart/Related Content-
                Type",
                Multipart/Related"multipart/related" Content-Type", RFC
                2112, February 1997.
                %%% This must be replaced by a reference to the new IETF
                draft which replaces RFC 2112 %%%
[RELURL]        R. Fielding: "Relative Uniform Resource Locators", RFC
                1808, June 1995.

[RFC822]        D. Crocker: "Standard for the format of ARPA Internet
                text messages." STD 11, RFC 822, August 1982.

[SGML]          ISO 8879. Information Processing -- Text and Office  -
                Standard Generalized Markup Language (SGML),
                1986. <URL:http://www.iso.ch/cate/d16387.html>

[SMTP]          J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
                821, August 1982.

[URL]           T. Berners-Lee, L. Masinter, M. McCahill: "Uniform
                Resource Locators (URL)", RFC 1738, December 1994.

[URLBODY]       N. Freed and Keith Moore: "Definition of the URL MIME
                External-Body Access-Type", RFC 2017, October 1996.

[VRML]          Gavin Bell, Anthony Parisi, Mark Pesce: "Virtual Reality
                Modeling Language (VRML) Version 1.0 Language
                Specification." May 1995,
                http://www.vrml.org/Specifications/.

16.   Author's Addresses

For contacting the editors, preferably write to Jacob Palme rather than
Alex Hopmann.

Jacob Palme                          Phone: +46-8-16 16 67
Stockholm University and KTH         Fax: +46-8-783 08 29
Electrum 230                         E-mail: jpalme@dsv.su.se
S-164 40 Kista, Sweden

Alex Hopmann                         E-mail: alexhop@microsoft.com
Microsoft Corporation
3590 North First Street
Suite 300
San Jose
CA 95134

Working group chairman:

Einar Stefferud <stef@nma.com>
I.