August 2011 - vip - lists.icann.org

The "Invisible Separator Characters" Issue
by Nicholas Ostler Aug. 23, 2011

Aug. 23, 2011

First of all, I apologize if I am using non-standard terminology. What I mean specifically is this: Unicode code-points that have no specific rendering of their own, but may affect the rendering of neighbouring codepoints in the string. Specifically we have been talking about U+200D ZWJ zero-width joiner and U+200C ZWNJ zero-width non-joiner both of which are actively used for some languages that use the Arabic and the Devanagari scripts. http://en.wikipedia.org/wiki/Zero-width_non-joiner shows that they can also make a difference in German spelling, and in Hebrew. Unicode calls these "special characters", which is not very helpful. People have been talking explicitly about their necessity for Persian and some other Indo-Aryan languages written in Arabic, e.g. behnam(a)esfahbod.info - [arabic-vip] Typographical Complexity of Arabic Script - 19/07/2011 and for Nepali, among languages written in Devanagari, e.g. bkbal(a)ltk.org.np - Re: [Devanagari-vip] Document for Hindi Language based on Policy for ccTLD .bharat - 03/07/2011 By their very nature - these characters, when placed where they would have no effect on rendering, allow identical renderings to be associated with the distinct strings of abstract characters. They go beyond the use of other "combining" codepoints (such as accents and cedillas, which (taken with other neighbouring codepoints) also sometimes result in a glyph indistinguishable from another codepoint), in that they can have this effect on any string of codepoints. So U+0301 [´] COMBINING ACUTE ACCENT combined with U+0065 [e] LATIN SMALL LETTER E can result in a glyph indistinguishable from U+00E9 [é] LATIN SMALL LETTER E WITH ACUTE; but ZWNJ or ZWJ placed anywhere in a string (as long as its neighbours are not combining charactyers) will always give a string outwardly indistinguishable from one without it. Seeing this danger of their use in URL identifiers, (essentially an open invitation to spoofing), the Indian approach was been simply to outlaw them: akshatj(a)cdac.in - Document for Hindi Language based on Policy for ccTLD .bharat - 01/07/2011 However, a less radical, but more complicated, approach, which allows ZWJ and ZWNJ to be used where necessary, is laid out by Unicode at http://unicode.org/review/pr-96.html Public Review Issue #96 - Allowing Special Characters in Identifiers - Revision 3 - 04-19-2007 (It generalizes the issue slightly, to bring in Mongolian separators.) This has involved looking at the use of the characters in a wide variety of languages (going beyond our 5 case-studies) and trying to characterize objectively the environments where ZWJ or ZWNJ could make a difference to rendering, and allow them in identifiers only in these environments. Those concerned about this issue for their languages (notably Nepali, Persian etc.) may wish to consider this approach as a concrete option. -- Nicholas Ostler nicholas(a)ostler.net +44 (0)1225-852865, (0)7720-889319 Chairman: Foundation for Endangered Languages www.ogmios.org Author: Empires of the Word (2005), Ad Infinitum (2007), The Last Lingua Franca (2010) www.nicholasostler.com

5 11

Path towards a multilingalization IUse referent
by jefsey Aug. 22, 2011

Aug. 22, 2011

Dear John, If I supported the IDNA2008 consensus it was because it suited my vision of the Internet architecture. This was a surprise. This meant that it was possible to read as the two faces of the same coin * the 2011 "inside Internet" that the IETF influences and documents. IANA glossary, PRECIS propositions * and the 2011 "outside Internet encapsulation" that we, its users, want to intelligently utilize . ICANN/WG/VIP, IUCG. Actually as the two sides of a smart interface that I call the IUI as: * the Internet Use Interface on its Internet side. * the Intelligent Use Interface on the User's side, because the IUI can also interface the same user with other technologies that will converge at the IUI. As you know this vision of mine raised two main problems:(1) where to document the IUI and (2) the need to experiment in order to correctly document it. ---- 1. My appeals to the IESG and IAB permitted the IETF to answer the first question. The IESG proposed for me to run a BOF about what it considered as research, but the IAB made it clear that the IETF was concerned but that it was not in its bailiwick. My evaluation is that the IUI is an "IUser" (Internet/Intelligent/independent, etc. user) community issue. This community of identified users, should be liaised with the IETF. I use the IUCG for that and the help/support/ideas of its small team. ---- 2. The particular IUI architecture that I investigate is in line with the architecture that I use, support, and have deployed for more than thirty years. 2.1. It is based on my extended systems understanding of: * the way systems, diversity, complexity, and simplicity are articulated (much in tune with the three basic principles of the Internet architecture: constant change (RFC 1958), simplicity (RFC 3439), and subsidiarity (as this results from the IDNA2008 architecture, once addressed the architecturally wrong location of IDNA in applications instead of at the IUI). * the particular case of communications where transmitted contents use static metadata in telecoms, metadata contained in the packet in datacommunications like the Internet, and separated metadata in what I call the metacommunications. IDNA2008 the way it implements the presentation layer in the Internet is at the border with metacoms. 2.2. From experience (Tymnet Extended Services), I think the location of the metacoms support is to be on the user side so that it is transparent to the network use. This is the Internet PLUS architecture, i.e. plugged additional OSEX layers (Extended OSI) on the user side. This layers can also be faked in a centralized manner, and result in the "+" approach: e.g. Google+. 2.3. The way IDNA2008 is designed calls for two necessary moves: * to use the DNS to deliver network oriented metadata, hence by synergy in order to, most probably, probably use DDDS registries for intersem (semantic internet layers above) referent data management and an IPv6 like registry addressing. In any case JTC1/SG32/WG2 is to be carefully considered and I miss the time for that. * a total separation from the Unicode typography that is not able to easily cope with network use requirements and to support human oriented algorithms. This separation does not need to be repudiation. However, the Internet MUST be supported by a network/human oriented universal semiotic system. I think it can start with a graphic (passive) and then a dynamic sign oriented approach in CLASS 0, as a common safe support of the other classes above, including the IN class. ----- 3. The danger of what we found and in such architecture is that it actually is the Internet technology architecture. There is not a single change in the existing RFCs or in a single bit in the existing protocols that is needed. However, there are a lot of opportunities for adjustments and, at the same time, there is major pressure being imposed on the whole architecture and on in particular on the ML-DNS (i.e. an IDNA2008 compliant encapsulation of the DNS). This pressure is the gTLD project of ICANN with its gTLD fee and delays. This may lead to a lot of individual architectural "tunings" to evade ICANN or to protect ICANN; in addition to these "adjustments", such as PRECIS. ----- 4. My first idea was to use the notoriety of ICANN's plans and Google Public DNS to experiment IDNA2008 compliant free gTLDs (like Projet.FRA). Then to proceed from there on, before anyone could try to make a business of it. A quick and dirty move to force everyone to understand where we are, how weak the Internet is IRT the market and sponsors, make people integrate diversity into their network thinking process. For personal reasons you know I was not able to dedicate myself to this. At the same time, I did better explore as to what the very initial visions of the Internet actually brought. Not only the "networking group", but others too. There is a solution I wish to try to revive, if possible in parallel (partial code integration). However, if that solution has been disregarded it is probably because of the complication that the IETF has reached. So the priority for me is to clarify and simplify the model. You already did a lot with IDNA2008, but it is not enough as we stayed (Charter) within the IDNA concept. We have to come back to fundamentals. The Internet MUST be considered from the outside as a unique and simple system (service black box) that is able to support several, and more or less equivalent architectures, on the user side. I agree with John Day: we miss an Internet OS. To implement it calls for a clearer and coherent technical culture. The internet tomography is still to be done. The earthquake is the RFC 5895. It is from there that we need to proceed. In two directions: 4.1. to think, accommodate, test, and deploy a simpler, clearer, etc. Internet of today, i.e. multilingual and semiotic ready (support of passive [as today] but also active and localized content). 4.2. to make sure that the "patches" being discussed in parallel do not conflict and block that innovation. My understanding (bet?) is that, as usual, the single point of simplicity to obtain this is for everyone to use the same language and for the concepts underlying that that language to be open enough so they permit to clearly spell out the "post IDNA2008 possible". This is why I engaged the IUCG to compile all the data, ideas, demands, confusion, etc. on multilingualization (i.e. architectural linguistic neutrality) that are discussed. We are probably still missing many things currently, but we have compiled 73 dense pages. ---- Your misunderstanding about the way we use wikis (as a quickly visible to all mailing archives, that can be translated in the MindMap), has led me to work this afternoon for you. And to build the next step. This still is NOT a document; this is only a next phase IUse community working wiki, located at <http://iucg.org/wiki/Multilingualization_Glossary>http://iucg.org/wiki/Multilingualization_Glossary. This is rough stuff. My intent is to digest it through a clear network ontology and model (ontography) and tune it until its coherent with what the Internet IS and what our IUI MUST be. So that it can become a reference glossary. Obviously, there will be parts that do not belong to the IETF area, but to the IUTF area (the emerging IUse technical TF). That is because of our IUse center of the world is not your IETF/Unicode center of the world. However, we need our common world to entually be unique even if all this takes time to think, adjust; set-up. This is why I am making the place of that work visible to well-intentioned people and why I give my deep thanks to those who help. jfc

3 2

Re: [vip] IDNA and Multilingual Internet issues and vocabulary after IDNA2008
by jean-michel bernier de portzamparc Aug. 19, 2011

Aug. 19, 2011

Dear Mr. Klensin, "we" are Internet and IETF users. This makes a pretty large community. There are three ways one can do it: - in surviving with what we (do not) get. Very large part of our community. - in hacking the internet from the outside on behalf of our right to protect ourselves from digital ecosystem pollution risks. Small part of our community. - in trying to cooperate with you guys and help your inside work with our outside perspective. Microscopic part of our community. Guess why? Please read the begining of your mail. We do it because Jefsey convinced a few of us and the IETF Chair that it had to be tried. However, if the inside Internet is made of individual's and ISOC's copyrights and cannot even be discussed and helped, Jefsey will soon be alone! Please respond: the ball is your field. Tell me: are we wrong trying to work in the open, liaise with the IETF and carry a lot of work to be able to answer you, the happiana, the PRECIS, the VIP people in a consistant way, also with other open works? This being said you perfectly know that this 2011/8/19 John C Klensin <john-ietf(a)jck.com> > without any specific > attribution or acknowledgment. Those materials include several > RFCs and draft-ietf-appsawg-rfc3536bis. is wrong. Your name, your RFCs etc. are quoted as such. We do not publish, we try to draft a pertinent mail to you! > I am an author or major > contributor on several of those. Especially since I had asked > earlier that any compendium of this sort list terms covered in > other documents, comment on them as you thought appropriate, This is correct. But to respond to you, a lot of work must be carried. Beginning with an enlarged scope to other intricate real needs you did not consider yet. Portzamparc BTW I am not French, I am Breton!

1 0

IDNA and Multilingual Internet issues and vocabulary after IDNA2008
by jean-michel bernier de portzamparc Aug. 19, 2011

Aug. 19, 2011

IDNA2008 has introduced the need for post IDNA2008 protocol and technology adaptations in different areas. Several mailing lists are working on such adaptations. There is a need they know the others' targets and they use the same terminology with the same meaning. To that end we have compiled charters and drafts, terminology definitions and propositions from the different souces involved: IAB, IETF/WG/IDNA2008, IETF/WG/PRECIS, ICANN/WG/VIP, UNICODE, IUCG, IUTF, ALFA, IANA and Unicode. The file is http://iucg.org/wiki/IDNS_Common_Glossary. At this stage we would like to continue compiling suggestions to add to this document in order to have a comprehensive consolidation of ideas and terms. Once inputs are stabilized, I will sort all the terms towards an update of the IANA terminology file. I hope it could help reaching consensuses more easily if we speak the same language. Portzamparc

1 0

Educational session on existing variant practices
by Vladimir Shadrunov Aug. 14, 2011

Aug. 14, 2011

The topic of variants isn't new and the issues we are trying to examine here in this group may have already been defined and/or dealt with somewhere on this planet. We have experts from different fields here, and not necessarily all of us are well informed about the existing practices related to variants. Hence an idea: how about holding an educational session for the entire group where we will review how variant issues are managed in: 1. Existing ICANN TLD programs (Fast Track, Applicant Guidebook) 2. IDN ccTLD registries - variants on the top level 3. TLD registries - variants on the second level 4. DNS standards (some background on DNAMEs might be helpful) 5. RFCs that deal with string similarity (4790, 3743 for Chinese, 5992 for Cyrillic, others?) 6. (possibly) Trademark laws I'm happy to contribute to part 3 sharing the .tel experience with managing variants. We support IDNs in 15 languages with different degrees of variant management in Chinese, Japanese and Russian. Would the group support such an effort? Best regards, Vladimir Shadrunov

17 30

Update of the IDNS Glossary
by jean-michel bernier de portzamparc Aug. 6, 2011

Aug. 6, 2011

Just to let you know that the wiki IDNS Common Glossary ( http://iucg.org/wiki/IDNS_Common_Glossary) has been updated to cover: - the ML-DNS diagram - inputs from RFC 6055 - the different positions and problem statements This makes it a rather complete compendium of the post-IDNA2008 terms and propositions. I would be happy with your comments and suggestions. You can use the discussion page or send me a mail. Best Portzamparc

1 0

Re: [vip] IDN Variant Experience Webinar
by Francisco Arias Aug. 5, 2011

Aug. 5, 2011

Yes, all the materials are posted here: https://community.icann.org/display/VIP/Webinar+Recordings+and+Material __ Francisco On 8/3/11 6:44 AM, "Dmitry Kohmanyuk" <dk(a)intuix.com<mailto:dk@intuix.com>> wrote: Greetings all, would presentations be available to non-participants or later viewing? I noticed that Andrzej posted his online, perhaps others are too. Thanks! 01.08.2011, в 11:53, Francisco Arias написал(а): Thank you all the presenters for their help in putting this together: Fahd Batayneh, Iftikhar H. Shah, Behnam Esfahbod, Andrzej Bartosiewicz, Vladimir Shadrunov, Karen and Andew.

2 1

Internet User review: IDNA2008 follow-up at IETF/PRECIS and ICANN/VIP
by JFC Morfin Aug. 2, 2011

Aug. 2, 2011

Jean-Michel, I agree with you. However, things are not that simple. Andrew Sullivan asked for an algorithm and he is right: machines and systems need algorithms. What you emphasize is that in our cases (Variants, Stringprep replacement, IDNA support on the user side, extended services naming, IUsers' expectations, etc.) the algorithmic nature is just as precise as the mathematical algorithm that Andrew expects, but it obeys an entirely different logic because it also involves a brain to brain level. We have the tool (fringe to fringe as permitted by IDNA2008 and exemplified in RFC 5895) to support it but we first have to understand and document this logic. Therefore, we first need to get everyone who shares this burden to accept that their approach is to be shared with others and to understand that their logic and the logic of the others will help, but that the final logic cannot be a common logic. It is a new logic to we have to explore in common. Their experience and the experience of the others are needed but the case that we have to address is totally new. That case first needs to be understood. IPv6 is to give everyone millions of sub addresses (we call them IDv6, IIDs that are globally addressable). People will from then on allocate one, or several, thousand domain names to themselves, in the same way that they used to have an address, a name, a nickname, a mobile directory of addresses, TV channels, file names, etc. Therefore, we are talking of a world digital ecosystem naming intrastructure of hundreds of billions of domain names plus mail names, login ID, passwords, keys, codes, etc. In addition, we the users want this to be simple, sure, and secure for everyone in every language and every orthotypography (an orthotypographic requirement that IDNA2008 adequately refused to include in the network side in refusing mapping and ICANN calls "variants" on the user side). Compared to this, IDNA2008 was a _very_ simple thing to achieve. Now, you have summarized your vision of the VIP, WG/PRECIS, IAB, and IUCG problem in a metaductive manner. IMHO, this is correct. Metaduction is the proper and only way to address a problem of this size and complexity as a way to think in networks. However, metaduction is a way of thinking that everybody partly uses all the time but that is still only explored as such, at least in the way you use it, within our ALFA (Architecture Libre/Free Architecture) research framework. Some have emphasized that there was a deep need for a common glossary. Yes! However, the target is not only to use the same glossary, but also to have a common understanding of the ways of thinking of the concerned parties (engineers, operators, users). Therefore, let me explain it and translate what you mean to others, then analyze what you state and what it might imply in order to address these groups' needs, as they result from our IDNA2008 final consensus. At 10:39 27/07/2011, jean-michel bernier de portzamparc wrote: >Jefsey, > >I read your mails and compare them with our discussions. What I feel >is that we progressively switch to and from the three forms of >comparison, we call semantical (sense) as opposed to mathematical >(one character at a time) and physical (same external form). These three types belong to what we are exploring as "intelligent thinking" in order to address complexity, as an alternative to Edgar Morin's "complex thinking". Complex means woven, (complexus: canvas in Latin), like the web. Intelligent thinking is based on the idea that there are three(+one) levels of intelligence: 1. physical, like the Internet lines and nodes, 2. logical/mathematical, like the protocols, 3.1. semantical, like the meaning of what is exchanged. 3.2 pragmatical, like a paradigm (everyone thinks the same): This corresponds to : 1. "to be in good intelligence with" and interlinks, 2. "intelligence" (as in the CIA) as information and command of the hyperlinks, 3.1. be intelligent, i.e. to be able to adequately use that information in modeling (comprehending) it and observing/emulating the model behavior. 3.2. the same but when instead of considering a single semantic processors one considers a semantic processor network: a crowd, country, culture, community, etc. Here, the reasoning cannot be classical deduction, induction, abduction,or even hypothetico-deduction. We call it metaduction. It consists in building a brain vision, a mental map of what we understand. We call it an ontography (because 50% of the brain uses vision related functions, e.g. "theory" means an observation, we refer to our "points of view", etc.). The legend of this "map" is an ontology. Then, the metaductive reasoning consists in observing the mental map and progressing through it. This is truly mentally walking a theory. One, therefore, understands that metaduction extensively uses contextual models, and that being dependent on models makes it totally dependent on context, i.e. on the adjacencies that define a context (or in IDNA2008 terms and thinking environment: "joiners" and "CONTEXTO"). As a consequence, when - physical logic is built on correspondence - and mathematical logic is built on equivalence - then semantical logic is built on coherence - and pragmatical logic is, in addition, dependent on internal consistency. (note: pragmatic is semantic in a context, i.e. considering the influence/interference of a given relational space and therefore of its referent [an exemple of referent is the IANA, which up to now was unique, however the Internet technology defines one IANA per DNS class]). Communications are about exchanging (uttering/understanding) our "maps" with others. Our first needs are, therefore, to name, locate, protect, and access our "maps" in a simple, sure, and secure manner. This is what WG/PRECIS and ICANN/VIP attempt to do. This is a part of the IDNA2008 consequences that I proposed to discuss two years ago and that led me to appeal the IAB against the IESG's lack of warning about the consequences of IDNA2008 when publishing the RFC set. Let me remind you here that the outcome of these appeals was extremely positive as they identified that this issue extended far outside the area of responsibility of the IETF since it concerns the whole digital ecosystem, even though IDNA2008 bluntly reminded us about the true, very larger extent of the Internet architecture. In this digital ecosystem, the Internet legacy proposition/contribution does: - name in using domain names, login, etc., - locate in using IP addresses, - protect in encrypting, - access in using keywords, etc. - deal with transmitting datagrams as efficiently as possible (this is end to end connectivity) - want that "Everything else should be done at the fringes" (RFC 1958: Architectural Principles of the Internet). IDNA2008 has clarified what, in diversity support, is: - at the end to end (protocol) level (RFC set) - and at a fringe to fringe intelligent level that the IETF never documented before. This is why the RFC 5895, which permitted our IDNA2008 consensus, was published only for informational purposes. Because its matter was "unusual" for the IETF: "this document does not specify the behavior of a protocol that appears 'on the wire'. It describes an operation that is to be applied to user input in order to prepare that user input for use in an "on the network" protocol. As unusual as this may be for a document concerning Internet protocols, it is necessary to describe this operation". - and permitted this way to support what is at the brain to brain, human semantic and pragmatic level. IDNA has removed constraints on the Internet architectural support of diversity (while considering the case of the linguistic diversity), hence of complexity. In so doing, it also modified our reading of the Internet architecture: it showed that the Internet is also built on the principle of subsidiarity (in addition to the principle of constant change [RFC 1958] and of the principle of simplicity [RFC 3439: Some Internet Architectural Guidelines and Philosophy]). The consequence that we are faced with is threefold: 1. we have to adapt to IDNA2008 changes and update ourselves and the technology to the IDNA2008 unleashed opportunities. 2. we are in an open architectural context that we are not familiar with, however it only results from a full reading of the RFCs that we know as well as from a full use of the very unchanged code that we use every day. The danger is that we can consider solutions that are already provided or contradict them without noticing it. This was the case of IDNA2003. This still is the case of the IDNA concept (RFC 6055). 3. the architectural context that we call the IUI (cf. below) i.e. the Internet Use Interface on the Internet side of it, and the Intelligent Use Interface on our user side, is something that we will also intelligently use (i.e. with our same intelligence and need for simplicity, surety and security) with other technologies we should consider (mobile phones, regular mail, registries, etc.). We are not used to their standardization except common users. While implicitly simplicity, surety and security on our user side calls for an advisable unicity (RFC 1958) in the coherence and consistency of the proposed solutions. This should be helped by the use of the same IDNA2008 on the Internet side and our demand of a single follow-up on this Internet side: this is why, as users, we wish for the same common liaison and work between the "sons of IDNA2008", like VIP, PRECIS, IUCG, and IDNABis experience, etc. >This is a plex. Yes. A plex is a network of ideas. This is the very nature of complexity. A plex is a plex of a plex etc. We observe that metaduction, as introduced above, is not about reducing complexity into small simpler problems (rationalism) because one loses the influence of the complexity (the whole is more than the addition of its parts because parts lose the whole when being split from other parts). Metaduction is about looking at confusion as a whole, to progressively map it, to study the map when looking for its apices (plural of apex) of complication and simplicity, i.e. what seems to be the most difficult to understand and what seems to be the simplest to do to clarify things. This is a pure application of RFC 3439: in very large systems one must apply the principle of simplicity. > It meshes domain name, variants, phishing, meanings, sounds, > feelings, perceptions, etc. This is human communication vs. machine > communications. Object communications - as we know them, are based upon geometric correspondence: translation, forgetting the size or not. Machine communications - as we know them, are based upon the mathematical comparison function: equivalence, equality, if then else. Human communications - want to use machines acting as peripheral simplificators (operators of complexity simplification) are based upon the semantical comparison function: coherence - or on its pragmatic similitude. IDNA2008 has established an interface between these three forms of communications in the way that it establishes the relation between the Internet and applications, which in turn need an interface with the Internet. This middleware is what permits us, the users, to use the Internet in the way we want. This middleware will also be present when we deal with any other digitized communications technology this is why we used to call it the Intelligent Use Interface (IUI) and have started exploring it in parallel to IDNA2008. >We therefore need to address it as a plex, metasimplify it and find >its apex of simplicity. Yes. This is the process that I introduced above. However, metaduction is not the way the IETF, ICANN, etc. think. This was acknowledged by ICANN in a very interesting fundamental document named ICP-3. http://www.icann.org/en/icp/icp-3.htm. It states that the Internet community proceeds through experimentation. Therefore, ICANN called for community experimentation. This was in 2001.. It seems that we were alone in carrying it out. Except for Google, which by its size can do something equivalent at any time with http://code.google.com/intl/fr/speed/public-dns/ their Public DNS. We do not discuss an alternative root or so on, or the extension of the root. We are speaking about a full true implementation of the DNS itself, the way it is documented and in the light IDNA2008 unconstrains it. . > I think that clarifying what "string" means in the three types of > comparisons would help a lot. > >Physical : same frequency >Mathematical : same components >Semantical : same what? You have to also consider the Pragmatic alternative to Semantic; There are community side effects in what is discussed. A "Variant" as per VIP could be what is related to Pragmatic. The term could be used. >A way to address this point would be to look for another word than >"string" that would lead people to identify the differences with a >mathematical string in terms of comparison. You have to also consider the Pragmatic alternative to Semantic; There are community side effects in what is discussed. A "Variant" as per VIP could be what is related to Pragmatic. The term could be used. And we could define it along similitude grades depending on contexts A way to address this point would be to look for a word other than "string" that would lead people to identify the differences with a mathematical string in terms of comparison. >Also, to decide if their comparison is correspondence, equivalence >or coherence. This makes sense. This is a common approach to start with more appropriated and identified definitions. It is also to decide if their comparison is correspondence, equivalence, or coherence. Or rather acceptance in the pragmatic case. >This way we can use the principle of correspondence to check where we are. The principle of correspondence states that innovation in science must not only explain new aspects but also keep explaining these that were already explained. This is the IDNA prerequisite and what IDNA2008 guaranteed: the DNS as we know it and it is deployed millions of times, operational protocols, and users' satisfaction MUST not be affected. Thank you. Now we have to agree upon a new word to qualify a "smart string" if a "dumb string" is something we cannot read (spell) but only see. This means that: - a "dumb string" (symbol) supports a signal - a "string" supports content - a "smart string" to supports a thought. I would propose using "sememe", with a coherence seme by seme: http://en.wikipedia.org/wiki/Seme_%28semantics%29. - a "local smart string" to support a relational space's accepted "pragmeme" between a "pract" and an "allopract" (cf.pragmatician experts). Let me be clear, if we accept that: The last two propositions cannot be processed by a machine in a way that an RFC can describe, but an RFC can describe a common procedure and the guidelines for such a process to be carried by common agreement. We have a good example in the way Unicode code-points are worked out, langtag tables are built, ccTLDs are defined, etc. I suggest that we work on this and add these definitions to our glossary. Then, I think we should start from Marc Blanchet's Draft http://www.ietf.org/id/draft-blanchet-precis-framework-02.txt and discuss if a graphcode approach could address his requirements. Note: I use the concept of "graphcode" for a stringprep replacing algorithm made of a table of character graphical symbols for every existing script: one (phishing proof) symbol per geometric form. Each graph-point corresponds to a number of "in-code-points", and to one single "out-code-point" per orthotypography. This is a pragmatic equivalent of RFC 5892, i.e. the algorithm is not processed by a computer program but by a multibrain consensus. Then, the resulting code-graph (equivalent to code-point in a graphcode) system could be implemented for a test at one of the layers of the ML-DNS. Note: The ML-DNS is an IDNA2008 conformant encapsulation of the DNS that we are exploring (testing is to be carried before being documented), to process a naming pile that is able to address the people's final needs. This pile is the pile of the variants of the same name in various classes and presentations, e.g. A-label, U-label, UDN (user actual entry), etc. A major difference with the IDNA context is that the ML-DNS supports a single "IDNApplication service" per machine (single resolution source). However, frankly, my first and main concern is that your approach confirms that these three (VIP, PRECIS, and IUCG) groups are working on things very similar and quite intricate. They do need to relate in a way or another. At least, as the users of their deliverables, we need to ensure that they do. The work that they are engaged in is revamping Shannon's communications theory in a multilingual human context. It is worth some consideration. jfc

2 1

IDN Variant Experience Webinar
by Steve Sheng Aug. 2, 2011

Aug. 2, 2011

When: Monday, August 01, 2011 8:30 AM-10:00 AM. Pacific Standard Time *~*~*~*~*~*~*~*~*~* Thank you for your interest in the IDN Variant Experience Webinar! This email provides the details for the upcoming webinar. Event Date and Time: Date: Monday, 01 August 2011 Time: 15:30 – 17:00 UTC Duration: 90 minutes Language: English In brief: 15:30 UTC / Pass code 5670364 / http://icann.adobeconnect.com/idnvarianttld/ <http://icann.adobeconnect.com/idnvarianttld/> To check the correct time for your location, go to: http://www.timeanddate.com/worldclock/fixedtime.html?msg=IDN+Variant+Educat… Draft Agenda – subject to change 1. An overview of existing TLD programs related to variants by ICANN staff [15 minutes] 2. Experience of Variant Handling in ccTLDs [50 minutes] Five presentations [7 mins each] Presenters: Fahd Batayneh, Iftikhar H. Shah, Behnam Esfahbod, Andrzej Bartosiewicz, Vladimir Shadrunov Q&A [15 mins] 3. Overview of DNS mechanisms and status from IETF standards [7 mins] 4. Outline of RFC discussions about variant handling [15 mins] 5. Wrap up [3 mins] How to Participate: Adobe Connect: We will be using ADOBE CONNECT for this meeting to facilitate the sharing of documents and information. To log-in, please go to: http://icann.adobeconnect.com/idnvarianttld/ <http://icann.adobeconnect.com/idnvarianttld/> After clicking the link to enter the Adobe Connect room, please choose ‘Enter as a Guest’, type in your first and last name, and click ‘Enter Room’. For those of you using Adobe Connect for the first time, please find a short introduction video here: https://admin.adobe.acrobat.com/_a227210/participatemeeting/ Dial-In Information: From the dial-in phone list below, please select the number that is closest to your location. If you would like an operator to call out to you, please email hayley.laframboise(a)icann.org with your primary (preferably a land line number) and alternative contact numbers by Friday, 29th July 2011. Can’t join the webinar? The slides and recording of the presentation will be made available and posted on the IDN Variant TLDs Issues Project Community wiki workspace shortly following the meeting: https://community.icann.org/display/VIP/Home Yours sincerely, Hayley Laframboise Hayley M. Laframboise Project Coordinator, IDN Variant Issues Project ICANN – Internet Corporation for Assigned Names and Numbers Dial-in phone numbers: Participant Passcode: 5670364 Country City Toll-Free Toll Argentina 0800-444-0893 Australia Sydney 1-800-659-369 61-2-8211-1354 Australia Perth 1-800-659-369 61-8-9467-5276 Australia Canberra 1-800-659-369 61-2-6100-1997 Australia Melbourne 1-800-659-369 61-3-9010-7766 Australia Adelaide 1-800-659-369 61-8-8121-4895 Australia Brisbane 1-800-659-369 61-7-3102-0997 Austria 0800-005-258 43-1-92-81-112 Belgium 0800-3-8922 32-2-400-9860 Brazil 0800-7610703 55-11-3958-0782 Chile 1230-020-5927 China 10800-120-1661 86-400-810-4795 Colombia 01800-9-156441 Czech Republic 800-700-176 420-2-25-98-56-66 Denmark 8088-8306 45-7014-0283 Estonia 800-011-1113 Finland 0-800-1-17496 358-106-33-202 France Lyon 080-563-6117 33-4-26-69-14-28 France Marseille 080-563-6117 33-4-86-06-02-28 France Paris 080-563-6117 33-1-76-74-25-67 Germany 0800-304-0517 49-69-2222-4857 Greece 00800-12-8029 30-80-1-100-0685 Hong Kong 800-933-559 852-3001-3817 Hungary 06-800-12773 36-1-700-8859 India 1800-300-00432 Indonesia 001-803-011-3983 Ireland 1800-992-642 353-1-247-5686 Israel 1-80-9212594 Italy 800-986-382 39-02-3601-9646 Japan Tokyo 0066-33-812354 81-3-5539-5181 Japan Osaka 0066-33-812354 81-6-7739-4791 Latvia 8000-3195 Luxembourg 352-27-000-1363 Malaysia 1-800-81-3073 Mexico Mexico City 001-866-944-6209 52-55-5062-9119 Mexico Monterrey 001-866-944-6209 52-81-2482-0619 Mexico Guadalajara (JAL) 001-866-944-6209 52-33-3208-7319 Netherlands 0800-023-4478 31-20-718-8587 New Zealand 0800-451-493 64-9-970-4654 Norway 800-16586 47-21-590-063 Panama 011-001-800-5072352 Peru 0800-54079 Philippines 63-2-858-3773 Poland 00-800-1213465 Portugal 8008-14912 Russia 8-10-8002-5584011 Saudi Arabia 800-8-110098 Singapore 800-120-5204 65-6883-9140 Slovak Republic 421-2-322-422-24 South Africa 080-09-82126 South Korea 00798-14800-7778 82-2-6744-1013 Spain 800-300-052 34-91-414-25-32 Sweden 0200-884-615 46-8-566-19-363 Switzerland 0800-120-031 41-44-580-6397 Taiwan 00801-137-857 886-2-2795-7307 Thailand 001-800-1206-65711 United Kingdom London 0808-238-6028 44-20-7108-6369 United Kingdom Birmingham 0808-238-6028 44-121-210-9068 United Kingdom Glasgow 0808-238-6028 44-141-202-3268 United Kingdom Leeds 0808-238-6028 44-113-301-2168 United Kingdom Manchester 0808-238-6028 44-161-601-1468 Uruguay 000-413-598-3826 USA 866-692-8755 1-517-466-3030 Venezuela 0800-1-00-4794 ------ End of Forwarded Message

5 5

Re: [vip] [arabic-vip] Language table updation
by Kim Davies Aug. 1, 2011

Aug. 1, 2011

Dear Sarmad, On Jul 26, 2011, at 2:02 PM, Sarmad Hussain wrote: An issue which came up during the discussion in our group meeting was whether it is possible for a registry to submit a language table and then to revise it (e.g. (but not limited to) the variant table within it). Is there anything in the protocol on this? Are there any IANA policies around it? If yes, are there any procedures stipulated? With respect to the IDN repository on IANA's website (i.e. http://www.iana.org/domains/idn-tables) yes, TLD registries are free to update and revise the IDN table they have listed as they see fit. A number of TLD registries have updated the tables they have listed on the website. We have little in the way of formal policies for this resource right now. To ensure listings are authentic, we ask the contacts for a TLD to consent to a listing or an update. However, we don't have any strict limits on the formatting of what is provided. All we ask that it be provided as plain text, HTML or PDF. I quickly review submitted tables and if the format is too much of a divergence from the classical JET-style format, I'll ask if they are sure they wish to submit it in that particular form, given the goal is re-usability by other registries. However there is no formal requirement it be of a specific format. kim

1 0