[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Requirements I-D
- To: idn@ops.ietf.org
- Subject: Re: [idn] Requirements I-D
- From: Paul Hoffman / IMC <phoffman@imc.org>
- Date: Thu, 18 May 2000 11:07:25 -0700
- Delivery-date: Thu, 18 May 2000 11:16:17 -0700
- Envelope-to: idn-data@psg.com
At 5:55 AM -0400 5/18/00, John C Klensin wrote:
> I
>believe that, if we are going to play those games, there need to
>be explicit protocol provisions for clients fetching the mapping
>tables (or mapping table extensions) at regular or orderly
>intervals. That isn't impossible, or even very hard --I can
>think of several ways to do it-- but I believe it would need to
>be part of a protocol standard, not just something
>implementations figure out.
There is a different option, one requires much less overhead than
this. The character repertoire that is allowed in IDN is exactly that
of ISO 10646 at the time we finish IDN. There is a single
case-mapping table, a single canonicalization table, and so on, at
that point. Those tables for those characters never change except
under the most widespread agreement by everyone (meaning, they'll
probably never chage). As new characters get entered into the
repertoire, they get new table entries; to date, this happens once a
year or less.
The rule for IDN (which is arguably what is being used for today's
US-ASCII host names) would be "MUST NOT return illegal code points in
responses, SHOULD reject queries with illegal code points".
A client that did not have the most recent repertoire list and the
associated tables would get an error saying "invalid character".
Internet lore would tell folks to get their new tables, particularly
when there are popular additions to the repertoire. But there would
be no protocol issue with a client that had an out-of-date set of
tables, and thus no protocol need for automatic updating.
>Now, we are moving toward a style of internationalization of the
>DNS that considers these strings names, rather than protocol
>elements.
Fully agree.
> As names, I believe they need to be linguistically
>sensible in each relevant target language or, in some basic way,
>we fail.
Fully disagree with the binary-ness of "we fail". This statement
ignores the long string of past successes we have had with the
Internet using far-less-than-optimal protocols. Even as some of those
protocols were being developed, the record shows that many features
that were obviously desired were not put in, some methods were chosen
because of the personalities of the players at the time, and some
guesses were just plain wrong. And yet using the Internet works
acceptably well for its current market and can be made to work
acceptably well for billions of new users.
Interacting with human language in any medium always has its
limitations. Those are not failures.
--Paul Hoffman, Director
--Internet Mail Consortium