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

[Patrik Fältström <paf@swip.net>]

At 22.55 -0400 00-06-26, J. William Semich wrote:
>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.

Not at all. We need the strong language because of interoperability, 
like Ran has so much argumented for.

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

That is for me not good enough. Keep the language proposed.

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

Nope, they are not longer. If you in Unicode have a "decomposed" 
character, "composing" it will make it shorter.

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

Nope again. It should be done _immediately_, and early in the process 
so we internally have only canonical strings to work with. For 
exactly the same reasons you list above.

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

It is a bit more expensive. The tables you have to have is not small. 
It is still the case that the clients (together) have much more CPU 
power than the servers, and it is much better if the clients do the 
work, and leave the servers to serve data. I.e. making life as simple 
as possible for the servers is a good thing.

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

Not at all. Canonicalization is something which needs to be done 
always when you compare strings, and those algorithms should not 
change -- especially not regarding DNS -- because then two domains 
which previously were different (and because of that registered by 
two different parties) will no longer be different so one of the 
domain name holders have to give up his name.

    Patrik