Re: [idn] New protocol proposal: IDNRA

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

At 14.22 +0800 00-08-27, James Seng wrote:
>a) Section 2.1.1
>
>    If you accept any charset here, and lets presume RACE is charset,
>    then I don't see why the neccessity to put additional restriction
>    on RACE.

Because we wanted to talk about the case when people which happen to 
know the RACE encoding of a hostname want to be able to send that as 
input to an "old" application. And, in that way be able to access the 
services without being able to use the "real" internationalized 
domainname.

>    I suggest rewording the second paragraph to
>
>    "Application MAY allow RACE input and output. Any charset, including
>    RACE, choosen MUST be supported by a proper rendering engine to
>    display the glyphs correctly."
>
>    This means the application can decide to support RACE I/O so long
>    it can render RACE into glyph (and that is possible).

My take (and that is why Paul wrote the text that way I guess :-) is 
that one might want to know what the race encoding of a domainname 
is, just so one can give it out to people which do not have support 
for input of richer character sets than ascii.

I wrote this draft together with Paul just because I feel that the 
transition period for _applications_ will be extremely long (~10 
years or more) so we definitly have to talk about the use of RACE 
encoded names being used as domainnames on buissness cards etc etc. I 
presume I (with swedish characters in my name, and therefore probably 
in future IDN domainnames) will have to have a double-sided buissness 
card for a looooong time, with proper characters on one side, and 
race encoded on the other.

I feel that the text you suggest is not clear on whether the RACE 
should be rendered into ascii characters (and display the raw race 
encoding) or if the race should be decoded and then the glyphs should 
be displayed? My take is that both can be allowed, and probably that 
(that is what we tried to write) that it might even be good if an 
application allowed both display methods.

>b) Section 2.1.2:
>    Is there any particular reason that UTF-8 is used at this level
>rather
>    than the more commonly wchar_t for API?
>
>    As IDN implementor, i used wchar_t internally as I need not waste
>    CPU cycle converting UTF-8 char to wchar_t while doing my nameprep.

This can be discussed further, and the best API should be chosen. The 
important issue for _this_ draft is that the API used is a different 
than what is currently used.

>c) In between 2.1.2 & 2.1.3, there should be an intermediate caching
>    servers. It would be better if there is a section describing how
>    caching servers should behave.

I don't feel that is needed as in the picture you see in 2.1, there 
is no difference between the different kind of DNS servers. I.e. as 
soon as you leave the resolver and use the DNS protocol, you use ONLY 
RACE encoded domainnames.

>d) In Section 3, you mention "New/Old Application/Resolver". By reading
>    the draft, I guess you presumed that
>
>    1. New Applications are applications which can I/O I18N characters
>       and call the new resolver API. It SHOULD NOT convert to RACE
>       (altho it MAY).

Correct.

>    2. New Resolvers are resolvers which can take Unicode characters,
>       nameprep it, convert it to RACE before capturing it into DNS
>       packet and shoot it out.

Yes, i.e. new resolvers have the new resolver API.

>    I suggest you have a stronger defination on the behavior of this
>    or at least capture it down in the I-D.

Ok.

>    A real problem which occurs out of this is Microsoft product.
>
>    Win2K has a "new resolver" feature except it spit out UTF-8.
>    IE5.0 is also a "new application" which also spit out UTF-8.
>    Combine this two together, you get UTF-8^2. *doh*

That is one of the reasons why we wanted to make clear that the API 
to the new resolvers either is the "new" one which will do nameprep, 
race encoding etc (and as you mention below discover if something 
already is in RACE) and the "old" which is ASCII only.

>    This may be less concern if we are using RACE. This is because
>    RACE^2 = RACE. (Yes, go try it :-)

Correct.

   paf