Re: [idn] New protocol proposal: IDNRA

[James Seng <James@Seng.cc>]

Paul,

A few comments:

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.

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

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.

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

   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.

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

   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*

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

-James Seng

Paul Hoffman / IMC wrote:
> 
> Greetings again. Patrik Fältström and I have submitted a new proposal
> for the main IDN protocol. It was announced on this list earlier this
> week, but seems to have been lost among the other threads. You can
> read the draft at
> <http://www.ietf.org/internet-drafts/draft-ietf-idn-idnra-00.txt>.
> 
> Basically, this protocol allows IDN to happen fully without updating
> *any* DNS servers anywhere. Given that all the proposals so far would
> require that applications and resolvers would have to be updated
> anyway, we thought that a proposal that didn't require the updating
> of the DNS servers on the Internet would be a big win for deployment.
> The draft also carefully explains what happens when some parts of the
> Internet are updated and others aren't.
> 
> The protocol has resolvers talking to DNS servers using RACE. The
> protocol solves the leakage problem that was heavily discussed on
> this mailing list a while back by specifying exactly what can and
> cannot be sent between old and new applications and resolvers.
> 
> Comments on the specifics in the draft are greatly appreciated.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium