Network Working Group Jacob Palme
Internet Draft Stockholm University/KTH
draft-palme-text-html-02.txt Sweden
Category-to-be: Standard February 1996
Expires August 1996
The Text/HTML Content Type and the Content-Location MIME Header
or
Sending HTML Documents via MIME E-mail
Status of this Memo
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).
This memo provides information for the Internet community. This'
memo does not specify an Internet standard of any kind, since
this document is mainly a compilation of information taken from
other RFC-s. Distribution of this memo is unlimited.
Abstract
This memo specifies how to send HTML-formatted documents in Internet
mail. The memo particularly addresses the issue of handling of
hyperlinks in HTML documents referring to embedded content in other
body parts in the same message. In order to do this, the memo
introduces one new MIME content-header with the name =B2Content-
Location=B2.
Palme [Page 2]
=0Cdraft-plame-text-html-02.txt February 1996
Differences from Version draft-palme-text-html-00.txt
The postscript (.ps) version of this draft shows the differences
between version 00 and 02 through underscoring and strikethru markup.
This document has been revised based on the discussions in the ietf-
types and MHTML mailing lists and in the BOF at the Dallas IETF meeting
in December 1995.
Use of the Content-Base header has been introduced. The =B2linking=B2
parameter has been removed and replaced with use of the Content-Base
parameter.
Use of the Content-Disposition header has been replaced with use of the
=B2Content-Base: FILE=B2 and =B2Content-Location=B2 headers.
Information on the new mailing list for further discussions of this
ietf draft has been added.
Syntax for embedding URI-s in MIME headers has been added, copied from
[URLBODY].
Security considerations for implementations using proxy servers has
been added.
A =B2Conformance=B2 chapter has been added.
A temporary annex on implementation has been added. This annex might be
removed in the final version of this standard.
Palme [Page 3]
=0Cdraft-plame-text-html-02.txt February 1996
Table of Contents
1. Introduction
2. Terminology
3. The Content-Location MIME Content Header
3.1 Definition of the Content-Location Header
3.2 Encoding of URI-s in RFC822 headers
4. Parameters for the Content-Type: Text/HTML
5. Use of Relative URL-s in Text/HTML Contents
6. Use of the Content-Type: Multipart/related
7. Use of the Content-type: Multipart/alternative
8. Combination of the Content-Types: Multipart/related and
Multipart/alternative.
9. Format of Links to Other Body Parts
9.1 General Location-Method: Identical URI-s in Content-
Location headers
9.2 Filename-Method: Use of virtual File Names
9.3 CID-method: Use of CID URL-s
9.4 Recommended Choice of Method:
10. Indication of Method Used
11. Content-Disposition header
12. Sending forms in e-mail
13. Encoding Considerations
14. Security Considerations
17. Conformance
16. Acknowledgments
17. References
18. Author's Address
Annex B: Issues to be resolved
Issue 1: Which methods should be recommended
Issue 2: Indication of Method Used
Issue 3: FILE or LOCAL-FILE
Issue 4: Use of Multipart/related
Issue 5: Multipart/alternative
Issue 6: Type parameter to Multipart/related
Issue 7: Replies to forms sent in e-mail
Issue 8: What is the best title for this document?
Palme [Page 4]
=0Cdraft-plame-text-html-02.txt February 1996
Mailing List Information:
Further discussion on this memo 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
The archives are also available by e-mail. Send a message to
LISTSERV@SEGATE.SUNET.SE with the text =B2INDEX MHTML=B2 to get a
list of the archive files, and then a new message =B2GET <file
name>=B2 to retrieve the archive files.
or
GET MHTML DIGEST
1. Introduction
The HTML format is a very common format for documents in the Internet,
and there is an obvious need to be able to send documents in this
format in e-mail [SMTP, RFC822]. The =B2text/html; version=3D2.0=B2 media
type is defined in [HTML2]. This memo gives additional specifications
and advice on how to use the text/html media type as a Content-Type in
MIME [MIME1] e-mail messages. In particular, the document discusses
sending of HTML documents with embedded links to images and other data
in separate files which are to be displayed inline to the recipient.
2. Terminology
Most of the terms used in this memo are defined in other RFC-s.
For example, URL is defined in [URL], URI, absolute URI, and relative
URI is defined in [HTML2].
3. The Content-Location MIME Content Header
3.1 Definition of the Content-Location Header
An additional MIME header is defined with the name =B2Content-Location=B2.
This header field can occur in any MIME message heading or content
heading. Its value can be an absolute or relative URI.
A relative URI in the Content-Location header is only allowed if there
is also a Content-Base header (as defined in [RELURL]) specifying the
base for the relative URI.
Palme [Page 5]
=0Cdraft-plame-text-html-02.txt February 1996
This header is used to indicate that the data sent under this heading
is also retrievable, in identical format, through normal use of this
URI. Thus, the information sent in the message can be seen as a cached
version of the original data. This header is only permitted if the data
is actually retrievable through use of this URI.
In practice, at present only those URI-s which are URL-s are used, but
it is anticipated that other forms of URI-s will in the
future be used. This heading is similar to the Location header as
defined in [HTTP].
The syntax for the new header is, using the syntax definition tools
from [RFC822]:
content-location ::=3D =B2Content-Location:=B2 URI-parameter
where URI is at present (November 1995) restricted to the syntax for
URL-s as defined in [URL]. This syntax will be widened when the
definition of the URI syntax becomes more stable.
Note: This header is similar to the Location header defined in [HTTP].
3.2 Encoding of URI-s in RFC822 headers
The URI must be encoded in a format which allows for splitting of long
URI-s into more than one line. This is done using the following syntax,
copied from [URLBODY]:
URL-parameter :=3D <=B2> URL-word *(*LWSP-char URL-word) <=B2>
URL-word :=3D token
; Must not exceed 40 characters in length
The syntax of an actual URL string is given in [URL]. URL
strings can be of any length and can contain arbitrary
character content. This presents problems when URLs are
embedded in MIME body part headers that are wrapped according
to RFC 822 rules. For this reason they are transformed into a
URL-parameter for inclusion in a message/external-body
content-type specification as follows:
(1) A check is made to make sure that all occurrences of
SPACE, CTLs, double quotes, backslashes, and 8-bit
characters in the URL string are already encoded using
the URL encoding scheme specified in [URL]. Any
unencoded occurrences of these characters must be
encoded. Note that the result of this operation is
nothing more than a different representation of the
original URL.
(2) The resulting URL string is broken up into substrings
of 40 characters or less.
Palme [Page 6]
=0Cdraft-plame-text-html-02.txt February 1996
(3) Each substring is placed in a URL-parameter string as a
URL-word, separated by one or more spaces. Note that
the enclosing quotes are always required since all URLs
contain one or more colons, and colons are tspecial
characters [MIME1].
Extraction of the URL string from the URL-parameter is even
simpler: The enclosing quotes and any linear whitespace are
removed and the remaining material is the URL string.
4. Parameters for the Content-Type: Text/HTML
The optional =B2version=B2 parameter for the Content-Type: Text/HTML
indicates the version of HTML used, with =B22.0=B2 as default value.
5. Use of Relative URL-s in Text/HTML Contents
The use of relative URL-s inside contents with the Content-Type:
Text/HTML SHOULD never be used except in one of the following three
cases (in order of priority, if more than one of them are present, the
first-listed applies):
(a) There is a BASE element in the HTML document which resolves the
relative URL into a non-relative URL.
(b) There is a Content-Base header (as defined in [RELURL]), giving
the base to be used.
(c) There is a Content-Location of the Text/HTML which can then serve
as the base in the same way as the URL of a HTML document itself
can serve as a base for relative URL-s within the document.
6. Use of the Content-Type: Multipart/related
A message can contain one or more Text/HTML body parts and also contain
as separate body parts, data, to which hyperlinks (as defined in
[HTML2]) in the Text/HTML body part refers.
Such embedded linked parts must, together with the Text/HTML body part,
be enclosed within a Multipart/Related body part as defined in [REL].
The root (as defined in [REL]) SHOULD then be of the Content-Type:
Text/HTML, or of the Content-Type Multipart/Alternative which resolves
to Text/HTML.
Such an embedded linked part can itself be a Multipart/related body
parts including its own linked objects.
Palme [Page 7]
=0Cdraft-plame-text-html-02.txt February 1996
7. Use of the Content-type: Multipart/alternative
If the message is sent to recipients, all of which may not have mailers
capable of handling the Text/HTML content-type, then the Content-Type:
Multipart/Alternative [MIME1] can be used, for example with Content-
Type: Text/plain as the first choice, and Content-Type: Text/HTML as
the second choice.
8. Combination of the Content-Types: Multipart/related and
Multipart/alternative.
Both the Content-type: Multipart/related, as defined in chapter 6 above
and the Content-Type: Multipart/alternative, as defined in chapter 7
above can be combined in the same message. It is then recommended to
put the Multipart/alternative inside the Multipart/related.
Example:
Content-Type: Multipart/related; boundary=3D=B2boundary-example-1=B2;
type=3DMULTIPART/ALTERNATIVE
--boundary-example 1
Content-Type: MULTIPART/ALTERNATIVE
Boundary: boundary-example-2
--boundary-example-2
Content-Type: Text/plain
... plain text version of the document for recipients
whose mailers cannot handle Text/HTML ...
--boundary-example-2
Content-Type: Text/HTML
Content-ID: content-id-example@example.host
... text of the HTML document ...
--boundary-example-2--
--boundary-example-1
Content-Type: Image/GIF
... a body part, to which the HTML document has a link ...
--boundary-example-1--
Palme [Page 8]
=0Cdraft-plame-text-html-02.txt February 1996
9. Format of Links to Other Body Parts
A Text/HTML body part may contain hyperlinks to documents which
are included as other body parts in the same message and within the
same multipart/related content. Often such linked documents are meant
to be displayed inline to the reader of the main document. HTML version
2.0 [HTML2] has only one way of specifying hyperlinks to such embedded
content, the IMG tag. New tags with this property are however proposed
in the ongoing development of HTML.
Three ways to send HTML documents with such linked body parts is
specified in this memo:
9.1 General Location-Method: Identical URI-s in Content-Location
headers
With this method, All URI-s in the Text/HTML document SHOULD be
absolute URI-s as defined in [HTML2] or relative URI-s relative to a
surrounding Content-Base header. It SHOULD be possible to use these URI-
s to retrieve the referred document using the protocol defined for
retrieval of this particular URL scheme in [URL] (subject to access
control). Thus, a recipient SHOULD be able to see the whole document
even if the recipient discards all other body parts, within the
Multipart/related, except the main HTML part, and instead retrieves
these body parts from the net.
For each distinct URI in the Text/HTML document, which refers to data
which is sent in the same MIME message, there SHOULD be a separate body
part within the multipart/related part of the message containing this
data. Each such body part SHOULD contain a Content-Location header, and
the string in this field SHOULD be identical to the URI as used in the
Text/HTML document. These separate body parts are needed for recipient
who only have e-mail but not full Internet access.
Note: By identical string is not meant equivalent URI-s but actually
identical URI strings, except for added white-space as specified in
section 3.2 above.
The receiving mailer can then resolve the hyperlink either by using the
URI in the normal way, or by using the data in the body part whose
Content-Location contains the same URI.
Example with absolute URI-s:
Content-Type: Multipart/related; boundary=3D=B2boundary-example-1=B2;
type=3DText/HTML
--boundary-example 1
Content-Type: Text/HTML
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC=3D=B2http://www.ietf.cnri.reston.va.us/images/ietflogo.gif=
=B2>
Palme [Page 9]
=0Cdraft-plame-text-html-02.txt February 1996
--boundary-example-1
Content-Type: Image/GIF
Content-Location:
=B2http://www.ietf.cnri.reston.va.us/images/ietflogo.gif=B2
--boundary-example-1--
Example with relative URI-s:
Content-Base: =B2http://www.ietf.cnri.reston.va.us=B2
Content-Type: Multipart/related; boundary=3D=B2boundary-example-1=B2;
type=3DText/HTML
--boundary-example 1
Content-Type: Text/HTML
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC=3D=B2/images/ietflogo.gif=B2>
--boundary-example-1
Content-Type: Image/GIF
Content-Location: =B2/images/ietflogo.gif=B2
--boundary-example-1--
9.2 Filename-Method: Use of virtual File Names
This method is a special case of the Location-Method described in
section 9.1, but also differs in that it may be used even if the
enclosed parts are not retrievable from other places than the body
parts included in the message.
With this method, the hyperlink URIs to other body parts in the same
message in the Text/HTML document SHOULD have a very simple format.
This simple format is relative URL-s of the form
relative-url ::=3D 1ALPHA 0#7ALPHADIGIT [ =B2.=B2 1#3ALPHADIGIT ]
ALPHADIGIT ::=3D ALPHA / DIGIT
i.e. 1-8 characters plus 0-3 extension characters, only using Ascii
letters and digits and beginning with a letter.
The choice of this simple format is to match permitted file name
formats in most operating systems in wide use today.
For each distinct URI in the Text/HTML document, which refers to data
which is sent in the same MIME message, there SHOULD be a separate body
part, within the same multi-part/related content in the message,
containing this data. Each such body part SHOULD contain a Content-
Location header. The string in this Content-Location header SHOULD be
identical to the relative URI as used in the Text/HTML document.
Palme [Page 10]
=0Cdraft-plame-text-html-02.txt February 1996
Note: This method does not require that the body parts are actually
stored in files in the recipient computer. The receiving mailer may
choose to implement this method by storing the individual body parts in
files with the virtual file name, or may choose other implementation
methods.
Example:
Content-Base: =B2FILE:=B2
Content-Type: Multipart/related; boundary=3D=B2boundary-example-1=B2;
type=3DText/HTML
--boundary-example 1
Content-Type: Text/HTML
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC=3D=B2ietflogo.gif=B2>
--boundary-example-1
Content-Type: Image/GIF
Content-Location: =B2ietflogo.gif=B2
--boundary-example-1--
9.3 CID-method: Use of CID URL-s
With this method, the hyperlink URIs to other body parts in the same
message in the Text/HTML document SHOULD be CID (Content-ID) URL-s as
defined in [URL] and [MIDCID].
For each distinct URI in the Text/HTML document, which refers to data
which is sent in the same MIME message, there SHOULD be a separate body
part in the message containing this data. Each such body part MUST have
a Content-ID header [MIME1]. The value of this Content-ID header SHOULD
be identical to the CID as used in the Text/HTML document.
Example:
Content-Type: Multipart/related; boundary=3D=B2boundary-example-1=B2;
type=3DText/HTML
--boundary-example 1
Content-Type: Text/HTML
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC=3D=B2cid:ietflogo*jpalme@dsv.su.se=B2>
--boundary-example-1
Content-Type: Image/GIF
Content-ID: ietflogo*jpalme@dsv.su.se
Palme [Page 11]
=0Cdraft-plame-text-html-02.txt February 1996
--boundary-example-1--
Note: Content-ID-s SHOULD be globally unique. It is not permitted to
make them unique only within this message or within this
multipart/related.
9.4 Recommended Choice of Method:
A Text/HTML content may always, in addition to the use the methods
described in this chapter of this memo, contain URI-s only resolvable
using the method defined for this particular URI scheme, and not
referring to any data in separate body parts of the same message.
Method Body part identifi Recommendation
cation method
=
------ ------------- --------------
=
Virtual File name=
in Content- Recommended as the primary choice, to
file name Location header be used whenever possible.
method
=
=
=
=20
=
General Cont=
ent-Location Recommended if existing HTML
Content- header documents are to be sent unchanged,
Location but only if the referred-to
method document(s) are publicly available
and retrievable using the scheme used
in the URI.
=
CID method Content-I=
D header For experimental use between
consenting partners.
=
Each Multipart/relat=
ed in the message SHOULD only use one of the three
methods described above, but if a message contains more than one
Multipart/related, then they may use different methods.
10. Indication of Method Used
Which of the methods above is used is indicated by the value of the
surrounding Content-Base header:
Method Indicated by:
------ ------------
Virtual file name method Content-Base: FILE:
as defined in [URL]
=
CID method =
Content-Base: CID
as defined in [CID]
=
General Content-Location method =
Any other Content-Base or no
Content-Base specified
Palme [Page 12]
=0Cdraft-plame-text-html-02.txt February 1996
11. Content-Disposition header
Information in the Content-Disposition header (as defined in [CONDISP])
on individual body parts within a multipart/related is ignored, since
that information is defined by tags in the HTML text itself. Receiving
mailers which are not capable of handling the multipart/related header,
and which thus by default handles the multipart/related header as if it
was multipart/mixed, can however make use of information in the Content-
Disposition header.
12. Sending forms in e-mail
When an e-mail message contains an HTML form, then the default for
ACTION (as defined in [HTML2] section 8.1.1) SHOULD be replying by e-
mail to the From: or Reply-To: address of the message containing the
form, and not, as specified in [HTML2], the base URI of the document.
13. Encoding Considerations
There are two recommended ways to encode 8-bit characters in Text/HTML
contents:
(1) Let the charset of the content part be iso-8859-1 or some other
8-bit character set, and encode the content with the QUOTED-
PRINTABLE encoding method.
(2) Let the charset of the content part be us-ascii, and encode
non-us-ascii characters in the text using the data character
encoding defined in [HTML2].
Both these encoding methods are permitted, and they can also be mixed
in the same document. Recipients must be capable of handling both
encoding alternatives. However, it is recommended that encoding method
(2) above is used when sending Text/HTML messages.
If only method (2) is used, the charset parameter SHOULD be =B2us-ascii=B2.
If method (1), or a mixture of method (1) and method (2) is used, the
charset parameter SHOULD be =B2iso-8859-1=B2 or the character set used in
the HTML text.
14. Security Considerations
There is a potential security risk if the Content-Location: heads a
body part whose data is not identical to that retrievable using the URI
in the Content-Location. To reduce this risk, it might be unsuitable to
cache the data in such a way that the cached data can be used for
retrieval of this URL from other documents than those included in the
same message as the Content-Location header.
Palme [Page 13]
=0Cdraft-plame-text-html-02.txt February 1996
One way of implementing messages with linked body parts is to handle
the linked body parts in a combined mail and WWW proxy server. The mail
client is only given the start body part, which it turns over to a web
browser. This web browser requests the linked parts in the normal way,
but these requests are intercepted by the proxy server. If this method
is used, 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.
17. Conformance
An e-mail system which claims conformance to this standard must support
sending and retrieval of HTML using both the Filename-Method and the
General Location-Method as defined in chapter 9. If the e-mail system
is only to be used on computers with full Internet connectivity, then
the e-mail system may support the General Location-Method through
ordinary HTTP retrieval of the embedded parts from the net.
16. Acknowledgments
Harald Tveit Alvestrand, Richard Baker, Roy Fielding, Al Gilman, Mark
K. Joseph, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Larry
Masinter, Keith Moore, Pete Resnick and several other people have
helped me with preparing this memo. I alone take responsibility for any
errors which may still be in the memo.
17. References
Temporary note: This list contains some references to Internet drafts.
It is anticipated that these Internet drafts will become RFC-s before
this memo. The references will then in this memo be changed to refer to
the corresponding RFC instead.
Ref. Author, title
=
--------- --------------------------------------------------------
[CID] E. Levinson: =B2Message/External-Body Content-ID Access
Type=B2, RFC 1873, December 1995.
=
[CONDISP] R. Troost, S. Dorner: =B2Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header=B2, RFC 1806, June 1995.
=
[HOSTS] R. Braden (editor): =B2Requirements for Internet Hosts --
Application and Support=B2, STD-3, RFC 1123, October 1989.
=
[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk: =B2Hypertext
Transfer Protocol -- HTTP/1.0=B2, <draft-ietf-http-v10-spec-
04.txt>, April 1996.
Palme [Page 14]
=0Cdraft-plame-text-html-02.txt February 1996
[MIME1] N. Borenstein & N. Freed: =B2MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies=B2, RFC
1521, Sept 1993.
=
[MIME2] N. Borenstein & N. Freed: =B2Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types=B2. draft-ietf-
822ext-mime-imt-02.txt, December 1995.
[NEWS] M.R. Horton, R. Adams: =B2Standard for interchange of
USENET messages=B2, RFC 1036, December 1987.
=
[REL] Harald Tveit Alvestrand, Edward Levinson: =B2The MIME
Multipart/Related Content-type=B2, <draft-levinson-
multipart-related-00.txt>, January 1995.
=
[RELURL] R. Fielding: =B2Relative Uniform Resource Locators=B2, RFC
1808, June 1995.
=
[RFC822] D. Crocker: =B2Standard for the format of ARPA Internet
text messages.=B2 STD 11, RFC 822, August 1982.
=
[SMTP] J. Postel: =B2Simple Mail Transfer Protocol=B2, STD 10, RFC
821, August 1982.
=
[URL] T. Berners-Lee, L. Masinter, M. McCahill: =B2Uniform
Resource Locators (URL)=B2, RFC 1738, December 1994.
=
[URLBODY] N. Freed and Keith Moore: =B2Definition of the URL MIME
External-Body Access-Type=B2, draft-ietf-mailext-acc-url-
01.txt, November 1995.
=
|HTML2] T. Berners-Lee, D. Connolly: =B2Hypertext Markup Language -
2.0=B2, RFC 1866, November 1995.
18. Author's Address
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
Palme [Page 15]
=0Cdraft-plame-text-html-02.txt February 1996
Annex A: Implementation methods
-------------------------------
This annex is not part of the standards and is only included for
informational purposes. This annex might be removed before making this
memo into an IETF standard.
This standard has been intentionally written to be implementable both
in cases where the web browser and e-mail program is combined, and when
they are separate programs. Implementation is of course no problem if
the web browser is combined with the e-mail client.
+---------+ +--------+
| Web | | Mail |
| browser | | client |
+-------+-+ +-+------+
| |
+--+-------------------------------+--+
| +----------+ +--+ +--+ |
| | Start | | | | | Related |
| | HTML | | | | | body part |
| | document | | | | | parts |
| +----------+ +--+ +--+ |
+-------------------------------------+
If the web browser is separate from the e-mail client, the e-mail
client might turn over the HTML body part to the web browser and ask it
to display it. One way of doing this is to store the HTML body part in
a file, and ask the web browser to display this file. If
multipart/related is used, this can be implemented by storing all the
body parts within the multipart/related in an otherwise empty
folder/directory. With the virtual file name method described in
section 9.2 above, this does not require any rewriting of the HTML text
and is thus easy to implement, that is why the virtual file name is
recommended as the primary method above.
+---------+ +--------+
| Web | | Mail |
| browser | | client |
+-------+-+ +-+------+
| |
+--+------------------------------+-+
| +--------+ +--+ +--+ |
| | Trans- | | | | | Related |
| | lation | | | | | body part |
| | table | | | | | parts |
| +--------+ +--+ +--+ |
+-----------------------------------+
With the general Content-Location methods, the web browser must in some
way be instructed to retrieve the body parts from the received message.
This can be done by a translation table, if the web browser has an API
which allows for such a table.
Palme [Page 16]
=0Cdraft-plame-text-html-02.txt February 1996
+--------+ +-----------+ +--------+
| Proxy | | Data base | | Mail |
| web |-------| of cached |-------| server |
| server | | objects | | |
+----+---+ +-----------+ +----+---+
| |
+----+----+ +----+---+
| Web | | Mail |
| browser | | client |
+-------+-+ +-+------+
| |
+--+------------------------------+-+
| Start HTML object |
+-----------------------------------+
Other methods are to rewrite the HTML text in the receiving mailer
before turning it over to the web browser, or to use a proxy web
server, to which the web browser requests are sent, and which will then
use the cached body parts instead of normal web retrieval from the
network.
The mail client and the web browser can of course communicate in other
ways, such as using inter-process communication or combining mailer and
web browser in one program.
With the CID-method, the web browser must either understand CID URL-s
and know that they refer to objects supplied by the mailer, or the HTML
document must be rewritten, before turning it over to the web browser,
replacing the CID-s with other kinds of URL-s. Such rewriting can
convert the URL-s to local file names which the web browser will use by
default, in the same way as for the virtual file name method as
described above.
Palme [Page 17]
=0Cdraft-plame-text-html-02.txt February 1996
Annex B: Issues to be resolved
Issue 1: Which methods should be recommended
The draft above defines three different methods of linking body parts
to HTML bodies, the General-Location Method, the Filename-Method and
the CID-method. Which of these three methods should (a) be described in
the document (chapter 9), (b) be recommended (section 9.4) and (c) be
required for conformance (chapter 15).
Issue 2: Indication of Method Used
An alternative to the proposal in chapter 10 above of how to indicate
which method is used, might be to use the start-info parameter in the
Multipart/related header, e.g.
Content-Type: Multipart/related; type=3Dtext/html;
start-info=3D=B2linking=3Dvirtual=B2
Issue 3: FILE or LOCAL-FILE
Should LOCAL-FILE, as defined in [MIME2] be used instead of FILE as
defined in chapter 10 above? Or should something new, such as =B2LOCAL=B2
or =B2VIRTUAL FILE=B2 be used to clarify that no real file storage is
necessary?
Issue 4: Use of Multipart/related
Is it OK to require that linked body parts must all of them be inside
the Multipart/related (as specified in chapter 9), or is it permitted
to have links to other body parts outside of the Multipart/related
within the same message, or even within other messages?
Issue 5: Multipart/alternative
Is the recommendation for combination of Multipart/related and
Multipart/alternative in chapter 8 OK?
Issue 6: Type parameter to Multipart/related
To follow the letter of RFC 1872, the type parameter of
Multipart/related in section 8 should be:
Content-Type: Multipart/related; boundary=3D=B2boundary-example-1=B2;
type=3DMULTIPART/ALTERNATIVE
It might however be more natural to specify this parameter as:
Content-Type: Multipart/related; boundary=3D=B2boundary-example-1=B2;
type=3DText/html
But this seems to require that we do not fully adhere to the letter of
RFC 1872.
Palme [Page 18]
=0Cdraft-plame-text-html-02.txt February 1996
Issue 7: Replies to forms sent in e-mail
Is there any need to specify more about the format of replies to forms
sent in e-mail, or is the text in chapter 12 above enough? I.e. could
some expert on HTML forms say if HTML itself specifies this so that we
do not need to add anything more to what is specified in the HTML
specs?
Issue 8: What is the best title for this document?
Choice 1: The Text/HTML Content Type and the Content-Location MIME
Header or Sending HTML Documents via MIME E-mail
Choice 2: The Text/HTML Content Type and the Content-Location MIME
Header
Choice 3: Sending HTML Documents via MIME E-mail
Choice 4: MIME Encapsulation of Aggregate HTML Documents (MHTML)
Palme [Page 19]