Re: Unicode is so flawed that 7 or 8 bit encoding is not an issue
James; As you could have seen, on IETF mailing list, Harald and I have, at least, agreed that, if you use unicode based encoding, local context (or locale) must be carried out of band Few will disagree (including me) that using Unicode to do localization is almost impossible without locale context. Huh? No one said such a thing. What is agreed is that, to use unicode, it must be supplied out of band local context. So, could you explain how the context is supplied with current IDN spec? But I am touching on a sensitive topic about what you considered as I18N L10N and what the rest of the world thinks. Totally irrelevant. But, anyway, the discussion so far in IETF list is enough to deny IDN. I am not aware there was a IETF wide last call on IDN yet. To deny IDN, IESG can simply say IDN is disbanded. There is no last call necessaruy. I have found a theory to deny PKI and to explain why public key cryptograpy is not so polular dispite the efforts of ISO, which will destory entire business of a company or companies owing several important TLDs. Very interesting. Could you share the theory, or privately if you prefer? I will post it later if I have time. Masataka Ohta
Re: Unicode is so flawed that 7 or 8 bit encoding is not an issue
Few will disagree (including me) that using Unicode to do localization is almost impossible without locale context. Huh? No one said such a thing. What is agreed is that, to use unicode, it must be supplied out of band local context. In that case, I disagree with to use unicode, it must be supplied out of band local context. You only need out of band local context to use Unicode if you are doing localization. So, could you explain how the context is supplied with current IDN spec? Internationalization as defined in POSIX, means making software location neutral. Making a program specific to any particular language or culture or codeset is known as localization. I in IDN is Internationalization. I am not aware there was a IETF wide last call on IDN yet. To deny IDN, IESG can simply say IDN is disbanded. There is no last call necessaruy. Ah of course IESG can. But sorry, you dont represent IESG. I have found a theory to deny PKI and to explain why public key cryptograpy is not so polular dispite the efforts of ISO, which will destory entire business of a company or companies owing several important TLDs. Very interesting. Could you share the theory, or privately if you prefer? I will post it later if I have time. Please do. Thanks. -James Seng
Re: I don't want to be facing 8-bit bugs in 2013
You want to be facing 8-bit bugs in 2002? I recommend reconsideration of priorities. -- James W. Meritt CISSP, CISA Booz | Allen | Hamilton phone: (410) 684-6566
RE: Netmeeting - NAT issue
Aaron Falk wrote: I think one can make the case that having border protection may prevent a DOS attack from consuming interior network resources and allowing interior hosts to communicate amongst themselves. And if your interior network resources are less than 10x your external resource, you have an unusual network indeed. Yes it may be more convenient to have the border deal with DOS, but is it *required* as Noel asserted? We've recently had some fierce DOS attacks on our ISP but I'm still able to run NFS without a problem. This is a good thing. NFS 'good thing' are a matter of personal opinion. In any case if NFS has trouble running when it has less than 90% of the interior resource, one might have to question which set of packets should be defined as the DOS. Tony
RE: Netmeeting - NAT issue
From: Tony Hain [EMAIL PROTECTED] it may be more convenient to have the border deal with DOS, but is it *required* as Noel asserted? First, there's good idea, required, and *required*. It's *required* that your computer have a test-and-branch instruction to be a Turing machine. It's not *required* that it have a jump instruction, but all computers do - so it're pretty much required in a machine architecture. An example of good idea would be lots of registers - most machines have that, but not all. Etc, etc. I never said it was *required* to have some security functions at the border - merely that it was likely to happen for a variety of reasons (e.g. policy enforcement in a large organization). I think my meaning was somewhere between good idea and required (as defined above) - I don't know exactly where. Second, when I made my statement about security alone demands that we be able to move some functionality to a 'site border router', or some such, I was speaking of security stuff in general, not DoS protection in particular. I think there are different kinds of DoS attacks (I actually created a taxonomy of DoS attacks for a research effort I'm involved with), and I expect that different DoS attacks will need different mechanisms to handle them (i.e. in the most efficient and robust manner - bearing in mind the old adage that and engineer is someone who can do for $1 what any fool can do for $5). I suspect that some might be at the borders, some might be at the servers - but that's my intuition. But DoS is still a very limited corner of security. Noel
Moving Towards UTF8 vs ASCII(ACE) Forever
An underlying question we must ask ourselves from all the discussions that have sprung up every now and then is: Do we wish to 1. eventually move the DNS towards UTF8/16 OR 2. do we want to stay with ASCII(ACE) for the rest of our lives? If the answer is 1. then the IDN solution should take it into concern. If it is 2. then perhaps the IETF should revise some of its internationalization policies. I can see an arguement coming that says there is no draft on this, but if we dont even get this fundamental question figured out, how can there be a collective or meaningful effort towards a solution that makes most sense?? Edmon PS. Perhaps we should have a show of hands or something about the real DIRECTION that PEOPLE want to see with the internationalization of the Domain Names.
Re: [idn] Re: I don't want to be facing 8-bit bugs in 2013
Unicode is not usable in international context. ... It would not be worth replying to these threadworn and repeated assertions by Mr. Ohta, except that some members of this list may not be that familiar with Unicode. Clearly Unicode is being used successfully in a huge variety of products in international contexts. For more information on the CJK repertoire (which is the part Mr. Ohta objects to), see http://www.unicode.org/unicode/faq/han_cjk.html. Mark — Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com - Original Message - From: Masataka Ohta [EMAIL PROTECTED] To: Robert Elz [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 20, 2002 07:58 Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 Kre; | IDNA does _not_ work, because Unicode does not work in International | context. This argument is bogus, and always has been. If (and where) unicode is defective, the right thing to do is to fix unicode. Unicode is not usable in international context. There is no unicode implementaion work in international context. Unicode is usable in some local context. There is some unicode implementaion work in local contexts. However, the context information must be supplied out of band. And, the out of band information is equivalent to charset information, regardless of whether you call it charset or not. So, stop arguing against unicode (10646) - just fix any problems it has. Fix is to supply context information out of band to specify which Unicode-based local character set to use. With MIME, it is doable by using different charset names for different local character set. See, for example, RFC1815. As for IDN, it can't just say use charset of utf-7 or use charset of utf-8. IDN can say for Japanese, use charset of utf-7-japanese. Or, if you insist not to distinguish different local character sets by MIME charset names, IDN can say use charset of utf-7, but, for Japanese, use Japan local version of utf-7 and somehow specify how a name is used for Japanese. Anyway, with the fix, there is no reason to prefer Unicode-based local character sets, which is not widely used today, than existing local character sets already used world wide. Masataka Ohta
Re: Unicode is so flawed that 7 or 8 bit encoding is not an issue
[Note: IDN WG list removed] As you could have seen, on IETF mailing list, Harald and I have, at least, agreed that, if you use unicode based encoding, local context (or locale) must be carried out of band Few will disagree (including me) that using Unicode to do localization is almost impossible without locale context. But I am touching on a sensitive topic about what you considered as I18N L10N and what the rest of the world thinks. But, anyway, the discussion so far in IETF list is enough to deny IDN. I am not aware there was a IETF wide last call on IDN yet. I have found a theory to deny PKI and to explain why public key cryptograpy is not so polular dispite the efforts of ISO, which will destory entire business of a company or companies owing several important TLDs. Very interesting. Could you share the theory, or privately if you prefer? ps: btw, what effort of ISO are you referring? So, don't bother to say that there are so many so-called-international- but-actuallly-local domain names registered. Huh? Since when this was ever a factor in IETF consideration? -James Seng
Re: [idn] WG last call summary
On Mar 19, D. J. Bernstein [EMAIL PROTECTED] wrote: Go sell a Greek user an ``internationalized domain name'' with a delta, Pete. Then tell him that most of his correspondents will see the delta as incomprehensible gobbledygook rather than a delta. See what he says. Okay, I'm not Greek, but as the registered owner of .com, I'll tell you*. I expect that some windoze users will display it (.com) as a box dot com; mac users will display it as a delta dot com; and everyone else will display it as a bq--eida.com (RACE), or dq--uuyg.com (DUDE), or zq---h9g.com (AMZ_C), or punycode, or whatever -- AND, they will continue to do so until they have the appropriate software on their machines to handle the conversion. That's what I expect. On the other hand, I do not expect that the IDN will eventually produce something that will transparently produce the appropriate glyphs on millions of users machines. In my mind, that's simply not possible because I think it requires that every machine on this planet have a complete copy of UNICODE installed and available. Granted, I am clueless about a lot of this IDN stuff and I may be hubris (as Mr. Paul Hoffman once informed me) in my offering my opinion to the Gods of the Internet, but I do think I see the distinction between which side of the modem one is on and what responsibility lies in each camp. OK, scenario 1: You tell him that although it's gobbledygook to people without greek alphabet support, it will still work. It's not convenient, but it WILL work. Guaranteed. For his business colleagues and friends in Greece, who DO have the latest and greatest software, it will display as a delta. His ISP hasn't had to upgrade, and everybody in the world can use his domain - eventually they will see it as a delta as well, but for now they see it as an encoded string they can still use no problem. -snip If you were IT director of a large firm, and you had a choice as to which to roll out, which would you choose? -- Paul Robinson I would vote for scenario 1. Besides, IMHO (in my hubris opinion) that's the only way it's going to work. tedd * The Greek version of delta registers a internal error -- it's the Math language set that provides an acceptable delta. -- http://sperling.com
Re: I don't want to be facing 8-bit bugs in 2013
Date:Thu, 21 Mar 2002 00:57:18 +0859 () From:Masataka Ohta [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Otha-san | Anyway, with the fix, there is no reason to prefer Unicode-based | local character sets, which is not widely used today, than existing | local character sets already used world wide. Let's assume that local char sets, and an explicit indication of which to use is adequate for this purpose (as Harald has said, and I agree, that's not sufficient for all purposes, but for stuff like domain names, file names, etc, I suspect it is). Then, let's take all the MIME names of those charsets, and number them, 0, 1, 2, 3, ... (as many as it takes), that's a 1::1 mapping, after all the mime charset names are in ascii, we wouldn't want to keep that. Then, rather than labelling whole names with a charset, we'll label every individual character, so if, by some strange chance, ascii (or 8859-1) happened to be allocated number 0, then 'A' would be 0-65. This way we can mix and match names with characters from any random character set (it may be a little less efficient than one label per name but that's OK, assume we'll pay that price for the flexibility). No, we'll just list all the possible characters in all the char sets, with their char set numbers attached, in one big table. What we have at that point is (essentially) 10646 - unicode. Just up above you said this works (throwing in some redundant labelling cannot cause it to stop working, nor can altering the labels from ascii to binary numerals). Of course, a large fraction of the char sets that we just listed in a big table contain ascii as a subset,so we end up with dozens of versions of A (it's in 8859-1 8859-2 ... tis-620 (Thai) ...). All of those A's are in all respects identical, keeping them will do no more than cause interoperability problems. So let's go through and squash all the duplicates. and then renumber everything to be a bit more compact (the renumbering is a 1::1 operation that alters nothing important). Having done that, we have exactly 10646 (or can have, if we picked the right character sets for our initial big list of everything, gave them the appropriate char set numbers, and compressed the number spaces in just the right way). Again, you said above, this works. The only place in all of this where there's any possibility of a problem is in the squash all the duplicates - if some characters that are duplicates aren't removed, or some that aren't are treated as if they are. If this happened, then there'd be a bug in the actual character tables (too many, or too few) - but this doesn't alter the principle of the thing. If there is a bug like this (which I am not able to judge) then someone should get it fixed. Whether or not there is a bug, the unicode/10646 approach is clearly the most flexible way, and is perfectly adequate for, labelling things using whatever characters anyone wants to use - internationally or locally. There is simply no way to rationally claim that a local char set, plus label, is adequate and unicode is not. kre
Looking ahead to IETF 54
As a frequent visitor to Japan, I am planning to put together some kind of guide and put it on a web page somewhere, more on that later. Meanwhile, please mark your calendar for: 1. Akihabara (electronics town) Geek Tour, Sunday July 14. On Sundays, the Main Drag aka Chuo Dori is closed to cars and Akihabara will be full of people shopping for the latest gadgets. Meet at entrance to Landmark shopping center at 11am. We will return before 5pm in time for the welcome reception. 2. Minato Mirai Hall Fisk Pipe Organ Demo. Monday, July 15, 6pm. Details to follow. http://www.city.yokohama.jp/me/mmhall/about/pipe-e.html When you plan your travel, consider using Osaka (KIX) as you entry point instead of Tokyo. If you do, you should stop in Kobe or Osaka and visit the world's longest suspension bridge: http://www.hsba.go.jp/bridge/e-akasi.htm You'll also have easy access to Kyoto. Then take the bullet train to Yokohama. Get a Nozomi if you can, they are the fastest. See you in Yokohama! Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office of the CTO, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj
Re: Moving Towards UTF8 vs ASCII(ACE) Forever
Do we wish to 1. eventually move the DNS towards UTF8/16 OR 2. do we want to stay with ASCII(ACE) for the rest of our lives? it's a false dichotomy. first, there are probably some purposes for which identifiers (including DNS names) should stay ASCII (and not even 10646 encoded as ASCII) for the forseeable purpose. there are other purposes for which IDNs are useful. second, ASCII for the rest of our lives is a mischaracterization. IDNA allows applications to accept and present IDNs in native form, without requiring all applications and infrastructure to upgrade before IDNs can be used. IDNA is designed to maximize the rate at which IDNs can be deployed. users don't care whether IDN queries are encoded on the wire. they only care about whether IDNs work for them. IDNA puts the user in a position to determine whether IDNs work for him - a UTF-8 everywhere approache forces him to wait for everybody else to adopt IDNs before he can use them. Keith
Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever
Provably false: well-coded applications know the limitations of domain names, and do not even attempt to make requests for non-ASCII names. First of all, I disagree with the well-coded part because I believe a well-coded application will do the dns request as is and allow the dns response to determine the validity of a domain name. Nope. You can almost certainly give your user a better error message if you validate the input yourself. For that matter, a well-designed application will not even make it possible to enter anything but ASCII in an input field (whatever) for a domain name. Basic rule of usability: making user mistakes impossible is better than catching them after the fact. Secondly, if this is the case, then the plugin should be intercepting the input to the app and not the output. It is still a possibility. No, because that input is highly application-specific. /\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |Diplomacy: The art of letting someone else have your way| \/
Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever
John Stracke writes: For that matter, a well-designed application will not even make it possible to enter anything but ASCII in an input field (whatever) for a domain name. That's incredibly bad design. You're violating the basic principles of information hiding articulated by Parnas in the early 1970s. Instead of isolating the name-existence decision in one place (the DNS server's database), you're spreading the decision across a huge number of programs on a huge number of machines. Changing a decision becomes extremely expensive. We're seeing the economic consequences of this in BIND's res library. That library is the most widely used UNIX DNS-lookup mechanism, and is one of the largest sources of UTF-8 failures; see http://pi.cr.yp.to. It has to be fixed on a huge number of machines. (Note that this cost, together with the other costs of making UTF-8 IDNs work, is only a tiny fraction of the costs of making IDNA work.) If you think that the 8-bit problems in res are an example of people agreeing with your design ideas, you're mistaken. The change was made in a panic in 1996, when CERT announced that several programs had security flaws based on careless use of DNS PTR results. Of course, anyone who thinks about the problem for a moment can see that unusual DNS A _input_ has no relevance to the security issue, but people in a security-related panic often don't stop to think about the damage they're causing. Basic rule of usability: making user mistakes impossible is better than catching them after the fact. You obviously aren't achieving that goal. You're catching typos if and only if they involve non-ASCII characters. What about ASCII typos? What is the basis for your assertion that the no-such-name message should, as a matter of UI design, be different between these two situations? Even worse, what about ASCII typos that produce valid domain names? Basic rule of usability: Have the computer copy the data so that the user doesn't have an opportunity to make a mistake. Saves time, too. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
7 bits forever!
Keith Moore writes: IDNA is designed to maximize the rate at which IDNs can be deployed. I hereby declare that cs.utk.edu is an IDN. We will now spend twenty years trying to convince all application programs to display it as the international picture of an ostrich with his head in the sand. Look, Keith, we've deployed an IDN in zero time! Infinite rate! You didn't even have to touch your DNS records! Boy, I'm glad that, when you faced the much smaller problem of non-ASCII subject lines back in 1991, you and your buddies decided to ``maximize the rate'' of deployment by inventing your own encoding mechanisms, rather than giving in to the demands of 8-bit transparency. Oh, sure, we still have quite a few display failures eleven years later, and users in Europe are constantly sending raw ISO 8859-1 in violation of your 7-bit requirement, and sendmail still has problems with UTF-8, and now we're facing years of IDNA pain followed by years of IDNA-MAILBOX pain, but you were able to _instantaneously_ deploy Quoted-Printable back in 1991, and that's what matters! Brilliant! Even better, your incisive design decisions mean that billions of people will be able to continue using their 36-bit computers, which, as you know, are incapable of processing character data in units other than 7 bits, because 36 is not divisible by 8, but it is divisible by 7, um, well, except for the remainder of 1, but who's counting? The point is, Keith, THANK YOU! You've made all our lives so much better! I hope someday you can travel to Taiwan and meet some of your fans. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
Re: Netmeeting - NAT issue
On Thursday, March 21, 2002, at 06:15 PM, [EMAIL PROTECTED] wrote: Of course, there is the possibility that if they were totally honest, and marketed their devices as Enabling appliances for selected Internet services that they'd STILL make money (and then you'd have no one to blame). Please read the warning below and keep NAT products away from kids and children who are not old enough to understand the risks of network address translation: INTERNET ARCHITECTURE BOARD WARNING: Using Network Address Translators Causes Loss of Routing Transparency and may Complicate Application Protocol Interoperability in the Internet. Thank you! -- j h woodyatt [EMAIL PROTECTED] please network responsibly.
