<br><br><div class="gmail_quote">On Wed, Dec 19, 2012 at 3:09 AM, Brian E Carpenter <span dir="ltr">&lt;<a href="mailto:brian.e.carpenter@gmail.com" target="_blank">brian.e.carpenter@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 19/12/2012 04:59, John R Levine wrote:<br>
...<br>
<div class="im">&gt;&gt; I am a developer, and when I have to carefully read each word and<br>
&gt;&gt; analyze the meaning of each sentence, there is no better support for<br>
&gt;&gt; me than a printed page in ASCII.<br>
&gt;<br>
&gt; I also write my share of code that implmenents various standards, and I<br>
&gt; prefer a printed page that looks typeset, not like a 1960s line printer,<br>
&gt; or maybe something on my tablet, or legible on my screen.<br>
<br>
</div>Isn&#39;t the point that the normative text MUST be unambiguous and<br>
universally displayable/printable? I don&#39;t think that imposes ASCII,<br>
but it is still a very strong constraint. In a sense, ASCII is the<br>
lazy way to implement that constraint. Saying &quot;any Unicode and any<br>
font is allowed&quot; clearly does not meet the constraint. We have to be<br>
somewhere in between.<br></blockquote><div><br></div><div>Why does normative text need to be displayable on every machine?</div><div><br></div><div>If I get a punch card reader, does the IETF have to support that? How about paper tape?</div>
<div><br></div><div>The technical change that is now driving this is the proliferation of smartphone type devices that have the interesting property that they support virtual keyboards. Until now the only way to input many languages into a computer has been through a keyboard with a Latin alphabet and Arabic numerals. So Japanese and Chinese users of the Internet have been familiar with ASCII transliteration hacks as of necessity. </div>
<div><br></div><div>With the virtual keyboard, that requirement goes away... So assuming that the Japanese speaker will know how to use a Western alphabet is going to be an increasingly bad assumption.</div><div><br></div>
<div><br></div><div>Yesterday my wife discovered that the reason she could not use the company VPN from home was that she has an ampersand in her password (they do demand a non alphabetic character). The problem was that the developer had only tested on a limited character set (and quite likely there is a SQL injection issue).</div>
</div><div><br></div><div><br></div>What concerns me is that we get coverage of the significant use cases. If we are going to write specs that can be used by German speakers in their own language we have to go beyond 7 bit ASCII. If we are going to support languages that have a non-Latin alphabet we need to go beyond the 8-bit code to UNICODE.<br clear="all">
<div><br></div><div>I don&#39;t think we need to support Zapf&#39;s Dingbats but we should choose at least one non-English language that uses a Latin character set plus accents and one that uses a non-Latin character set.</div>
<div><br></div><div>The point here is to make the specs better by encouraging developers to consider examples that are non English usage examples. We use Alice and Bob as users all the time We could do with adding Anaïs and Benoît for French, Алла and Борис for Russian.</div>
<div><br></div><div>Unicode is pretty regular. If something works for French and Russian it is pretty likely to work for any written language based on an alphabet and quite likely Japanese and Chinese. Add in one of those two and you can be confident of supporting pretty much any living language other than Korean.</div>
<div><br></div><div>One of the features of communications is that the smaller the community of speakers, the smaller the complexity that can be tolerated. A language like Chinese or Korean which has been a written language for thousands of years and has had millions of literate speakers can be very complex. A language like Cornish which has a few thousand speakers is forced to use an existing alphabet and can&#39;t make any special typographic demands if it is going to survive.</div>
<div><br></div><div>So from the point of view of covering possible corner cases, the big languages are more likely to give rise to them than the small ones.</div><div><br></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
<br>