[EAI] Downgrade simplifications

[Ernie Dainow <edainow at ca.afilias.info>]

I think there are a number of things we can change to make Downgrade 
simpler and have less impact on existing email systems yet still provide 
the key backward compatibility that many people feel is important to the 
success of EAI.

The current design of Downgrade is very comprehensive. A lot of clever 
things were done to provide Downgrade in every possible situation and to 
provide a complete audit trail through the use of new Downgraded headers 
that also provide the ability to reconstruct the original UTF8 address 
information (Downgraded display). We can greatly simplify Downgrade by 
limiting the design goals to support only essential cases and make clear 
that Downgrade is an interim feature, is not perfect and does not 
provide a complete audit trail.

1. As recommended in 4.2 of  draft-ietf-eai-email-clients and in various 
emails on the EAI list, we should consider downgrade of forward-pointing 
(recipient) addresses as a configuration error and not something that 
Downgrade needs to support. Then we can remove Alternate Addresses for 
recipients. I think this would also allow us to redesign Downgrade 
without the double angle bracket syntax which seems to be the source of 
a lot of compatibility and security concerns.

2. Implementation of Downgrade is currently an option for MUA, POP/IMAP. 
Consideration of these cases in draft-ietf-eai-email-clients (3.1.1, 
3.2) is that these are unusual configurations. The standard should be 
explicit and state that Downgrade is only done by MTAs.

3. While an audit trail and ability to display original UTF8 addresses 
from a Downgraded message is a nice feature, some people consider the 
case in which this is useful to be a configuration error (an EAI MUA, 
POP or IMAP behind a non-EAI MTA.). In any case, it is not an essential 
feature within the revised design goals outlined above. If it is 
dropped, then all the added "Downgraded-" headers can be dropped.

4. Alternate Addresses for the sender can be handled in the "Accounts" 
setting of the MUA. They can also be provided by the SMTP server, as in 
draft-yao-eai-deployment. Since there is no interface for the MUA to 
find out from the server if it needs to provide Alternate Addresses or 
not, this ambiguity may lead to unexpected behavior in terms of which 
Alternate Address gets used if it is provided by both. While the server 
solution offers a certain amount of transparency to the end user, the 
MUA solution is more general in that it supports a legacy ASCII Address 
that may be on a different email provider. The standard should resolve 
this ambiguity and specify that Alternate Address for the sender is 
provided by the MUA and not the server.

5. Capturing UTF8 addresses in empty groups when Downgrading should be 
dropped. This has numerous interoperability problems with existing mail 
clients (3.2.1 in draft-ietf-eai-email-clients).

To make a clean line between Downgrade and the rest of the EAI standard, 
so that we can move ahead with standards track of the latter while 
continuing to work on experimental track Downgrade, all normative 
requirements relating to Downgrade should be pulled out of the EAI 
documents and moved into the Downgrade document. So for example, the 
ALT-ADDRESS parameter should be moved from RFC 5336 to the Downgrade 
document and the addr-spec for double angle brackets moved out of RFC 
5335 into the Downgrade doc (or dropped if 1. above can be achieved).

  -Ernie Dainow