Appeal to the IESG against an IESG decision concerning RFC 3066 Bis Draft (JFC Morfin; 2006-01-14) - 2006-01-14
Appeal - 2006-01-14
Subject: Appeal to the IESG against an IESG decision
Date: Sat, 14 Jan 2006 15:05:24 +0100
From: Jefsey Morfin <jefsey@online.fr>
To: iesg@iesg.org
Dear IESG Members,
here is the announced appeal against the IESG decision concerning RFC
3066 Bis Draft of Novembre 15th, 2005. You will note that the Tunis
agreement has changed the context of the IANA, IETF and of RFC 3066
Bis. This has permitted a more positive vision of this appeal.
You will also find the PDF of this text at
http://jefsey.com/appeal-3066b-iesg.pdf
Sincerely yours.
jfc morfin
APPEAL TO THE IESG AGAINST AN IESG DECISION
This is an appeal against the IESG decision to approve the RFC 3066
Bis Draft on November 15th, 2005. It documents the context of the
appeal. It discusses the points raised against the IESG decision and
also proposes solutions to suggest the WG-LTRU.
- Context
This part documents contextual or architectural points which this
appeal does not raise. These may be raised if this appeal has to
escalate to the IAB. These points help to understand the context of
this appeal.
1.1. new challenges
Languages are symbolic ways to convey information through different
modes (spoken, written, signs). These are the protocols of human
layers exchanges. These are parameterised by referents (what is
accepted by all their speakers). These are used along various
personal styles and in different contexts (what is accepted by all
the participants to an exchange). Languages are currently under major
evolutions:
· documents have become computer assisted, with the emergence
of "architexts" (smart source of the presented text), with new
memorisation, presentation, multilingualisation approaches.
· new human technologies may lead to different referents for a
same language. A text may have consistent orthogonal readings
depending on the trade of the readers of a same language.
· languages are networked. They are used:
· in polylogual multilocutors contexts documented by underlying
or environmental meta-elements.
· in multilingual and multicultural local competition.
Symbolic ways are out of the scope of the IAB and IETF, but protocols
over a network are in their scope. However, the mutual impact of
protocols, symbolic ways, modes, styles, computer, trade, networking
and cultural competition make the identification and the referencing
of networked languages an issue of responsibility and of competence,
with technical, societal, cultural, economical, political and
vernacular usage implications wider than the scope of any existing SSDO.
1.2. globalization vs. harmonisation doctrines
Globalization is understood by the IETF as internationalizing the
network and localizing the end. The target is to remove the lingual
barriers between a supplier and its foreign clients. The Internet, as
agreed at the Tunis summit and documented in the reports of IAB and
ICANN meetings on IDNs, is the internationalized US data network
system. It empowers the American language, culture, economy, etc.
The task now is to permit an equal empowerment opportunity to the
other 96 % of the mankind. "What ever you can do in American, you
MUST be able to do it, with the same comfort, in all other 20.000
languages listed in future ISO 639-6". It calls for a, most probably
rewarding, new architecture.
The architecture to address this challenge is multilingualisation. It
can be a cross-globalization for every language; a universalised core
and a personalisation of the ends; a multilateral architecture ... In
any case it should support the IETF US internationalization, possibly
as a default if it permits.
Multilingualisation will be a never ending process. It will have to
keep pace with the changes in the human society, technology, and
cultures. This constant harmonisation will probably be very complex.
It will be a dramatic change, from the mono[lingual] Internet we are
used to, to the multi[lingual] Internet we need. This evolution will
not be limited to its basic requirement: brain to brain interintelligibility.
1.3. conditions of the debate
I came to the IETF to offer RFC user QA over multilingual issues at
the WG-IDNA. I found no interest in the users' needs. I found a lobby
(leadership?) wanting to "influence" the ways the world "design, use
and manage" the Internet (RFC 3935). Network hysteresis does not
permit to disregard errors engaging usage. Experiences in naming and
numbering have shown these may delay the network development for decades.
Creating an opposing lobby was my first move. I quickly saw it would
only be damaging to the IETF, a bigger waste of time and non
productive. This is why I chose to give the necessary time to common
sense to prevail, in exposing their mistakes in a way they could
forced to correct some of them. The democratic method for that is
work and filibustering. Filibustering is not pleasant. But it
permitted to obtain what users' protection demanded:
- to get the lobby discussed above to expose itself, and its
(RFC 3869) commercial sponsors - to get done most of the work needed to clean the messy
December 2004 version of the Draft. - to get this Draft approved only after the Tunis Summit made
it a US local proposition.
It did not permit yet to make it useful to users. This is the reason
for this appeal.
Work allowed me to build an alternative open solution. Not to be
disruptive I need an IAB guidance on its introduction. I used the
appeal mechanism against the aforesaid lobby to request it. I now wait for it.
1.4. purpose and context of the Draft
The purpose of the WG-LTRU debate and (non-considered) charter is in
fact to build an authoritative Language Name System (l call LNS for
simplicity). This LNS is to be consistently used to name languages,
locale files, lingual products, contents and services, etc. and even
possible lingual TLDs.
Yet, the WG-LTRU debate has shown the intent was not to build this
LNS as the basic building block of the open Multilingual Internet, a
Multilingual Internet the world calls for. It was to constrain its
ABNF and to use its registry management to influence designers, users
and managers (RFC 3935) towards an internationalized Internet along
the Unicode consortium' vision. Forging such an exclusive, through
the single IANA langtag registry, reminds the ICANN exclusive over
the Domain Names registry. Network stability and good governance
should then lead to an IETF/Unicode/IANA MoU over Language Names
issues. It can either be taken as a commercial war declaration on
cultures, or a decision to balkanise the Internet.
1.5. not documented resulting obligations
RFC 3066 Bis was to welcome ISO languages and script names within the
Internet standards. The Draft does not consider the extensions under
way of these standards. It does not discuss what a structural
analysis shows as a layer violations(wrong location of the Unicode
table, taken as a super charset instead of a registry). The mere
allusion to such a possibility was considered as ... insulting.
· ISO 639-4 and 6 may partly or totally obsolete RFC 3066 Bis.
Long term JTC1/SG32./W2 efforts, ISO 639-6 and ISO 11179 conformance
may lead to much more powerful propositions, giving a corrected RFC
3066 Bis its place in the global language information jigsaw.
· We all need, and will obviously implement, an open compliance
with ISO 11179 and with any other SSDO standard. WG-LTRU decided
against ISO 11179 conformance, bridges and compatibility.
· The support of the Unicode OS unification CLDR locale files
project is one of the targets of the WG-LTRU. Its discussion was
denied. It is promoted since the Draft has been approved.
RFC 3066 Bis makes the IETF to support a unilateral US industry
proposition. It imposes on the IETF (RFC 3935) competence and
responsibilities demands which it cannot match. The IETF is now going:
· either to manage a not yet considered, defined, organised and
budgeted compilation, verification and dissemination system,
eventually much larger than the DNS, in an area foreign to its
engineering skills and legitimacy.
· or to dismay the whole Internet community as it did for the
IDNA, but on a much, much larger scale.
Without a complete review of the undertaken responsibility and
obligations, the first option is unrealistic.
- Contested points
The points documented in this part make the appeal against the IESG decision
2.1. non-documented management aspects
The presented Draft does not document the expected usage of the
langtag registry. Without any of the concerned linguistic, cultural
and political authorities being involved, there are hundreds of
languages now documented by a now started IANA registry. They should
soon extend to a few tens of thousands. The architecture of this
registry is not intended to link other registries. For example, every
XML document may at some stage call for an updated direct or indirect
access to the IANA langtag registry. Should every Internet user do it
only once a year, it would mean more than 30 (average) 2 Meg file
downloads a second.
There will be a need of a large number of yearly updates, additions,
changes (variants, new languages, changes in national structures,
etc.), calling for much more user updates.
· the current "ietf-languages @ alvestrand.no" registry
management mailing list has handled 72 registry entries in ten years.
· there is a reasonable expectation that developers,
organisations, users, etc. start relying on the RFC 3066 Bis
langtags and on its registry, and that this registry cannot scale and
support their current or future legitimate extension expectations.
· there is a reasonable expectation that traffic needing
langtag information to proceed be blocked in an undetermined future,
due to a beyond practical possibilities and lack of access to this information.
This is not documented in the security considerations part.
2.2. Competition to the IANA
The presented Draft does not want to consider alternatives solutions
in naming and documenting languages. This creates a situation of
competition between the IANA and other registries. No one has been
accustomed to such a situation up to now.
If such a competition (as it is likely from the current state of the
art) find enough support and usage, this may lead to a balkanisation
of the Internet where IANA compliant only systems would not be able
to use common practice procedures partly supported by the IANA. (Due
to the relative volume of data and related data the LNS may
represent, it is likely that this will lead to switch of the users
from the IANA to the LNS system).
This is not documented in the security considerations part.
2.3. ABNF confusion confirmed by the IESG
RFC 3066 Bis uses a very restrictive ABNF. This format uses one
character or figure prefix, followed by a dash, to introduce one or
several specialised subtags of 8 characters or figures. There is no
initial prefix if the first subtag is a language code. Most of the 36
characters and figures are not currently assigned a meaning as a
prefix. The "x-"prefix opens a private use area. I represented
several times that external SSDOs and private users needed a larger
space than 8 characters of figures. It has been repeatedly answered
that users could use several 8 characters or figure strings to fully
document what they wanted.
"en-x-ietf2006-ustx7071" is a valid langtag. This format is
dissuasive. Its documentation is confused. An example of progressive
langtag abbreviation documented that it obeyed to the common rules.
The AD, confirmed by the IESG, decided it was a typo, removing the
only clarification on the private use format. Harald Alvestrand
documented that this format is dangerous. There is no other way than
walled gardens to prevent two groups of users to legitimately use the
same strings with a different meaning. Everyone can imagine the
dangers this may represent.
This is not documented in the security considerations part.
2.4. non-documented dangerous types of utilisation
The external observable major change from RFC 3066 to RFC 3066 Bis is
a distinctive format. The WG-LTRU's Charter demanded it for "easily
identifying the role of each subtag in the language tag, so that, for
example, whenever a script code or country code is present in the tag
it can be extracted, even without access to a current version of the
registry".
This leads to a dramatically easier use of IETF langtags in order to:
· profile traffic for cultural, national, racial, religious evaluation
· cultural, national, racial, religious searches in search engines
· cultural, national, racial, religious relational "marking" in
using retro-meta-spam: one interlocutor "marks" his traffic (web
pages, mails, etc.) with langtags. The returning traffic designates
the persons who were able to understand it. These persons ignored
they were victims of a meta-spam.
· filter national traffic for specific content, as against
human rights or democratic behaviour
In addition, it is to be noted that:
· the information made public through langtags meta-spam on
public mails and sites permits to collect information on private
persons violating privacy laws of many countries.
· this hidden privacy violation may endanger the business of
search engines which may start offering information (ex.: please
search Google for "ar-arab-us") which may be illegal in some countries.
· this may become criminal activity in some civilised countries
when that information concerns cultural, national, racial or
religious information on the persons.
· the documents such as RFC 3066 Bis which permits such a crime
and incites Internet users to implement solutions permitting such a
crime may be deemed criminal themselves in some countries as inciting
to racial hatred. This engages the responsibility and the credibility
of the IETF, in particular of its leaders and of the IESG. This would
certainly be detrimental to the whole Internet.
This is not documented in the security considerations part.
2.5. lack of verification
No validation tool is associated to the RFC 3066 Bis langtag
proposition. It is entirely based on trust with no
security-associated feature. The langtag of a text can be untrue.
There is no documented algorithm to permit verifications (for example
the number of occurrence of " the " to confirm the claim of "en-" langtag.
Actually, the debate on the further filtering document shows an
opposition between its author and Harald Alvestrand over the
encouragement to use the langtags not to document the text of the
content, but to drive the filtering system. Such a practice will
defeat the whole purpose of the described best "practice".
This is not documented in the security considerations
- suggested solutions
This part documents the suggestions that IESG should give to the
WG-LTRU to consider in order to tackle the issues raised above.
3.1. update of the security considerations
The first proposition I can suggest is to rewrite the security
considerations. This was denied to me by the WG-LTRU, when I started
considering some of the points above. The current text is only a copy
of the RFC 3066 considerations, as if the RFC 3066 Bis did not
introduce any new risk.
3.2. management of the resulting obligations
The unilateral centralisation of the IANA functions makes them a
political/commercial target. It also confines the IANA to a limited
number of issues. In addition, the RFC 3066 Bis now affirms the
internationalization approach. The NTIA publicly confirms that the
IANA could be sold to the private sector (names have been rumoured).
This puts the IANA for the first time in (commercial) competition
with the work engaged by other SSDOs or grassroots processes and
their own clearing houses.
I engaged such a process. I am here to represent the rights and
interests of such endeavours which the WG-LTRU disregarded, as an
IETF DoS. My DRS project (distributed registry system) is an extended
and distributed approach of the IANA. A LNS (language name system) is
mandatory to such a project. I will support RFC 3066 Bis langtags,
among all the others system we may encounter.
The multilateral management and distribution of an inclusive LNS
proposition, in a way comparable to the DNS, is probably the only way
to get a stable, open, flexible, democratic, and scalable solution.
This is what the WG-LTRU should document. I am certainly not alone
in considering such architecture. But I may be the only one desiring
to maintain consistency with the IETF propositions.
3.3. equal lingual opportunity position
I suggest the WG-LTRU should be asked to include in the Draft, the
following equal lingual opportunity proposition.
"The purpose of technology is not to ensure that everyone should have
an equal opportunity regardless of his language, its purpose is to
allow for this goal.
"In its domain, this document wants to allow everyone to freely share
the cultural life of the computer and Internet community, to enjoy
using its solutions on an equal linguistic, cultural, technical,
economical and commercial basis. It also aims to allow everyone to
share into the benefits of the technology and its advancements
without distinction of any kind - such as race, colour, sex,
language, religion, political or other opinion, national or social
origin, property, birth or other status and education. Therefore the
goal is to build a common technical standard for all people and all
nations to be used, or embedded in any technical solution, without
any limitation resulting from the script, the language, the
references or the context of its utilisation environment.
"Taking into account the granular nature and the diversity of the
world's digital ecosystem, as well as the requirements of its
technical convergence, the authors of this technical memorandum
strongly advocate its free, secure and stable implementation to serve
the rights and freedoms of its users at a global, multinational,
international, cultural and lingual, national, local, and personal
level, in the respect of sovereign laws and jurisdiction of each
State, of the empowerment of local cultures, and of its
intergovernance by subsidiarity, in each of its government or
private, community or individual application."
3.4. addressing the users need
The concept of indicating the language attributes of texts in the
documents themselves is a totally new concept, only permitted by the
use of architexts through historically very young, blossoming and
often non-compatible formats. RFC 3066 Bis (due to the importance of
the Internet in content transport, access and archiving) wants to
make this revolution in human practices simultaneously:
· de facto mandatory and global
· ruled by its sole ASCII ABNF and ISO selected lists.
· documented by its sole IANA Unicode based and ruled registry.
It also wants to make that change as a BCP (description of existing
practices) while,
· it did not consider its consequences in the legal, privacy,
cultural, meta-spam, etc. areas.
· it did not use other names than those selected by Unicode for
leading mostly written languages.
· it was not approved by any concerned legitimate cultural,
societal and political representation.
Should the US law not object its consequences; such a proposition can
be standardised for the Tunis accepted internationalized US Internet.
It could even be accepted as a working global default proposition for
the convergence of the world digital ecosystem. But it MUST support
other language naming systems which are able to replace it along with
the evolution of the state of the arts, the user common practices,
the legal obligations, the international agreements and the not yet
considered security aspects.
The diversity supported by the 'tag' URI scheme (RFC 4151) provides
an off-the-shelves solution which matches these criteria.
Some among all the naming information provided by the langtags can
also be obtained from a URI (or IRI). There are three ways of using RFC 4151:
· to use it as a replacement of RFC 3066 Bis. This would be a
final balkanisation of the Internet.
· to introduce a one-letter/figure+dash sequence as an escape
sequence to RFC 4151. This however breaks the langtag concept and continuity.
· to create a users RFC 4151 ABNF conformant space. It will be
introduced by a figure+dash sequence (to be script transparent).
Abbreviations of this space will obey RFC 3066 Bis rules.
My proposition is "'0-'+RFC 4151 ABNF". Others may be devised.
This proposition was disregarded by the WG-LTRU Chair. I was banned
for supporting it. An appeal confirmed that odd position.