Re: [idn] Adding "optional" characters in draft-ietf-idn-nameprep

[Paul Hoffman / IMC <phoffman@imc.org>]

At 6:32 PM -0400 8/13/00, Keith Moore wrote:
>  > But with (d), these rules will have to be implemented on all servers
>>  that are directly superior to an authoritative server that might use
>>  the letter, which might eventually mean putting it in the root
>>  servers. The extra processing might be small, but we have to decide
>>  whether or not we really want it there.
>
>I don't see this.  The fuzzy matching could happen on a per-label
>basis.  Servers shouldn't be doing any fuzzy matching for a zone
>unless they're authoritative for that zone.

Exactly right. The servers for .com would have to do it for every SLD 
under .com, and so on.

>   So root servers
>shouldn't be doing fuzzy matching  for anything except TLDs. (at most)
>(and hopefully we won't need it there)

But we might. It would be good to make the IDN names equally useful 
on all labels, not just non-TLD ones.

>  > >1. the client supplies a slightly "mis"-spelled name.  the
>  > >    server realizes that there can be only one name matching this one,
>  > >    so it returns the records for that name to the client.
>>
>>  The same thing happens under (a) or (b) or (c), except that the
>>  application or resolver (whichever is doing the normalization) does
>>  the realizing before sending out the correct DNS query.
>
>it's not clear that this can be made to work well enough for
>some languages of interest...we need to find out.

It will work equally as well or as poorly for all four options, so 
this is not an argument in favor of (d).

>  > >2. the server realizes that there are multiple names which might
>>  >    match the one that the client typed in.  so it returns a list.
>>  >    in this case the client has to provide some mechansism that
>>  >    allows the user to choose.
>>
>>  This forces a significant change in the way applications use the DNS
>>  (including expecting a person to be able to choose by context).  That
>>  seems pretty extreme for a problem where we have much simpler
>>  solutions.
>
>IF we have much simpler solutions.  It's not clear that we do.

(a) is identical to (d); it's just done at a different place in the 
structure. (b) and (c) are definitely simpler than (a) and (d), but 
they have consequences that people so far have not liked.

--Paul Hoffman, Director
--Internet Mail Consortium