[governance] FW: Blogpost: Open Data: Empowering the

[JFC Morfin]

At 14:11 09/09/2010, McTim wrote:
>On Thu, Sep 9, 2010 at 2:47 PM, jefsey <jefsey at jefsey.com> wrote:
>Why would Google want this? or are you talking about the names n
>numbers?  Why would Google want that?  Far too much headache for far
>too little ROI IMHO.  They make Billions per quarter, DNS isn't
>"profitable" compared to search,etc that Google does.

Tim,

Sorry, but this calls for some explanations that you probably already 
know, but that others may not. I will try to be as concise as I can.

The current Internet is about English ASCII information dissemination 
(passive content) with an evolution towards UTF8. The equilibrium 
that we currently have will have to adapt to a full UTF8 support 
(naming and content) of the linguistic diversity (which is also 
economic diversity). Every information provider and naming 
administrator has a need, therefore, to adapt to IDNA2008 and multilingualism.


1. ICANN

ICANN's job is to manage a small Excel table. They have always had to 
be good enough to make believe that this depended on complex 
unnecessary contracts to create and manage scarcities (TLDs, IPv4). 
They have intelligently started first taking control of the IANA 
(focal point), then in launching the TLD (linguistic groups of 
servers) saturation proposition, and in pursuing its make believe "I 
am the center of the world" permanent strategy with DNSSEC.

At the same time, they made a mistake. To start Fast Track quickly 
enough, they privileged IDNccTLDs over IDNgTLD projects. It is in 
this way that they made a lot of money to bepotentially  available, 
ready to support any innovation that bypasses their blocking 
"monopoly". They also made it impossible for local/cultural 
non-profit organizations to plan a TLD. This wqy they opposed the 
planned grassroots Multilinc and Projet.FRA tests.


2. GOOGLE

The Unicode consortium (mainly IBM, M$, Apple, Oracle, Yahoo!, and 
Google - you could initially read this list in decreasing order, but 
now in increasing order) has the internationalization strategy.

2.1. What is internationalization?

With the world's globalization, there is an accentuated dichotomy 
between norms and standards. Until now, they have gone together as 
US, French, European, etc. norms/standards, the norms being a concept 
for the description of the local normality and the standard a concept 
of what we want to make with this normality locally. Now, the norms 
tend to become the global normality, and international standards 
infiltration is the way to conquer foreign markets with the standards 
of national industries. Internationalization (of national standards) 
is WW III.

Until now, war was to plundering other countries to resolve sovereign 
debt problems. Today, this is no longer possible when the wealth of a 
country is its stable just-in-time production and services and debts 
are interrelated. Therefore, what countries look for is a higher 
growth ratio for their exports than for their debts so that they are 
then considered as AAA++. The same is true for leading industries 
(e.g. Google).

Standardization is a powerful and stable way to obtain this by 
forcing other countries to run their just-in-time processes with 
nationally compatible solutions and not overly innovative [MHL1] 
products. This is why Mark Davis' (President, Unicode) 
"globalization" is a key element in the Unicode consortium 
industrials growth as well as USA's growth (FYI globalization = 
internationalization of the medium + localization of the ends + 
filtering of the languages - on the Internet and in the information centers).

2.2. Natural strategy

First, IMHOthere isn't a finalized strategy offered by anyone. 
However, there are natural trends and common sense attitudes. This is 
either because people saw, see, or shall eventually see that things 
fit better for them in one way more than another.

The Internet is the internationalization's main medium: they must 
keep some control of it. The IANA is its information core and RFCs 
are its guidelines. However, the IANA's exposure makes it unadvisable 
to visibly control it. Therefore, the Members of the Unicode 
consortium are/should be happy:

1) That ICANN is believed to be the one in charge (IETF actually is of most)
2) They have overloaded the IANA with the language tables (RFC 4645)
3) Which may require an IANA computer response that only Google could 
sustain (they openly suggested that they could provide the machines) 
should these tables become used in the present state of Mark Davis' RFCs (5646)
4) i.e. permitting traffic and search service control on a cultural 
(hence economic) basis - network neutrality is nothing vs. service neutrality.
5) They control the code of Mark Davis' ICU routines, which in turn 
control that use: they are universally deployed in protocols and 
languages to interoperate with Unicode information.

De facto, through the IANA, the Internet can be DoS-ed by Mark Davis. 
Just one line added to the ICU code, to update local user linguistic 
tables on a regular basis, and the IANA would dump 90% of its content 
into each user with a new ICU. This would represent a progressive (as 
programs get updated) network overload. All the same, Google + Public 
DNS can represent the largest resolution system. Yet it has to be 
protected from networked alternative resolution habits, the DDDS 
possible evolution (extension of the DNS type of database to other 
issues) and ISO 11179 metadata registry norms.

Mark Davis, was with Apple, then IBM, and now Google, as is the case 
of Harald Alvestrand, former IETF Chair, Member of the Unicode Board, 
Member of the ICANN board and their Internet, VP, Vint Cerf, founder 
of ISOC and Chair of the IETF WG/IDNABIS, which had to produce IDNA2008.


3. Internet Users

In all of this, the milked users have never been considered, except 
through "the Internet for all" slogan, user's purse centric doctrine, 
and democratic liberty campaigns to "free" them from their national 
protections. The world information system is planned to be 
centralized by Google. With the current IANA and DNS, this was in 
fact possible.

This has changed this year, however, with the adoption of RFC 5890's 
suites documenting IDNA2008. For various reasons, IDNA was to be 
separated from Unicode (including the changes in namespace due to new 
Unicode releases). This was a strategic thread for Unicode leading 
members. Maybe that is why the WG/IDNABIS mailing list belonged to 
Harald Alvestrand, Mark Davis was the only one protesting at the end, 
and Vint Cerf was the Chair. Everything was tightly locked.

The reality is that they had bet on the wrong horse: Unicode cannot 
fulfill the job. The reason why that is the case is that Unicode is a 
typographic solution, for scripts. The need is for an 
orthotypographic solution, for languages. The typical trouble is the 
French (Latin) majuscules and their needed support by Projet.FRA. 
Because "Etat.fra" means "State" and "état.fra" means "status". 
Equivalent issues exist in every script. French, and to a lesser 
extent German, Greek, Iranian, Tamil, etc., people attended the WG 
and a full Arabic mailing list watched closely.

Unicode has no way to support the "majuscule" or other 
orthotypographic metadata information. Therefore, there would be no 
way to support the Intersem (semiotics and semantics) and the 
semantic addressing system (SAS) through the DNS, that is, if IDNA is 
controlled from within the Internet by a unique RFC for all kind of 
uses by the linguistic diversity. This is why there was a need for a 
multi-layer DNS encapsulation that is specified on the user side. 
This is what I initially proposed and that they had hoped that they 
could avoid.

The result is what IAB/IETF wished for and what French/Latin language 
and many other languages need: no character mapping within the 
Internet, hence no interference by RFCs and IANA, and hence by paying 
ISOC platinum/golden sponsors in languages and cultures. This means 
that control of cultural expression in coherence with search engines 
(as prepared by Mark Davis' RFCs) had to be abandoned by Vint Cerf. 
Google may have to quote domain names that they do not know how to 
resolve without also having to respect local, cultural, national 
naming standards and UTF8 resolution processes. Men are not Google peripherals.

A patch was found that permitted a consensus to be reached: the 
necessary preparation (and mapping) of UTF8 entries will be made on 
the user side. This was not a big practical issue for Unicode since 
their Members already distribute users' applications and libraries 
all over the place. Moreover, Google Public DNS received publicity at 
that time: the size of Google's own DNS service is such that they can 
become a de facto operational reference. Example: If they introduce 
".google" (or any other TLD) they will go through; Vint Cerf has 
already played that game when he adopted a new ".biz" against the 
existing one.

However, IDNA2008 cannot work (except in some default situations) in 
the way most believe it can, i.e. as documented by the IDNA concepts. 
IDNA2003 was specified on the Internet and on the user's side. There 
is a major need to standardize IDNA2008 on the user's side as well, 
with a non-IDNA (IDN in application) user side achietcture. IAB has 
documented a few good reasons as to why that is in a soon to be published RFC.

The only existing proposition is ML-DNS. As a precaution, I asked 
everyone(WG, AD, IESG, and IAB) if they wanted to take over its 
investigation and documentation. I am now left with the hot potatoes. 
IAB will only further discuss the problem...


  4. Present situation

ICANN owns the IANA and the root system. Google has the power to 
influence the IANA and the root file and replace the root system in 
many people's lives. IUsers do not need any of them, and the 
possibilities open to them are very large. However, there is a need 
for experimentation first (what we investigate with an Intertest 
project using the Internet as its own test-bed (as proposed by ICANN 
in its ICP-3 document).

Everyone wants stability + something contradictory with the others. 
ICANN wants to retain control of naming; Google wants to retain 
control of information processing. IUsers object to control except 
for in identificative naming (vs. designative and appellative), but 
they would like for it to be nationally controlled.

  jfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20100910/90a4e084/attachment.htm>
-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance

Translate this email: http://translate.google.com/translate_t