Re: [idn] IDNRA comments

[James Seng <James@Seng.cc>]

The problem can be sub-divided if you think RACE as yet another charset. Then
consider nameprep'ed RACE as RACE'.

- On User<->App interface, RACE _MAY_ be use for I/O (provided an 
  appropriate IME/Renderer is available). And App may also use RACE
   internally. 
- On App<->Resolver, UTF-8 (I prefer UCS-4) to be use.
- On Resolver->DNS, RACE' (ie nameprep'ed RACE) is used.

Given this behavior, then

Old App, Old Resolver, you need to I/O RACE'.
Old App, New Resolver, I/O RACE'
New App, Old Resolver, I/O any charset, New App need to send RACE'
New App, New Resolver, I/O any charset, Resolver send RACE'

Hence, New App MAY send RACE' if it works with Old Resolver. It is recommended
that New App send UCS4 when working with New Resolver.

Am I making any sense? (I hope so...I am falling asleep...)

-James Seng

Patrik Fältström wrote:
> 
> At 13.57 +0200 00-08-31, Harald Tveit Alvestrand wrote:
> >An advantage of this description method is to explain exactly what
> >that UTF-8 label is doing in the middle: Saying that the system has
> >to behave AS IF UTF-8 was used at this interface.
> >
> >OK?
> 
> Keith found the same problem when he pointed out one of the
> advantages with the IDNRA proposals (from my point of view) and that
> is that the ACE encoded domainname is not only sent from the resolver
> in the DNS packages, but also used by the applications in the
> protocols. That means that an application have to be able to do
> nameprepping.
> 
> I am thinking about how to describe this.
> 
>    paf