RE: Punycode at ASCII for IDN MDN via Y2K Project Management
Further to what I wrote yesterday, the 2 IDN algorithms: ToASCII and ToUnicode perhaps would need tweaks hence ToASCII2 and ToUnicode2 with perhaps ASCII registrations needing also an ACE sort prefix, say yn-- similar to xn-- that are put for IDN. This development could then allow MDN (Multilingual Domain Names) that would help the users that are multilingual / would like multilingual text at domain name platform. You can have for MDN another ACE sort prefix, say zn-- to distinguish them from IDN and ASCII registrations. Regards Meeku --- On Mon, 10/11/08, linuxa linux [EMAIL PROTECTED] wrote: From: linuxa linux [EMAIL PROTECTED] Subject: RE: Punycode at ASCII for IDN MDN via Y2K Project Management To: ietf@ietf.org, [EMAIL PROTECTED] Cc: Ruszlan Gaszanov [EMAIL PROTECTED] Date: Monday, 10 November, 2008, 11:15 PM --- On Sun, 9/11/08, Ruszlan Gaszanov [EMAIL PROTECTED] wrote: From: Ruszlan Gaszanov [EMAIL PROTECTED] Subject: RE: Punycode at ASCII for IDN MDN via Y2K Project Management To: [EMAIL PROTECTED], ietf@ietf.org Date: Sunday, 9 November, 2008, 10:21 PM ..ASCII domain names *are* in fact punycode domain names by definition. That's the problem and the reason for Punycode2 allowing ASCII registrations to be Punycoded via Punicode2. As soon as you want to encode ASCII characters with something else, you'll need a new parallel DNS infrastructure and at this point a new version of DNS protocol that works... You got this wrong because when you Punycode via Punycode2 ASCII registrations you will have ASCII letters however they will be in machine code, same as IDN thus equal virtue and for ASCII registrations to be viewed they will be viewed similarly as IDN (Internationalized Domain Names / Internationalised Domain Names) and here also equal virtue. ...But the bottom line is that there is no way to develop a new punycode encoding ASCII domain names with something else then ASCII and implement that on existing DNS infrastructure without completely breaking the Internet, period. Again you are putting something which I have not said for Punycode2. While you wait for learning curve developments, I suggest you use ASCII based letters for Punycode 2 however you machine code the ASCII registrations like you are doing with IDN. I am not a technical expert, however based on what I have gleaned can I suggest the 2 IDN algorithms: ToASCII and ToUnicode perhaps would need tweaks hence ToASCII2 and ToUnicode2 with perhaps ASCII registrations needing also an ACE sort prefix, say yn-- similar to xn-- that are put for IDN. This development could then allow MDN (Multilingual Domain Names) that would help the users that are multilingual / would like multilingual text at domain name platform. I hope this signals to you the urgency that is required for implementing. Regards Meeku ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Punycode at ASCII for IDN MDN via Y2K Project Management
--- On Tue, 11/11/08, Ruszlan Gaszanov [EMAIL PROTECTED] wrote: From: Ruszlan Gaszanov [EMAIL PROTECTED] Subject: RE: Punycode at ASCII for IDN MDN via Y2K Project Management To: [EMAIL PROTECTED], ietf@ietf.org Date: Tuesday, 11 November, 2008, 9:36 AM .. without messing up the registrations that have been there for decades. The proposal is for new registrations, why twist the issue? Previous registrations would become sort after learning curve developments like I said to you. ASCII is also *machine code* for goodness sake! You just do not see it as machine code because virtually all software knows how to translate it to something you can read. Any information stored on computers and transmitted over digital networks is *machine code* - it is only a matter of whether your software can present this or that machine code in human-readable form or not. You are putting a molecular backend eye to ASCII, when you know quite well we are discussing from a user and practical layer, see http://en.wikipedia.org/wiki/Image:ASCII_full.svg That image shows you Complete set of printable ASCII characters and the letters are roman/latin based letters. These and a few symbols are what the frontend internet/web user sees / is able to see at the frontend layer. I am concerned about the nepotistic network that has developed where a shortcut is being given to ASCII roman/latin character based language at the frontend layer however for the non-ASCII based languages the user gets an almost backend / machine code service. Thus the proposal is to give a equal field where all users get a frontend layer service. This proposal also would bring about MDN (Multilingual Domain Names) an issue that you are totally ignoring. ...you can't just update existing registrations to new format instantly on millions of DNS servers all over the World operated by different organizations. If ICANN starts doing that, the whole domain-name-lookup infrastructure will submerge in complete chaos for months, which would render the Internet virtually unusable. However you are accusing without any technical basis and all your arguments are FUD (Fear, Uncertainty and Despair). You know that IDN is based on ASCII machine code thus non-IDN / ASCII registrations should also use ASCII machine code. You want ASCII at the frontend however you should not have a nepotistic service, quite the opposite you need to implement an equal service to all users at the frontend layer. Thus you need to put the equal service for all users not that you give one user class a poor frontend layer that's almost backend machine code and another class a rich frontend layer. Then there is a class that want MDN (Multilingual Domain Names) however you are basically say don't give them any service. Thus your proposal is a nepotism one where only close conspiratorial charactered friends get a real frontend service and those that are not have to become close conspiratorial charactered friends. This is then your goal at the internet/web, it also then also related to your passive/active goal beyond internet/web technical activities. Regards Meeku http://twitter.com/nepotism ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Punycode at ASCII for IDN MDN via Y2K Project Management
Correction 1: FUD (Fear, Uncertainty and Doubt) Correction 2: This is then your goal at the internet/web, it then is also related to your passive/active goal beyond internet/web technical activities. Corrected also at below emailed copy. Regards Meeku http://twitter.com/nepotism --- On Tue, 11/11/08, linuxa linux [EMAIL PROTECTED] wrote: From: linuxa linux [EMAIL PROTECTED] Subject: RE: Punycode at ASCII for IDN MDN via Y2K Project Management To: ietf@ietf.org, [EMAIL PROTECTED] Cc: Ruszlan Gaszanov [EMAIL PROTECTED] Date: Tuesday, 11 November, 2008, 8:20 PM --- On Tue, 11/11/08, Ruszlan Gaszanov [EMAIL PROTECTED] wrote: From: Ruszlan Gaszanov [EMAIL PROTECTED] Subject: RE: Punycode at ASCII for IDN MDN via Y2K Project Management To: [EMAIL PROTECTED], ietf@ietf.org Date: Tuesday, 11 November, 2008, 9:36 AM .. without messing up the registrations that have been there for decades. The proposal is for new registrations, why twist the issue? Previous registrations would become sort after learning curve developments like I said to you. ASCII is also *machine code* for goodness sake! You just do not see it as machine code because virtually all software knows how to translate it to something you can read. Any information stored on computers and transmitted over digital networks is *machine code* - it is only a matter of whether your software can present this or that machine code in human-readable form or not. You are putting a molecular backend eye to ASCII, when you know quite well we are discussing from a user and practical layer, see http://en.wikipedia.org/wiki/Image:ASCII_full.svg That image shows you Complete set of printable ASCII characters and the letters are roman/latin based letters. These and a few symbols are what the frontend internet/web user sees / is able to see at the frontend layer. I am concerned about the nepotistic network that has developed where a shortcut is being given to ASCII roman/latin character based language at the frontend layer however for the non-ASCII based languages the user gets an almost backend / machine code service. Thus the proposal is to give a equal field where all users get a frontend layer service. This proposal also would bring about MDN (Multilingual Domain Names) an issue that you are totally ignoring. ...you can't just update existing registrations to new format instantly on millions of DNS servers all over the World operated by different organizations. If ICANN starts doing that, the whole domain-name-lookup infrastructure will submerge in complete chaos for months, which would render the Internet virtually unusable. However you are accusing without any technical basis and all your arguments are FUD (Fear, Uncertainty and Doubt). You know that IDN is based on ASCII machine code thus non-IDN / ASCII registrations should also use ASCII machine code. You want ASCII at the frontend however you should not have a nepotistic service, quite the opposite you need to implement an equal service to all users at the frontend layer. Thus you need to put the equal service for all users not that you give one user class a poor frontend layer that's almost backend machine code and another class a rich frontend layer. Then there is a class that want MDN (Multilingual Domain Names) however you are basically say don't give them any service. Thus your proposal is a nepotism one where only close conspiratorial charactered friends get a real frontend service and those that are not have to become close conspiratorial charactered friends. This is then your goal at the internet/web, it then is also related to your passive/active goal beyond internet/web technical activities. Regards Meeku http://twitter.com/nepotism ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Punycode at ASCII for IDN MDN via Y2K Project Management
--- On Sun, 9/11/08, Ruszlan Gaszanov [EMAIL PROTECTED] wrote: From: Ruszlan Gaszanov [EMAIL PROTECTED] Subject: RE: Punycode at ASCII for IDN MDN via Y2K Project Management To: [EMAIL PROTECTED], ietf@ietf.org Date: Sunday, 9 November, 2008, 10:21 PM ..ASCII domain names *are* in fact punycode domain names by definition. That's the problem and the reason for Punycode2 allowing ASCII registrations to be Punycoded via Punicode2. As soon as you want to encode ASCII characters with something else, you'll need a new parallel DNS infrastructure and at this point a new version of DNS protocol that works... You got this wrong because when you Punycode via Punycode2 ASCII registrations you will have ASCII letters however they will be in machine code, same as IDN thus equal virtue and for ASCII registrations to be viewed they will be viewed similarly as IDN (Internationalized Domain Names / Internationalised Domain Names) and here also equal virtue. ...But the bottom line is that there is no way to develop a new punycode encoding ASCII domain names with something else then ASCII and implement that on existing DNS infrastructure without completely breaking the Internet, period. Again you are putting something which I have not said for Punycode2. While you wait for learning curve developments, I suggest you use ASCII based letters for Punycode 2 however you machine code the ASCII registrations like you are doing with IDN. I am not a technical expert, however based on what I have gleaned can I suggest the 2 IDN algorithms: ToASCII and ToUnicode perhaps would need tweaks hence ToASCII2 and ToUnicode2 with perhaps ASCII registrations needing also an ACE sort prefix, say yn-- similar to xn-- that are put for IDN. This development could then allow MDN (Multilingual Domain Names) that would help the users that are multilingual / would like multilingual text at domain name platform. I hope this signals to you the urgency that is required for implementing. Regards Meeku ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Punycode at ASCII for IDN MDN via Y2K Project Management
Please read response below. I am not a technical expert, thus my understanding could be flawed, thus I would like to say sorry for any errors throughout this. Regards Meeku --- On Tue, 4/11/08, Ruszlan Gaszanov [EMAIL PROTECTED] wrote: From: Ruszlan Gaszanov [EMAIL PROTECTED] Subject: RE: Solutions to the IDN Problems Discussed To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Tuesday, 4 November, 2008, 11:34 AM There is a problem with solution #1 - it already exists :) though for semi-ASCII language and Internationalised domain names it does not work :( because I visited this website http://www.nameisp.com/puny.asp and did an experiment with total-ASCII language domain names and the punycode representation was the same as the domain name. Thus there is a problem with punycode machine code presently, as it cheats and does not code the total-ASCII language domain names like it does with semi-ASCII language and Internationalised domain names. .. Any other implementation would be incompatible with existing DNS infrastructure and requires developing a completely new name-lookup protocol as well as setting up a parallel server infrastructure. Punycode exists at the Whois for Internationalised Domain Names and you could easily put a Y2K project management with a timeline for ending old type ASCII registrations and where new type Punycode registrations would commence at ASCII names. ASCII names would get processed via the Punycode field like you have with IDN and your previous ASCII field shuts, that's all. Both systems could exist simultaneously, the new process open and the previous closed yet continuing then later when there's learning curve development you could consider correcting the old type closed ASCII system. This system would allow registrations that are (1) IDN (Internationalised Domain Name) and also those that are (2) MDN (Multilingual Domain Names). Since such protocol would be fundamentally incompatible with any existing internet applications, new software will have to be developed. This would practically mean creating a second Internet. Software applications would catch-up to this via the Y2K sort project management and also via market. Unicode got accepted then Punycode at ASCII registrations compatibility should also get accepted. Considering the cost and time requirements of such a project, as well as all the confusion and inconveniences the transition would cause, I do not really believe the user community would benefit from it. In any case this kind of project is quite beyond the mandates of either ICANN or Unicode Consortium. You have Punycode existing at IDN then you can also use same at ASCII. Only the registration window get's changed and you have an extended Punycode that also changes ASCII registration into Punycode. The user community would really become happy because you would get quicker IDN implementation and a new type registration that are Multilingual. Software application integration would happen early. This would help those people that speak / write more than one language. People could then interact better and with virtue atmosphere than before they were able to with only their single language domains and software applications. You find that there are countries where the railway stations are using their traditional languages as well as the english language. The world has become more cosmopolitan and thus you need this to happen very urgently. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Solutions to the IDN Problems Discussed
February 2008 I had a dialogue with ICANN about Internationalised Domain Names / Internationalized Domain Names and I would like to now make this public on the IETF mailing list because they mention problems and also possible solutions for a better way. - - - - - 1. Complaint about .ORG Registry IDN - Asian Tuesday, 19 February, 2008 8:23 AM From: linuxa linux [EMAIL PROTECTED]View contact details To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] .COM / .NET have for several years had Internationalised Domain Names for Asian Languages. .ORG is probably as old a suffix / gTLD as them. However yesterday I have been told by the .ORG registry that you appointed for .ORG, that they cannot give out any time / timeline or even year that they will implement Internationalised Domain Names for Asian Languages. I complain on behalf of myself and others about this slow way the .ORG registry is behaving. Please answer my and others concerns urgently. Regards Meeku .. - - - - - 2. RE: Complaint about .ORG Registry IDN - Asian Tuesday, 19 February, 2008 9:34 AM From: Tina Dam [EMAIL PROTECTED]View contact details To: linuxa linux [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Dear Meeku, Thank you for your email. The implementation of IDNs under existing TLDs have been done differently for each TLD. Some have followed a very careful approach and are initially only offering a few additional characters (in addition to the historic a,b,c...,z/0,1,2...9/-) in order to make sure that everything will still work well for the users. These introductions are entirely done based on technical and business decisions by the registries. .org is required to follow the IDN Guidelines, however, that does not require them to offer all characters available. If you would like to make registrations of domain names using characters from some of the Asian languages then please use the TLDs that currently offer such. Your registrar should be able to provide you with more details about which TLDs are available for you. I hope this is addressing your concerns. Please don't hesitate to let me know if you have any follow-up questions. Kind regards, Tina Dam Director, IDN Program ICANN - - - - - 3. RE: Complaint about .ORG Registry IDN - Asian Tuesday, 19 February, 2008 8:19 PM From: linuxa linux [EMAIL PROTECTED]View contact details To: Tina Dam [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Tina Thank you for your response. I see some problems with your not being critical of the .ORG registry that ICANN / you granted the license via not translating key things on your email. - the latest registry that took control of the .ORG suffix is meant to look after particular human interests, however this registry is not doing this job for .ORG because the vast majority of the world's languages have not being given Internationalised Domain Name facilities on the .ORG suffix - the .ORG is a gTLD representing the world's languages however the vast majority of the world's languages are barred as a result from Internationalised Domain Name facilities by this registry that took control of the .ORG suffix breaching human rights - thus any license / operation from ICANN to the registry that took control of the .ORG suffix is under the above 2 standards and I would be grateful if you take a critical view. I also want to complain about the way Internationalised Domain Name for .COM / .NET etc have generally been handled from a technical perspective. Though I am not an technical expert I can see as a user the poor service the user is getting. - The identity of the Internationalised Domain Name cannot be maintained throughout the Internet and world-wide web as the registrant-user of a Internationalised Domain Name has to give 2 website and email address, one based on their specific language and another that's is punycode machine code, just in case the previous does not work - There has not been any ample evidence showing what is being done to stop the problem from occurring - the punycode machine code website and email address is a lower service level for a user compared to a non-punicode website and email address - all these problems impact on the Internationalised Domain Name from a user perspective I also want to complaint about the fact that the Internationalised Domain Name system is not multilingual at the domain naming level (the field between the http://www; and .com/net etc suffixes) as you cannot mix different languages with each other. - Specifically I have a need for this from a religious, philosphical and spiritual reasons and I mentioned this on an October 2007 email. Regards Meeku - - - - - 4. RE: Complaint about .ORG Registry IDN - Asian Thursday, 21 February, 2008 9:49 PM From: Tina
Re: Unicode.org Software Internationalisation Standards Specifications
Doug, Thanks for your response that shows your knowledge and expertise about internet / computer things, common sense, organisational topics and also the replacing k/K to unicode 0915 glyph shape issue. You might as well send your message to your MP or to the Queen, for all the good it will do to send it to IETF. Airing the issue to the internet / computer community. I don't speak for their mailing-list administrator. The Unicode.org website home page copy that I quoted is not factual. Accusing an organization of process failure and insensitivity and stubbornness is not usually a productive way to get them to come around to your point of view. The Unicode.org website page copy that I quoted is not factual. You have stipulated that this constitutes The Unicode.org website page copy that I quoted is not factual. There should be some limitations. They don't have a demo that proves the first quote and the Unicode.org is not a framework. ...You are accusing Unicode of things it is not responsible for. This is like blaming the weatherman when it rains. The Unicode.org website page copy that I quoted is not factual. There should be some limitations. They should clarify what they are not responsible for. Their home page copy that I quoted is a trap for Unicode.org and readers. You are trying to change the basic form of a letter that has existed in the Latin alphabet for over two thousand years, on the basis of an association between the K glyph and the intersection of three rivers, derived loosely from a secondary Krishna text. [that the letter K represents suicide and needs to be changed] You are trying to change the basic form of a letter recognized by billions of people, and one of your first moves is to approach an international standards-making organization, which does NOT standardize the Latin alphabet itself and is NOT in the business of deciding what letters are supposed to look like, and accuse them of improper conduct because they do not immediately modify their charts and develop new fonts based on your views, which so far I have only heard from ONE person. To say you are outside the mainstream would be a serious understatement. The latin / roman k/K letter needs to be replaced to another shape for reasons you know. You have to understand that issue is beyond organisational management because it is related to human life. Approaching Unicode.org and IETF.org was essential because they claim to have various controls over internet / computer transmitted language. Some helpful interim things should be put in place, leadership and management is much needed. Unicode.org website home page communicates the wrong impression and they should correct that. Style of what?Content of what? The standard is described in excruciating detail at http://www.unicode.org/versions/Unicode5.1.0/ ..Unicode doesn't tell people how to design user interfaces. That is completely up to application developers, as it should be.See http://www.unicode.org/consortium/join.html .Unicode doesn't tell people how to build applications, whether open-source or proprietary. Do you feel it should? Thus Unicode.org has not any framework. Certain programmers thus become baffled. The Unicode.org home page copy that I quoted is not factual. There should be some limitations. It does not say that it will take you by the hand and show you how to program, configure, or use a computer in any language. Unicode.org are unjustly saying things on the website home page copy that I quoted, they are not communicating there what they are not responsible for. They are leaving this to other imaginations and trapping themselves and others. Unicode makes it possible to put tens of thousands of different characters on a .a plain-text document I refer to .txt files, are you also suggesting that you can put save a .txt file on the computer that has unicode 0915 glyph shape? What sort of framework are you looking for to accomplish your goals? Be specific, please, for once. I was being specific that there is not any framework about Style, Content, User Interface, Membership and Extensions, these generic areas that can help Software Internationalisation otherwise certain programmers would not get baffled for example at particular opensource code applications when they are asked to remove all k/K letters and replace them with unicode 0915 glyph shape. There should be some catch-all process / principle at header and footer of a code for example BBCode / HTML has this and this principle perhaps should be considered to ease the burden. I am not a coder / programmer thus I am not sure whether this way is possible. ..It can *only* mean granting of favors, such as employment or political status, to personal relatives regardless of their qualifications. You can say corporate nepotism if you like and English speakers will
Re: Unicode.org Software Internationalisation Standards Specification
Sorry about this error, The Unicode.org website page copy that I quoted is not factual and similar. I should clarify here, not that my gleaning and copy/pasting quotation from the Unicode.org website home page is unfactual, the Unicode.org content itself from their website home page is unfactual. Regards Meeku http://twitter.com/nepotism --- On Sun, 2/11/08, Joe Baptista [EMAIL PROTECTED] wrote: From: Joe Baptista [EMAIL PROTECTED] Subject: Re: Unicode.org Software Internationalisation Standards Specification To: [EMAIL PROTECTED] Cc: ietf@ietf.org, [EMAIL PROTECTED] Date: Sunday, 2 November, 2008, 2:08 PM This all smells bad. regards joe baptista On Sun, Nov 2, 2008 at 8:48 AM, linuxa linux [EMAIL PROTECTED]wrote: Doug, Thanks for your response that shows your knowledge and expertise about internet / computer things, common sense, organisational topics and also the replacing k/K to unicode 0915 glyph shape issue. You might as well send your message to your MP or to the Queen, for all the good it will do to send it to IETF. Airing the issue to the internet / computer community. I don't speak for their mailing-list administrator. The Unicode.org website home page copy that I quoted is not factual. Accusing an organization of process failure and insensitivity and stubbornness is not usually a productive way to get them to come around to your point of view. The Unicode.org website page copy that I quoted is not factual. You have stipulated that this constitutes The Unicode.org website page copy that I quoted is not factual. There should be some limitations. They don't have a demo that proves the first quote and the Unicode.org is not a framework. ...You are accusing Unicode of things it is not responsible for. This is like blaming the weatherman when it rains. The Unicode.org website page copy that I quoted is not factual. There should be some limitations. They should clarify what they are not responsible for. Their home page copy that I quoted is a trap for Unicode.org and readers. You are trying to change the basic form of a letter that has existed in the Latin alphabet for over two thousand years, on the basis of an association between the K glyph and the intersection of three rivers, derived loosely from a secondary Krishna text. [that the letter K represents suicide and needs to be changed] You are trying to change the basic form of a letter recognized by billions of people, and one of your first moves is to approach an international standards-making organization, which does NOT standardize the Latin alphabet itself and is NOT in the business of deciding what letters are supposed to look like, and accuse them of improper conduct because they do not immediately modify their charts and develop new fonts based on your views, which so far I have only heard from ONE person. To say you are outside the mainstream would be a serious understatement. The latin / roman k/K letter needs to be replaced to another shape for reasons you know. You have to understand that issue is beyond organisational management because it is related to human life. Approaching Unicode.org and IETF.org was essential because they claim to have various controls over internet / computer transmitted language. Some helpful interim things should be put in place, leadership and management is much needed. Unicode.org website home page communicates the wrong impression and they should correct that. Style of what?Content of what? The standard is described in excruciating detail at http://www.unicode.org/versions/Unicode5.1.0/..Unicode doesn't tell people how to design user interfaces. That is completely up to application developers, as it should be.See http://www.unicode.org/consortium/join.html .Unicode doesn't tell people how to build applications, whether open-source or proprietary. Do you feel it should? Thus Unicode.org has not any framework. Certain programmers thus become baffled. The Unicode.org home page copy that I quoted is not factual. There should be some limitations. It does not say that it will take you by the hand and show you how to program, configure, or use a computer in any language. Unicode.org are unjustly saying things on the website home page copy that I quoted, they are not communicating there what they are not responsible for. They are leaving this to other imaginations and trapping themselves and others. Unicode makes it possible to put tens of thousands of different characters on a .a plain-text document I refer to .txt files, are you also suggesting that you can put save a .txt file on the computer that has unicode 0915 glyph shape? What sort of framework are you looking for to accomplish your
Re: Unicode.org Software Internationalisation Standards Specifications
I don't want to discuss further this topic because I have received flamage accusations. I was reading that link you send however it is a bit complex for the non-coder / non-programmer. Have a good weekend. --- On Sun, 2/11/08, Doug Ewell [EMAIL PROTECTED] wrote: From: Doug Ewell [EMAIL PROTECTED] Subject: Re: Unicode.org Software Internationalisation Standards Specifications To: ietf@ietf.org Cc: [EMAIL PROTECTED] Date: Sunday, 2 November, 2008, 4:37 PM My last attempt to get through before PLONK. linuxa linux linuxalinux at yahoo dot co dot uk wrote: Unicode makes it possible to put tens of thousands of different characters on a .a plain-text document I refer to .txt files, are you also suggesting that you can put save a .txt file on the computer that has unicode 0915 glyph shape? No plain-text file, anywhere, in any language, in any character encoding, specifies the glyph shape. That is outside the domain of plain text. This e-mail, which is written in plain text, does not specify anything about the shapes of the letters, so even though I see it in Lucida Sans Unicode, 10 point, you might see it rendered entirely differently. You might see it in a serif font, or cursive, or in bold block capitals. If you were blind, you might not see it at all; you might hear it read to you by a screen reader. If you want the letter between J and L to be represented with a specific glyph, you have two choices: 1. Use U+004B or U+006B, the correct CHARACTER, but specify a particular font that renders that character as if it were U+0915. 2. Use U+0915 directly, which destroys searching and sorting, but which will usually be rendered the way you want (or as a box). The right thing to do, before carrying on this crusade against Unicode, would be to read and learn about the difference between characters and glyphs. See http://unicode.org/reports/tr17/#CharactersVsGlyphs. It is much easier to criticize than learn, however, so I doubt you will do this. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fw: Unicode.org Software Internationalisation Standards Specifications
Fyi Regards Meeku http://twitter.com/nepotism --- On Sat, 1/11/08, linuxa linux [EMAIL PROTECTED] wrote: From: linuxa linux [EMAIL PROTECTED] Subject: Unicode.org Software Internationalisation Standards Specifications To: [EMAIL PROTECTED] Date: Saturday, 1 November, 2008, 4:07 PM This portion is from the home page of the Unicode.org website: Welcome! The Unicode Consortium enables people around the world to use computers in any language. Please show me how to use my computer in any language with a demo and if you cannot then say, Welcome! The Unicode Consortium enables people around the world to use computers in any language [though there is not as yet a demo to show people how this is possible.] Our members develop the Unicode Standard, Unicode Locales (CLDR), and other standards. These specifications form the foundation for software internationalization in all major operating systems, search engines, applications, and the Web. Why then are certain programmers getting baffled by the code for example at opensource code applications when they are asked to specifically replace all k/K letters to unicode 0915 glyph here (1) Style (2) Content (3) User Interface (4) Membership (5) Extensions, thus are you saying that your standards and specifications not have a framework for these generic areas because then you should say Our members develop the Unicode Standard, Unicode Locales (CLDR), and other standards [without a framework]. These specifications form the foundation for software internationalization in all major operating systems, search engines, applications, and the Web [without a framework.] Regards Meeku http://twitter.com/nepotism ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Unicode.org Software Internationalisation Standards Specifications
--- On Sat, 1/11/08, Doug Ewell [EMAIL PROTECTED] wrote: From: Doug Ewell [EMAIL PROTECTED] 1. The Unicode Consortium is not an IETF organization. Complaining to IETF, ICANN, or any other such organization about the statements or policies of the Unicode Consortium will have no effect. Nevertheless because there is some internet / computer relationship between Unicode.org and IETF.org and did you know Unicode.org blocked that Fyi message I copied to IETF.org from their mailing list. Thus Unicode.org don't wish to be criticised and they like their mutual appreciation society. 2. Do you have an example of a written language in which you cannot use a Unicode-enabled computer, because of something the Unicode Consortium has or has not done? The Unicode Consortium is not responsible for showing you how to use your computer. Yes actually due to Unicode.org I cannot properly use english language where all the k/K letters are replaced with unicode 0915 glyph via HTML because the line spacings are not all equal. I don't see at the english unicode table another unicode 0915 glyph shape unicode number that allows choice not to use k/K alphabets. I don't see qualitatively / graphically on websites that use unicode the same unicode 0915 glyph shape that you see on the unicode table. Also there is not a lower case unicode 0915 glyph at sunskrit or at english unicode table. 3. The Unicode Consortium cannot be responsible for what baffles certain programmers, whoever they may be. The Unicode Consortium defines coded characters and their properties and general techniques for working with them. It does not specify or mandate particular software development products that must be used to make applications compliant. I don't know if that's what you mean by without a framework; if not, please clarify. Unicode.org Software Internationalisation Standards Specifications are sans / without framework. Thus certain programmers are getting baffled where to locate these generic areas, (1) Style (2) Content (3) User Interface (4) Membership (5) Extensions at certain opensource applications, where they can remove the k/K letters and replace them with unicode 0915 glyph. Unicode.org is trying to falsely say on it's website what it's doing things without clarifying. Thus I put the points about demo and framework. 4. You have used the word nepotism before in similar e-mails. You are aware, aren't you, that the English word nepotism refers to the granting of political positions, employment, or other favors to one's relatives on the basis of personal relationship instead of qualifications? It has nothing to do with organizations working together, or holding similar viewpoints, or anything related to this K is evil campaign. Continuing to apply the word nepotism inappropriately to your opponents in this effort will only cause people to take your effort less seriously, and may cause you personal embarrassment as well (though this is probably mitigated by your use of only a first name and pseudonym in your postings). Unicode.org and IETF.org can also have nepotism and this can be evidenced from final decisions and mid-way deliberations, where you find a biased decisions and individuals. Perhaps you can put the words organisational / corporate before the word nepotism if it helps you. I wish to point out this nepotism tendency. I hope this effort will be seen constructively. Regards Meeku http://twitter.com/nepotism ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Unicode.org, ICANN.org IETF.org
Hello Ladies Gentlemen, I posted this as a posting series at the Unicode.org list and I am posting parts of the same here for your comments. .Due to the ASCII character encoding being the core/monopoly and primarily basis to the internet/web infrastructure that has become the conventional starting point for subsequent Unicode and Punycode character encoded internet/web, this has brought usability and integration problems for a truly multilingual internet/web because presently you cannot have domain names that are multilingual, for example: japanese and english language mixed character domain names, hindi and english language mixed character domain names etc. Another example, there is not much browser / URL bar integration and usability innovation that allow for a non-ASCII language domain name to stay non-ASCII script on the browser / URL bar without it changing to Punycode. Thus there is a basic underlying problem that can only be rectified when all the languages get represented on the internet/web infrastructure and not only ASCII character encoded languages. ASCII monopoly has not helped usability and integration for the internet/web and a Unicode approach is need. Unicode has accomplished things at the non-internet computer ground and now it needs to expand at the internet/web ground. Otherwise things are not equal between the ASCII and non-ASCII languages. For example you are seeing Punycode and not the non-ASCII script for non-ASCII domain names on the browser / URL bars -- a solution for this example here could perhaps be to have even ASCII based domain names to be also Punycoded as a standard not just non-ASCII based domain names to be Punycoded, thus bringing equality. When you get equality between the two then there will be browser / URL bar integration and usability innovation simultaneously between all the languages. I put this to Tina Dam at ICANN, the person handling these issues and Paul Twomey, the ICANN President/CEO and Pamela Miller at PIR the .ORG registry a few months ago however there was not much progress with them. .Fyi, I said to the ICANN-family that they was nepotism because they were not showing equality when it cam to the multilingual internet/web.Why should ASCII based internet/web always be the primarily and conventional way for the internet/web? Non-ASCII languages should also become part of the internet/web infrastructure and Unicode.org and ICANN.org [and IETF.org] etc should make this a truly multilingual internet/web a reality. I now move to another topic and this is to ask the list if it is possible to get a different alphabet shape (and code point) on the english/european Unicode Table group/s that can allow the option to replace a particular english/european unicode alphabet at both upper and lower cases if the user / viewer wish? I can understand that there is not a precedent however would a public petition be the way? Please say what the requirements and procedures are? Also based upon this, please can someone say how ASCII can be altered also to accommodate this?. .Specifically I would like to discuss the 11th letter of the english/european language, please view this posting with UTF-8. I would like users and viewers the option not to use the k and K shaped letters of the english/european languages for their english/european language usages and instead use another alphabet, lower and upper case क. There is a BBT font that does this and I state how via what someone mentioned: English font where the glyph representing the English k(Unicode 0x004B and 0x006B) has been replaced by a glyph representing the Hindi [I would say Devanagri] ka(0x0915) [क]. You can get the BBT font from here: http://openfontlibrary.org/media/files/BBT/239 The BBT font has both a lower and upper case equivalents for क. The lower case क is not on the Unicode Table and thus does not have a code point. Also when you use the unicode code point 0915 alphabet [क] on the internet/web, the output generated is not qualitatively exactly the same compared to what you see on the Unicode Table at Unicode.org, for example the left upper swirl on the devanagri alphabet क is not meeting the line, see http://www.geocities.com/linuxalinux/2325.html This becomes more visible the more you magnify the browser view. Then when you try to use the devanagri alphabet क with the other english/european alphabets on a website, the line spacing is not equal, see http://www.geocities.com/linuxalinux/testingk.html and this becomes more visible the more you magnify the browser view. Thus I would like to find out how a different alphabet (क) can be a given new code points and put on the english/european Unicode Table for usage by these languages? This is obviously new and there is not any precedent thus would a public petition will be the only way for it to be considered and justified? Other further
