As per Relevance of the word relative, we have this rfc below:
Network Working Group J.
Request for Comments: 2110 Stockholm University/
Category: Standards Track A.
Microsoft
March 1997
MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Although HTML [RFC 1866] was designed within the context of MIME
more than the specification of HTML as defined in RFC 1866 is
for two electronic mail user agents to be able to interoperate
HTML as a document format. These issues include the naming of
that are normally referred to by URIs, and the means of
objects that go together. This document describes a set of
that will allow conforming mail user agents to be able to send
deliver and display these objects, such as HTML objects, that
contain links represented by URIs. In order to be able to
inter-linked objects, the document uses the MIME
multipart/related and specifies the MIME content-headers "Content
Location" and "Content-Base".
Table of
1. Introduction.............................................. 2
2. Terminology............................................... 3
2.1 Conformance requirement terminology................... 3
2.2 Other terminology..................................... 4
3. Overview.................................................. 5
4. The Content-Location and Content-Base MIME Content Headers 6
4.1 MIME content headers.................................. 6
4.2 The Content-Base header............................... 7
4.3 The Content-Location Header........................... 7
4.4 Encoding of URIs in e-mail headers.................... 8
5. Base URIs for resolution of relative URIs................. 8
6. Sending documents without linked objects.................. 9
7. Use of the Content-Type: Multipart/related................ 9
8. Format of Links to Other Body Parts....................... 11
Palme & Hopmann Standards Track [Page 1]
RFC 2110 MHTML March 1997
8.1 General principle..................................... 11
8.2 Use of the Content-Location header.................... 11
8.3 Use of the Content-ID header and CID URLs............. 12
9 Examples................................................... 12
9.1 Example of a HTML body without included linked objects 12
9.2 Example with absolute URIs to an embedded GIF picture 13
9.3 Example with relative URIs to an embedded GIF picture 13
9.4 Example using CID URL and Content-ID header to
embedded GIF picture.................................. 14
10. Content-Disposition header............................... 15
11. Character encoding issues and end-of-line issues......... 15
12. Security Considerations.................................. 16
13. Acknowledgments.......................................... 17
14. References............................................... 18
15. Author's Address......................................... 19
Mailing List
Further discussion on this document should be done through
mailing list MHTML@SEGATE.SUNET.SE
To subscribe to this list, send a message
LISTSERV@SEGATE.SUNET.
which contains the
SUB MHTML
Archives of this list are available by anonymous ftp
FTP://SEGATE.SUNET.SE/lists/mHTML
The archives are also available by e-mail. Send a message
LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get a
of the archive files, and then a new message "GET "
retrieve the archive files
Comments on less important details may also be sent to the editor
Jacob Palme .
More information may also be available at URL
HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.
1.
There are a number of document formats, HTML [HTML2], PDF [PDF]
VRML for example, which provide links using URIs for
resolution. There is an obvious need to be able to send documents
these formats in e-mail [RFC821=SMTP, RFC822]. This document
additional specifications on how to send such documents in MIME [
1521=MIME1] e-mail messages. This version of this standard was
on full consideration only of the needs for objects with links in
Palme & Hopmann Standards Track [Page 2]
RFC 2110 MHTML March 1997
Text/HTML media type (as defined in RFC 1866 [HTML2]), but
standard may still be applicable also to other formats for sets
interlinked objects, linked by URIs. There is no
requirement that implementations claiming conformance to
standard are able to handle URI-s in other document formats
HTML
URIs in documents in HTML and other similar formats reference
objects and resources, either embedded or directly accessible
hypertext links. When mailing such a document, it is often
to also mail all of the additional resources that are referenced
it; those elements are necessary for the complete interpretation
the primary object
An alternative way for sending an HTML document or other
containing URIs in e-mail is to only send the URL, and let
recipient look up the document using HTTP. That method is
in [URLBODY] and is not described in this document
An informational RFC will at a later time be published as
supplement to this standard. The informational RFC will
implementation methods and some implementation problems.
are recommended to read this informational RFC when
implementations of the MHTML standard. This informational RFC is
when this RFC is published, still in IETF draft status, and will
that way for at least six months in order to gain more
experience before it is published
2.
2.1 Conformance requirement
This specification uses the same words as RFC 1123 [HOSTS]
defining the significance of each particular requirement. These
are
MUST This word or the adjective "required" means that the item
an absolute requirement of the specification
SHOULD This word or the adjective "recommended" means that there
exist valid reasons in particular circumstances to ignore
item, but the full implications should be understood and
case carefully weighed before choosing a different course
Palme & Hopmann Standards Track [Page 3]
RFC 2110 MHTML March 1997
MAY This word or the adjective "optional" means that this item
truly optional. One vendor may choose to include the
because a particular marketplace requires it or because
enhances the product, for example; another vendor may
the same item
An implementation is not compliant if it fails to satisfy one or
of the MUST requirements for the protocols it implements.
implementation that satisfies all the MUST and all the
requirements for its protocols is said to be "
compliant"; one that satisfies all the MUST requirements but not
the SHOULD requirements for its protocols is said to
"conditionally compliant."
2.2 Other
Most of the terms used in this document are defined in other RFCs
Absolute URI, See RFC 1808 [RELURL].
CID See [MIDCID].
Content-Base See section 4.2 below
Content-ID See [MIDCID].
Content-Location MIME message or content part header with
URI of the MIME message or content part body
defined in section 4.3 below
Content-Transfer-Enco Conversion of a text into 7-bit octets
ding specified in [MIME1].
CR See [RFC822].
CRLF See [RFC822].
Displayed text The text shown to the user reading a
with a web browser. This may be different
the HTML markup, see the definition of
markup below
Header Field in a message or content heading
the value of one attribute
Palme & Hopmann Standards Track [Page 4]
RFC 2110 MHTML March 1997
Heading Part of a message or content before the
CRLFCRLF, containing formatted fields
attributes of the message or content
HTML See RFC 1866 [HTML2].
HTML Aggregate HTML objects together with some or all objects
to objects which the HTML object
hyperlinks
HTML markup A file containing HTML encodings as
in [HTML] which may be different from
displayed text which a person using a
browser sees. For example, the HTML
may contain "<" where the displayed
contains the character "<".
LF See [RFC822].
MIC Message Integrity Codes, codes use to
that a message has not been modified
MIME See RFC 1521 [MIME1], [MIME2].
MUA Messaging User Agent
PDF Portable Document Format, see [PDF].
Relative URI, See RFC 1866 [HTML2] and RFC 1808[RELURL].
URI, absolute and See RFC 1866 [HTML2].
URL See RFC 1738 [URL].
URL, relative See [RELURL].
VRML Virtual Reality Markup Language
3.
An aggregate document is a MIME-encoded message that contains a
document as well as other data that is required in order to
that document (inline pictures, style sheets, applets, etc.).
Aggregate documents can also include additional elements that
linked to the first object. It is important to keep in mind
differing needs of several audiences. Mail sending agents might
Palme & Hopmann Standards Track [Page 5]
RFC 2110 MHTML March 1997
aggregate documents as an encoding of normal day-to-day
mail. Mail sending agents might also send aggregate documents when
user wishes to mail a particular document from the web to
else. Finally mail sending agents might send aggregate documents
automatic responders, providing access to WWW resources for non-
connected clients
Mail receiving agents also have several differing needs. Some
receiving agents might be able to receive an aggregate document
display it just as any other text content type would be displayed
Others might have to pass this aggregate document to a
program, and provisions need to be made to make this possible
Finally several other constraints on the problem arise. It
important that it be possible for a document to be signed and for
to be able to be transmitted to a client and displayed with a
risk of breaking the message integrity (MIC) check that is part
the signature
4. The Content-Location and Content-Base MIME Content
4.1 MIME content
In order to resolve URI references to other body parts, two
content headers are defined, Content-Location and Content-Base.
these headers can occur in any message or content heading, and
then be valid within this heading and for its content
In practice, at present only those URIs which are URLs are used,
it is anticipated that other forms of URIs will in the future
used
The syntax for these headers is, using the syntax definition
from [RFC822]:
content-location ::= "Content-Location:" ( absoluteURI |
relativeURI )
content-base ::= "Content-Base:"
where URI is at present (June 1996) restricted to the syntax for
as defined in RFC 1738 [URL].
These two headers are valid only for exactly the content heading
message heading where they occurs and its text. They are thus
valid for the parts inside multipart headings, and are
meaningless in multipart headings
Palme & Hopmann Standards Track [Page 6]
RFC 2110 MHTML March 1997
These two headers may occur both inside and outside of
multipart/related part
4.2 The Content-Base
The Content-Base gives a base for relative URIs occurring in
heading fields and in HTML documents which do not have any
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.
; A Content-Base header cannot be placed here, since this is
; multipart MIME object
--boundary-example-1
Part 1:
Content-Type: Text/HTML; charset=US-
Content-ID:
Content-Location: http://www.ietf.cnir.reston.va.us/images/foo1.bar
; This Content-Location must contain an absolute URI, since no
; is valid here
--boundary-example-1
Part 2:
Content-Type: Text/HTML; charset=US-
Content-ID:
Content-Location: foo1.bar1 ; The Content-Base below applies
; this relative
Content-Base: http://www.ietf.cnri.reston.va.us/images
--boundary-example-1--
4.3 The Content-Location
The Content-Location header specifies the URI that corresponds to
content of the body part in whose heading the header is placed.
value CAN be an absolute or relative URI. Any URI or URL scheme
be used, but use of non-standardized URI or URL schemes might
some risk that recipients cannot handle them correctly
The Content-Location header can be used to indicate that the
sent under this heading is also retrievable, in identical format
through normal use of this URI. If used for this purpose, it
contain an absolute URI or be resolvable, through a Content-
Palme & Hopmann Standards Track [Page 7]
RFC 2110 MHTML March 1997
header, into an absolute URI. In this case, the information sent
the message can be seen as a cached version of the original data
The header can also be used for data which is not available to
or all recipients of the message, for example if the header refers
an object which is only retrievable using this URI in a
domain, such as within a company-internal web space. The header
even contain a fictious URI and need in that case not be
unique
Example
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/
--boundary-example-1
Part 1:
Content-Type: Text/HTML; charset=US-
... ... 
... ...
--boundary-example-1
Part 2:
Content-Type: Text/HTML; charset=US-
Content-Location: fiction1/fiction
--boundary-example-1--
4.4 Encoding of URIs in e-mail
Since MIME header fields have a limited length and URIs can get
long, these lines may have to be folded. If such folding is done,
algorithm defined in [URLBODY] section 3.1 should be employed
5. Base URIs for resolution of relative
Relative URIs inside contents of MIME body parts are
relative to a base URI. In order to determine this base URI,
first-applicable method in the following list applies
(a) There is a base specification inside the MIME body
containing the link which resolves relative URIs into
URIs. For example, HTML provides the BASE element for this
(b) There is a Content-Base header (as defined in section 4.2),
specifying the base to be used
Palme & Hopmann Standards Track [Page 8]
RFC 2110 MHTML March 1997
(c) There is a Content-Location header in the heading of the
part which can then serve as the base in the same way as
requested URI can serve as a base for relative URIs within
file retrieved via HTTP [HTTP].
When the methods above do not yield an absolute URI the procedure
section 8.2 for matching relative URIs MUST be followed
6. Sending documents without linked
If a document, such as an HTML object, is sent without other objects
to which it is linked, it MAY be sent as a Text/HTML body part
itself. In this case, multipart/related need not be used
Such a document may either not include any links, or contain
which the recipient resolves via ordinary net look up, or
links which the recipient cannot resolve
Inclusion of links which the recipient has to look up through the
may not work for some recipients, since all e-mail recipients do
have full internet connectivity. Also, such links may work for
sender but not for the recipient, for example when the link refers
an URI within a company-internal network not accessible from
the company
Note that documents with links that the recipient cannot resolve
be sent, although this is discouraged. For example, two
developing a new HTML page may exchange incomplete versions
7. Use of the Content-Type: Multipart/
If a message contains one or more MIME body parts containing
and also contains as separate body parts, data, to which these
(as defined, for example, in RFC 1866 [HTML2]) refers, then
whole set of body parts (referring body parts and referred-to
parts) SHOULD be sent within a multipart/related body part as
in [REL].
The root body part of the multipart/related SHOULD be the
object for rendering the object, such as a text/html object,
which contains links to objects in other body parts, or
multipart/alternative of which at least one alternative resolves
such a start object. Implementors are warned, however, that
mail programs treat multipart/alternative as if it had
multipart/mixed (even though MIME [MIME1] requires support
multipart/alternative).
Palme & Hopmann Standards Track [Page 9]
RFC 2110 MHTML March 1997
[REL] requires that the type attribute of the "Content-Type
Multipart/related" statement be the type of the root object, and
value can thus be "multipart/alternative". If the root is not
first body part within the multipart/related, [REL] further
that its Content-ID MUST be given in a start parameter to
"Content-Type: Multipart/related" header
When presenting the root body part to the user, the additional
parts within the multipart/related can be used
(a) For those recipients who only have e-mail but not
Internet access
(b) For those recipients who for other reasons, such as
or the use of company-internal links, cannot retrieve
linked body parts through the net
Note that this means that you can, via e-mail, send HTML
includes URIs which the recipient cannot resolve via
other connectivity-requiring URIs
(c) For items which are not available on the web
(d) For any recipient to speed up access
The type parameter of the "Content-Type: Multipart/related" MUST
the same as the Content-Type of its root
When a sending MUA sends objects which were retrieved from the WWW
it SHOULD maintain their WWW URIs. It SHOULD not transform these
into some other URI form prior to transmitting them. This will
the receiving MUA to both verify MICs included with the
message, as well as verify the documents against their
counterpoints
In certain special cases this will not work if the original
document contains URIs as parameters to objects and applets. In
a case, it might be better to rewrite the document before sending it
This problem is discussed in more detail in the informational
which will be published as a supplement to this standard
This standard does not cover the case where a multipart/
contains links to MIME body parts outside of the
multipart/related or in other MIME messages, even if methods
to those described in this standard are used. Implementors
provide such links are warned that mailers implementing this
may not be able to resolve such links
Palme & Hopmann Standards Track [Page 10]
RFC 2110 MHTML March 1997
Within such a multipart/related, ALL different parts MUST
different Content-Location or Content-ID values
8. Format of Links to Other Body
8.1 General
A body part, such as a text/HTML body part, may contain hyperlinks
objects which are included as other body parts in the same
and within the same multipart/related content. Often such
objects are meant to be displayed inline to the reader of the
document; for example, objects referenced with the IMG tag in
[RFC 1866=HTML2]. New tags with this property are proposed in
ongoing development of HTML (example: applet, frame).
In order to send such messages, there is a need to indicate
other body parts are referred to by the links in the body
containing such links. For example, a body part of Content-Type
Text/HTML often has links to other objects, which might be
in other body parts in the same MIME message. The referencing
other body parts is done in the following way: For each body
containing links and each distinct URI within it, which refers
data which is sent in the same MIME message, there SHOULD be
separate body part within the current multipart/related part of
message containing this data. Each such body part SHOULD contain
Content-Location header (see section 8.2) or a Content-ID header (
section 8.3).
An e-mail system which claims conformance to this standard
support receipt of multipart/related (as defined in section 7)
links between body parts using both the Content-Location (as
in section 8.2) and the Content-ID method (as defined in
8.3).
8.2 Use of the Content-Location
If there is a Content-Base header, then the recipient MUST
relative to absolute resolution as defined in RFC 1808 [RELURL]
relative URIs in both the HTML markup and the Content-Location
before matching a hyperlink in the HTML markup to a Content-
header. The same applies if the Content-Location contains an
URI, and the HTML markup contains a BASE element so that
URIs in the HTML markup can be resolved
If there is NO Content-Base header, and the Content-Location
contains a relative URI, then NO relative to absolute
SHOULD be performed. Matching the relative URI in the Content
Location header to a hyperlink in an HTML markup text is in this
Palme & Hopmann Standards Track [Page 11]
RFC 2110 MHTML March 1997
a two step process. First remove any LWSP from the relative URI
may have been introduced as described in section 4.4. Then perform
exact textual match against the HTML URIs. For this matching process
ignore BASE specifications, such as the BASE element in HTML.
that this only applies for matching Content-Location headers, not
URL-s in the HTML document which are resolved through network look
at read time
The URI in the Content-Location header need not refer to an
which is actually available globally for retrieval using this
(after resolution of relative URIs). However, URI-s in Content
Location headers (if absolute, or resolvable to absolute URIs)
still be globally unique
8.3 Use of the Content-ID header and CID
When CID (Content-ID) URLs as defined in RFC 1738 [URL] and RFC 1873
[MIDCID] are used for links between body parts, the Content-
statement will normally be replaced by a Content-ID header. Thus,
following two headers are identical in meaning
Content-ID: foo@bar.
Content-Location: CID: foo@bar.
Note: Content-IDs MUST be globally unique [MIME1]. It is thus
permitted to make them unique only within this message or within
multipart/related
9
9.1 Example of a HTML body without included linked
The first example is the simplest form of an HTML email message.
is not an aggregate HTML object, but simply a message with a
HTML body part. This message contains a hyperlink but does
provide the ability to resolve the hyperlink. To resolve
hyperlink the receiving client would need either IP access to
Internet, or an electronic mail web gateway
From: foo1@bar.
To: foo2@bar.
Subject: A simple
Mime-Version: 1.0
Content-Type: Text/HTML; charset=US-
Palme & Hopmann Standards Track [Page 12]
RFC 2110 MHTML March 1997
Hi there!
An example of an HTML message.
Try clicking here.
9.2 Example with absolute URIs to an embedded GIF
From: foo1@bar.
To: foo2@bar.
Subject: A simple
Mime-Version: 1.0
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML; start=foo3*foo1@bar.
--boundary-example-1
Content-Type: Text/HTML;charset=US-
Content-ID:
... text of the HTML document, which might contain a
to the other body part, for example through a statement such as
--boundary-example-1
Content-Location
http://www.ietf.cnri.reston.va.us/images/ietflogo.
Content-Type: IMAGE/
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4
etc...
--boundary-example-1--
9.3 Example with relative URIs to an embedded GIF
From: foo1@bar.
To: foo2@bar.
Subject: A simple
Mime-Version: 1.0
Content-Base: http://www.ietf.cnri.reston.va.
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/
Palme & Hopmann Standards Track [Page 13]
RFC 2110 MHTML March 1997
--boundary-example-1
Content-Type: Text/HTML; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-
... text of the HTML document, which might contain a
to the other body part, for example through a statement such as
Example of a copyright sign encoded with Quoted-Printable: =A
Example of a copyright sign mapped onto HTML markup: ¨
--boundary-example-1
Content-Location: /images/ietflogo.
Content-Type: IMAGE/
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4
etc...
--boundary-example-1--
9.4 Example using CID URL and Content-ID header to an embedded
From: foo1@bar.
To: foo2@bar.
Subject: A simple
Mime-Version: 1.0
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/
--boundary-example-1
Content-Type: Text/HTML; charset=US-
... text of the HTML document, which might contain a
to the other body part, for example through a statement such as
--boundary-example-1
Content-ID:
Content-Type: IMAGE/
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4
etc...
--boundary-example-1--
Palme & Hopmann Standards Track [Page 14]
RFC 2110 MHTML March 1997
10. Content-Disposition
Note the specification in [REL] on the relations between Content
Disposition and multipart/related
11. Character encoding issues and end-of-line
For the encoding of characters in HTML documents and other
documents into a MIME-compatible octet stream, the
mechanisms are relevant
- HTML [HTML2, HTML-I18N] as an application of SGML [SGML]
characters to be denoted by character entities as well as by
character references (e.g. "Latin small letter a with acute accent
may be represented by "á" or "á") in the HTML markup
- HTML documents, in common with other documents of the
"Content-Type text", can be represented in MIME using one
several character encodings. The MIME Content-Type "charset
parameter value indicates the particular encoding used. For
exact meaning and use of the "charset" parameter, please
[MIME-IMB section 4.2].
Note that the "charset" parameter refers only to the
character encoding. For example, the string "á" can be
in MIME with "charset=US-ASCII", while the raw character "
small letter a with acute accent" cannot
The above mechanisms are well defined and documented, and
not further explained here. In sending a message, all the
mentioned mechanisms MAY be used, and any mixture of them MAY
when sending the document via e-mail. Receiving mail user
(together with any Web browser they may use to display the document
MUST be capable of handling any combinations of these mechanisms
Also note that
- Any documents including HTML documents that contain octet
outside the 7-bit range need a content-transfer-encoding
before transmission over certain transport
[MIME1, chapter 5].
- The MIME standard [MIME1] requires that 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
LFs or something else. This is in contrast to [HTTP] where
3.6.1 allows other representations of line breaks
Palme & Hopmann Standards Track [Page 15]
RFC 2110 MHTML March 1997
Note that this might cause problems with integrity checks based
checksums, which might not be preserved when moving a document
the HTTP to the MIME environment. If a document has to be
in such a way that a checksum integrity check becomes invalid,
this integrity check header SHOULD be removed from the document
Other sources of problems are Content-Encoding used in HTTP but
allowed in MIME, and charsets that are not able to represent
breaks as CRLF. A good overview of the differences between HTTP
MIME with regards to "Content-Type: Text" can be found in [HTTP],
appendix C
If the original document has line breaks in the canonical
(CRLF), then the document SHOULD remain unconverted so that
check sums are not invalidated
A provider of HTML documents who wants his documents to
transferable via both HTTP and SMTP without invalidating
integrity checks, should always provide original documents in
canonical form with CRLF for line breaks
Some transport mechanisms may specify a default "charset"
if none is supplied [HTTP, MIME1]. Because the default differs
different mechanisms, when HTML is transferred through mail,
charset parameter SHOULD be included, rather than relying on
default
12. Security
Some Security Considerations include the potential to mail someone
object, and claim that it is represented by a particular URI (
giving it a Content-Location header). There can be no assurance
a WWW request for that same URI would normally result in that
object. It might be unsuitable to cache the data in such a way
the cached data can be used for retrieval of this URI from
messages or message parts than those included in the same message
the Content-Location header. Because of this problem, receiving
Agents SHOULD not cache this data in the same way that data that
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
recipients of documents containing such URLs
One way of implementing messages with linked body parts is to
the linked body parts in a combined mail and WWW proxy server.
mail client is only given the start body part, which it passes to
web browser. This web browser requests the linked parts from
Palme & Hopmann Standards Track [Page 16]
RFC 2110 MHTML March 1997
proxy server. If this method is used, and if the combined server
used by more than one user, then methods must be employed to
that body parts of a message to one person is not retrievable
another person. Use of passwords (also known as tickets or
cookies) is one way of achieving this. Note that some caching
proxy servers may not distinguish between cached objects from e-
and HTTP, which may be a security risk
In addition, by allowing people to mail aggregate objects, we
opening the door to other potential security problems that until
were only problems for WWW users. For example, some HTML
now either themselves contain executable content (JavaScript)
contain links to executable content (The "INSERT" specification
Java). It would be exceedingly dangerous for a receiving User
to execute content received through a mail message without
attention to restrictions on the capabilities of that
content
Some WWW applications hide passwords and tickets (access tokens
information which may not be available to anyone) and other
information in hidden fields in the web documents or in on-the-
constructed URLs. If a person gets such a document, and forwards
via e-mail, the person may inadvertently disclose
information
13.
Harald T. Alvestrand, Richard Baker, Dave Crocker, Martin J. Duerst
Lewis Geer, Roy Fielding, Al Gilman, Paul Hoffman, Richard W
Jesmajian, Mark K. Joseph, Greg Herlihy, Valdis Kletnieks,
LaLiberte, Ed Levinson, Jay Levitt, Albert Lunde, Larry Masinter
Keith Moore, Gavin Nicol, Pete Resnick, Jon Smirl, Einar Stefferud
Jamie Zawinski, Steve Zilles and several other people have helped
with preparing this document. I alone take responsibility for
errors which may still be in the document
Palme & Hopmann Standards Track [Page 17]
RFC 2110 MHTML March 1997
14.
Ref. Author,
--------- --------------------------------------------------------
[CONDISP] R. Troost, S. Dorner: "Communicating
Information in Internet Messages:
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
Language". RFC 2070, January 1997.
[HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup
- 2.0", RFC 1866, November 1995.
[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk:
Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.
[MD5] R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[MIDCID] E. Levinson: "Content-ID and Message-ID
Resource Locators". RFC 2111, February 1997.
[MIME-IMB] N. Freed & N. Borenstein: "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet
Bedies". RFC 2045, November 1996.
[MIME1] N. Borenstein & N. Freed: "MIME (Multipurpose
Mail Extensions) Part One: Mechanisms for Specifying
Describing the Format of Internet Message Bodies",
1521, Sept 1993.
[MIME2] N. Borenstein & N. Freed: "Multipurpose Internet
Extensions (MIME) Part Two: Media Types". RFC 2046,
November 1996.
[NEWS] M.R. Horton, R. Adams: "Standard for interchange
USENET messages", RFC 1036, December 1987.
Palme & Hopmann Standards Track [Page 18]
RFC 2110 MHTML March 1997
[PDF] Bienz, T., Cohn, R. and Meehan, J.: "Portable
Format Reference Manual, Version 1.1", Adboe
Inc
[REL] Edward Levinson: "The MIME Multipart/Related Content
Type". RFC 2112, February 1997.
[RELURL] R. Fielding: "Relative Uniform Resource Locators",
1808, June 1995.
[RFC822] D. Crocker: "Standard for the format of ARPA
text messages." STD 11, RFC 822, August 1982.
[SGML] ISO 8879. Information Processing -- Text and Office -
Standard Generalized Markup Language (SGML),
1986.
[SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10,
821, August 1982.
[URL] T. Berners-Lee, L. Masinter, M. McCahill: "
Resource Locators (URL)", RFC 1738, December 1994.
[URLBODY] N. Freed and Keith Moore: "Definition of the URL
External-Body Access-Type", RFC 2017, October 1996.
15. Author's
For contacting the editors, preferably write to Jacob Palme
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.
S-164 40 Kista,
Alex Hopmann E-mail: alexhop@microsoft.
Microsoft
3590 North First
Suite 300
San
CA 95134
Working group chairman
Einar Stefferud
Palme & Hopmann Standards Track [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
