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

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

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

just the ones immediately under .com..  but yes, each zone could have
its own fuzzy matching rules.

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

I'm assuming that the political barriers associated with defining 
new fuzzy TLDs are the limiting factor here.  It's been hard enough 
to get to the point where we might someday see new non-fuzzy gTLDs.

though there are certainly interesting issues with fuzzy matching -
DNSSEC being one (what do you do when the RRs you get back don't
match the labels you asked for?), and propagation of updates to
other servers being another (are we going to define a standard format
for specifying fuzzy matches?)

on the other hand, with non-fuzzy matches we need to specify
a set of language-specific "canonicalization" rules for all
other languages of interest, to go along with the rules we
already have for ASCII DNS names (case folding, certain characters 
disallowed).

neither approach seems particularly attractive.

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

I don't see where you get that idea.  to me it seems that there's a 
fundamental difference between requiring the sender to know a 
single set of matching rules for every zone, and requiring each zone 
to implement the matching rules that it needs for its purposes.  
it's not even clear to me that it's possible to come up with a 
reasonable, single, set of rules for all languages of interest.
there's also a fundamental difference between expecting the match
to be implemented by a canonicalization step (done on the client)
and a simple comparison step (done on the server), and allowing
the server to apply whatever matching algorithm it deems appropriate.
there's also a fundamental difference between requiring us to
get the canonicalization/comparison split more-or-less right the 
first time (because code that exists on all clients will be difficult
to change once deployed), and letting each zone specify its own
comparison algorithm. 
 
and who is going to come up with the canonicalization rules if we 
do decide to try to go that way?    this is *way* beyond IETF expertise.

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

that's simply not true.  you cannot model all kinds of matches
by using a canonicalization step followed by a single comparison step. 

Keith