[EAI] Downgrade simplifications
Ernie Dainow <edainow@ca.afilias.info> Tue, 04 August 2009 15:26 UTC
Return-Path: <edainow@ca.afilias.info>
X-Original-To: ima@core3.amsl.com
Delivered-To: ima@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C747E3A68DC for <ima@core3.amsl.com>; Tue, 4 Aug 2009 08:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIhzZz7Wj2SG for <ima@core3.amsl.com>; Tue, 4 Aug 2009 08:26:10 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id CD0C328C3E9 for <ima@ietf.org>; Tue, 4 Aug 2009 08:26:10 -0700 (PDT)
Message-ID: <4A7852F2.6010506@ca.afilias.info>
Date: Tue, 04 Aug 2009 11:25:38 -0400
From: Ernie Dainow <edainow@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.6 (Windows/20080710)
MIME-Version: 1.0
To: ima@ietf.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Authenticated: True
Subject: [EAI] Downgrade simplifications
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2009 15:26:11 -0000
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
- Re: [EAI] Downgrade simplifications YAO Jiankang
- [EAI] Downgrade simplifications Ernie Dainow
- Re: [EAI] Downgrade simplifications Harald Alvestrand
- Re: [EAI] Downgrade simplifications John C Klensin
- Re: [EAI] Downgrade simplifications YAO Jiankang
- Re: [EAI] Downgrade simplifications SM
- Re: [EAI] Downgrade simplifications John C Klensin
- Re: [EAI] Downgrade simplifications Joseph Yee
- Re: [EAI] Downgrade simplifications John C Klensin
- Re: [EAI] Downgrade simplifications Ernie Dainow
- Re: [EAI] Downgrade simplifications Harald Tveit Alvestrand
- Re: [EAI] Downgrade simplifications John C Klensin
- [EAI] [recharter to standard track with ] Re: Dow… YAO Jiankang
- Re: [EAI] [recharter to standard track with ] Re:… Joseph Yee
- Re: [EAI] [recharter to standard track with ] Re:… Joseph Yee
- Re: [EAI] [recharter to standard track with ] Re:… John C Klensin
- Re: [EAI] [recharter to standard track with ] Re:… SM
- Re: [EAI] [recharter to standard track with ] Re:… John C Klensin
- Re: [EAI] [recharter to standard track with ] Re:… SM
- Re: [EAI] [recharter to standard track with ] Re:… John C Klensin
- Re: [EAI] [recharter to standard track with ] Re:… SM
- Re: [EAI] [recharter to standard track with ] Re:… John C Klensin
- Re: [EAI] [recharter to standard track with ] Re:… Bill McQuillan
- Re: [EAI] [recharter to standard track with ] Re:… John C Klensin