Re: Unicode normative value [was. Re: VS: "French+" support by Unicode]

From: JFC Morfin (
Date: Mon Apr 14 2008 - 23:01:57 CDT

  • Next message: Stephane Bortzmeyer: "Re: Unicode normative value [was. Re: VS: "French+" support by Unicode]"

    Dear John,
    I am afraid that we get confused here. The point is not a legal
    dispute. It is a multilinguistic and epistemologic related
    consideration. It is not that easy to grasp. I am not fully sure
    about it, but I think it is true and important to consider.

    Up to now the debate is based upon local linguistic inputs. Analysis
    shows that in fact most of the problems we face comes from:
    - multilinguistics issues, where multilinguistics, as MLTF debugs it,
    can be described as what corresponds to networked "diversity" as
    opposed to "linguistics" in the support of the "linguistic diversity".
    - the global nature of the issue where the difference between a norm
    (describing normality) and a standard (describing how to accomodate
    it) becomes a key issue. Locally norms are tuned by local standards
    so they can be confused. Universal norms are locally impacted by many
    local standard, but not globally (or not with the same hysteresis).

    Interoperability can be obtained in two ways:
    - from the share of the norm (common normality) by local standards in
    multilateral systems
    - from the internationalisation of a local standard in unilateral systems.

    The later is the IETF decentralised (RFC 3935) Copernician paradigm,
    and its applied consequences extremely well documented and applied in
    sciences, industries, and economies for two centuries, since Emmanuel
    Kant : constraint to limit the internationalisation options of a
    network (user) centric system. RFC 3935 defines it very well: the
    IETF technology is not the one which could be developped but the one
    which corresponds to its core values: English, decentralised, end to
    end, fully shared resources, etc.

    However, the former corresponds to our global world distributed and
    ontocentric paradigm, ISO, WSIS and the world shares. The center of
    the world is not the IETF but the 6.5 billions of JFCs. Awfull :-) !
    The language center of the workd is not English, but every existing
    language as compiled by David Dalby, and Debbie is now quoting as
    40.000 language entitiies. But still worse, the way human beings
    think it is as diverse as their languages.

    I agree that ISO and JTC1 thought they could "fake" their bilingual
    equal delivery mission. And people/users accepted because it did not
    seem to make a big difference except a cost and delay reduction. I
    agree that Unicode thought it would be simpler, faster and less
    expensive to improve the ISO 10646 English version (cf. RFC 3869 analysis).

    But this was a mistake and the difficulties with RFC 4646 and with
    IDNA come from there.

    The reason why TC46 deliveries are better quality. Is _not_ because
    many people there are French. It is because being French they
    _have_to_ respect the ISO process and make the French and English
    thinking and text progress together. Respecting the ISO rule by
    necesity, when the English speakers disrepect it by convenience. This
    explains why Unicode seems better to you as an English speaker,
    thinker and writter, than for me and a non-English speakers. The
    French pragmatic helped reducing the English pragmatic. The French
    semantic helped adding to the English semantic. So there is not
    eventually more metalinguistic in both languages to support
    multilinguistic needs enough.

    A natural consequence, I think, is that it is more difficult for you
    to see that the IDN architectonic is inconsistently complicated and
    that the multilngualism complexity cannot really be simplified
    without an OSI (another ISO consistent multilayer inconvenience)
    presentation layer. The same as for RFC 4646. This has eventually
    been decided at ISO/TC46 when they did not supported Debbie's
    internationalisation proposition against my acknowledgment of ISO
    3166 as a multilingual padadigm.

    I hope I was clear enough?

    At 03:12 15/04/2008, John C Klensin wrote:

    >A few comments below, less about Unicode / ISO/IEC 10646 than
    >about JTC1 procedures more generally.
    >--On Monday, 14 April, 2008 15:54 -0700 Asmus Freytag
    ><> wrote:
    > > On 4/14/2008 3:27 PM, JFC Morfin wrote:
    > >> Dear Asmus,
    > >> I am afraid there is a misunderstanding. Unless there is a
    > >> JTC1 supplement I did not considered, Annex E (normative) of
    > >> ISO/IEC General Directives says :
    > >>
    > >> (E.3) "International Standards are published by the ISO and
    > >> IEC in English and in French (and sometimes in multilingual
    > >...
    >I don't have time to look up and check on what you are reading
    >from, by there are actually two separate sets of Directives.
    >One applies to ISO Technical Committees and are usually known as
    >"ISO Directives". If IEC has adopted them for its subsidiary
    >groups at well, that happened while I wasn't looking, but I
    >haven't been paying much attention to the details in that area
    >for the last decade or so.
    >There are, separately, Directives for ISO/IEC JTC1 (Information
    >Technology) which are, well, different. The general ISO
    >Directives do not apply to the Joint Technical Committee, which
    >has its own, self-contained, set of rules.
    >More below.
    > >...
    > > Well, whatever JTC1 decrees in its lofty spheres about this,
    > > the reality on the ground is that the French text (of 10646 in
    > > particular) is an after-the-fact translation, that, while
    > > presumably prepared with care, is not subject to any rigorous
    > > review by the working group responsible for 10646. It may aid
    > > in "comprehension" but for the reasons I mentioned here and
    > > before, there are practical limits on how far you can rely on
    > > it as a formal reference in fully the same manner as the
    > > original.
    >Asmus's explanation generalizes far beyond Unicode or 10646.
    >While the majority of ISO's many standards describe processes or
    >physical measurements that lend themselves to accurate parallel
    >development, the conclusion was reached a _very_ long time ago
    >that, for information technology and systems, translation is a
    >sensitive enough business that one version was always designated
    >as normative even if the other version existed. If the
    >translation did not agree with the original, it was always clear
    >which one was the original and authoritative version; bugs in
    >the translation got fixed. For at least most of the life of
    >ISO/TC97 (JTC1's predecessor on the ISO side) and in JTC1, I'm
    >not aware of any standards being developed in parallel in both
    >languages. Usually English was the development language,
    >perhaps occasionally French, but not both. The rules in TC97
    >required that a French translation exist for a standard
    >developed in English before that standard could be balloted (or
    >perhaps published), but AFNOR, which had responsibility for the
    >translations could waive translation and, for large or complex
    >documents, usually did (my involvement with ISO standards
    >efforts only goes back to around 1968; I have no first-hand
    >information about what happened before that). I haven't studied
    >the JTC1 rules about multiple-language versions for years and
    >the Directives do change over time, but my recollection is that
    >they are (or were) even more relaxed about translation
    >availability than TC97 was.
    > >...
    > >> Obviously, this raises the question of Unicode being chosen
    > >> as a reference by the IETF for RFC 4646 and IDNA. As you
    > >> note it, Unicode has introduced average-English speaking
    > >> user friendly solutions.
    > >
    > > Yes, the additional information is provided as parallel
    > > (informative) annotations (which will form part of a new
    > > combined nameslist between 10646 and Unicode, and which have
    > > already been translated into French as far as they apply to
    > > French speakers, by the way) and also as separate, independent
    > > publication UTN #24, "Sample American English Translation of
    > > Unicode Names List", (which is not part of the Unicode
    > > Standard).
    > >
    > > Neither of these causes any of the questions you are trying to
    > > raise.
    > >
    > >> The problem is that these solutions are no part of ISO 10646
    > >> both versions
    >The IETF makes decisions about what to reference. Those
    >decisions are usually made quite carefully and thoughtfully,
    >but, in any case, they get made. Once that reference occurs,
    >it is the reference that is important. We have, for example,
    >preserved references to at least one ISO Member Body standard in
    >its 1968 version in spite of the fact that the Member Body has
    >revised the document several times and its ISO near-equivalent
    >has also been revised several times since it was created.
    >While we have a general preference for referencing international
    >consensus standards rather than consortium efforts, working
    >groups do what they need to do and references to consortium
    >standards (Unicode and otherwise) are fairly common.
    >If I correctly understand your comments, you are concerned about
    >an apparent violation of ISO's procedures by ISO in producing an
    >ISO Standard. I rather doubt that the violation actually
    >exists, but, even if it does, it would have no effect on any
    >IETF document that references that Standard (one might object,
    >in a WG or at Last Call, to the reference itself, but, once the
    >document is published as an RFC, it is published). If you
    >think ISO has broken their own rules, you need to take it up
    >with ISO. I'm sure the IETF will be fascinated to hear what
    >they tell you, but, even if ISO were to withdraw the relevant
    >standard (which would astonish me), it would not affect the IETF
    > john

    This archive was generated by hypermail 2.1.5 : Mon Apr 14 2008 - 23:05:49 CDT