" 
"
This is a draft in order to get comments on the form. Do not fill in this form yet. At this stage I want comments on the form. The text has been modified based on what was said during the MHTML F2F meeting in Los Angeles, March 31, 1998 /Jacob Palme
MHTML Implementation status report form version 5, 12 April 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
1.	To check that different implementations can co-work by supporting the same facilities. 
2.	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://www.dsv.su.se/~jpalme/ietf/mhtml-impl-status-v5.html
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