At 19:59 30/11/2005, Burger, Eric wrote:
Wouldn't having quasi-authoritative translations *result* in balkanization?
No. The current system leads to balkanization:
- exclusively ASCII standards call for translation. Since there is no
possible cross-verification, the understanding may diverge.
- the local practices stay unknown to the IETF.
We need to build bridges, not to exclude, and to permit
cross-verification. The first step is to have a common naming of the
common references. Only bi-lingual people will be able to
cross-verify, but we only need three of them to have a reasonably
cross-verification of the texts and of the auditors. IRI-tags can
permit that. Today an RFC cannot even quote a non-English reference.
The next step is to be able to integrate in the IETF authoritative
BCPs, quotes of locally authoritative rules. Not to change them. We
must not translate the normative quote (a translation should always
be informative). This calls for the support of UTF-8. Otherwise the
IETF creates the balkanization it wants to avoid (it cuts itself from
the rest of the world).
The Chinese National Standard series comes immediately to mind of
authoritative translations *with interpretations*.
I note that the best protection against interpretations is
multilingualism. If you have a version in English and a version in
Chinese, it is difficult to say which is to be used as a reference
(as Vint says, is authoritative the most accepted understanding - a
basic brainware rule) - so the Chinese standard will soon be the
referent. But if you have a version in French, in German, in Russian,
in Arabic, etc. and only one says something different, common sense
will prevail (and we will be able to analyse why, what may lead to
new developments).
nal Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
JFC (Jefsey) Morfin
Sent: Monday, November 21, 2005 8:08 PM
To: ietf(_at_)ietf(_dot_)org
Subject: Why are we so exceptional [was: Translations of standards (was:
RE: ASCII art)]
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf