Re: [idn] Canonicalization: [28] through [31]

[bill@mail.nic.nu (J. William Semich)]

At 08:48 AM 6/27/00 +0800, James Seng wrote:
>I think we should leave this discussion to the proposal. I am okay with
Paul's
>amendement, ie.
>
>"The protocol MUST specify canonicalization, and the canonicalization 
>SHOULD be done before the request enters the DNS service interface."


SHOULD is still too strong a requirement for an open approach to
implementation. 

Let's say:

"The protocol MUST specify canonicalization, and the canonicalization 
MAY be done before the request enters the DNS service interface or it MAY
be done at the server."

And add:

"If cannonicalization is done at the server, the server should be able to
recognize when requests have already been canonicalized and should treat
them as such."
 
And let's see what various implementations do.

Consider:

1. Canonicalized names are longer, use up more characters/bits, in the DNS
packet. 
Canonicalizing on the server avoids that constraint on the wire, permitting
(relatively) longer names.

2. IMO, canonicalization should happen as *late* as possible, 
so that changes in the canonicalization algorithm
don't orphan all the stuff at the application level and the edge of the
network.  Canonicalization discards information along the way and so 
should be delayed as long as possible - it should happen at the server.

3. Canonicalization is practically free, computationally, at the server -
implementation testing
shows it's about as expensive as the current downcase operation already
done by the server. 

4. Changes will be underway to facilitate IDN implementation for some time
to come. Canonicalizing at the server will minimize the number of things
that need to be changed, and simplify and centralize the process of change.


Bill Semich