RE: Charset policy - Post Munich

[Ned Freed <Ned.Freed@INNOSOFT.COM>]

> Chris - In general, I very much agree. Pushing UTF-8, and strongly
> telling people to include language tagging into their protocols, is
> very much what is needed. I definitely do not want to argue about
> this.

I'm sorry, but I continue to see all this as nothing more than continuing to
attempt to build solutions to non-problems. We have plenty of real problems to
solve without worrying about hypothetical ones that our experience tells us
have little grounding in reality.

> However, both for UTF-8 and for language tags, as well as for
> other internationalization issues, I think it is important to
> not preclude further developments, and not to express requirements
> in an absolute and unchangeable way that makes protocol developers
> and implementers think that if only the do X, all their internatio-
> nalization problems go away.

We have no control over people's ability to take erroneous conclusions away
from specifications. It happens sometimes and that's all there is to it. We can
put in a myraid of disclaimers and people will still draw the wrong
conclusions. However, what will happen is that they will draw more of them
because of the added complexity. They may not be the same ones, but they will
still be wrong. All this sort of nonsense does is clutter up what should be
clear, crisp specification with irrelevant material.

Morover, what we do know is that certain interoperability problems are solved
by language tagging. And perhaps more to the point, the IESG has indicated that
the IAB report is being taken very seriously and that protocols either provide
the necessary facilities or else they aren't likely to approved for placement
on the standards track. As such, until and unless we document this reality we
are not giving protocol developers the tools they need to do the job right the
first time.

And because of all this we have a clear need to indicate that such tagging is
required. And as long as we don't say that this isn't a sinecure and
isn't the answer to every i18n problem out there, this is where our
responsibility ends.

> Specifically, I also agree that language tags are a big help
> to current stupid machines. But if we put an absolute requirement
> for language tags into our policy, a requirement that in the
> extreme might say: "Every protocol has to be able to language
> tag all the characters it sends around, with potentially
> different tags for each character.",

Martin, this is nothing but a strawman and you know it. We have ample
experience with protocol design and that experience tells us that protocol
designers don't go out of their way to label things. In fact it's the devil's
own job to get them to do the minimal amount of proper labelling that's
actually needed. The trend is so strongly in the other direction that I feel
confident in saying that there is absolutely no danger of this ever happening.

This also presupposes a level of cluelessness on the part of WG chairs, area
directors and directorates, the IESG, and the IAB that I almost find offensive.
We do have checks and balances in this process, you know.

I urge you to run, not walk, to your nearest bookstore and pick up a copy of
the book "The Death of Common Sense". It explains far better than I ever can
how making rules that assume the people involved are stupid and hence won't
follow the intent rather than the letter of a specification is a recipe which,
far from preventing disasters, tends to guarantee them.

We seem to do extraordinarily well in the IETF when we make specifications that
reveal clear intentions rather than trying to legislate down to the last picky
detail. And for this reason alone I'm opposed to having much of  anything other
than a requirement that there be a way to tag material as to the language it is
written in.

> and we thereby give
> implementors the impression that that's all they have to do,
> and text-to-speech conversion, machine-translation, spelling
> and grammar checks, hyphenation, high-quality display, and
> subtile glyph distinctions maybe necessary for names, and so on,
> will work magically and perfectly, then we clearly create the
> wrong impression.

I have seen nothing in any of the specifications we're talking about that
a reasonable person could take to mean any of this. Again I think you're
arguing against a strawman here.

				Ned