Re: [idn] Requirements I-D

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

At 11:19 AM -0400 5/19/00, John C Klensin wrote:
>This is just another variation on "what we have / can forsee
>today is good enough forever".

No, it's not. It is fully extensible for new characters added to the 
repertoire, just as your proposal is.

>   I believe that every single
>Internet design decision that has been made on that basis has
>gotten us into trouble.

If you are looking for a trouble-free life, you chose the wrong job 
(and the wrong species, for that matter...).

>I don't anticipate discovery of major
>new human languages/ character sets either, but the possibility
>of discovering a new coding mechanism that really needs to be
>included during the next decade or so seems nontrivial.  This
>example will probably get me into trouble, but, as we start
>using the internet over very long distances, I can imagine
>needing to take advantage of the coding efficiency of
>ideographic languages by doing the equivalent of inventing a new
>one (or adding a _lot_ of characters to an existing one).   Now,
>we might not need to case-fold those things, and I'd be a little
>more comfortable with "characters can be added, but they are
>defined as not folding", but, still...

This example of a whole new coding mechanism would work just fine 
with what I proposed. These are new characters added to the 
repertoire; they will come with their own additions to the tables. 
For that matter, we could even add new types of folding or other 
transformations for new characters added to the repertoire (but not 
with values for the existing characters).

>I don't have time right now to work through all of the cases,
>but suspect this would not work with all of the variations on
>resolver- server- forwarder splits in use today.

Please find the time and let us know if your suspicions turn out 
correct. If all the transformations are done before the request hits 
the big box in the chart in the requirements document (and I am a 
believer that this is the proper way to do the protocol), then I do 
not see how the contents of that big box would not work with the 
proposal.

>Paul, we agree on the history.  But the important characteristic
>of those protocols is that the issues were about protocols and
>features.  This issue is a cultural one about whether one can
>use one's own language in a way that is normal, reasonable, and
>grammatically and linguistically correct within the context of
>that language/ culture.

Probably everything that the IETF has done with text-based protocol 
elements has moved towards human-compatible naming. You may not like 
that, but that is the reality. In the movement towards 
human-compatibility for protocol elements that are exposed to people, 
many people (including most of us on this mailing list) want to make 
that as useful as possible to as many people as possible. We all 
admit that this is not fully possible, and that there will be, as you 
so eloquently called it in Adelaide, an "allocation of pain". We are 
Internet users: we are already quite used to the allocation of pain 
when using krufty protocols, even with the very best front ends on 
them.

All of us on this list know that the eventual IDN protocol will have 
flaws with respect to the cultural norms of some (probably all) 
people. We're still willing to try.

>And, while I sympathize with your
>dislike for binary choices and statements, the reality in this
>sort of cultural situation is that, as soon as one moves to
>either "well, I get to use my language (and characters)
>correctly, but you don't" or "we _almost_ get to do it
>correctly", we've pretty much dropped the "names" story and
>dropped back to "protocol elements" with a restricted set of
>rules.

That last clause can easily be reworded to "we've had to put some 
restrictions on 'names' as we expanded the 'protocol elements' to use 
a different set of rules that includes the rest of the world".

>Now, once we get back to "protocol elements" (where is where we
>are today, even for English -- there are perfectly good
>"English" names that can be written in ASCII, but not in
>email-valid DNS names), then we can make rules that expand the
>character repertoire in DNS names but still impose restrictions.
>But each such restriction provides an incentive for people to
>create non-interoperable variations (or "extensions") to the DNS
>to accomodate their languages and cultures.  And I repeat that I
>consider that result, or things that stimulate it, to be a
>failure case.

That scenario is less of a failure than the one of telling the world 
"we decree that you will never get to use your names in the DNS 
because of a mistake we made 15 years ago".

--Paul Hoffman, Director
--Internet Mail Consortium