Re: [idn] An open letter to the IDN WG (long)

[Dave Crocker <dhc@dcrocker.net>]

At 10:23 PM 3/19/2001, John C Klensin wrote:
> > "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.

Sounds good.  Not a goal or requirement for DNS, and not possible as part 
of DNS.  We agree.


> > 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.

Significant evidence that it is the wrong goal would be helpful before 
pursuing this vector.

The primary argument that it is the right goal is that it changes no DNS 
functionality -- and therefore does not perturb the DNS "model" -- but 
permits encodings to be in character sets other than the current, 
restricted ASCII.  Hence it lets the style of DNS that we all love and use 
be the same, albeit accessible to a larger community.

In response to your presentation comments last night and in Melbourne:

         Having a random array of end-users say that they want domain names 
to be "words in free text" is not sufficient.  Of course end users do want 
that enhancement.  They would be foolish not.  However we all want world 
peace, too.  A practicality/appropriateness function is required, to 
mediate end-user requests.

One of the reasons that a company needs to separate Marketing from Sales is 
that Sales is constantly coming back with complaints about the product, as 
an excuse for not being able to sell the product.  Marketing's job is to be 
careful about interpreting those criticisms -- filtering out the ones that 
are really only excuses for doing a bad sales job -- and balance them with 
achievable goals that will ensure product use.

A particularly obnoxious management style is to let that constant stream of 
complaints whip the company around, constantly changing requirements.  It 
guarantees company death.

We are changing infrastructure. The rule needs to be to make the smallest 
amount of change that we can get away with.  Anything more increases risk.


>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.

There is always a delicate balance to strike, between maintaining project 
focus, versus having procrustean tenacity to original goals while ignoring 
market evidence that the goals are wrong.

Lose focus and your project never completes.  Ignore market evidence and 
you deliver the wrong product.

We do not have evidence that maintaining the current working group focus on 
international character sets for domain names is the wrong goal.

We DO have evidence that any number of people would like to overload the 
activity with the larger and much more problematic goals, such as solving 
the 25 year requirement for a global directory service.

Let's keep in mind that there have always been complaints about the 
DNS.  However it is a strikingly successful service; it demonstrates an 
excellent balance between technical and human factors requirements.  When 
pursuing changes to it, we need to maintain its success by not breaking the 
basis of it.


>         (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".

As I noted in the working group  meeting, "internationalized access" is not 
a term that authorizes changes the very nature of a domain name.


>That was not an accident -- the intent was precisely to permit the WG to 
>explore both "modify the DNS" and "do something        elsewhere" approaches.

The wording might have been intended to convey authority to break the DNS 
model, but the wording was too clever (or, at least, far too subtle.)  It 
does not convey the semantic that the nature of a domain name is allowed to 
be changed.

To the extent that such a fundamental change was anticipated, for a service 
that is fundamental to the Internet and has been stable for 14 years, the 
language should have been much more explicit.  That way we could have 
fought the battle over this problematic goal at the beginning of the 
working group, rather than this far down the path, when it serves mainly as 
a distraction.


>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".

An IETF working group is driven by their charter.  Evidence that a charter 
needs changing is always relevant, but the later it comes, the more 
problematic the effect, and questionable the claim against it.

You want to change IDN's chartered task to be something larger and less 
attainable.

Your particular suggestion, to insert a directory layer, is fascinating and 
worth pursuing.

However it is a research project.

I say that in all seriousness.  To the extent that you disagree, please 
provide a technical review that permits anyone to believe that a workable 
specification -- one that is likely to be adopted and deployed and used 
successfully -- can be attained within one year.

Pointing to any other large-scale, deployed directory service seems like a 
reasonable requirement, for indicating that the task is not research, given 
that you are suggesting a massive change to a fundamental piece of Internet 
infrastructure.  (I am not aware of any such exemplars.)


> > 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.


"strongest".  hmmmm.  I could easily claim that it is also the strongest 
requirement for English-based strings, if we ask the right (really, the 
wrong) people and we ask the right (really the wrong) question.  That does 
not justify breaking the ASCII DNS.

Again, we need to very careful when taking random comments from random 
end-users and assuming that a) they are phrased properly, and b) that they 
represent a sufficient understanding of what is reasonable and possible, 
and c) that they are a representative sample of "community", thereby 
permitting generalization from their assertions of requirements.


>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

Domain names currently work well for roughly 75-100 million users.  That's 
rather strong human factors validation.

It will be interesting to see an Internet-related alternative that has 
equally compelling use.  (I am not aware of any.)


> > 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.

One of the nice things about suggesting work that involves creating a new 
layer is that it permits independent pursuit.  So it would be reasonable to 
create an independent working group to define the extension to DNS naming 
(and that is a naming, not a character set issue) that you have in mind.

However my own recommendation is that it be handed to the IRTF until a 
rather definitive set of attainable requirements are specified... and 
substantiated, particularly given the poor track record of large-scale 
directory service projects.


> > Even grandmothers can learn cryptic syntax, though it is not
> > reasonable to force them to learn different character sets.
>
>Or, probably, different languages.

Correct, but how is that relevant?  The focus of the current work is on 
character sets, not languages.  (The work you are suggesting DOES involve 
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.

Being our age, yes, our mothers are the grandmother exemplars.  Mine has 
been oddly proud of having two children in this business but being, 
herself, unsure that light switches really  work.  I got her onto webtv 
less than a year ago, with trepidation.  She's doing quite well, though.

But seriously, I'll repeat my claim that a user base of 75-100 million is 
damn good substantiation that a design balances technical and human factors 
issues well.

When considering the human factors issues, we need to distinguish between 
something that can be used by 100% of the population, versus something that 
can be used by a smaller percent.

100% includes people who are mentally retarded, emotionally disturbed, or 
who have equally distracting, though less dramatic, barriers to use.  (I am 
not being frivolous, here.  When talking about end-users, perfection is 
impossible, so we need to be clear how many sigmas of variation are 
included, and what outliers are excluded.)

While I entirely concur with the caveat you issue -- namely that 80% might 
not be sufficient in some cases -- we need to be careful not to assume that 
that means that 100% is the only alternative.

It isn't.

d/


----------
Dave Crocker   <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464