MHTML Implementation status report form version 6, 28 October 1998

This form can be used to report the status of implementation of various features of the MHTML standard. The object of this reporting is

To check that different implementations can co-work by supporting the same facilities.
To check whether there exists two different co-working implementations of each feature, since this is needed to progress the MHTML standard from proposed to draft status in IETF.

This document is available from URL: http://dsv.su.se/jpalme/ietf/mhtml-impl-status-v5.html. It is also available in RTF format from URL: http://dsv.su.se/jpalme/ietf/mhtml-impl-status-v5.rtf . Please fill in the form before 15 November 1998 and send the filled-in form by e-mail to Jacob Palme <jpalme@dsv.su.se>. To fill in the form, use an HTML editor like Frontpage, Netscape Gold, Pagemill, Dreamweaver, etc. This is not a HTML form which can be filled in using a web browser and submitted with a SUBMIT button.

When nothing else is said, the form is meant to cover sending via SMTP and receipt via e-mail protocols like SMTP, POP or IMAP.

Your name:

Your company:

Software product:

Are you using any software (for handling HTML-formatted e-mail) you have not developed yourself (like using a web browser/HTML viewer from some other manufacturer). If so, indicate which such softwares you are using.

Is your implementation A commercial product An experimental or research product

The reason for the question about use of other company's software is that according to IETF rules, a standards feature must be supported by two different implementations to allow progressing of a standard from proposed to draft status.

Notation to use when filling in the table below: If you have this feature now in at least beta-release, write "now". You can also, if you so wish, report features which will soon be implemented in future releases of your software, by filling in words like "coming" or "this year".

Form A: Questions on fulfillment of standards functions

No.
Content-type used when sending HTML Support for sending Support for receipt using your own software Support for receipt using other company's software

1
Does your implementation support Content-Type: Multipart/related?

2
Does your implementation support Content-Type: Message/HTTP?

Link types between body parts Support for sending Support for receipt using your own software Support for receipt using other company's software

3
Support of "cid:" type links between body parts.

4
Support for Content-Location with absolute URIs for links between body parts.

5
Support for Content-Location with relative URIs, using the implied base "this_message:/", for links between body parts.

6
Support for Content-Location with relative URIs, which are resolved to absolute URIs through base indicated in a Content-Location in a surrounding multi-part content-heading.

7
Support for Content-Location header to indicate a Base to be used for other URLs in the same content body.

8
Support for Content-Location header on a multipart body to apply recursively to included body parts.

9a
Support for nested multipart/related inside each other, with links from an inner such structure to an outer such structure.

9b
If your implementation receives a document with a hyperlink (inline or not inline) which it cannot support, will it then show nothing on the screen, or show something, like a broken image, to indicate that here is a graphic which you cannot render. Not applicable

Which of the following methods of producing HTML messages does your implementation support: Support for sending Support for receipt using your own software Support for receipt using other company's software

10
a. Submitting HTML taken from the web (local or global), user gives URL. Not applicable Not applicable

11
b. Editing HTML with an editor provided for writing e-mail messages. Not applicable Not applicable

12
c. Taking HTML from files (which might have been produced with separate HTML editor). Not applicable Not applicable

Non-e-mail use of MHTML Support using your own software Support using other company's software

13
MHTML objects (Content-Type: message/rfc822) can be retrieved through HTTP and displayed. Not applicable

14
MHTML objects (Content-Type: multipart/related) can be retrieved through HTTP and displayed. Not applicable

15
Aggregate HTML documents, retrieved through HTTP, can be saved in MHTML format (combining all body parts in one saved file of Content-Type: message/rfc822 or Content-Type: Multipart/related). Not applicable

16
Aggregate HTML documents, received through e-mail, can be saved in MHTML format (combining all body parts in one saved file of Content-Type: message/rfc822 or Content-Type: Multipart/related). Not applicable

Support of HTML features in e-mail messages Support for sending Support for receipt using your own software Support for receipt using other company's software

17
Basic HTML <P>, <H1>, <BR>, <I>, <UL>, <OL>, etc.

18
HTML Tables.

19
HTML forms with transmission of the result in the Content-Type: application/x-www-form-urlencoded

20
HTML forms with transmission of the result in the Content-Type: multipart/form-data

21
HTML forms with mailto submisson of results

22
HTML forms with http submission of results

23
Images in GIF format.

24
Images in JPEG format.

25
Other image formats than GIF and JPEG

26
Frames.

27
Java.

28
Javascript.

29
Encoding of line breaks using CRLF (after Content-Transfer-Decoding).

30
Encoding of line breaks using LF or CR (after Content-Transfer-Decoding, allowed in HTTP but not in e-mail).

Advanced MHTML features Support for sending Support for receipt using your own software Support for receipt using other company's software

31
Combination of multipart/related with multipart/alternative, with multipart/alternative outside the multipart/related.

32
Combination of multipart/related with multipart/alternative, with multipart/alternative inside the multipart/related, usually as the start body part of the mulitpart/related.

33
Hyperlinks between body parts in different messages.

34
Support for using MHTML for other primary formats than HTML, for example PDF or VRML.

35
Multipart/related where all parts are not displayed inline, for example sending a set of linked HTML pages in one message, which the recipient can move between by clicking on hyperlinks.

36
More than one multipart/related inside the same e-mail message.

36b
Does your implementation support multipart/related for other root object formats than text/html or multipart/alternative with text/html as one choice? If so, which format?

Which of the following methods of putting in-line objects like IMG-linked graphics, etc., into HTML messages does your implementation support Support for sending Support for receipt using your own software Support for receipt using other company's software

37
a. All included in the message.

38
b. Not all included in the message, non-included parts retrieved through URLs in the HTML text, which the recipient mailer can resolve through, for example, HTTP requests.

39
b. Not all included in the message, non-included parts retrieved through use of Content-Type: Message/external-body.

Security Support for sending Support for receipt using your own software Support for receipt using other company's software

40
Combination of MHTML with PGP.

41
Combination of MHTML with SMIME.

42
Documents can be taken from the web, and posted through e-mail, without breaking security cheksums.

Documents received through e-mail can be posted for HTTP retrieval, without breaking security checksums: Do not fill in this field Do not fill in this field Do not fill in this field

43
(A) If the document uses relative Content-Locations. Not applicable Not applicable

44
(B) If the document uses absolute Content-Locations. Not applicable Not applicable

45
(C) If the document uses Content-Ids and "mid:" type hyperlinks. Not applicable Not applicable

Syntax issues Support for sending Support for receipt using your own software Support for receipt using other company's software

46
Folding of long URLs to fit in <80 character lines according to the MHTML standard.

47
Content-Transfer-Encoding of characters not in ASCII, like "é".

48
HTML &-markup of characters not in ASCII, like "é".

Form B: Questions not related to fulfillment of standards functions

This form is not necessary for IETF needs, implementors can fill it in if they are willing to.

Syntax issues Support for sending Support for receipt using your own software Support for receipt using other company's software

49
HTML objects retrieved through e-mail are cached in a cache which is also used for objects retrieved via HTTP.

50
HTML objects retrieved through e-mail are cached in a cache which is only used for e-mail, and not for objects retrieved via HTTP.

51
A cache of objects received through HTTP is used in showing messages received through e-mail for resolving links which are not resolved within the e-mail message.

Automatic rewriting of HTML (not manual rewriting done when the user gives editing commands) Support for sending Support for receipt using your own software Support for receipt using other company's software

52
Any checking of the correctness of submitted HTML before sending it? Not applicable Not applicable

53
Does your implementation rewrite the URLs in HTML text in some cases before sending it? Not applicable Not applicable

54
Does your implementation do any other rewriting of HTML before sending. Not applicable Not applicable

55
Does your implementation rewrite the URLs in HTML text in some cases at receipt, before displaying it? If so, when? Not applicable

How does your implementation communicate between web browser and mailer when displaying incoming messages? Support for sending Support for receipt using your own software Support for receipt using other company's software

56
(A) By rewriting the HTML and storing all the body parts as files in the same directory. Not applicable

57
(B) By a translation table. Not applicable

58
(C) By a proxy HTTP server. Not applicable

59
(D) Browser and mailer combined for all kinds of HTML messages. Not applicable

60
(E) By turning the whole multipart/related over to a web browser capable of handling this format. Not applicable

61 (F) No communication needed, since web browser and mailer are intregated. Not applicable

62
(G) Some other method. Not applicable

How does your implementation communicate between web browser and mailer when displaying incoming messages? Support for sending Support for receipt using your own software Support for receipt using other company's software

63
(A) Fully integrated web browser and mailer Not applicable

64
(B) Web browser displays message in a frame within the mailer Not applicable

65
(C) Web browser executed as separate software Not applicable

Your name:
Your company:
Software product:
Are you using any software (for handling HTML-formatted e-mail) you have not developed yourself (like using a web browser/HTML viewer from some other manufacturer). If so, indicate which such softwares you are using.
Is your implementation	A commercial product	An experimental or research product

No.	Content-type used when sending HTML	Support for sending	Support for receipt using your own software	Support for receipt using other company's software
1	Does your implementation support Content-Type: Multipart/related?
2	Does your implementation support Content-Type: Message/HTTP?
	Link types between body parts	Support for sending	Support for receipt using your own software	Support for receipt using other company's software
3	Support of "cid:" type links between body parts.
4	Support for Content-Location with absolute URIs for links between body parts.
5	Support for Content-Location with relative URIs, using the implied base "this_message:/", for links between body parts.
6	Support for Content-Location with relative URIs, which are resolved to absolute URIs through base indicated in a Content-Location in a surrounding multi-part content-heading.
7	Support for Content-Location header to indicate a Base to be used for other URLs in the same content body.
8	Support for Content-Location header on a multipart body to apply recursively to included body parts.
9a	Support for nested multipart/related inside each other, with links from an inner such structure to an outer such structure.
9b	If your implementation receives a document with a hyperlink (inline or not inline) which it cannot support, will it then show nothing on the screen, or show something, like a broken image, to indicate that here is a graphic which you cannot render.	Not applicable
	Which of the following methods of producing HTML messages does your implementation support:	Support for sending	Support for receipt using your own software	Support for receipt using other company's software
10	a. Submitting HTML taken from the web (local or global), user gives URL.		Not applicable	Not applicable
11	b. Editing HTML with an editor provided for writing e-mail messages.		Not applicable	Not applicable
12	c. Taking HTML from files (which might have been produced with separate HTML editor).		Not applicable	Not applicable
	Non-e-mail use of MHTML		Support using your own software	Support using other company's software
13	MHTML objects (Content-Type: message/rfc822) can be retrieved through HTTP and displayed.	Not applicable
14	MHTML objects (Content-Type: multipart/related) can be retrieved through HTTP and displayed.	Not applicable
15	Aggregate HTML documents, retrieved through HTTP, can be saved in MHTML format (combining all body parts in one saved file of Content-Type: message/rfc822 or Content-Type: Multipart/related).	Not applicable
16	Aggregate HTML documents, received through e-mail, can be saved in MHTML format (combining all body parts in one saved file of Content-Type: message/rfc822 or Content-Type: Multipart/related).	Not applicable
	Support of HTML features in e-mail messages	Support for sending	Support for receipt using your own software	Support for receipt using other company's software
17	Basic HTML <P>, <H1>, <BR>, <I>, <UL>, <OL>, etc.
18	HTML Tables.
19	HTML forms with transmission of the result in the Content-Type: application/x-www-form-urlencoded
20	HTML forms with transmission of the result in the Content-Type: multipart/form-data
21	HTML forms with mailto submisson of results
22	HTML forms with http submission of results
23	Images in GIF format.
24	Images in JPEG format.
25	Other image formats than GIF and JPEG
26	Frames.
27	Java.
28	Javascript.
29	Encoding of line breaks using CRLF (after Content-Transfer-Decoding).
30	Encoding of line breaks using LF or CR (after Content-Transfer-Decoding, allowed in HTTP but not in e-mail).
	Advanced MHTML features	Support for sending	Support for receipt using your own software	Support for receipt using other company's software
31	Combination of multipart/related with multipart/alternative, with multipart/alternative outside the multipart/related.
32	Combination of multipart/related with multipart/alternative, with multipart/alternative inside the multipart/related, usually as the start body part of the mulitpart/related.
33	Hyperlinks between body parts in different messages.
34	Support for using MHTML for other primary formats than HTML, for example PDF or VRML.
35	Multipart/related where all parts are not displayed inline, for example sending a set of linked HTML pages in one message, which the recipient can move between by clicking on hyperlinks.
36	More than one multipart/related inside the same e-mail message.
36b	Does your implementation support multipart/related for other root object formats than text/html or multipart/alternative with text/html as one choice? If so, which format?
	Which of the following methods of putting in-line objects like IMG-linked graphics, etc., into HTML messages does your implementation support	Support for sending	Support for receipt using your own software	Support for receipt using other company's software
37	a. All included in the message.
38	b. Not all included in the message, non-included parts retrieved through URLs in the HTML text, which the recipient mailer can resolve through, for example, HTTP requests.
39	b. Not all included in the message, non-included parts retrieved through use of Content-Type: Message/external-body.
	Security	Support for sending	Support for receipt using your own software	Support for receipt using other company's software
40	Combination of MHTML with PGP.
41	Combination of MHTML with SMIME.
42	Documents can be taken from the web, and posted through e-mail, without breaking security cheksums.
	Documents received through e-mail can be posted for HTTP retrieval, without breaking security checksums:	Do not fill in this field	Do not fill in this field	Do not fill in this field
43	(A) If the document uses relative Content-Locations.		Not applicable	Not applicable
44	(B) If the document uses absolute Content-Locations.		Not applicable	Not applicable
45	(C) If the document uses Content-Ids and "mid:" type hyperlinks.		Not applicable	Not applicable
	Syntax issues	Support for sending	Support for receipt using your own software	Support for receipt using other company's software
46	Folding of long URLs to fit in <80 character lines according to the MHTML standard.
47	Content-Transfer-Encoding of characters not in ASCII, like "é".
48	HTML &-markup of characters not in ASCII, like "é".