idnits 2.17.1
draft-ietf-mhtml-info-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-19) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 4 instances of too long lines in the document, the longest one
being 304 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (August 1996) is 10109 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'HOSTS' is defined on line 473, but no explicit
reference was found in the text
== Unused Reference: 'MIDCID' is defined on line 487, but no explicit
reference was found in the text
== Unused Reference: 'MIME2' is defined on line 495, but no explicit
reference was found in the text
== Unused Reference: 'NEWS' is defined on line 499, but no explicit
reference was found in the text
== Unused Reference: 'REL' is defined on line 502, but no explicit
reference was found in the text
== Unused Reference: 'RELURL' is defined on line 506, but no explicit
reference was found in the text
== Unused Reference: 'RFC822' is defined on line 509, but no explicit
reference was found in the text
== Unused Reference: 'SMTP' is defined on line 512, but no explicit
reference was found in the text
== Unused Reference: 'URL' is defined on line 515, but no explicit
reference was found in the text
== Unused Reference: 'URLBODY' is defined on line 518, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 1806 (ref. 'CONDISP') (Obsoleted by
RFC 2183)
** Obsolete normative reference: RFC 1866 (ref. 'HTML2') (Obsoleted by RFC
2854)
** Downref: Normative reference to an Informational RFC: RFC 1945 (ref.
'HTTP')
-- Possible downref: Non-RFC (?) normative reference: ref. 'MHTML'
** Downref: Normative reference to an Experimental RFC: RFC 1873 (ref.
'MIDCID')
** Obsolete normative reference: RFC 1521 (ref. 'MIME1') (Obsoleted by RFC
2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049)
== Outdated reference: A later version (-04) exists of
draft-ietf-822ext-mime-imt-02
** Obsolete normative reference: RFC 1036 (ref. 'NEWS') (Obsoleted by RFC
5536, RFC 5537)
-- Possible downref: Non-RFC (?) normative reference: ref. 'REL'
** Obsolete normative reference: RFC 1808 (ref. 'RELURL') (Obsoleted by RFC
3986)
** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822)
** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC
2821)
** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC
4248, RFC 4266)
Summary: 20 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group Jacob Palme
2 Internet Draft Stockholm University/KTH
3 draft-ietf-mhtml-info-03.txt
4 Category-to-be: Informational
5 Expires: February 1997 August 1996
7 Sending HTML in E-mail, an informational supplement to RFC ???:
8 MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)
10 Status of this Memo
12 This document is an Internet-Draft. Internet-Drafts are working
13 documents of the Internet Engineering Task Force (IETF), its
14 areas, and its working groups. Note that other groups may also
15 distribute working documents as Internet-Drafts.
17 Internet-Drafts are draft documents valid for a maximum of six
18 months and may be updated, replaced, or obsoleted by other
19 documents at any time. It is inappropriate to use Internet-
20 Drafts as reference material or to cite them other than as
21 ``work in progress.''
23 To learn the current status of any Internet-Draft, please check
24 the ``1id-abstracts.txt'' listing contained in the Internet-
25 Drafts Shadow Directories on ftp.is.co.za (Africa),
26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
29 This memo provides information for the Internet community. This' memo
30 does not specify an Internet standard of any kind. Distribution of this
31 memo is unlimited.
33 Abstract
35 The memo "MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)"
36 (draft-ietf-mhtml-spec-03.txt) specifies how to send packaged aggregate
37 HTML objects in MIME e-mail. This memo is an accompanying informational
38 document, intended to be an aid to developers. This document is not an
39 Internet standard.
41 Issues discussed are implementation methods, caching strategies, making
42 messages suitable both for mailers which can and which cannot handle
43 Multipart/related and handling recipients which do not have full
44 Internet connectivity.
46 Table of Contents
48 1. Introduction
49 2. Implementation methods
50 2.1 Method 1: Combining web browser and e-mail program
51 2.2 Method 2: Rewriting the HTML
52 2.3 Method 3: Using a translation table
53 2.4 Method 4: Using a proxy HTTP server do retrieve referenced body parts
54 2.5 Method 5: Putting the mail client into a proxy HTTP server
55 2.6 Other methods
56 2.7 Communication between web browser mail client
57 3. Caching of body parts
58 4. Recipients which cannot handle the Multipart/related Content-type
59 5. Use of the Content-Type: Multipart/alternative
60 6. Recipient may not have full Internet connectivity
61 7. Encoding of non-ascii characters
62 8. Conversion from HTTP to e-mail
63 9. Acknowledgments
64 10. References
65 11. Author's Address
67 Mailing List Information
69 Further discussion on this document should be done through the mailing
70 list MHTML@SEGATE.SUNET.SE.
72 To subscribe to this list, send a message to
73 LISTSERV@SEGATE.SUNET.SE
74 which contains the text
75 SUB MHTML
77 Archives of this list are available by anonymous ftp from
78 FTP://SEGATE.SUNET.SE/lists/mHTML/
79 The archives are also available by e-mail. Send a message to
80 LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get a list of
81 the archive files, and then a new message "GET " to retrieve
82 the archive files.
84 Comments on less important details may also be sent to the editor, Jacob
85 Palme .
87 More information may also be available at URL:
88 HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.HTML
90 1. Introduction
92 [MHTML] specifies how to send packaged aggregate HTML objects in MIME e-
93 mail. This memo is an accompanying informational document, intended to
94 be an aid to developers. This document is not an Internet standard.
96 2. Implementation methods
98 The [MHTML] standard has been intentionally written to be implementable
99 both in cases where the web browser and e-mail program is combined, and
100 when they are separate programs. Implementation is of course no problem
101 if the web browser is combined with the e-mail client.
103 2.1 Method 1: Combining web browser and e-mail program
105 This is the architecturally simplest approach. A web-browser with a
106 built in e-mail program will be able to use its own web browser
107 capabilities to display HTML-formatted messages.
109 2.2 Method 2: Rewriting the HTML
111 +---------+ +--------+
112 | Web | | Mail |
113 | browser | | client |
114 +-------+-+ +-+------+
115 | |
116 +--+-------------------------------+--+
117 | +----------+ +--+ +--+ |
118 | | Start | | | | | Related | Figure 1
119 | | HTML | | | | | body part |
120 | | document | | | | | parts |
121 | +----------+ +--+ +--+ |
122 +-------------------------------------+
124 If the web browser is separate from the e-mail client, the e-mail client
125 might turn over the HTML body part to the web browser and ask it to
126 display it (Figure 1). One way of doing this is to store the HTML body
127 part in a file, and ask the web browser to display this file. If
128 multipart/related is used, this can be implemented by storing all the
129 body parts within the multipart/related in an otherwise empty
130 folder/directory.
132 The mail client may have to rewrite the HTML, replacing URL-s with
133 shorter relative URL-s which the Web browser can resolve as file names
134 in the same directory/folder where the HTML document itself is stored
135 when turning it over to the Web browser.
137 2.3 Method 3: Using a translation table
139 +---------+ +--------+
140 | Web | | Mail |
141 | browser | | client |
142 +-------+-+ +-+------+
143 | |
144 +--+------------------------------+-+
145 | +--------+ +--+ +--+ |
146 | | Trans- | | | | | Related | Figure 2
147 | | lation | | | | | body part |
148 | | table | | | | | parts |
149 | +--------+ +--+ +--+ |
150 +-----------------------------------+
152 An alternative to rewriting the HTML file before turning it over to the
153 Web browser may be to use a translation table, in case the Web browser
154 has the capability to use such a table to rewrite URL-s on the fly while
155 displaying the document (Figure 2). This requires that the Web browser
156 is capable of receiving CID: URL-s and resolving them using this
157 translation table in the same way as for other URL-s.
159 2.4 Method 4: Using a proxy HTTP server do retrieve referenced body
160 parts
162 +--------+ +-----------+ +--------+
163 | Proxy | | Data base | | Mail |
164 | web |-------| of cached |-------| server |
165 | server | | objects | | |
166 +----+---+ +-----------+ +----+---+
167 | |
168 +----+----+ +----+---+ Figure 3
169 | Web | | Mail |
170 | browser | | client |
171 +-------+-+ +-+------+
172 | |
173 +--+------------------------------+-+
174 | Start HTML object |
175 +-----------------------------------+
177 Yet another method is to use a proxy web server, to which the web
178 browser requests are sent, and which will then use the cached body parts
179 instead of normal web retrieval from the network (Figure 3). If the Web
180 browser is set to use this proxy server for all URL-s, also for CID URL-
181 s, no rewriting of the HTML will be necessary.
183 2.5 Method 5: Putting the mail client into a proxy HTTP server
185 +--------+--------+
186 | Proxy | Mail |
187 | HTTP | client |
188 | server | |
189 +--------+--------+
190 |
191 HTTP protocol Figure 4
192 |
193 +----+----+
194 | Web |
195 | browser |
196 +---------+
198 A mail client can also be included in an HTTP server (Figure 4). The
199 user will then not have to install any mail client software in his
200 personal computer, all the mail functionality is mapped on HTTP and HTML
201 elements.
203 2.6 Other methods
205 The mail client and the web browser can of course communicate in other
206 ways, such as using inter-process communication.
208 2.7 Communication between web browser mail client
210 Many web browsers have API-s to allow other programs to communicate with
211 them. There is however no accepted real or de-facto standard for such
212 API-s, which means that a mail program which relies on such API-s will
213 only be able to use those Web browser, whose API they support.
215 Note however, that most of the methods described above can be
216 implemented with a very minimal such API. The only API function needed
217 is to be able to tell a Web browser, when it is started, to open a
218 particular file. And this API function is a standardized part of the
219 operating system on most platforms. In particular, method 1 and 3 above
220 uses the functionality that a relative URL is resolved with the location
221 of the base document as base. This means that if the base document is a
222 file, relative URL-s will be resolved as FILE URL-s in the same
223 directory/folder where the HTML document itself is placed.
225 There is a need for buttons in the Web page which the user can use to
226 get back to the mail program again after reading the mail with the Web
227 browser. A common technique to achieve this is to define a new MIME data
228 type for this button. The Web browser is then configured to transfer
229 control to the mail client when the user pushes this button, i.e.
230 downloads a file of this new MIME type.
232 3. Caching of body parts
234 Suppose a message contains body parts with the Content-Location header
235 as defined in [MHTML]. A receiving agent might then put this body part
236 into a web cache, with the URL in the Content-Location as its name, so
237 that later retrievals of this URL use the cached body parts. There is
238 however no guarantee that such a cached item is correct. Such caching is
239 thus not recommended for use in other ways than for resolution of links
240 within this e-mail message.
242 4. Recipients which cannot handle the Multipart/related Content-Type
244 A message sent according to the specifications in [MHTML] may have
245 recipients, whose mailers cannot handle the Multipart/related Content-
246 Type in the way specified in [MHTML].
248 According to [MIME1] a mailer which encounters an unknown subtype to
249 Multipart, should handle this as Multipart/mixed.
251 To improve this, Multipart/alternative can be used as discussed in
252 section 5 of this memo.
254 Content-Disposition, as specified in [CONDISP] and in [MHTML], section
255 10, can also be used as an aid to mailers which do not understand
256 Multipart/related.
258 Captions on images, which are included in the HTML text, might for non-
259 HTML-capable recipient been found in the Content-Description header. Do
260 not assume that HTML-capable user agents will display the Content-
261 Description header, they may assume that this information is included in
262 the HTML text instead.
264 5. Use of the Content-Type: Multipart/alternative
266 If the message is sent to recipients, all of which may not have mailers
267 capable of handling the Text/HTML content-type, then the Content-Type:
268 Multipart/Alternative [MIME1] can be used in two ways:
270 (a) Inside the Content-Type Multipart/related, body parts can be
271 specified with Content-Type: Text/plain as the first choice, and Content-
272 Type: Text/HTML as the second choice.
274 Example:
276 Content-Type: Multipart/related; boundary="boundary-example-1";
277 type=MULTIPART/ALTERNATIVE
279 --boundary-example 1
280 Content-Type: MULTIPART/ALTERNATIVE
281 Boundary: boundary-example-2
282 --boundary-example-2
283 Content-Type: Text/plain
285 ... plain text version of the document for recipients
286 whose mailers cannot handle Text/HTML ...
288 --boundary-example-2
289 Content-Type: Text/HTML; charset=US-ASCII
290 Content-ID: content-id-example@example.host
292 ... text of the HTML document ...
294 --boundary-example-2--
295 --boundary-example-1
296 Content-Type: Image/GIF
298 ... a body part, to which the HTML document has a link ...
299 --boundary-example-1--
301 Note that the type parameter of Multipart/related in this case should be
302 Multipart/alternative and not Text/HTML.
304 (b) Outside the Multipart/Related, with Multipart/Related as one
305 alternative and Multipart/Mixed as the other alternative.
307 When choosing between these two methods of employing
308 multipart/alternative, note the following:
310 (1) Clients which do not support Multipart/related, and which thus will
311 interpret it as multipart/mixed, will with choice (a) display
312 the inline objects. Thus, a recipient whose mailer can handle Image/gif
313 but not multipart/related will still be shown the images, they
314 will not be suppressed by being inside a suppressed branch of the
315 Multipart/alternative.
317 (2) Choice (b) will not show inline images in the Multipart/Related,
318 unless this information is repeated in both branches of the
319 Multipart/Alternative.
321 A general warning: Many mailers do not support Content-Type:
322 Multipart/alternative, and may then interpret it as Multipart/mixed.
324 6. Recipient may not have full Internet connectivity
326 The recipient of a message sent by e-mail may not always have full
327 Internet connectivity. The recipient may be behind a gateway or firewall
328 which prohibits or restricts Internet connectivity.
330 This means that the recipient may not be able to resolve URL-s in an e-
331 mail message, unless the referred-to documents are included in the e-
332 mail message itself. Thus, it is often suitable to include in an e-mail
333 message all documents which are referred to (directly or indirectly) by
334 URL-s in the message. This may of course not always be possible, in some
335 cases the set of referred-to documents (directly or indirectly) may be
336 the whole WWW document space, i.e. millions of documents. A choice must
337 then be made how much to include. Of course, it is most important to
338 include all inline objects, i.e. objects linked by such hyperlinks as
339 IMG, etc., which specify that the linked objects are to be shown to the
340 user immediately.
342 In the case of ACTION elements in HTML forms, by making these ACTION
343 elements of the "mailto:" URL type, rather than the "http:" URL type,
344 you will enable also recipients without full Internet connectivity to
345 fill in and send in your forms. The HTML specification [HTML2] allows
346 default action when no ACTION element is included, but this default
347 action may not be suitable when sending the HTML document via e-mail.
348 Thus, it is better to always put an explicit ACTION element into HTML
349 forms sent by e-mail.
351 7. Encoding of non-ascii characters
353 Displayed text Displayed text
354 | ^
355 V |
356 +-------------+ +----------------+
357 | HTML editor | | HTML viewer |
358 | | | or Web browser |
359 +-------------+ +----------------+
360 | ^
361 V |
362 HTML markup HTML markup
363 | ^
364 V |
365 +---------+ +---------------+ +-------------+ +---------------+
366 | MIME | | MIME content- | | MIME | | MIME content- |
367 | encap- | | transfer- | | heading | | transfer- |
368 | sulator | | encoder | | interpreter | | decoder |
369 +---------+ +---------------+ +-------------+ +---------------+
370 | | ^ ^
371 V V +-----------+ | |
372 MIME heading + MIME content->| Transport |->MIME heading + MIME content
373 +-----------+
375 Figure 5
377 Definitions (see Figure 5):
379 Displayed text A visual representation of the intended text.
381 HTML markup A sequence of characters formatted according to the
382 HTML specification [HTML2].
384 MIME content A sequence of octets physically forwarded via e-mail,
385 may use MIME content-transfer-encoding as specified
386 in [MIME1].
388 HTML editor Software used to produce HTML markup.
390 MIME content- Software used to encode non-US-ASCII characters
391 transfer-encoder as specified in [MIME1].
393 MIME content- Software used to decode non-US-ASCII characters
394 transfer-decoder as specified in [MIME1].
396 MIME heading Software used to interpret the information in MIME
397 interpreter headings.
399 HTML viewer Software used to display HTML documents to recipients.
401 Some implementations may have a choice of whether to represent non-ascii
402 characters at the HTML layer (using "&" entity references or numeric
403 character references as defined in [HTML2] section 3.2.1) or at the MIME
404 layer (using Content-Transfer-Encoding as defined in [MIME1] section 5).
406 In choosing between these two representation methods, note the following
407 effects:
409 (1) Modifying HTML markup may disrupt security content integrity checks.
411 (2) The choice of modifying HTML markup may be more suitable for
412 recipients whose mailers do not support MIME.
414 (3) Using MIME Content-Transfer-Encoding may be more suitable for
415 recipients who have MIME-compliant mailers but do pass the text over
416 to a web browser.
418 8. Conversion from HTTP to e-mail
420 Information received or retrieved using HTTP cannot always be sent
421 unchanged as e-mail using the Content-Type: Text/HTML, because of the
422 restrictions which MIME places no the format of Content-Type: Text/HTML.
423 The same problem may occur for documents retrieved via HTTP, which are
424 in other textual formats than HTML. In particular, note the following:
426 (a) Content-encodings allowed in HTTP, but not allowed in MIME, must be
427 removed.
429 (b) HTTP allows line breaks as bare CRs or bare LFs or something else,
430 while MIME only allows line breaks as CRLF in subtypes of the Text
431 content-type.
433 (c) HTTP allows character sets like Unicode-1-1, which do not represent
434 line breaks as CRLFs, such text may have to be rewritten to character
435 sets like Unicode-1-1-UTF-7 in which line breaks are represented as
436 CRLFs.
438 A good overview of the differences, with regard to the use of Content-
439 Type:text, between MIME and HTTP, can be found in [HTTP] appendix C.
441 If you want to send HTTP unchanged via e-mail, you might consider using
442 the content-type message/HTTP instead of the content-type Text/HTML.
444 8. Representation of line breaks
446 Implementors should note that while HTML allows bare CRs, bare LFs and
447 CRLFs as line breaks, MIME requires that all line breaks must be CRLF.
448 If you want the same HTML text to be returned after decoding that was
449 sent before encoding, then you can use BASE64 or Quoted-Printable
450 encoding of bare CRs and bare LFs.
452 9. Acknowledgments
454 Harald Tveit Alvestrand, Richard Baker, Dave Crocker, Martin J. Duerst,
455 Roy Fielding, Al Gilman, Paul Hoffman, Alexander Hopmann, Mark K.
456 Joseph, Greg Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson,
457 Jay Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Pete
458 Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski and several other
459 people have helped us with preparing this memo. I alone take
460 responsibility for any errors which may still be in the memo.
462 10. References
464 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. This list also includes some RFC-s which are not up to date, and which will be replaced by new memos presently in ietf draft status.
466 Ref. Author, title
467 --------- -------------------------------------------------------
469 [CONDISP] R. Troost, S. Dorner: "Communicating Presentation
470 Information in Internet Messages: The Content-
471 Disposition Header", RFC 1806, June 1995.
473 [HOSTS] R. Braden (editor): "Requirements for Internet Hosts --
474 Application and Support", STD-3, RFC 1123, October
475 1989.
477 [HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup Language
478 - 2.0", RFC 1866, November 1995.
480 [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext
481 Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.
483 [MHTML] J. Palme & A. Hopmann: "Packaging Aggregate HTML
484 Objects in MIME E-mail", , April 1996.
487 [MIDCID] E. Levinson: "Message/External-Body Content-ID Access
488 Type", RFC 1873, December 1995.
490 [MIME1] N. Borenstein & N. Freed: "MIME (Multipurpose Internet
491 Mail Extensions) Part One: Mechanisms for Specifying
492 and Describing the Format of Internet Message Bodies",
493 RFC 1521, Sept 1993.
495 [MIME2] N. Borenstein & N. Freed: "Multipurpose Internet Mail
496 Extensions (MIME) Part Two: Media Types". draft-ietf-
497 822ext-mime-imt-02.txt, December 1995.
499 [NEWS] M.R. Horton, R. Adams: "Standard for interchange of
500 USENET messages", RFC 1036, December 1987.
502 [REL] Harald Tveit Alvestrand, Edward Levinson: "The MIME
503 Multipart/Related Content-type", , January 1995.
506 [RELURL] R. Fielding: "Relative Uniform Resource Locators", RFC
507 1808, June 1995.
509 [RFC822] D. Crocker: "Standard for the format of ARPA Internet
510 text messages." STD 11, RFC 822, August 1982.
512 [SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
513 821, August 1982.
515 [URL] T. Berners-Lee, L. Masinter, M. McCahill: "Uniform
516 Resource Locators (URL)", RFC 1738, December 1994.
518 [URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME
519 External-Body Access-Type", draft-ietf-mailext-acc-url-
520 01.txt, November 1995.
522 11. Author's Address
524 Jacob Palme Phone: +46-8-16 16 67
525 Stockholm University and KTH Fax: +46-8-783 08 29
526 Electrum 230 E-mail: jpalme@dsv.su.se
527 S-164 40 Kista, Sweden
529 Working group chairman:
531 Einar Stefferud