[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 <firstname.lastname@example.org>
- Subject: Re: [idn] Adding "optional" characters in draft-ietf-idn-nameprep
- From: Keith Moore <email@example.com>
- Date: Sun, 13 Aug 2000 15:49:33 -0400
- cc: Keith Moore <firstname.lastname@example.org>, email@example.com
- Delivery-date: Sun, 13 Aug 2000 12:50:11 -0700
- Envelope-to: firstname.lastname@example.org
> >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
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