Re: Alignment of IANA language subtag registry to ISO 639-3

From: JFC Morfin (jefsey@jefsey.com)
Date: Mon Oct 15 2007 - 06:44:10 CDT

  • Next message: Marcin ‘Qrczak’ Kowalczyk: "RE: Submission to ConScript Unicode Registry: Sylabica"

    At 08:07 09/10/2007, Doug Ewell wrote:
    >Philippe Verdy <verdy underscore p at wanadoo dot fr> wrote:
    >>As you are the signing author of this draft, why isn't it split
    >>into two separate drafts:
    >>* this file without section 3 (that makes most of its content but
    >>is intended to be deleted upon publication)
    >>* section 3 as a draft for the updated registry itself?
    >
    >The short answer is: "Any discussion of... anything... about the
    >effort to update BCP 47, should be directed to the LTRU mailing list."
    >
    >The slightly longer answer is: Draft-ietf-ltru-4645bis-02 is
    >structured the way it is for very many, very specific reasons. Some
    >of them have to do with the way RFCs are REQUIRED to be structured,
    >and some with the decisions made by the co-chairs of the LTRU
    >Working Group, a group that is chartered within the IETF and
    >REQUIRED to act in certain ways.
    >
    >Do not think you can read two or three e-mail messages about the
    >LTRU effort and immediately understand its goals and history, and
    >fire off a pseudo-knowledgeable response, as you have with Unicode
    >and so many other subjects. Your lack of familiarity with the
    >subject is screaming from the rooftops.

    Dear Phillipe,
    Doug is right on two things: what concerns BCP47 should be directed
    to the LTRU mailing list. The LTRU's document goals, history, and
    involved interests are not clear to anyone.

    More interesting here are the concerns you may have about language
    tagging (on the Internet and elsewhere) and globalization. The way I
    understand the problem is that you need first to decide what you
    consider as a language: as a system or as a vehicle among people and machines.

    - If you consider them as systems (what does TC37 and ISO 639)
    together with their script etc., you are in a scientific context you
    can determine (for example: no machine languages included). You must
    be strict in what you send and receive. And you are to discuss
    precisely, as ietf-languages@alvestrand.no does, on tagging. In such
    a case I understand globalization = internationalization of the
    medium + localization of the end + tagging of access/application
    filtering. What you tag is the language in a particular text. One
    language at a time.

    - If you consider them as vehicles, as protocols between people and
    machines (what should be the IETF point of view) you are talking of
    something different. Something dynamic integrated in relational
    spaces. Here applies the basic Internet architectural rule "be strict
    in what you send and liberal in what you receive". This means that
    you must be strict not about what the other thinks, but about what
    you think, i.e. consistent. What you consider is environment
    multilingualisation, i.e. to keep people relating in the language
    they want, simulating thousands of separated lingual relational
    spaces. What you tag is an "externet" (an external network look-alike
    within the common network) - something not easy to understand in the
    Internet environment because the TCP/IP technology has no
    presentation layer. One language out of thousands, with its related
    context (culture). This is the TC46 ISO 3166 approach.

    This resulted in the need of a clarification between the ISO 639
    based English US ASCII internationalization and the ISO 3166
    multilingualisation paradigm, ISO has now clarified, and the need to
    accept and work on metalinguistic interoperability. Let hope it
    happens fast. For the time being I try to keep extended ISO 3166
    based unitags (country, script, language) as interoperable with BCP47
    as possible. However, this works only resumes now: we wanted to be
    sure everything stabilized before, and we will try to do the same
    with RFC 4646bis as soon as we better understand their fundamental
    "extended" language issue.

    jfc
    MLTF



    This archive was generated by hypermail 2.1.5 : Mon Oct 15 2007 - 06:46:39 CDT