At 17:16 02/05/2002 -0400, Keith Moore wrote:
Second, you're failing to consider that there's essentially no incentive
for a significant percentage of the world's mail users or MTA operators
to upgrade. An approach that relies on MUA upgrades to provide the new
functionality lets those who benefit from the new functionality - those
who have an incentive - do the upgrade and get immediate benefit. This
gets it deployed more quickly for those users who need it.
I think this is the key issue.
People in the UK, USA (and a large percentage of Europe) won't want to
fiddle with things that ain't broke just so that some people can send them
emails that they can't understand... This means that the majority of
Internet users will be running mail systems which people using IDN
wouldn't be able to contact in the near/mid future.
actually, they'll be able to contact each other. it's just that the IDNs
will be displayed in encoded form on the systems that haven't been upgraded,
and the user with the non-upgraded MUA will have to type in the ugly encoded
form of the address (or copy-and-paste that address into his address book).
Assuming the MTAs & MUAs can handle it properly.
since IDNA is syntactically compatible with existing ascii domain names,
it's likely that they will handle it properly. after all, that's how
IDNA was designed to work.
if you substitute "ascii equivalent" for "latin equivalent", that's
essentially what IDNA does.
It would work better if the latin equivalent was 'china-timber.cn' rather
than 'A863B350DHRS-25323-52GH.A4GWT' (or whatever the Unicoded translation
into ASCII would be).
people can still set up their own human-friendly ASCII aliases if they want.
IDNA doesn't preclude this.
arrgh! sure, let's build an entire mail system from scratch and run two
incompatible mail systems just so that half of the users can have one
additional feature. makes *lots* of sense...
If the alternative is to break everything else in the world, then it COULD
make a lot of sense. (If it won't break anything else, then what's this
discussion all about then :-) )
IDNA seems to be a solution with minimum breakage and minimum deployment
effort. It works with existing MTAs, MUAs, whatever without creating a
need to run new servers and agents, and without causing the existing
servers and agents to fail. Others have proposed solutions which appear
to have considerably more breakage and more deployment cost in exchange
for a very marginal performance gain.
EG, you could have modifications to the RCPT and MAIL commands so that
messages are transferred (in the IDN 'world') as something like:
RCPT TO: <AFAS356GSS(_at_)A863B350DHRS-25323-52GH(_dot_)A4GWT>
ASCII=joe(_at_)china-timber(_dot_)cn
no, because it wouldn't solve any problems. users don't generally care
about what happens at the SMTP level, so they don't care whether the
addresses at that level are encoded in ASCII or not.
Obviously, people in IDN 'worlds' would have to have two 'names' (one
'local', one 'ASCII') for each user if they are going to be communicated to
from other countries, but that would probably make sense anyway. (If there
isn't an ASCII= extension, you could either bounce the message when it goes
out of the IDN 'world', or you could send it unchanged and hope for the
best :-) )
If it worked this way, then the only people who would need to worry about
IDN would be people who wanted to use it - everyone else would keep things
EXACTLY as they are now.
the IDNA solution already has this property, and requires fewer changes
than what you are proposing.
Keith