RE: [idn] Reality Check

[Patrik Fältström <paf@cisco.com>]

--On 01-07-16 11.03 -0700 Russ Rolfe <rrolfe@windows.microsoft.com> wrote:

> I see no wrong asking users to take some of the responsibility of moving
> to a new technology (i.e. having two addresses, adding a line as part of
> the signature pointing to non-IDN address, requesting System-Operators
> to upgrade)?  I know that this will be uncomfortable for users in the
> beginning, but because of this, there will be more pressure to upgrade
> to the new IDN standard and thus the final solution (UTF8) will be
> reached sooner.

Being a bit pessimistic on the ability for end users to make software
developers and system managers (yes, I was one of them for some 10 years)
to upgrade, I say we should look at the bad handling of MIME which make
client and server software still not handling mime correctly.

But, due to the ascii encoding MIME has (for example in the headers) makes
it possible for people to communicate just because the encodings are 100%
backward compatible with the standard.

I did interoperability tests for MIME during the 90's, and even though we
had minimal requirements, it took software manufacturers _years_ to handle
the things correctly.

It's also the case that I only see "I support UTF-8" when a real solution
with UTF-8 would be something like IDNA, with UTF-8 as the output and not
ACE encoded strings, let's call it INDU. :-)

Because of the fact that some software already do UTF-8 (without nameprep),
and people on this list which should know better say "UTF-8 and not ACE"
when they should point at the actual algorithm used, I am extremely worried
that what I see on this list is IDNA (which include nameprep) or "just send
UTF-8 without nameprep". In reality that is.

Is that what people want?

Is that not what people will get?

If not, explain how the software which today send UTF-8 on the wire will
stop doing that the day we release the IDNU proposal? Who will suffer and
discover what software do nameprep and not?

  paf