> >>p.s. Jefsey, the only relevant WSIS message here is that blindly > >>going off and enthusiastically implementing and deploying IDNs > >>(or IRIs), without consideration of these issues that have been > >>well-understood for years, puts users at risk to the point of > >>being irresponsible. That doesn't imply in any way that IDNs > >>are bad, only that one needs to consider the systems of which > >>they are a part, do registrations and implementations with > >>appropriate safeguards and user education, and that handwaving > >>is not a sufficient way to address the issues. And, again, that > >>is very old news -- to the extent that, if the WSIS process and > >>contributors don't understand it, it is a problem with their > >>processes.
Dear John,
we are in full agreement here. The way I see the things is that we had an erroneous approach of the demand for vernacular support, starting with domain names, but continuing with IRI, langtags, exchange spaces, address deployment, usage architecture, user support, etc.. This results from a non-multinational culture of the ISOC/IETF. None of us will change the world, and this is why the IETF has to live with a demand it does not fully understand (or even accept) and the world with the IETF (unless it blows it). But we can contribute in having the IETF accepting the world (hence my clumsy efforts to internationalize it, to include some form of market study/user validation in its deliverables production process), and in having the world - as you say - to understand that the IETF deliverables are not turn-key solutions. The MINC has understood it and prepared as test-bed. ICANN had understood it and requested an IETF supervised DNS experimentation, I think I was alone in carrying, with a few 30 European test root servers organized in three root trees (dot-root program), respecting and adding to the ICANN test criteria.
In that context we have to try to make our best to permit usage to survive and develop in guiding it. IETF "how to's" are the BCPs. They carry some real weight (this is why I do not want them to become confusing as the proposed RFC 3066bis Draft). All what we can do is to advise on how to protect the users against the IDN dangers, and to put this into the perspective of the drastic DNS (and network usage architecture) changes we start facing (just to stay in the naming issue).
1. a domain name is an IP (mnemonic and portable) alias. Period. This has been confused a time with the introduction of the HTTP.1.1 "virtual NAT" (the domain name contributes to the routing within the host). This confusion has been made "ICANN community correct" with the huge commercial mistake of Verisign which did not understand that in keeping the alias line they could have sold ten times more Domain Names (ten aliases per web site) and open a seamless road towards multilingualism (as they did start doing it with James Seng's i-DNs initial effort). But probably M$ IIS limitations did not help. Now, with IPv6, DNs can resume their unique alias role, and users will be able to call their favorite site with their own decided "keywords". I have entered the ICANN site IP in my Hosts.txt file and I use to type "nuts" to get to their site. All over the world we will have ML hosts.txt maintained alias lists, supported by LDAP servers or daily updates. There are 40 millions of DNs, but how many are you using on your real life externet (the external resources you are interested in)? May be 300 a year (look at your favorite menu). Hosts.txt is much faster and reliable and easier to maintain with a specialized support - it comes with built-in parental protection and anti-banners firewalling. Question: how are you going to maintain some kind of order into this, IRI wise, IPR wise?
2. the directory applications (there are the DNS, Handles, the RFID, the OID, etc. etc.) need to have some stability and references. The DNS governance (what the WSIS confuses in part with an "Internet Governance") needs some more serious management than what IDN permits.
- Internationalization is a first step (and I continue to say that a DN should depend, from TLD to nLD, on a unique lang5tag, every possible special case being permitted but flagged - there is not only homograph problems, but also typos, signaling, etc. that are not supported). [lang5tag are the ISO related lang3tag proposed by the "RFC 3066bis" Draft made flexible and operational in adding a style (default: IDN table) and the authoritative source of the associated rules, dictionary, etc. (default ccTLD Manager)]
- But multilingualization should have been supported - that is the real language support and its constraints. A lot of work should have been achieved on virtual DNS zones to permit lingual [or others] co-registries, related to a lang5tag for example.
- Vernacularization (the real users' [human and telemated services] needs support) is much more complex: I think it can be supported by the DNS and some extra tools like access engines (access decision upon a fuzzy name).
All this, the adaptation of the existing solutions and the development of a new vision can be carried by the IETF, or elsewhere. The IETF to say, and to say _now_ as the WGIG conclusion will most probably create a momentum in favor of IETF or not. The inability of ICANN (read their strategic plan) to even perceive this demand probably means their inability to support it. This means that the IETF is also to find a new way to organize the naming intergovernance and make it work. Many conflicting entities are going to be freely involved: the alt root experience should have helped). Solutions are to be found, quick, in order to prevent the mess (naming can become worse than spam).
At least we should start in stopping mistakes. The RFC 3490 limitations over TLDs, the IRI lack of clear support of "ML.ML" names, the "lang3tag" confusion over what the IANA is (not an ISO repository but an Internet protocol parameter clearing house). Then we should word a clear demand of guidance to the IAB over the Multilingual Internet the world wait for, and drastic architectural changes, starting with the distribution of the IANA function, rather than its survival protection control by ICANN.
Figures may help to understand the WSIS problem and the lacks of adequation of the current support of its IAB/IETF main technology provider. There are may be today 850.000.000 of Internet non permanent web watchers and spam sufferers using an end to end architecture, with may be 50.000.000 DNs and 97.5% of illegitimate DNS root calls. We are looking how to support within 20 years (or far less in terms of options and capacity) an extended services, broad bandwidth continuity and interpersonal brain to brains (cpu2cpu) ubiquitous and 24/365 space of secure, reliable, fast privacy protected multiexchanges involving 20.000.000.000 stations, 7.000.000.000 users, probably one or two terra names and more numbers and RFIDs, using 7620 languages (ISO last current count), 20.000 dialects (last non-ISO very very reduced count), for 42650 business areas (last UN count) most proximity services networks, in full respect of national, business, personal privacy, empowerment and sovereignty and support of States regalian services, at a cost and an intergovernance complexity the world can foot.
Question is: does the IETF respond the RFP or not? jfc
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf