[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[idn] IDNRA comments



Some comments on the IDNRA document:

- I like the proposal. It is complete.
   I am not happy to end up with a situation where we will probably have ACE
   on the wire forever, but I can live with that.

- The presentation of the solution in chapter 2 needs work.

I suggest to make another picture.

The interfaces in IDNRA can be represented pictorially as:

                 +------+
                 | User |
                 +------+
                     ^
                     |   Input and display: local interface methods
                     |   (pen, keyboard, glowing phosporus, ink on paper...)
    +--------------- v -------------------------------+
    |         +-------------+                         |
    |         | Application |                         | End system
    |         +-------------+
    |                ^
    |                |   API call and return: UTF-8
    |                v
    |          +----------+
    |          | Resolver |
    |          +----------+                           |
    +----------------^--------------------------------+
                     |   DNS query and response: RACE
                     v
              +-------------+
              | DNS servers |
              +-------------+

The accompanying text should say that:

"This document standardizes ONLY the format of the DNS query and response.
For the purposes of this description, we are assuming a system that is
structured according to the drawing above. But all other implementation 
strategies that result in the same bits on the wire for the same user input 
are valid implementations of this standard."

Other implementation strategies I can think of offhand (ASCII lines
omitted for speed of typing):

     User
     Application with built-in RACE/nameprep/DNS client library
     DNS server

(it is NOT true that all clients use the resolver code in the C library.
Some do weird things like using the Net::DNS Perl module....)

or:

     User
     Application
     Internal resolver with UTF-8 transparency
     Network link (intranet, most likely) using a DNS-like protocol
             on private port
     Application layer gateway that does RACE/nameprep
     DNS server

Of course, the latter implementation strategy is likely to lead to leakage 
of just-send-utf-8, and should NOT be recommended; but it is, IMHO, a valid 
implementation of IDNRA.

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?

--
Harald Tveit Alvestrand, alvestrand@cisco.com
+47 41 44 29 94
Personal email: Harald@Alvestrand.no