Re: [EAI] Thinking about requirements / downgrade

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

Harald Alvestrand wrote:

The overarching issue found with variants of this proposal previously rejected was:

Can we guarantee (for a sufficiently strong version of "guarantee") that there are no valid mailboxes that "just happen to look like" the Punycoded strings?

I'm not sure it is necessary for a standard to guarantee this. I think it is just the responsibility of email administration to avoid name collisions. Currently, when a new email address is requested, the email administrator for the domain on which the name is requested (or email admin software) will not grant the email address if
1. the address (local name) is assigned to someone else on the domain.
2. the address is already in use as an alias on another email account on the domain.

Suppose EAI used automatic punycode email addresses, where punycode conversion is applied separately to each side of the @. Then email administrators on EAI systems just have the following additional verification to do on new email account requests:
3. generate the punycode of the new address (local name) and apply tests 1 and 2 above to make sure the punycode name is not in use on the domain.

Since only owners of a domain can create email addresses, name collisions cannot occur unless administrators fail to check for uniqueness before granting new email addresses. That requirement is no different from today.

Another concern about using ACE conversions in EAI was the issue of punycode addresses "leaking" into the user environment. Just to remind people how ugly this can be, here is a conversion of one of the EAI addresses used in one of the downgrade tests.
<xn--qxa.xn--mxafqqky at xn----vlbebiih2aiue6addbz1awu3bzg.info>

If not, we have to stick with the "don't mess with the left-hand side" principle and not let the specs define any upgrading, ever. (But then, if all home systems for the email recognized the Punycoded form, there isn't much reason to upgrade. But (3rd level) then that's a burden they'll have to carry around roughly forever..... more levels?)

I think receiving a lot of email with long unrecognizable ACE conversions might be incentive for people to upgrade to EAI.

IDNA made the leap of faith that no existing application would be inconvenienced if we assumed that no domain name label starting "xn--" existed with any other use than IDNA.

Email administrators can avoid local name collisions as outlined above. This assumption is also important to EAI to avoid collusions on the domain name.

What assumption can we make?

                         Harald (who was around when X.400 LHS encoding met Sendmail).