[governance] ICANN declined Bulgarian IDN fast-track

[teleanu sorina]

Hi!
I am quite new to this list, but during the last couple of days I have been following the discussions on Bulgaria's application ...
The e-mail bellow is at least confusing to me... Is it about Bulgaria or about Romania? Although we are neighbours, we are not the same country... And, to my knowledge, there has been no application from Romania for a IDN ccTLD (we use the Roman script, afterall).
Some clarifications would be helpfull.
Thanks a lot.
Sorina Teleanu(Romania)

--- On Sat, 5/29/10, JFC Morfin <jefsey at jefsey.com> wrote:

From: JFC Morfin <jefsey at jefsey.com>
Subject: Re: [governance] ICANN declined Bulgarian IDN fast-track
To: governance at lists.cpsr.org, "gerard lang" <gerard.lang at insee.fr>, workon at idna2010.org
Cc: newprep at ietf.org, iucg at ietf.org
Date: Saturday, May 29, 2010, 2:35 PM


 
Dear all,

 

This mail follows from the apparent ICANN denial of the IDNccTLD U-label
that was chosen by the people and government of Romania. 

 

Introduction

 

1. This mail comes after years of ICANN’s active lack of preparation of
the only ICANN concern in the WSIS' Internet. ICANN’s role, as assigned
by the USG, is (1) a coordination of the cooperative governance and
adminance of the so-called legacy "root file" and its (2)
relations with RIRs (ICP-2). The rules to apply are defined in RFC 1591
and ICP-1. Their evolution is defined in the long forgot ICP-3. 

 

ICANN improperly considered the issues created by the IDNA, in which its
positions are:

 

- unfit to match the IDNA2008 context, 

- intrinsically foreign to the so-called IDNA2010 (practical application
of IDNA2008 on the user side) 

- and IDNA2012 (administration, operations, maintenance, and future of
the IDNA2008/IDNA2010 system).

- In particular, ICANN is ignorant of the constraints imposed by the
virtual root open unique matrix ("vroum") evolution.

 

2. This is why this mail is copied to those who have, or have partly,
omitted the actual responsibility to address this point in conformance
with the Internet design/architectural consistency principles as defined
by RFC 1958, 3439, and IDNA2008:

 

- the governance at list.cpsr.org mailing list (Annex 1 - debate on the
list) where the Romanian question was raised.

- the Chair of the ISO 3166 maintenance agency that decides on ccTLDs
(RFC 1591, ISO 3166, and ICP-1) and ICANN is one of the ten members for
that reason.

- the IDNA2010 working list on the practical user implementations of the
IDNA2008, not yet published, RFC set.

- the IETF WG/NEWPREP that is under preparation (Annex 2 - Mail on the
Internet Users preliminary questions before a possible Stringprep
replacement cooperative work is to be carried out).

- the Internet User Contributing Group.

 

3. This mail and its annexes will be attached to my appeal to the IAB
that is under preparation prior to June 7. This appeal discusses the
fundamental issues created by the lack of an IESG warning to the
community in general, and to ICANN, in particular, due to the technical
impossibility and risks of running a testing project such as FAST TRACK,
especially if it only involves non-roman IDNccTLDs instead of temporary
IDNgTLDs that are selected at least for their technical neutrality to
phishing.

 

4. This mail must be considered in the IDNA2008/FAST TRACK/Internet Users
triangular context. As emphasized yesterday in my mail to brother at arms
George Sadowsky: (in ANNEX 3), in this domain, ICANN is technically
impaired, its BoD is unaware of the Internet Users’ world, and its CEO is
politically nimble. 

 




TECHNICAL SITUATION SUMMARY


The IDNA2008 success is based upon the fact that no "MUST"
affects the users. Therefore, the Use side can be entirely flexible in
the way it matches the Network side limitation in transcoding the user's
presented characters in what IDNA may accept (this replaces stringprep).
However, there MUST be a way for this flexibility to be organized among
users. Otherwise, the way a domain name is mapped into an IDNA2008
conformant U-label in a browser may differ from the way it is mapped in
another one. 

 

An attempt to document this has shown that it was possible, which in turn
permitted the IDNA2008 consensus. That attempt was consensual at the WG
(some considering it as the response, others - like me - as a default
guidance). This is why the Area Director did not accept it and the
document was declared "dead". Here is the final wrap-up on the
matter by Vint Cerf (WG Chair) and Lisa Dusseault (Application AD).





<quote from Vint Cerf, Chair>

"Although the last poll regarding the "mappings" document
seemed to show that most respondents wanted to proceed with submission to
the IESG, the AD felt that there were mapping issues not addressed to her
satisfaction. We were unable to agree on a version of mapping that would
satisfy all concerns among the AD and editors. Reference to TR46 seemed
to be desired by the AD but as you see from Patrik Faltsrom's detailed
review of that draft document, there is much to discuss and debate. In
the end, the only way forward seemed to be to declare the WG
"mappings" document to be "dead" and to allow a
version of it to be submitted for publication as an independent
submission.

vint"

<end of quote>




<quote from Lisa Dusseault, AD>

"To answer the question about my concerns, I was particularly
worried about client implementations of mappings: the WG consensus call
indicated that those who had plans to implement mappings, planned to
implement TR46 rather than the WG product.  


"The WG had a lot of discussions a year ago about whether to leave
mappings as a free-for-all and what I heard at that time was that a lot
of people saw the value in consistent mappings across implementations --
so a user going from one browser to another, or from email to a browser,
won't be surprised at where they end up.  Unfortunately, we didn't
arrive at a conclusion that provided that consistency, with one set of
mappings proposed by the Unicode Consortium and another set proposed by
this WG.  I still hope for Unicode and IETF participants both to
work on understanding why there are conflicting requirements and gain a
realistic view of what is likely to be implemented (and over what
transition period).  So, work can continue thanks to individual
contributions and reviews, or even through the possibility of a future
WG.


Lisa"

<end of quote>


Such a work does/will continue:

 

- through my appeal to IESG/IAB for the needed clarifications and
guidance and then the IUCG workon at iucg.org mailing list as well as under
the supervision of the iucg at ietf.org mailing list.

- the WG/NEWPREP preparation in order to discuss a consistent stringpreps
convergence

- possibly through the “locked” ICANN WG/IDNA, as Vint Cerf initially
proposed it and Internet Users opposed it, since they do not feel that
they are represented by ICANN.

 

This work still to be done is actually what FAST TRACK should mainly
test. So, FAST TRACK is a political way to make believe it was carried
out and to influence or to block it. The rest of FAST TRACK is to test
the ICANN IDNcc/gTLD selection and deployment process.

 

 


NETWORK NEUTRALITY

 

The main problem that Internet technology meets is to sustain network
neutrality for all, that is: no one can be technically privileged for
whatever reason. 

 

1. The Internet had a linguistic bias. The task of reducing that
architectural bias was started with IDNA2003.

 

2. IDNA2008 represents impressive steps ahead in that direction: one of
them is to have IDNA disconnected from Unicode, while using Unicode
codepoints to document the Internet User character set. This means that
whatever the variations on the Internet use, the Internet DNS technology
will remain unaffected. Since this is the part that ICANN is involved
with, it means that there is _nothing_ to be tested related to the
Internet.

 

3. However,

 

3.1. IDNA (on the user side and general adminance) is not completed,


3.2. Its architecture is questioned by the IAB and the Applications AD,


3.3. Several Internet users’ sides are developing more or less actively
RFC 1958/3439 and IDNA2008 conformant open alternatives, 

3.4. Its punycode algorithm has not unified/simplified the Internet
linguistic support. 

 

This means, in other words, everything that FAST TRACK is supposed to
test (i.e. not the technology but the use of the technology) has not been
agreed upon or documented yet.

 


Rod Becktrom's action, therefore, tends to replace the Internet
linguistic technical bias, by an Internet ICANNistic political bias,
before the IETF, industry, standards, and users agree that the time has
come for a new naming paradigm - where ICANN and its "naming
industry" seek to continue to be a part of. 

 

There are many new architectural features, possibilities, and
opportunities opened by IDNA2008 that will put Internet neutrality into a
new perspective. In that perspective, it is entirely possible to navigate
an immensely extended Internet (and its service and semantic
continuations) without using a single root server system - from ICANN or
any other root system. This means that no one can impeach Romanians from
choosing and operating the xn-- tld that they want and to safely
interoperate on the Internet - even if some of their customers start
getting Brazilian friends and business by error. They will just not pay
ICANN for what is worth $10 a year (registering a single DN).

 


THE GRASSROOT SOLUTION WE (USERS) NEED AND WORK ON


This means that other solutions/agreements/behaviors have to be
found, documented, experimented, deployed, supported, and collectively
operated, if possible after negotiation with all the stakeholders of this
new game. You are welcome to join workon at idna2010.org
(
http://idna2010.org/mailman/listinfo/workon_idna2010.org) in order to
start discussing this issue.

 

The basic need that we have, and are working on, is a tool that is able
to support network linguistic neutrality on the user side, which is the
equivalent of  as how IDNA2008 is currently able to ensure network
linguistic neutrality on the network side. This means that IDN should not
mean an "internationalized domain name" any more, but rather an
"Internet domain name" differentiating them from other private,
community, and (foreign) technologies interoperable domain names.

 

To achieve this, the rule "first come, first serve" MUST
continue to apply without resulting in possible visual confusion,
phishing risk, and class conflicts. This means that

 

1.  the IDNA2008 charset must be revised in two directions:

 

- to support metadata (such as French majuscules) in order to not occlude
any orthotypography

- to be visually coded: this means that visual sorting and indexing do
match. It also means that the Internet has its own charset where
codepoints (Unicode) are regrouped by “visual equivalence codes” and
registrations are “netically” (per netiquette) made on a first come first
use basis (1) in using this Unisign/Unigraph (name it the way you want)
charset (2) exclusively reserving the “two 0-Z” table to ISO3166 (3)
other stringprep processes ranging from IETF technology to banks, police,
IDs, etc. converge towards the same code standard. (this means that we do
not speak anymore of “o”, “cyrilic o”, “omicron”, but of “half-size
circle on the bottom line”.

 

2. the namespace governance is to be renegotiated before unilateral
confusing decisions are taken by local, cultural, trade groups, or
mafias...and by private Internet Users. This is to jointly explore all of
this (rather than imposing a grass-root free of charge, but messy,
system). Therefore, we created the workon at idna2010.org mailing list
(
http://idna2010.org/mailman/listinfo/workon_idna2010.org)




The internet is an open @large place without monopoly but with
alliances.

jfc





ANNEX 1 - Debate over the ITLD Romanian request.


At 20:09 28/05/2010, krum.jonev at dir.bg wrote:

Hello,


I am new to this list, but I would like to bring to your attention an
issue that recently appeared in Bulgaria.


The Ministry of Transport, IT and Communications announced that ICANN has
declined the Bulgarian application in the new IDN ccTLD fast-track
process, as the proposed string .бг looked too much like the existing
ccTLD of Brazil (.br).


However, the people in Bulgaria that are in favor of introducing an IDN
ccTLD are practically mad of this decision. A few user groups sent
protest letters to the Ministry, advising them to appeal the ICANN`s
decision. Others just sit and doesn't know what to do.


Therefore, I am looking for your opinion on those questions - do you
think that the string .бг "presents an unacceptably high risk of
user confusion" with .br (as said in ICANN reply); and does Bulgaria
have any chance if decides to appeal, as this is the desire of the
majority of the Internet community? There were even two proposals of
imposing a requirement for the IDN ccTLD registry, to allow only
registration of domain names that contain an unique Cyrillic letter - in
this way, all similarities would be avoided.


Thank you in advance for you time.


Kind regards,

Krum Jonev

At 20:13 28/05/2010, McTim wrote:


Hi,


On Fri, May 28, 2010 at 9:09 PM,  <krum.jonev at dir.bg>
wrote:

> Hello,

>


<snip>


> Therefore, I am looking for your opinion on those questions - do you
think

> that the string .бг "presents an unacceptably high risk of
user confusion"

> with .br


yes


 (as said in ICANN reply); and does Bulgaria have any chance if

> decides to appeal, as this is the desire of the majority of the
Internet

> community?


maybe, is there an appeals process for IDNs?


-- 

Cheers,


McTim

At 20:24 28/05/2010, Hong Xue wrote:


Thanks for the information. Is
it a formal "announcement" of ICANN? I

cannot find it on ICANN website. Or, is it only an outcome of string

evaluation? In the latter case, you may wish to further communicate

with ICANN. The restrictive registration policy you mentioned may

somewhat erase the concerns of user confusion. But domain names are

accessible globally. An IDN string non-confusing to local 
community

might inflict phishing in other part of the world.


Well, we are right in the mud of how to evaluate "confusingly

similarity" between IDN scripts and Latin scripts.


Hong

At 22:28 28/05/2010, Yrjö Länsipuro wrote:

Hi,


Would there be another meaningful Cyrillic string that would stand for
Bulgaria? After all, in many cases IDN ccTLD's are not exact
translitterations of the ASCII ccTLD, since in many languages/scripts
such abbreviations don't make sense. 


Please note, too, that Russia could not have a Cyrillic translitteration
of .ru, because it would have been identical with ASCII .py
(Paraguay)


Best 


Yrjö Länsipuro

At 23:00 28/05/2010, krum.jonev at dir.bg wrote:


Hi,


.бг is the most meaningful representation (was selected with a full
consensus between all interested parties) - and the local Internet
community doesn`t want to give it up without at least an "appeal
attempt" from the government.


Now we are trying to make the government communicate with ICANN and
actually do something. That`s why I wanted to ask if we should appeal -
maybe write to ICANN ombudsman, etc. However, there isn`t any formal
appeal process for the decisions taken in the string evaluation
part.


Among the proposed other options are .бгр (first association is
Belgrade, not Bulgaria), .бул (first association is "bull")
and .българи� (which is ridiculously long for a tld).


There are more and more oppinions that any other IDN ccTLD string will
"kill the idea", and even some people say that if we can not
keep .бг, its better for Bulgaria not to have an IDN ccTLD at
all.


Regards,

Krum

At 23:10 28/05/2010, Avri Doria wrote:


On 28 May 2010, at 14:13, McTim
wrote:


> 

> 

> (as said in ICANN reply); and does Bulgaria have any chance if

>> decides to appeal, as this is the desire of the majority of the
Internet

>> community?

> 

> maybe, is there an appeals process for IDNs?




was it already subjected to the extended review?


I don't know if there are any appeals from IANA decisions, but if there
are, it is the ICANN Board.


a.

At 23:30 28/05/2010, Karl Auerbach wrote:


On 05/28/2010 11:09 AM,
krum.jonev at dir.bg wrote:


The Ministry of Transport, IT
and Communications announced that ICANN

has declined the Bulgarian application in the new IDN ccTLD
fast-track

process, as the proposed string .бг looked too much like the
existing

ccTLD of Brazil (.br).

The standard of "presents an unacceptably high risk of user
confusion" is entirely subjective.  Normally those kinds of
choices need to be refined over the years by building a set of principled
decisions, decisions that express their logic, rationale, and weighing of
the competing interests.  However, ICANN is rather week when it
comes to building compendiums of principles to guide these
choices.


I have my own TLD, .ewe (not in the ICANN root - see

http://eweregistry.cavebear.com/ - it's a prototype, not active) -
Anyway, some say that it is too close to .eu to which I sheepishly answer
with this question:


   Which came first, female sheep or the European
Union?


One could get into endless arguments about which came first, Bulgaria or
Brazil.  And they would be fruitless arguments.


But such arguments would reveal a meta issue: Why should Brazil get
automatic priority, why is .6r considered as causing an unacceptable
confusion to people using .br.  Why is the question not put the
other way around, i.e. might .br be unacceptably confusing to users of
.6r?


If the principle that we pull from this is "first in time, first in
right", then fine.


But what then do we say to people who have been using or advocating
certain TLDs for a long time, such as IOD's 2000 proposal to ICANN (for
which IOD paid ICANN a $50,000 application fee) for .web, and what about
the .biz that was in existence and operating before there even was an
ICANN?


And how does the standard of "user confusion" fare when faced
with the increasing technical and cultural reality in which domain names
are fading as visible identifiers as opposed to address books, shortnames
(e.g. .ly, tinyurl, etc), facebook logins, twitter ids, etc etc?


Perhaps that standard is more the creation of the overheated mind of some
trademark lawyers who, like the old monarchs of Spain and Portugal, are
out to plant their flag of ownership on everything than it is the result
of a reasoned, but perhaps transient, choice among actual users on the
rapidly evolving internet?


The argument of "unacceptable user" confusion could have been
levied against the internet back in the 1970s when there were a
multiplicity of different email systems.


And US telephone users are routinely confused by country codes on
telephone numbers.


The point is that confusion of some degree will always exist, we ought
not to hold back progress because some people can't handle the
"future shock".


          
         
--karl--


At 23:34 28/05/2010, Milton L Mueller wrote:

Content-Transfer-Encoding:
base64> -----Original Message-----

> 

> Therefore, I am looking for your opinion on those questions - do
you

> think that the string .бг "presents an unacceptably high risk
of user

> confusion" with .br 


No. I don't have any trouble distinguishing between a 6 and a b.



> and does Bulgaria have

[žHÚ[˜ÙHif decides to appeal, as this is the desire of the majority

> of the Internet community? 


ICANN has no formal accountability mechanisms. This is a problem for all
of us, not just you.

However, if by appeal, you mean, "Can I get my government and a
bunch of other powerful people to make enough noise to scare ICANN into
changing its decision, it is possible. But that is about the only option
you have. 


> There were even two proposals of imposing a

> requirement for the IDN ccTLD registry, to allow only registration
of

> domain names that contain an unique Cyrillic letter - in this way,
all

> similarities would be avoided.


Some 


At 00:35 29/05/2010, Lee W McKnight wrote:

Re appeal process or lack
thereof:  if there are no rules, then however you play the game must
be fair.


And while partial to .br for many reasons, I can't imagine why people or
machines would confuse b with cyryllic script regularly. 


 In fact it would seem o be a rather low probability action for
either people or machines to get the 2 confused.


So my 2 cents: go for it.


Lee

At 01:28 29/05/2010, Desiree Miloshevic wrote:




On 28 May 2010, at 21:28, Yrjö
Länsipuro wrote:


Hi,


Would there be another meaningful Cyrillic string that would stand for
Bulgaria? After all, in many cases IDN ccTLD's are not exact
translitterations of the ASCII ccTLD, since in many languages/scripts
such abbreviations don't make sense.  is .бг is less
similar to .br then .бр would be?


User's confusion with IDN strings in general, not just with Cyrillic and
ASCII,

is one of expected "by-products", as well as one of many
trade-offs we have to live with.


Desiree

At 02:45 29/05/2010, Avri Doria wrote:


On 28 May 2010, at 18:35, Lee W
McKnight wrote:


> 

> And while partial to .br for many reasons, I can't imagine why
people or machines would confuse b with cyryllic script regularly. 

> 

> In fact it would seem o be a rather low probability action for
either people or machines to get the 2 confused.

> 




not that gtld review criteria have any relevance to idn cctld evaluation
that i know of. 

but:


and if they were to follow the criteria, untested as they are, for new
gTLDs, then it is not the possibility of confusion that counts but the
likelihood of confusion.  and one could ask how many Bulgarians or
others  were likely to be confused.




> 2.1.1.1.1 Review Procedures

> The String Similarity Panel’s task is to identify visual string

> similarities that would create a probability of user

> confusion.


...


> Standard for String Confusion ­ String confusion exists where

> a string so nearly resembles another visually that it is likely
to

> deceive or cause confusion. For the likelihood of confusion

> to exist, it must be probable, not merely possible that

> confusion will arise in the mind of the average, reasonable

> Internet user. Mere association, in the sense that the string

> brings another string to mind, is insufficient to find a

> likelihood of confusion.




so the question is, does it meet these conditions?  if so, i would
suggest standing down.


on the other hand if people who know what they are talking about can
attest that there is no probability of confusion, you might have 
leg to stand on. 


but again, new gTLD draft criteria don't really hold a lot of water, just
a place to start a discussion.


a.

At 04:10 29/05/2010, Norbert Klein wrote:


Yrjö Länsipuro wrote:

>

> Would there be another meaningful Cyrillic string that would stand
for

> Bulgaria?

Why look for another string? It is first of all those who stand for

Bulgaria who decide what shortcode to use in the code that stands
for

their country, in their script. (Unless there would be an exact
double

rendering like .ru  ->  .py.)

> After all, in many cases IDN ccTLD's are not exact
translitterations

> of the ASCII ccTLD, since in many languages/scripts such
abbreviations

> don't make sense. 

>

> Please note, too, that Russia could not have a Cyrillic

> translitteration of .ru, because it would have been identical
with

> ASCII .py (Paraguay)

This reference is not appropriate, though an often used irrelevant

example: ".ru" was probably made from the English word
"Russia" (as a

two-letter ISO country code - like .hu stands for Hungary and not
for

Magyarország in Hungarian) Russia would not have used ".py"
(then an

English abbreviation in Cyrillic script - "Russia" with an
"u" is anyway

different from Ро��и� with an "o"). What was chosen in
Russia is a

Cyrillic rendering of the "Russian Federation" - рф (Ð
у��кий федерации).


To say that .бг is similar to .br would only be understandable if
the

many ICANN reservations and exclusions for "confusingly
similar" would

also include the "visually impaired" (I am - but I still see
the

difference)...




Norbert Klein

(living in the Bulgarian Embassy in Cambodia)

At 10:54 29/05/2010,
Kleinwächter, Wolfgang wrote:

Dear List,

 

I encourage the Bulgarian friends to be more innovative and just to
respect that .bg in cyrillic is confusingly similar to .br. When the
Russian started to discuss their string in cyrillic, their first choice
was .ru in cyrillic, which was confusingly similar to .py, the ccTLD for
Paraguay. There was a strong group in the Russian Internet community
arguing in favour of .ru in cyrillic as an issue of "sovereignty and
pride of the national Russian community". The argument, .ru is owned
by Russia and not by ICANN, was used in some heated debates. However,
constructive consultations between ICANN and the Russian community led to
the .rf cyrllic code (which stands for Russian Federation) and now
everybody in Russia is happy to have it. Even President Medwedjew likes
.rf. Probably the Bulgarians will find a nice code which allows them to
keep the national pride and to accept that you should avoid to confuse
users (which than often is misused by all kinds of bad guys).

 

Wolfgang




ANNEX 2 - Response of JFC MORFIN to George Sadwosky on Rob Beckstrom
affirmation that ICANN is a nimble organization.




At 11:33 AM +0200 5/28/10,
JFC Morfin wrote:

At 16:37 27/05/2010, George
Sadowsky wrote:

Bertrand,


Given Adam's comments below, perhaps you would be willing to suggest some
concrete areas in which ICANN could be more nimble (or choose your own
adjectives) while ensuring responsiveness to community
inputs.

George,


I am sorry, but no one could be more nimble than our current ICANN
CEO!


Nobody else, including IESG, IAB, WG/IDNABIS and its Chair (Vint Cerf),
Application AD, etc. was aware that/how IDNA2008 can be tested by users.
The real ICANN break-through is that  from Rod Beckstrom on, no
technology is necessary anymore for the ICANNet to expand and offer new
technical services.


jfc

At 13:51 28/05/2010, George Sadowsky wrote:

JFC,

This is an unhelpful comment.  First, I can't understand what you
are saying.  Second, I sense a high level of sarcasm that occludes
the meaning.  Third, it is devoid of constructive suggestions. There
is an old Quaker saying that I recommend to you.  "Don't speak
unless you can improve upon the quality of
silence."

Dear George,


I chair the Projet.FRA for a French speaking space, a language that - as
you certainly know - IDNA occludes the semantics. This may explain that I
also found some typos in your "don't speak when eating your oatmeal
cereals unless ICANN improves their QoS" commercial. I did enjoyed
the pun: Quicker! ICANN the Quaker (netquake nimble survivor?)!


OK, after som fun, let's turn serious now. I am not here to help, but
rather to negotiate.


Now, I must say without sarcasm, but with sadness, that this is a very
helpful comment of yours. It explicitly documents that ICANN board
members have not yet realized that "their" ICANN does not
belong to the same world as the Internet Users' world and that they are
not even trying anymore to understand what Users are saying when they
contribute. In addition, they jump to negative conclusions and engage in
unproductive reactions (something of which you did not get us used
to).


In the Internet Users' world, technology comes first because it says
whether things are possible or not in a network made of bandwidth,
protocols, and machines. In ICANN's world, political beliefs come first
and says whether the intellectual network of contracts, media releases,
reports etc. is credible enough to support the stakeholders'
agenda.


ICANN is obviously not nimble. However, Rod is. What he says is
technically absurd. However, it is politically credible.


Up to now, politics and engineers went roughly along together because
they made a couple that roughly shared a common knowledge of what the
other one thinks the network is (cf. Karl's post).


I am afraid that this has definitely changed on January 7, 2010. On that
day, the IESG approved IDNA2008, (1) under the pressure of Rod's press
announcements - cf. WG/IDNABIS Chair (Vint Cerf)'s mails on this, and (2)
after having considered what the Internet Users' resulting technical,
adminance, and governance moves will be
(
http://www.ietf.org/id/draft-iucg-afra-reports-00.txt). In addition
to technology and politics, use (and adminance, i.e. what decides on the
possible use) is now a real component of Internet life.


Therefore,

- on the one hand, ICANN is pretending to test something that is by far
not released yet and refuses to discuss the way that it could be worked
out, even under its proposed "technical leadership" (?),

- on the another hand, the entire IETF process (IAB ongoing work, AD
oppositions, regular IETF appeal procedure) definitely refuses to
consider the ICANN moves as having any technical importance.

- and the rest of the body (users' use) has now been set technically free
to go where it wants.


In this situation,


- ICANN staff and contributors have fully shown their inability to make
the ICANN situation internally understood and to cooperate to reach a
solution.

- IETF has to decide if usage architecture belongs to its scope or not: I
do not expect to have a fully documented and digested IAB answer before
the end of the year.

- Internet Users comprise three main general categories: (1) active users
(this kind of governance lists) (2) end users (we never hear from them
but they vote with their dollar bills), and (3) lead users who face and
have to admin any new problems first. Lead users now have an
architectural place in the Internet and a technological/governance
empowerment capacity. This is not a couple anymore but rather a
trio.

- The stakeholders at this stage are mostly Unicode/ISOC/Google
led


ICANN actually faces the choice that Rod alludes to:


- either to ossify the de facto ISOCANN enhanced co-operation (UN support
could help but would probably lead to politico/technical
confusions),

- either be de facto replaced by the long planned DNSSEC oriented USG
emanation

- or to be identified with a "nimble Rod" able to contribute
with swift responses in negotiationsor power conflicts on behalf of the
current stakeholders' IN class and USG's DNSSEC strategy.


IN Class commercial and DNSSEC political interests will resist rogue
users wandering around for a certain time. IDNA, not. Nimble Rod's IDNA
"make believe" action certainly is what currently protects
ICANN in that area. The best for all strategy of which ICANN can follow
is:


- to support Rod,

- make him informed so that he has a better command of the issue,

- make him negotiate the best way out/compromise in the interest of the
IN Class, stakeholders' Group, and USG's DNSSEC strategy - before the
Internet is shacked by the malignant uses of the IDNA2008 implied
Internet architectural extensions.


ICANN's mistake was to unfairly favor a few IDNccTLDs over IDNgTLDs, and
to not ensure that they themselves understand first as to what IDNA2008
really is.


I regret that you chose not to
provide a constructive response to my query.

As you saw, I did provide you and ICANN with a pair's response. The ball
is now in your field. After several other board members, you will not be
able to claim  I did not warn you. Anyway the Draft is public as if
my IESG appeal
(
http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf), the IESG
response
(
http://www.ietf.org/iesg/appeal/response-to-morfin-2010-03-10.txt)
and will be my IAB appeal in a few days and the IAB response.


Best.


jfc




ANNEX 3 - IUCG clarification requirement concerning the IETF/NewPrep
project


As you know, as Internet
Users, we believe IDNA2008 represents several major achievements. One is
to uncouple the Internet and Unicode while succeeding in using ISO 10646
Unicode generated tables. This is a double big step ahead:


-          giving the
Internet its own independent charset.

-          advancing towards
a better transtechnology/usage operational scripting methods
unification.


However, IDNA still has to document three major issues that affect
stringprep and definitely disqualify any further involvement of Unicode
in the network support of strings:


-          lack of support
of orthotypograhy (i.e. language script syntax)

-          the multitude of
"stringpreps" functions (at least one per ISO 639-6 linguistic
entity) that are now to be specified on the users' side.

-          how they will be
administered together (what will then also concern
"newprep")


This is why what you call "IDNA" (just what is IDNA DNS layer
related, not what will be User layer related) also cannot qualify at this
stage. Everything is to be discussed together; the different stringpreps
are equivalents to additional languages with their own
orthotypographies.


Now, as users, we have a different, more pragmatic approach that goes
further and does not call on this endless kind of discussion. This is
because as Internet lead users we are more interested in forward
compatibility (i.e. with our needs, innovation, and simplification) than
in backward compatibility (installed basis).


In a technological evolution, those who were in advance knew that their
solution might not be final. Cf. RFC 1958: the fundamental Internet
architectural principle of constant change. The second main architectural
Internet principle (RFC 1958 and 3439) is the principle of simplicity. We
are not interested in several stringprep solutions due to historical or
partial technical analysis. We are interested in a stable, unique,
comprehensive manner to format strings in the world digital ecosystem,
which is currently mainly under Internet technology that prevents
phishing and sustains a single sorting and indexing order.


This is our architectural target. Our implementation strategy is to help
and use every effort that can help reaching that target, and oppose (IETF
and real world operations) every attempt that would confuse or delay
it.


This is because our main interest is not so much to "influence those
who design, use, and manage the Internet for it to work better",
(without a definition of what "better" may means RFC 3935is
meaningless anyway); our main interest is for us and our partners to best
use the Internet to better suit our common and present-day needs. This
SHOULD be the same. However, experience has shown that it MIGHT not
always be the same.


This is why the best is to clarify this issue from the onset. I was not
responded to when we started the WG/LTRU on langtags and I had to force
the consensus the way we know. I was very clearly responded to in the
case of IDNA and we were able to fully support the consensus.


---


My question is therefore:


-          "a need is
identified by our Internet user contributing party. This need is for a
stable, unique, comprehensive manner to orthotypographically format
prepared strings whatever the script and language. Such a format must
prevent phishing and support a single registry indexing and sorting order
of every possible orthotypographic string, throughout the Internet
protocols, related applications, and interoperated technologies.

-          Is this or is
this not also an immediate or ultimate goal for the AD, WG Chair, and
WG/newprep possible participants?"


Depending on the response given, we will participate and try to help this
wg/newprep effort, or we will pursue our own project, with the ambition
to address our needs while keeping things as interoperable with
newprep-like endeavors as is possible.


I thank you for your time, attention, and response.


jfc 


-----Inline Attachment Follows-----

____________________________________________________________
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


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20100530/e2c46335/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