Re: [idn] IDNs and email

[ned.freed@innosoft.com]

> Looking at the charter I can't see any reason why an IDN protocol candidate
> shouldn't be allowed to suggest changes to SMTP (or other protocols) as well
> as to the DNS protocol.  Of course those changes should be as minimal as
> possible.

I'm tempted to go even further -- I'd like to say that for any proposal that
extends the set of legal characters in the domain names used in protocols has
to outline the mechanism by which it is expected that this change will be
implemented in various protocols. It isn't necessary to deal specifically with
SMTP, but the general approach to be taken has to be made clear, and at a
minimum that amounts to suggesting changes.

Those of us who are interested specifically in some specific protocol can then
develop ancillary documents that specify whatever protocol extensions are
needed. If changes to the character repetiore are undertaken I expect there
will be a bunch of these documents, some standards track ones dealing with
protocol specifics, some informational ones dealing with user interfaces, and
so on.

> Some of the IDN candidates (UTF-5 and CIDNUC) allow international characters
> to the right of the @ sign while keeping the email infrastructure working.
> I suspect, however, that users would want to be allowed to use international
> characters anywhere in an email address, not just to the right of the @
> sign.

Sure, and it is fairly clear that this can also be undertaken at the
same time. However, these issues are outside the scope of the IDN effort.

> For the UTF-8 proposal, or for fully internationalised email addresses with
> the other proposals the email system will need to be modified.  To avoid a
> flag day there are two requirements on the SNMP modifications:

I think you meant SMTP.

> 1) There should be an ASCII-only equivalent email address for each
> internationalised email address.  There must be a way for a program to
> transform the internationalised address into the ASCII-only form (eg
> algorithmically or by doing a lookup somewhere).

Yup.

> Doing the transform algorithmically would be easier, but might not be quite
> so good for the user.  Doing it with a lookup (eg for a new type of DNS
> record) would be more complicated and generate fractionally more traffic
> (compared with the amount needed to send email anyway) but would probably be
> more user-friendly.

Agreed.

> 2) There must be an ESMTP option which indicates that a server supports
> internationalised email addresses.  If an internationalised ESMTP client has
> an internationalised email, but the server doesn't indicate support then the
> client must transform all addresses (in the envelope and in the message
> headers) into their ASCII-only equivalent.

Yep. Note that the option may enable more than this (like UTF-8 in 
other parts of message headers).

> In addition it would be nice if an internationalised recipient could
> transform the ASCII-only form back into the internationalised form (for
> example if the email has been through an ASCII-only relay).

I agree that this is something that SHOULD be done. I don't see making it
a MUST though.

> I think this suggests a further requirement for IDN (based on 1 above):

> | If an encoding is used which is not mapped into ASCII then there SHOULD
> | be an ASCII-only representation of each IDN, and there MUST be a way for
> | a program to find the ASCII-only representation (or lack of it) for an
> | IDN.

Nicely put. I agree completely.

> I say SHOULD and not must since if a lookup service is used then an
> administrator
> might choose not to configure an ASCII-only equivalent for a particular
> name.

In which case there are various options depending on where the address
appears. This gets rather messy, but it can be dealt with.

I think we are in substantial agreement here. I certainly support adding
the requirement you described above to the IDN requirements list.

				Ned