Re: [idn] San Diego Meeting Notes

["James Seng/Personal" <James@Seng.cc>]

Hi Dan,

Please see my corrected email. It is "Application Area Approach" vs
"Infrastructure Approach". Sorry for the confusion.

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

No, this problem is not specific to ACE. It is a general general due to
the normalization process which destory some information (e.g. case).

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

Agreed.

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

This problem is known as 'leaking' which was also mention in the meeting
by Rick. It is an issue which any proposal have to deal with, so once
again, not unique to ACE.

> Nameprep is designed for one purpose: to enable "only ACE in
application".

No. Nameprep is desgined for the purpose of doing nameprep. It does not
matter whether it is ACE or UTF-8 or UTF-16 or UTF-32 or whatever
encoding. Nameprep will still be needed for 'matching'.

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

I think this make good sense.


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

If the WG can agree with "Application Area Approach", then we need an
IDN protocol for without changes to the "Infrastructure" (in this
aspect, we refer without changes to DNS Infrastructure/Protocol").

-James Seng