Re: Just send UTF-8 with nameprep (was: RE: [idn] Reality Check)

[Keith Moore <moore@cs.utk.edu>]

> As I have remarked earlier, we don't need this WG to allow
> people to create random domain name labels. ACE is not
> 'domain names just as they are'. It's a clear layer violation.

That's simply BS.  ACE is an *encoding" just like UTF-8 is an *encoding*.

> You can't do any serious kind of processing (e.g. sorting,
> searching,...) on ACEd domain names.

You can do comparison of names with ACE.  Sorted ACE names are almost
as useful to humans as sorted names in UTF-8, which is to say - not very.
It's true that you cannot search for substrings of an ACE name as
easily as you can do so in UTF-8, but this hardly compels use of UTF-8
where it will break existing applications.

> >Your proposal it to break all current applications by requiring the
> >application to both do UTF-8 (which many don't do)
> 
> There are mainly three cases:
> - Those that just pass data along. Most implementations nowadays are
>    8-bit transparent, for most others, it's easy to clean them.
> - Those that do some actual character processing, but not display.
>    These will require work, but considerably less with UTF-8 than
>    with ACE.
> - Those that do display. Again, less work with UTF-8
>    than with ACE. And more work already done.

For the latter two, the burden in supporting ACE in addition to supporting
UTF-8 is small.  The application has to call API routines in either case -
the differences between ACE and UTF-8 are mostly hidden under those routines.

The other thing that you're leaving out is the additional complexity that
would be required to add UTF-8 negotiation to existing applications that
could not be expected to deal with UTF-8 names.

> >and to do nameprep (which those that currently do UTF-8 don't do).
> 
> Again, nameprep only is easier than nameprep+ACE.

It requires more code, but the application writer doesn't really notice
the difference.

Keith