[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


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.

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.

these are separate questions - it might be reasonable to support #1 but
not #2.

Keith