Re: [idn] New protocol proposal: IDNRA

[James Seng <James@Seng.cc>]

Patrik Fältström wrote:
> 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.

You are right. So perhaps we could add a statement:

"As RACE could either be rendered in ASCII or I18N glyphs, rendering
engine for RACE SHOULD have an option for user to select the preferred
display."

For those who are used to rendering engines, this is actually a feature
for most common third-party rendering engine, to display the text as
glyphs or just raw 8bits. 

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

My take that if the API is in UTF-8 as compared to UCS-4, then

Application takes native, convert to Unicode, convert it to UTF-8 to
pass onto Resolver. Resolver then take UTF-8, convert it to Unicode, do
all its funky nameprep, and convert it to RACE.

The additional processing overhead of converting to and from UTF-8 could
be removed if we were to use UCS-4 directly. And that seem to be the
common API interface.

But I may divert too much into the implementation here...

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

Erm. That's true...but would be nice to complete the whole picture so
there is a clear statement that caching server is involved in the
process but it doesnt really matter...

-James Seng