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

[Keith Moore <moore@cs.utk.edu>]

> At 3:49 PM -0400 8/13/00, Keith Moore wrote:
> >  > >d) we could have IDN servers accept strings with or without Hebrew
> >>  >vowels, then return records with the "correct" spelling.
> >>
> >>  This sounds like a close variation on (a). What is the advantage  of
> >>  returning a label that is different than what was requested?
> >
> >there are limits to what can be done with pre-canonicalization.
> >
> >with (a) the canonicalization rules for all langauages have to be
> >known in advance and defined as part of the spec in order for the
> >client to be expected to implement them.    and the client can't
> >use any sort of fuzzy matching. because it doesn't know what it's
> >matching against.
> >
> >with (d) the matching rules only have to be known by the server
> >that implements such names (the client isn't aware of them at all),
> >and the server only has to know the rules for the languages that
> >it supports. also, the matching rules don't have to be defined
> >as part of the spec.
> 
> 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.  So root servers
shouldn't be doing fuzzy matching  for anything except TLDs. (at most)
(and hopefully we won't need it there)

> 
> >there are two cases of interest:
> >
> >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.

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

Keith