Results from questionnaire on the future of e-mail
Report on future features expected soon in e-mail based on a questionnaire to a few IETF e-mail experts
By Jacob Palme <http://www.dsv.su.se/~jpalme>, e-mail: <mailto:jpalme@dsv.su.se>.
Table of contents
Links	
Summary	
Who answered the questionnaire?	
How did people fill in the questionnaire?	
Table of full questionnaire results	

Links
This document is available at the following URLs:
In RTF format: http://www.dsv.su.se/~jpalme/ietf/e-mail-q-results.rtf
In HTML format: http://www.dsv.su.se/~jpalme/ietf/e-mail-q-results.html
The original questionnarie at URL: http://www.dsv.su.se/~jpalme/ietf/e-mail-q-questionnaire.rtf
Books about e-mail at URL: http://www.dsv.su.se/~jpalme/e-mail-books-survey.html
More about e-mail standards at URLs: http://www.dsv.su.se/~jpalme/e-mail-book/additions.html
More about IETF work on e-mail standards at URLs: http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html and http://domen.uninett.no/apps
Summary
A questionnaire was answered anonymously by 9 e-mail experts at two IETF meetings. The questionnaire asked which features they expected will be implemented in the next 1-4 years in e-mail software.
One can conclude that the following features will soon (in one year or less) be implemented in those e-mail systems which do not already support them: Commands to scan threads (find from a given message which message it is a reply to, and which messages are replies to it), the ISO 10646 or Unicode character sets, messages in html and text/enriched formats (allowing richer formatting and graphics in messages), forwarding of incoming messages as separate body parts, showing separate body parts inline and not only as attachments, sending collections of e-mail messages as digests, security features (encryption, digital signatures, digital seals) using PGP (but not PEM or MOSS, unfortunately I forgot to include SMINE in the questionnaire), better support for folders, receipt notifications (senders are told if their messages have been read) and combined clients for e-mail and netnews.
The following features will probably be supported in 2-4 years from now: Supersedes links between messages, alternate versions of the same text in different formats, better search facilities and delivery notifications (senders are told if their messages have been delivered).
Some existing mailers split paragraphs into lines before sending them, others send each paragraph as one long line. This difference between mailers will continue, but future mailers will better be able to cope with incoming messages in either of these two formats. (My guess is that sending paragraphs as one long line will ultimately win, since the main reason against it is that some mailers cannot handle incoming such messages very good today. It has the obvious advantage that the ugly effect of lines being split more than once will disappear.)
It is interesting to note that even though delivery notifications have had an IETF standard since the beginning of 1996, while the receipt notification standard will be ready in the end of 1997, implementors say they will implement support for receipt notifications earlier than for delivery notifications. The reason for this is that many existing mailers already support receipt notifications in non-standard ways (only between mailers of the same type). Some did maybe answer the questionnaire by describing non-standard and not standard receipt notifications.
Who answered the questionnaire?
On the IETF meetings in April and August 1997 I distributed a questionnaire on which e-mail features exists today or were expected in the future. The questionnaire was distributed during meetings with the DRUMS IETF Working Group, a group working on the e-mail standards. The questionnaire was filled in by 9 e-mail experts. Four of these said that they were currently developers of e-mail or netnews software, three were not, two did not say.
How did people fill in the questionnaire?
When the result table below shows less than 9 answers, this is probably because some people answering the questionnaire were not sure and therefore did not fill in a prediction for this feature. It can also be because some respondents only answered what was in their committed plans for new products, while most respondents guessed at features later in the future, for which final decisions have not been taken yet.
The following instructions were given in the questionnaire on how to fill it in
Please fill in this form and give it to me or put it on a chair by the door after the end of DRUMS or MHTML working group meetings. The results will be computed and reported in a document available on the web. I will send a short note with the URL of the report to the mailing lists mailext@list.cren.net, drums@cs.utk.edu and ietf@cnri.reston.va.us. No individual replies will be reported, only statistics. I will not divulge to anyone what each person answered on this questionnaire. Your reply will not be interpreted as any promise to develop this function, just a guess what you believe will happen. The questionnaire is mainly oriented towards user functions, not towards functions only visible to technical experts. If you filled in this form and gave it to me at the April meeting, you need not do it again now during the August meeting.
Notes on how to fill in the questionnaire:
•		If a feature is available, but only by a user text-editing the message headers, this should not be regarded as “available”.
•		If a feature is available through use of a helper application, this should be regarded as “available”.
•		If a feature is available, but the body must be edited using another application, this is regarded as “available”.
•		The questionnaire is anonymous, you do not have to give your name, I will not try to find out who wrote which questionnaire. If you want to, you can of course give your name.
Table of full questionnaire results

If you do not like or want a feature, mark it as > 5 years or never	Is/will be available within	> 5		
Technical basis	User feature	Today	1 year	3 years	5 years	or never		
From: + Sender:	Facility to send what someone else has written	6		1		1	1	
Millennium problem	Four-digit years	7					2	
Bcc:	Each Bcc recipient is shown only to that recipient himself	4				3	3	
(two implementation choices)	The list of Bcc recipients is shown only to all the Bcc recipients	1				6	4	
Message-ID:	Generate globally unique Message-ID for all messages	8					5	
	Add Message-ID for relayed messages which lack it (controversial)	3				3	6	
	Use Message-ID to find, at receipt, duplicates of the same message	2	1	1		3	7	
In-Reply-To:, References:	Commands to scan thread up and down, i.e. find replied-to and replying messages easily	3	3	3			8	
Supersedes:	Generate Superseding messages		2	1	2	1	9	
	Help user who receives Superseding messages in a suitable way		2	1	2	1	10	
Keywords:	Search facility to find messages with a certain keyword	6	1			1	11	
charset=iso-8859-1	Facility to send in this format	7			1		12	
(Western Europe)	Facility to receive and display it	7			1		13	
charset=iso-8859-2	Facility to send in this format	6	1		1		14	
(Eastern Europe)	Facility to receive and display it	6	1		1		15	
ISO 10646=Unicode	Facility to send in this format	2	3	2	1		16	
character set	Facility to receive and display it	2	3	2	1		17	
Other character sets like Cyrillic,	Facility to send in this format	5	2		1	1	16	
Hebrew, Arabic, Japanese	Facility to receive and display it	5	2		1	1	17	
MIME header encoding	Facility to handle other than US-ASCII in message headers	7	2				18	
text/enriched	Facility to send in this format	4	2			2	19	
	Facility to receive and display it	6	1			1	20	
message/rfc822	Facility to forward in a body part in this format	4	3				21	
	Facility to receive and display it	5	2				22	
message/partial	Facility to send large messages in this format	2	2	1		1	23	
	Facility to receive and combine parts	2	2	1		1	24	
message/external	Facility to send in this format	2	5				25	
	Facility to receive and display it so that the recipient can easily read the full message	2	5	1			26	
Content-Disposition	Can set “inline” or “attachment” on body parts in sent message	4	4				27	
multipart combined with 	Facility to send in this format	4	3				28	
content-disposition: inline	Facility to display parts “inline” for text bodies	4	4				29	
	Facility to display parts “inline” for image (picture) bodies	3	5	1			30	
multipart combined with 	Facility to send in this format	6	1				31	
content-disposition: attachment	Attachment only shown at request	6	1				32	
multipart/digest	Facility to send in this format	1	4	1			33	
	Facility to read all in sequence	1	4				34	
	Read each part as a separate message	3	3	1			35	
multipart/alternative	Use when sending messages in formats all recipients cannot display, such as text/enriched or text/html	3	3	1			36	
	Receive and show only best alternative	3	2	2			37	
application/msword, /rtf, etc.	Facility to send in this format	4				3	38	
	Facility to receive and display it (may be by forwarding it to a suitable helper, user can configure the list of helpers)	5				2	39	
Multipart/related & Text/html	Facility to send in this format	1	5			1	40	
	Facility to receive and display it, also when the HTML-message contains inline links to other body parts	2	5			1	41	
Authentication of sender	Using PGP	4	3			1	42	
	Using PEM or MOSS		1	1	1	4	43	
Encryption of message text	Using PGP	3	3			1	44	
	Using PEM or MOSS		1	1	1	4	45	
Electronic seal (protection against	Using PGP	4	3			1	46	
modification in transit)	Using PEM or MOSS		1	1	1	4	47	
Forwarding	Using Resent-headers	3			1	4	48	
	Using MIME encapsulation	5	1	1		1	49	
Filtering and folders	Messages from a particular mailing list can be filtered into a particular folder	8	1				50	
	“Kill file”, command to say “I do not want to read any more messages on this topic within this folder (mailing list)”.	5	2		1	1	51	
	Command to scan through all new messages, even though they have been  filtered into separate folders	3	4	1		1	52	
	Ability to designate the personally preferred order in which folders with new messages are scanned	1	4	1		1	53	
	Spam  control		5	2		1	54	
Search	Facility to search through some or all folders to find messages	7					55	
	- on words in the subject	7	2				56	
	- on words in the body	6	3				57	
	- on date	5	2	1			58	
	- on from/sender/to/cc/bcc headers	6	2	1			59	
	- on seen/unseen status	5	2	1			60	
	Combinations of the above, such as “all messages from A between Date-X and Date Y with the subject Z”	4	1	1	1		61	
	- search result shown, saved or printed all matches in one file	3	4	1	1		62	
	- search result shown one at a time	6	1		1	1	63	
Encoding	Sending in Base64 or Quoted-printable	9	9				64	
	Receipt of Base64 and Quoted-printable	9	9				65	
Word-wrapping	Outgoing text is wordwrapped with max. 80 characters/line	5				2	66	
	Outgoing text is sent with each paragraph as one long line (using MIME encoding of long lines)	4				2	67	
	Word-wrapping of incoming text if more characters in a line than fits in the window	7				1	68	
	Reply with “> ” quote marks, which works also when incoming message had the quoted paragraph as one long line		7		1	1	69	
Delivery Status Notification	Ability to request it	2	2	1		3	70	
	Ability to receive them and show them in user-friendly way	2	2	2		2	71	
	Ability to ask for a report on all notifications received for a particular sent message		2	3		3	72	
Receipt Notification	Ability to request it	5	1	1		2	73	
	Ability to receive them and show them in user-friendly way	4	2	1		2	74	
	Ability to ask for a report on all notifications received for a particular sent message	1	3	2		3	75	
POP, IMAP, NNTP	Can download messages for local browsing in the user workstation	8	1				76	
NNTP & e-mail	Same client can be used both for sending and reading e-mail and sending and receiving newsgroups	4	2			1	77	
	Same user interface for newsgroups as for mailing lists	3	2	1		2	78	
	When a newsgroup article is forwarded as e-mail, change “Newsgroups” header to “Posted-To”.		1	2		4	79	

Any comments on the questionnaire or features I should have included but did not include?
Several respondents commented that SMIME should have been included in the questionnaire.