Re: [idn] Requirements I-D

[Paul Hoffman / IMC <phoffman@imc.org>]

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