Re: [iucg] [governance] ICANN declined Bulgarian IDN fast-track reques, etc.

[Francois Demay <[e-mail]>]

Dear all

I suppose that we should read Bulgaria, since Romanian is using the Roman
alphabet  while indeed Bulgarian makes use of the cyrillic one!

Република България beeing the name of Bulgaria written in Cyrillic, one can
imagine many ways to choose a label:

бя
блг

etc.


François Demay

2010/5/29 JFC Morfin <[e-mail]>

>  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 [e-mail] 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 [e-mail] mailing list as well as under the
> supervision of the [e-mail] 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 [e-mail] (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 [e-mail] 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, [e-mail] 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,  <[e-mail]> 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, [e-mail] 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, [e-mail] 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
>
>
> _______________________________________________
> iucg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iucg
>
>


-- 
François Demay

Ancien élève de l'Ecole Normale supérieure (Ulm, Sciences)
Ancien responsable éditorial d'Encyclopaedia Universalis, des Ouvrages
Larousse et de Microsoft-Encarta
Consultant, spécialiste en édition (papier et électronique) et traitement de
l'information  (lexicographie, terminologie, toponymie, encyclopédie,
indexation, structuration, classification, catégorisation, recherche
documentaire)
Membre de l'agence de maintenance de la norme ISO 3166
Membre de l'agence de maintenance de la norme  ISO 15924