Re: [idn] San Diego Meeting Notes

[Dan Oscarsson <Dan.Oscarsson@trab.se>]

>b) Strawpoll agrees with Protocol Design Team recommendation to focus
>   on "ACE on Application" now but do not rejecting a longer term
>   solution in future.
>

>From the discussions on this list I do not think we have agreed this
is the right way.

One major problem with "ACE in application" is that it requires a name
to be mangled into the form needed to compare two names, in the application
and it requires names to be store in DNS in the same way.
With mangling I mean things like forcing upper case to lower case.
Though you could fix this by allowing the DNS to return in responses
normlaised but unmangled names. This would allow names to be displayed
using the preferred form.

Another is: what names are "host names". Not all names in DNS are
host names! Other names do not have the same forbinnden characters.

And ACE in itself will give bad possibilities on the client side.
An ACE understanding application will display the name in a user
friendly way using the local character set instead of the ACE form.
The user uses copy/past to get the name into another application
that does not understand ACE. The result: a non-ACE name in local
encoding will be used. So ACE will get many of the problems an UTF-8
solution will give. ACE will also result in lots of non-ASCII characters
going into applications and protocols.


>c) Strawpoll agrees that the Nameprep Design Team is working in the
>   right direction. (See Nameprep-02)
>

Nameprep is designed for one purpose: to enable "only ACE in application".
There is a lot of good work in nameprep, but the nameprep work should be
split into parts:

1) Forbidden characters in "host names".
2) Normalisation of UCS text that can be used for all text (like
   Unicode normalisation form C or KC).
3) DNS name matching rules.

Then it would be a good base for non-ASCII handling in DNS.


I also have a question about what character should be treated the same in
name matching. In nameprep it says that the names are changed so that
letters that look the same are changed to a single representation.
Looking at the nameprep document it does not look like this is so.
In UCS we have "Latin A", "Greek A" and "Russian A", and "Latin a",
"Greek alpha" and "Russian a". As all A look the same all should be
merged into "Latin A" and the corresponding for lower case a.
Why is this not done?

>If you have any objection (I know a few of you do), please raise them
>now.
>
>If there is no major objection, then the next step would include
>

>2. Protocol Design Team (or someone) should start working on writing
>   an I-D for the IDN Protocol. As it stands now, IDNA seem the closest
>   we have.
>

What is the IDN protocol?

All my drafts are for the DNS protocol.

   Dan