- vip - lists.icann.org

FW: WHITE PAPER ON "DEFINITIONS" : YOUR COMMENTS AND FEEDBACK REQUESTED
by Naela Sarras Sept. 12, 2011

Sept. 12, 2011

From: doc <raymond.doctor(a)gmail.com<mailto:raymond.doctor@gmail.com>> Date: Fri, 19 Aug 2011 20:13:48 -0700 To: "vip(a)icann.org<mailto:vip@icann.org>" <vip(a)icann.org<mailto:vip@icann.org>> Subject: WHITE PAPER ON "DEFINITIONS" : YOUR COMMENTS AND FEEDBACK REQUESTED Dear colleagues, I had drafted a white paper on the definitions and questionnaires put forward at the Singapore meet which I attended remotely. The paper comprises three sections: 2.1 On Unicode 2.2. DNS 2.3. The main part of the paper dealing with the notion of variant-hood and which links variants with a script typology to arrive at a "unified theory" of variants. The paper was reviewed by Mr Andrew Sullivan and Dr Nicholas Ostler and I am grateful to them for their replies and comments which were extremely useful and constructive. I have also tried to reply to their comments. I am attaching the paper as well as the mails of Mr Andrew Sullivan and Dr Ostler and my replies to their comments. I have preferred to keep the original white paper as such and would like to hear from all colleagues, especially where the issue of variants (which affects us all) is concerned. Your feedback and comments and suggestions would be most helpful. I would suggest the following reading order: 1. WHITE PAPER ON QUESTIONNAIRE ver. 3.1.pdf (application/pdf) 1692K 2. Nicholas Ostler - reply.pdf (application/pdf) 124K 3. Nicholas Oster - remail reply.pdf (application/pdf) 67K 4. Andrew Sullivan - reply.pdf (application/pdf) 177K 5. Andrew Sullivan - email reply.pdf (application/pdf) 72K Thanking you Best regards, Raymond Doctor

3 3

Glossary
by JFC Morfin Sept. 12, 2011

Sept. 12, 2011

http://iucg.org/wiki/Multilingualization_-_Glossary has been updated with; - the definitions I gave in my last mail - the definitions given by RFC 3743.

1 0

[rfc-editor@rfc-editor.org: BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF]
by Andrew Sullivan Sept. 8, 2011

Sept. 8, 2011

Dear colleagues, An early draft of what became the attached RFC is referred to in our initial definitions document for this project. It might be worth having a look at the final RFC as you work on the draft reports. There's a lot in there, and most of it can, I think, be helpful. Best regards, Andrew -- Andrew Sullivan ajs(a)anvilwalrusden.com

2 1

FW: [latin-vip] Loudly spoken opinions - input for today's meeting
by Francisco Arias Sept. 7, 2011

Sept. 7, 2011

I wonder what others think about the ideas in this document posted to the latin team. Apologies to Harald for putting you in the spot. __ Francisco On 8/25/11 7:25 AM, "Harald Alvestrand" <harald(a)alvestrand.no> wrote: >I don't know if I can make today's meeting (conflicts), but I thought >I'd write some opinions. > >This is written as starkly as possible in order to make it very clear >what I think - it may come across as more strident than is really >warranted. Others may have different opinions. > >Anyway, it's a starting point. > >

4 11

oups!
by JFC Morfin Sept. 3, 2011

Sept. 3, 2011

Please read: In French: Etat = Government état = status Upper-cases can or not wear an accent. There is no difference. In ASCII "etat" is supposed to mean both. This kind of confusion cannot be accepted due to its semantic impact. Also, please remember that in this case "E" is just a way to express (in using an upper-case) that E is a majuscule. Unicode has no other way to support the "majuscule metadata" that upper-cases: this is why I said that the lack of upper-case support by IDNA2008 (to the contrary to IDNA2003, which did not affect upper-case entries from end to end, as the DNS does not either) was not bad. It implies the mandatory use of an added middle-netware (I call the IUI and which will offer intelligence on a fringe to fringe basis, between the user's computer plug and its unchanged OS socket. cf. IAB RFC 3238 on OPES). As in some other scripts, the important thing is not to transport the same typography on an end to end basis, but to carry the same message, i.e. data + metadata, on a fringe to fringe basis. Architecturally this important because it affects the kind of technical communication stratum we consider. - In value-added datacommunication (OSI, TCP/IP) the model includes communications oriented metadata in the envelope (along the layers of that model). If there may be a need for the content to be accompanied by metadata : these metadata are conveyed by the "presentation" layer. IDNA2008 institutes the missing TCP/IP presentation layer through the rudimentary "xn--" prefix. This is rudimentary because the metadata is correctly in the header, but not directly accessible (not at a structural address). - the stratum above telecommunication (no metadata) and datacommunications (metadata in the header) is the metacommunications where metadata are sent/obtained by their own. There are therefore two ways to deliver the othotypographic "majuscule" pay-load: - either in using the domain name. We still are in the rudimentary solution, but we can improve it if this becomes a stable extended way to proceed. - or in paralleling the data delivery with a metadata delivery ("the first character of the related domain name is a majuscule"). In this case we are outside of the standard telecommunications and value-added and extended datacommunications: we have entered metacommunications. To date the Internet is not a metacommunications technology. The possible improvement to support metadata, hence to support variants, can be: - to use another presentation, in changing or extending the "xn--" header. - xm-- means that the first letter is a majuscule: - "xn--5-- means that the fifth character is a majuscule or is a figure to take into a local list of numbers - etc. - in extending the punycode syntax and introducing an escape signal. for example "état"="status" and "^état"="Etat". - in acknowledging that this leads to a change of the nature of the domain name field in the TCP/IP packet. It becomes the presentation layer support. This calls for a presentation protocol defaulting to a regular ASCII FQDN. However, this definitely belongs either to the UI in the current IDNA IAB architecture, or to the IUI in the traditional Internet architecture as IDNA2008 read it and in the multitechnology digital ecosystem. This leads to the questions: 1) how does this WG/VIP intend to see its conclusion technically supported? 2) Will ICANN publish an IDNA/ICANN stringprep/stringextract function? 3) Will it develop or specify an IUI? 4) or will it publish its findings as a multilinguistics contribution. jfc

1 0

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