27933 - Mail header "accepted content types"

Status: NEW

(MailNews Core :: Composition, enhancement, P3)

Description

[Ben Bucksch (:BenB)]

If sending HTML is appropriate depends on a more or less arbitary decision of
the recipient, which can't even always be guessed from his/her MUA.

It was suggested on n.p.m.mail-news (threads "Assuming "plain text" or "html
mail".." and "Are users HTML compliant by default"), that a mail header should
be implemented, which states, which content types the sender accepts (similar to
the X-Accept-Language header). This header could be read by other MUAs, so they
can base the decision, which content type to send, on that.

The following suggestions have been made:
- A header "X-Accept-Content-Type" could list the accepted content
types in order of preference, e.g. "text/html, text/plain;
format=flowed, text/plain" (delimiters have to change), if you like it
"rich", or "text/plain, text/html", if you prefer plain text, but also
accept HTML.
- A header "X-Sender-Accepts:", in the HTTP "Accept:" header
format, for mail and news.
- A header based on <http://www.ietf.org/html.charters/conneg-charter.html>

The implementation could look like the following:
- There's some pref UI, which lets the user decide, which content types he/she
likes.
- Mail compose inserts the content type preference header.
- Mail reply reads the header of incoming mails and stores them into some new
field of the address book. This could be done in the code, which feeds the
"Collected addresses" address book.
- The code, that opens mail compose (nsMsgCompose::Initialize
<http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompose.cpp#396>
?), asks this field of the address book, which content type to create, of
type=default.
- The address book UI needs some way to display the read header, but maybe also
a way to override it.

Comment 1

[Ben Bucksch (:BenB)]

> This could be done in the code, which feeds the "Collected addresses" address
> book.

See nsIAbAddressCollecter
<http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/public/nsIAbAddressCollecter.idl>

There's an issue about invalidating the collected headers: A user might
switch to a MUA, which doesn't support the header and certain, previously
preferred content types.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

To update the header, one could store the Date from the message where the 
X-Accept header was harvested, along with the X-Accept contents itself. 
Overwrite the X-Accept information whenever the new Date is more recent than the 
old one.

Comment 3

[Ben Bucksch (:BenB)]

roc, the problem is, if the new MUA doesn't support the header at all, i.e.
there won't be an updating header at all.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Well then, if the latest message has no X-Accept header, just wipe out the 
X-Accept entry as if it never existed.

Comment 5

[John G. Myers]

Consider the case where a user regularly uses two different MUAs.  One MUA 
supports HTML, the other does not.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In that case, the user will have to configure the HTML-reading, 
Accept-header-producing MUA to disable HTML, or disable sending the Accept 
header altogether.

If you think this is a really serious problem and users won't be able to handle  
it, then we simply disable sending of the Accept header by default. Savvy users 
can enable it, and then we can assume they will turn it off if there are 
problems.

Personally, I think that the number of people using both an HTML-aware, 
Accept-aware MUA and a plaintext-only MUA to access the same account who are 
also not savvy enough to disable Accept will be fairly small.

One could try something funky like, if we see a message from this user's account 
sent by another MUA, prompt the user with the option to fall back to that MUA's 
supported types. That's probably overcomplicated.

Comment 7

[John G. Myers]

Cellphone/PDA mail clients are not unlikely to be text-only.  I respectfully 
disagree with [e-mail]

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fine. Then make the default behaviour "don't send header", i.e. the status quo. 
In the UI for enabling the header, also include selection of the acceptable 
content types so the user can't miss it. Any further objections?

(Personally, I hope that my cellPDA has the ability to suck the text out of HTML 
and show it to me, otherwise it's not going to be nearly as useful.)

Comment 9

[Ben Bucksch (:BenB)]

.

Comment 10

[Ben Bucksch (:BenB)]

It's a pity that I never got to fix this bug.

Comment 11

[Ben Bucksch (:BenB)]

Changing personal priorities. Giving away most of my bugs :-( (reassigning to
default owner).

I will still track these bugs closely. If you need my input, feel free to ask me.

New owner: Please do *not* close these bugs (as WONTFIX or whatever you may
find) unless they are fixed. Rather, reassign to <[e-mail]>, if you
don't want to work on them.