[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Adding "optional" characters in draft-ietf-idn-nameprep
- To: Paul Hoffman / IMC <phoffman@imc.org>
- Subject: Re: [idn] Adding "optional" characters in draft-ietf-idn-nameprep
- From: Keith Moore <moore@cs.utk.edu>
- Date: Sun, 13 Aug 2000 18:32:08 -0400
- cc: Keith Moore <moore@cs.utk.edu>, idn@ops.ietf.org
- Delivery-date: Sun, 13 Aug 2000 15:32:17 -0700
- Envelope-to: idn-data@psg.com
> 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