Subject: [Ltru] FW: appeal to the IESG against an IESG decision

From: "Scott Hollenbeck" <[email-masked]>
Date: Sun, 15 Jan 2006 19:19:05 -0500

Since this concerns a document produced by the LTRU working group I believe
it's something that should be shared here.  Note that IESG decisions must be
appealed to the IAB, not to the IESG.  I'm sure that error will soon be
corrected.

-Scott-

-----Original Message-----
From: Jefsey Morfin [mailto:[email-masked]] 
Sent: Saturday, January 14, 2006 9:05 AM
To: [email-masked]
Subject: appeal to the IESG against an IESG decision

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
<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. 

1.      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.

2.      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

3.      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.

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru