Language tags, the phillips draft, and procedures

Doug Ewell dewell at adelphia.net
Sun Jan 9 18:59:32 CET 2005


JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

> As expressed many times, I fully support the Draft too, provided (a)
> it is restricted to the areas where it is currently used, and further
> on to new areas only after being discussed new area per new area -
> what Addison refused

RFCs 1766 and 3066 were not restricted for use only in certain "areas."

> (b) that registrations are carried in a standard IETF way through an
> IETF WG with an IAB appoved charter warranting network architecture
> consistency.

There has been a Language Tag Reviewer, and a list-based review process,
since the release of RFC 1766.  There will be a Language Subtag Reviewer
under RFC 3066bis (expected to be the same person).  To my knowledge,
the appropriateness of this arrangement has not been seriously
challenged in the past ten years.

I fail to see how "network architecture consistency" applies to RFC
3066bis in a way it does not apply to RFCs 1766 and 3066.

> Would this draft be accepted as a global BCP it would conflict with my
> own needs the way I understand them (but I may be wrong) if are not
> included in the tag:

Nobody can ever promise that any document, even a BCP, will meet every
single person's needs.

> (a) the language usage framework

Does this mean you want the tag itself to contain a detailed analysis of
how and where the language is used?  I think this may *possibly*
conflict with the needs of others to have language tags fit in
restricted-length labels.

> (b) the language authoritative reference (so there may be as many tags
> for a same language, for a same scripting and for a same country as
> needed to cover the requirements/specifics of the concerned usages and
> parties).

There is no "language authoritative reference" for most of the languages
on Earth, as already explained.  Your native French is one of the very
few languages that has an Academy that can say exactly what utterances
are permissible and how they are to be spelled and pronounced.  Most
languages are not like this.

ISO 639-1 and -2 are used worldwide for encoding the names of languages,
both on the Internet (through RFCs 1766 and 3066) and elsewhere.  They
have clear guidelines for what a language is and when it qualifies for
encoding.  ISO 639-3 is on the way, and promises to encode the names of
over 7,000 languages, but it is not a standard yet.  RFC 3066bis
includes a mechanism by which ISO 639-3 comprehensive language codes may
be used in the future.

> As I indicated to Misha, what would really help would be a list of
> motivated support from IAB, Chairs of the IETF WGs from the different
> concerned areas, and non-English or non-American mother tongue
> involved network experts or authorities. Support from some leading
> persons of organizations or entities such as MINC, ITU, WSIS and
> UNESCO, from ETSI or GAC, from WTO and WIPO, would obviously help
> clarifying things a lot.

Again, I must ask:  Was this kind of broad-based international approval
required for RFC 1766, or RFC 3066?  Did anyone ask that ITU or UNESCO
or WTO be consulted before those Internet RFCs were approved?  Is that
generally required for other RFCs, even BCPs?

What in the current draft do you consider inadequate because it was
prepared by native English speakers?  How would it specifically benefit
the draft to have native French or German or Hausa speakers involved?
Was this considered necessary for RFCs 1766 and 3066?

Remember that neither RFC 3066bis nor its predecessors pretend to
"define languages."  They define a tagging system which can be used to
identify the language(s) of specified information content.

> Again, I oppose nothing, but I do not want us to make a big mistake.

RFC 3066bis is an evolutionary step along the path defined by RFCs 1766
and 3066.  I would like to know why it should be subject to a different
set of rules and acceptance criteria from its predecessors.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/




More information about the Ietf-languages mailing list