Re: [idn] IDNs and email

[Maynard Kang <maynard@pobox.org.sg>]

ned.freed@innosoft.com wrote:
> > 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.

I think that although definining what turns up to the left of the @ sign
(UserID) may not be within the auspices of this working group, it would
certainly be useful to formulate and possibly recommend a definable
transformed format for the UserID portion of an e-mail addresss.

This is especially so if we do the transformation algorithmically. Given
that the UserID portion of an e-mail address would also have to be
transformed to ASCII to suit RFC 821 and 822/MFS, it would be helpful to
use the same transformation algorithm for both the UserID and FQDN
portion so as to not to complicate the conversion process (Imagine what
it would it be like if an e-mail address were encoded in say,
ASCII-represented hexadecimal for the UserID and say, CIDNUC for the
FQDN)

However I do agree that it may be beyond the scope of this working
group. Perhaps a separate working group on Internationalization of
E-mail can be formed to address this issue.

> 
> > 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).
> 

Agreed, that is a good idea. But an ESMTP option only takes care that
the MTAs are able to handle internationalised characters. It may break
POP3 and e-mail clients - we may want to consider that too.

> > 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 agree too, that it should be a SHOULD (heh, I love recursive logic).
:-)

However, at which stage will this transformation back into
internationalised form occur? Should it be done at the "delivery" stage
or the "retrieval" stage? I am personally for the "delivery" stage
though this may break certain clients who are unable to handle
internationalised characters.

> > 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.

I, too, am in support.

Maynard