Re: [idn] Requirements I-D

[John C Klensin <klensin@jck.com>]

--On Wednesday, May 17, 2000 13:25 -0700 "Paul Hoffman / IMC"
<phoffman@imc.org> wrote:

> Another option is to say that we will not add any more
> case-folding after the original set is defined. To the best of
> my understanding, none of the scripts to be added to ISO 10646
> are both (a) in common use and (b) require case-folding. This
> is not to say that we must do it at the client, but to say
> that given the maturity of the current 10646 repertoire, we
> could.

I will happily nominate anyone who says "well, we can't see it
coming, so it won't and we don't need to worry about it" (which
I read into both your comment on this subject and Mark's) for an
associate membership in the "we won't ever have to worry about
having more than 254 (or 2**31) hosts on this network" club.   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.

>> I'm also concerned about the problem that acceptable
>> mapping/folding rules may differ from locale to locale with
>> the same characters.  Perhaps that is in the "bad, but not
>> terrible" category, but what this is supposed to be all about
>> is letting people use their own characters and languages in
>> natural ways.
> 
> For some value of "natural". Today's ASCII case-folding is not
> natural for many novice users, but they are being taught that
> it is just the way that it is. When we expand the characters
> involved with the beginning of IDN, there will be new rules
> that users have to get used to.

I think that I agree with your conclusion, but not with the
statement you use to justify it.  

But, more important, the IDN effort is driving toward a major
change in the way the DNS is used that is much more profound
than case-mapping, one that, IMO, changes the requirements and
criteria.  Prior to the beginnings of serious
internationalization efforts, and especially pre-URL, the DNS,
as used, consisted of an extremely narrow range of characters (a
subset of ASCII with substantially no "specials") that were
treated essentially as protocol elements.  Inability to use the
symbols "'" and "_" in names was commented on, and complained
about, since very long ago and, often in sentences like "my host
should bear my name, and I can't spell it correctly without...".
But statements of that sort were just not consider important
criteria, precisely because of what is referred to above and
elsewhere as the "protocol element" view: absolute clarity, even
when a name was scribbled on paper or read out loud, was a more
important objective than convenient and accurate representation
of human names or their equivalent.

Now, we are moving toward a style of internationalization of the
DNS that considers these strings names, rather than protocol
elements.  As names, I believe they need to be linguistically
sensible in each relevant target language or, in some basic way,
we fail.  While "that is how it works, get used to it" is a
quite reasonable, and generally acceptable, response to comments
about the idiosyncracies of definition of a protocol element,
"linguistically sensible" is a much harder target to reach.
Indeed, the usual (and quite proper) response to "get used to
it", is some (polite) variation on "my language (and its
spelling conventions and graphic set) has been in use for
thousands, or tens of thousands, of years, and you geeks need to
get used to it".  If we can fall into the failure mode, we need
to tag everything wrt the system being used (a different problem
from locality-tagging, but not a lot easier) because, surely,
local schemes will crop up.

    john