[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] An open letter to the IDN WG (long)
- To: Dave Crocker <dhc@dcrocker.net>
- Subject: Re: [idn] An open letter to the IDN WG (long)
- From: John C Klensin <klensin@jck.com>
- Date: Mon, 19 Mar 2001 21:23:39 -0500
- Cc: idn@ops.ietf.org
- Delivery-date: Mon, 19 Mar 2001 18:25:39 -0800
- Envelope-to: idn-data@psg.com
Dave,
I'm going to try to respond to this, but pick up some of Adam's
and Eric's concerns as well.
--On Monday, 19 March, 2001 13:59 -0800 Dave Crocker
<dhc@dcrocker.net> wrote:
> you have perfectly telescoped the topic I was most concerned
> about in your own open letter:
>
> your note introduces feature creep
>
> "The attempt to get words in free text to act as identifiers"
> is not a goal or requirement of the DNS.
Absolutely. Nor is it, I am arguing, possible to do in the DNS.
> It is therefore not a goal or requirement of internationalizing
> the DNS.
>
> I fully appreciate the appeal and benefit with that goal, but
> it is not within scope.
Well, here we need to be careful:
(i) It is possible for an IETF WG to discover that it is
solving the wrong problem. When that occurs, it is
arguably better to stop, evaluate the environment, find
the right problem, and solve it rather than saying "the
charter says this is the problem we are to solve, so all
correct solutions (to correctly-stated problems) are out
of scope". Standing on rituals and procedures in the
latter way is, IMO, a poor substitute for clear thinking
and careful action -- and I think I've heard you make
exactly that argument in other contexts.
(ii) However, that isn't the issue for this particular
WG. The charter was carefully written in terms of
"international access to domain names", not
"international names in the DNS". That was not an
accident -- the intent was precisely to permit the WG to
explore both "modify the DNS" and "do something
elsewhere" approaches.
So, IMO, whatever the right answer is here, we really need to
figure it out on the basis of requirements, functionality, and
cultural and marketplace demand, not by pointing to a charter and
saying "out of scope".
> Domain names sometimes seduce people into thinking that they
> represent words if free text, but that is not what they are.
Agreed. But the strongest requirements for internationalized
names are not for internationalized _identifiers_, but for
internationalized names and words and product and company names.
Identifiers would be a step forward, but at the same level as
"internationalized" identifiers in programming languages whose
keywords are [still] ASCII-based. Solving a problem that may or
may not be important (that is part of the philosophical
question), but not the problem of full international use by
non-specialists that I see the user community --and those who
intend to make money or careers supporting them-- doesn't serve
the IETF or the community well.
> *** And we have no need to expand domain names to be
> words in free text ***
>
> It is one thing to deal with a "coding" limitation and fix it,
> that is, to move from ASCII as the end-user string to an
> international range of characters. It is an entirely different
> thing to try to change the philosophy and semantics of the
> domain name "type".
Which is why I'm arguing for abstracting the problem above (or
beyond) domain names, since "chang[ing] the philosophy and
semantics of the domain name 'type'" isn't, IMO, going to be
adequate.
> Even grandmothers can learn cryptic syntax, though it is not
> reasonable to force them to learn different character sets.
Or, probably, different languages.
> There is always a balance to seek and, yes, we need to be very
> careful about the burden we place on grandmothers. However
> they learn postal codes and telephone numbers. And all the
> evidence is that they learn URLs reasonably well. Domain name
> restrictions fall well within that scope of restrictions.
Perhaps your grandmother has learned URLs fairly well. My mother
still hasn't completely mastered email addressing, much less
whether the slashes go forward or backward, and where.
john