At 20:49 21/11/2005, John C Klensin wrote:
--On Monday, 21 November, 2005 11:16 -0800 "Hallam-Baker,
Phillip" <pbaker(_at_)verisign(_dot_)com> wrote:
> I think that a better case to make wrt internationalization is
> that it is hard to see how a pure ASCII document is ever
> going to provide a satisfactory description of a protocol that
> is based on unicode.
This is an entirely different issue from the one that I think
Jefsey was raising and Tom was responding to. Conflating them
gets us nowhere at all.
I commented Paul Hoffman's response to Julien Maisoneuve about "why
we are so exceptional". Nothing else. May be should I have changed
the subject. This is now done.
And that takes us back to Paul's original comment, at least as I
understood it -- the important thing is the quality of the
writing. Access to fancy formatting and presentation tools may
make good writing easier to follow and, in particular, to let
the reader get the gist of what is going on before trying to
deeply study the text. But adding fancy formatting and
presentation to poor writing will, at best, only hide, for a
while, the fact that the explanations are inadequate.
Agreed.
But I hope you do not imply non-ASCII English is fancy formatting and
goes with inadequate explanations.
And, by not forcing the extra discipline that writing without a
dependence on clever illustrations requires, it may make it more
likely that we will get documents whose inadequacies are harder
to detect.
ASCII Draft is not the main point here. But it is true that a good
draft often speaks more than long texts.
As I said, that conclusion could change as experience with
"protocols based on Unicode" expands. But, so far, we have
almost no experience along that dimension (and, incidentally,
neither do ISO or ITU or IEEE, at least as far as I know).
I have no idea of what are "protocols based on Unicode". I only know
that equal linguistic opportunity and common global interest mean
that authoritative protocols and procedures should be producible in
every language and aggregated into the IETF document body. Not fully
permitting this would only increase the risks of balkanization of the Internet.
jfc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf