rfc2110.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/3 页
TXT
1,068 行
Network Working Group J. Palme
Request for Comments: 2110 Stockholm University/KTH
Category: Standards Track A. Hopmann
Microsoft Corporation
March 1997
MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
Status of this Document
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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 and specifies the MIME content-headers "Content-
Location" and "Content-Base".
Table of Contents
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 an
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 Information
Further discussion on this document should be done through the
mailing list MHTML@SEGATE.SUNET.SE.
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)>
Archives of this list are available by anonymous ftp from
FTP://SEGATE.SUNET.SE/lists/mHTML/
The archives are also 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.
Comments on less important details may also be sent to the editor,
Jacob Palme <jpalme@dsv.su.se>.
More information may also be available at URL:
HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.HTML
1. Introduction
There are a number of document formats, HTML [HTML2], PDF [PDF] and
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 [RFC821=SMTP, RFC822]. This document gives
additional specifications on how to send such documents in MIME [RFC
1521=MIME1] e-mail messages. This version of this standard was based
on full consideration only of the needs for objects with links in the
Palme & Hopmann Standards Track [Page 2]
RFC 2110 MHTML March 1997
Text/HTML media type (as defined in RFC 1866 [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.
2. Terminology
2.1 Conformance requirement terminology
This specification uses the same words as RFC 1123 [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.
Palme & Hopmann Standards Track [Page 3]
RFC 2110 MHTML March 1997
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 RFC 1808 [RELURL].
AbsoluteURI
CID See [MIDCID].
Content-Base See section 4.2 below.
Content-ID See [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 Conversion of a text into 7-bit octets as
ding specified in [MIME1].
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.
Palme & Hopmann Standards Track [Page 4]
RFC 2110 MHTML March 1997
Heading Part of a message or content before the first
CRLFCRLF, containing formatted fields with
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 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 "<" 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 RFC 1521 [MIME1], [MIME2].
MUA Messaging User Agent.
PDF Portable Document Format, see [PDF].
Relative URI, See RFC 1866 [HTML2] and RFC 1808[RELURL].
RelativeURI
URI, absolute and See RFC 1866 [HTML2].
relative
URL See RFC 1738 [URL].
URL, relative See [RELURL].
VRML Virtual Reality Markup Language.
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
Palme & Hopmann Standards Track [Page 5]
RFC 2110 MHTML March 1997
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 content.
In practice, at present only those URIs which are URLs are used, but
it is anticipated that other forms of URIs will in the future be
used.
The syntax for these headers is, using the syntax definition tools
from [RFC822]:
content-location ::= "Content-Location:" ( absoluteURI |
relativeURI )
content-base ::= "Content-Base:" absoluteURI
where URI is at present (June 1996) restricted to the syntax for URLs
as defined in RFC 1738 [URL].
These two headers are valid only for exactly the content heading or
message heading where they occurs and its text. They are thus not
valid for the parts inside multipart headings, and are thus
meaningless in multipart headings.
Palme & Hopmann Standards Track [Page 6]
RFC 2110 MHTML March 1997
These two headers may occur both inside and outside of a
multipart/related part.
4.2 The Content-Base header
The Content-Base gives a base for relative URIs occurring in other
heading fields and in HTML documents which do not have any BASE
element in its HTML code. Its value MUST be an absolute URI.
Example showing which Content-Base is valid where:
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML; start=foo2*foo3@bar2.net
; A Content-Base header cannot be placed here, since this is a
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?