Re: [EAI] Unicode / ASCII fallback mappings?

Shawn Steele <Shawn.Steele@microsoft.com> Tue, 30 June 2009 20:36 UTC

Return-Path: <Shawn.Steele@microsoft.com>
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 38B4228C46E for <ima@core3.amsl.com>; Tue, 30 Jun 2009 13:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.595
X-Spam-Level:
X-Spam-Status: No, score=-10.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 I9IJ3L070vZb for <ima@core3.amsl.com>; Tue, 30 Jun 2009 13:36:57 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 53E7528C46C for <ima@ietf.org>; Tue, 30 Jun 2009 13:36:57 -0700 (PDT)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 30 Jun 2009 13:37:02 -0700
Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([157.54.79.177]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Tue, 30 Jun 2009 13:37:02 -0700
From: Shawn Steele <Shawn.Steele@microsoft.com>
To: SM <sm@resistor.net>
Thread-Topic: [EAI] Unicode / ASCII fallback mappings?
Thread-Index: AQHJ+ILXgLffd0Seyk2qP20iynTVF5Bd27TAgAB+4gD//42i4IAAtKkhgAC2zXaAADCKMoAACkXw
Date: Tue, 30 Jun 2009 20:36:59 +0000
Message-ID: <CAD7705D4A93814F97D3EF00790AF0B315F5377C@tk5ex14mbxc105.redmond.corp.microsoft.com>
References: <CAD7705D4A93814F97D3EF00790AF0B315F4E0B2@tk5ex14mbxc105.redmond.corp.microsoft.com> <4A485EEF.9010109@it.aoyama.ac.jp> <CAD7705D4A93814F97D3EF00790AF0B315F4F15B@tk5ex14mbxc105.redmond.corp.microsoft.com> <74FF47A31A141F3D171B64DF@PST.JCK.COM> <CAD7705D4A93814F97D3EF00790AF0B315F4F5F7@tk5ex14mbxc105.redmond.corp.microsoft.com> <6.2.5.6.2.20090629220509.042672c0@resistor.net> <CAD7705D4A93814F97D3EF00790AF0B315F53487@tk5ex14mbxc105.redmond.corp.microsoft.com> <6.2.5.6.2.20090630105355.04290ec8@resistor.net>
In-Reply-To: <6.2.5.6.2.20090630105355.04290ec8@resistor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "ima@ietf.org" <ima@ietf.org>
Subject: Re: [EAI] Unicode / ASCII fallback mappings?
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, 30 Jun 2009 20:36:58 -0000

> If we are thinking in technical terms, we are going to draw up
> constraints based on existing systems.  I don't think that the model
> should even emphasize the downgrade ASCII address as it's only there
> to support legacy systems.  The premise is that the EAI address is
> the primary address and not an add-on.  It may be tempting to graft
> EAI on an existing infrastructure. But then we'll end up with hacks
> for the next 30 years. :-)

I don't think I explained myself correctly.  I'm not suggesting that EAI be hacked on to the existing system, and think it's doing well for a clean approach.  Regardless there will be a transition period.  All I'm saying is that it's not hard to migrate a current ASCII system to an EAI system.  It's also not that different than a clean EAI system.

Brand new EAI system:
* Needs a Unicode enabled email address
* Needs an alias (alt-address)
* Should use the Unicode email address in EAI contexts.

(This is a lot like how shawnste@microsoft.com and Shawn.Steele@microsoft.com both get mail to me.  One is used by my mailer, and the alt-address isn't typically advertised, but it could be.)

The new account experience in such a system:
1. Sign up for an account
        a) User is prompted for a primary account name, could be non-ASCII (or ASCII if they don't need Unicode)
        b) If non-ASCII, the user is prompted for an optional alt-address, with the caveat that if they don't pick one it might not work everywhere.
        c) The system stores both addresses.  One is primary, the other's used for alt-address in non-EAI aware contexts.

An EAI system upgraded from non-EAI:
* Already has an address that fits the requirements for alt-address
* Needs a Unicode enabled email alias.
* The new Unicode email address should be "primary" and used in EAI contexts.

This is pretty much the same as the "brand-new" EAI system.

The upgrading account experience in such a system:
1. Logon to existing account
        a) User is prompted for the Unicode EAI account name (if desired).
        b) Already has an ASCII address, so prompt not necessary for that.
        c) The system stores the new Unicode EAI account name.  This will be used as the primary account name now and in EAI contexts.  The "old name" will be used for alt-addresses.  If necessary it could even flip-flop the records to look like the "new eai" system, but I doubt it matters.

So I don't get how this contaminates the EAI standards?  The architecture is effectively identical in the brand-new EAI system and the upgraded system.  It's not a hack, but a migration path.  The nice thing is that in the upgraded system a user gets to keep their old mailbox, and doesn't have to remember to update their address with all their friends and banks.  New contacts can get the new EAI name, but there's no pain for the user.

I'd be really surprised if most mail providers weren't considering such an upgrade strategy.

-Shawn