Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet Government IT Politics

International URLs Pass First Test 159

Posted by Zonk from the nice-to-see-some-new-faces-online dept.
Off the Rails writes "The BBC reports on the results of a successful test of non-ASCII domain names on Internet-equivalent hardware (pdf) carried out last October. The next stage is to plug the system into the net, and if it still works, it could go live sometime next year. 'Early work on the technical feasibility of using non-English character sets suggested that the address system would cope with the introduction of international characters tests were called for to ensure this was the case ... Also needed are policy decisions by Icann on how the internationalised domain names fit in and work with the existing rules governing the running of the address books. Icann is under pressure to get the international domain names working because some nations, in particular China, are working on their own technology to support their own character sets.'"
This discussion has been archived. No new comments can be posted.

International URLs Pass First Test More

International URLs Pass First Test

Comments Filter:

  • Great (Score:5, Funny)

    by otacon ( 445694 ) on Tuesday March 13, 2007 @10:22AM (#18332799)
    now I have to learn second languages to look at asian porn.

  • Phishing just got a lot more interesting (Score:5, Funny)

    by L. VeGas ( 580015 ) on Tuesday March 13, 2007 @10:25AM (#18332827) Homepage Journal
    Imaging all the new ways to spell bank0famerlca.com.

    • Re:Phishing just got a lot more interesting (Score:4, Informative)

      by slart42 ( 694765 ) on Tuesday March 13, 2007 @10:39AM (#18333185)
      >Imaging all the new ways to spell bank0famerlca.com.

      This is already happening. A common example is the cyrillic lower case "?", which looks almost exactly like the latin "a" in most fonts.

      See http://en.wikipedia.org/wiki/IDN_homograph_attack [wikipedia.org] for more information.

    • Re: (Score:3, Informative)

      by colfer ( 619105 )
      Preventing that has been part of Mozilla's IDN implementation, and I assume other browsers have addressed (ha) it as well. If a TLD, like .ie, Ireland, has a policy against phishing, and a table of lookalike letters, then Firefox will present the IDN address in the address bar in its own, non-English, language. Otherwise, Firefox displays the address in its IDN-encoded form, which is all ASCII. AFAIK, from reading bug reports on Mozilla, this is already in force.

    • Re: (Score:1)

      by Alky_A ( 1015285 )
      I'd hope the first update all the browsers get is a 'language' label next to the address bar showing the language all the characters in the URL are from. URLs with multiple languages would then get a big flashing red bar screaming "OMG PHISH PHISH."
    • It's not going to work. Would you visit address bkófmrika.com? (Caution - polish letters, if you do not have appropriate font, you will just see question sign "?")

      • Re: (Score:2)

        by SnowZero ( 92219 )
        True, but I think the more likely spoof would be something like "bankófamerica.com". If the history of phishing is a guide, that will net some users. I don't know if they are already considering such a thing, but limiting each component in the URL to a single language character set might be a good idea.

        To me, the best approach would be to limit the character sets that can appear below any given TLD. So, having simplified Chinese under ".ch" would be fine, but not under ".com" or ".us" -- The idea be
    • Informing the user that some URL might be something different from what they thought it was supposed to be so that they can hopefully recognize fakes is just plain stupid. It relies on people interpreting information and people make mistakes, so a phisher just keeps trying until somebody messes up. Plus, it presumes excellent eyesight... some people can't really tell an 'o' from a 'e' in a normal English font, either from bad eyesight or bad monitor or both. Some people can't tell a 'b' from a 'd' due to
  • Non-ASCII? This is awesome! I can't wait for the ANSI addresses to start showing up.

    • Re: (Score:2)

      by omeomi ( 675045 )
      Yeah, that'll be just great. "Oops! I mistyped the address...I forgot the e was supposed to be #DD44AA, while the s and the x are supposed to be #FF22BB".

  • Dibs! (Score:4, Funny)

    by truthsearch ( 249536 ) on Tuesday March 13, 2007 @10:26AM (#18332865) Homepage Journal
    I got dibs on sêx.com!

    • Re: (Score:3, Informative)

      by kimba ( 12893 )

      I got dibs on sêx.com!


      Umm, you do realise this was registered in 2005? Such domains already exist and can be registered today.

      The technical test is about having Internationalised Domain Names at the top-level, or root, of the DNS. So then you can have .sêx rather than .sex.

      • Re:Dibs! (Score:5, Funny)

        by VWJedi ( 972839 ) on Tuesday March 13, 2007 @12:27PM (#18335137)

        The technical test is about having Internationalised Domain Names at the top-level, or root, of the DNS. So then you can have .sêx rather than .sex.

        So we could theoretically have sex at any level... but this is slashdot, so it's not likely to happen for anyone around here.

  • Phishing (Score:2, Redundant)

    by Alioth ( 221270 )
    In my skim through the various links, I didn't see what they are proposing to do for practical real-world problems such as phishing. What are they going to do to ensure that a phisher doesn't register a domain with characters that look almost indistinguishible from different characters in a different language, so as to trick users into visiting the phisher's site instead of the legitimate version of the site?

    • They'll do the same as is done right now: very little. If you're a company in this day-and-age, you have to register as many variants of your name as you can to ensure that phishers/domain squatters don't get undue traffic from your name. On the other hand, phishers don't necessarily need domain names that are close to their target domain; people don't generally read URLs that closely, just clicking on links they are sent. That's why phishing is still effective despite all the negative publicity.

    • Call them, say, "character sets.

      Then only allow names and queries all from the same character set.

       
      • Okay, I'll bite. I have what I think amounts to a fairly good, if basic, understanding of how internationalized character sets and encodings work, but I don't understand how you'd encode multiple character sets into one URL.

        I mean, first of all, in order to use non-Latin characters at all, you have to have some way of transmitting which character set / codepage you want to use. I can't find any place in TFA where they actually describe how this is going to work (although I didn't read the PDF, so perhaps it

    • Re: (Score:3, Informative)

      by evought ( 709897 )

      This has actually been discussed to some extent for years. One method is to only allow domains to be registered or displayed in a single language character set, such that a domain name can use latin characters or greek characters, but not both. This can be enforced at registration or when displayed in the browser (the browser can highlight improper URLs). This does not prevent attacks where the entire spelling of the domain is available in an alternate character set. One solution is for the browser to some

  • While browsers can't even properly show non-english alphabet, this doesn't seem to be a good a idea. My native language contains many special characters and I usually end up deciphering the emails sent by mom to me, because along the way, servers replace these characters with funny things.

    • Re:Maybe not.. (Score:4, Insightful)

      by LighterShadeOfBlack ( 1011407 ) on Tuesday March 13, 2007 @10:38AM (#18333167) Homepage

      While browsers can't even properly show non-english alphabet, this doesn't seem to be a good a idea. My native language contains many special characters and I usually end up deciphering the emails sent by mom to me, because along the way, servers replace these characters with funny things.
      Well is it the browsers or the servers that are the issue? AFAIK any modern browser fully supports Unicode and any other encodings so there shouldn't be an issue there. If the servers are the problem then either it's the protocol that needs updating/replacing (I don't know nearly enough about SMTP, IMAP4, or POP3 protocols to comment) or the servers themselves are non-compliant. If there's a problem it should definitely be fixed, but you really need to know what the problem is first.
      • Considering a lot of email is text, the inability to handle a character set may make it impossible for some people to email you if you have non-ascii characters in your address. Even people in your own country may have trouble. Not everyone uses the Outlook / Exchange combo...

        • Re: (Score:3, Informative)

          by Petrushka ( 815171 )
          Just about any e-mail service should enable the use of non-ascii characters. Any halfway decent e-mail client will; if you're using Thunderbird or Mail or Pegasus, just set the character set to UTF-8; I believe Pine allows UTF-8 too. (Personally I can't imagine any reason for not using UTF-8 as default; I use it all the time, even though almost all of my e-mails are in English.) Most web-interfaces allow it as well: Gmail certainly does, for example; I'm pretty sure Yahoo does.

        • Re: (Score:2)

          by fbjon ( 692006 )
          Such mail clients deserve to die already, IMHO. Not that I want to pressure anyone, but really, life and requirements move on.
    • Most modern browsers can show the characters. Even IE 6 and older versions of mozilla have no problem displaying them (though older versions of mozilla may require some tweaking). The way special characters are encoded in mail was designed to be compatible with already deployed servers (with some special tags and something similar to the base64 encoding used for attachments). These servers don't see anything other than plain 7bit ASCII text, so it is unlikely it became garbled during transit. The most likel
  • The concern I have with IDNs is that they will make it too easy to produce "lookalike" domains, like "mcrosoft.com".

    Testing functionality and behaviour with "good" names is an easy bar to hurdle.

    • Re: (Score:2)

      by argent ( 18001 )
      That should be "mࡺcrosoft.com". Slashdot will probably need to be upgraded to support IDNs, it seems. :)

    • Re: (Score:3, Insightful)

      by JanneM ( 7445 )
      Like you already have with "l", "I" and "1"; or "O" and "0"; or "V" and "U", depending on the particular font you happen to use?

      Phishing attacks mostly works not because people can't see a minute difference between two lookalike letters; they work because as long as nothing is utterly obviously, grossly out of order people just assume they're in the right place. You can have domain names that aren't even close to the real one, and websites with only superficial similarities to the original and a lot of peop

      • Re: (Score:2)

        by argent ( 18001 )
        Like you already have with "l", "I" and "1"; or "O" and "0"; or "V" and "U", depending on the particular font you happen to use?

        Indeed. This makes an existing problem much much bigger.

        Phishing attacks mostly works not because people can't see a minute difference between two lookalike letters; they work because as long as nothing is utterly obviously, grossly out of order people just assume they're in the right place.

        And what people see as "obviously out of order" changes as people learn about phishing. It's

    • The concern I have with IDNs is that they will make it too easy to produce "lookalike" domains, like "mcrosoft.com".

      This really seems like a pretty minor issue to me. Browsers would just need to adopt a policy of flagging URIs with mixed language character sets, highlighting that character in red or something. More dangerous is the new domain land grab as companies grab legitimate domains in other languages that natives feel the real company simply must own, but which the parent company probably does not. This can be addresses by a certificate scheme that ties identity verification to the site, however, and such a sche

      • Re: (Score:2)

        by argent ( 18001 )
        This really seems like a pretty minor issue to me. Browsers would just need to adopt a policy of flagging URIs with mixed language character sets, highlighting that character in red or something.

        It's not a minor issue, and it's not an insoluble issue, but it's one that needs to be positively and aggressively addressed.

        And it's not just browsers: you need to flag these characters in any application that renders internationalized text with or without HTML being an intermediary. Alternatively, registered domai
    • But at least I will be able to register my last name. It is nice to see the World Wide Web becoming more... world-centric.
  • If your company/organisation/you have any international contacts then you will NOT be using these international URLs. So you still need the old-style URLs or you'll need to explain how to get those umlauts etc to type in the url. On their national keyboard... not yours that has them. And if you've done any support you know how hard it's even to get someone to READ what's already on the screen...

    • Re: (Score:3, Informative)

      by leuk_he ( 194174 )
      umlaut is hardly a problem if you set the use keyboard to üs-ïnternätional. But asian/hebrew/arabic/hebrew charcacter are much more difficult to enter... in my expierence.

      But you will still be able to click them. IDN support is available in most popular browser (although disbled for security issues.)

      • Re: (Score:2)

        by kimba ( 12893 )
        IDN support is available in most popular browser (although disbled for security issues.)

        What browser are you referring to? IDN support is in Firefox, IE, Opera etc. and not disabled, so I am wondering what this most popular browser you are referring to is...

      • umlaut is hardly a problem if you set the use keyboard to üs-ïnternätional. But asian/hebrew/arabic/hebrew charcacter are much more difficult to enter... in my expierence.

        Those who will have these "international" URLs will almost all be using their national keyboards so they will not be familiar with the US keyboard layout... or other foreign layouts. And umlauts was just one example... what about "ç" (had to paste it myself..) or "". How would they be certain how they're mapped in a fo

        • Re: (Score:2)

          by leuk_he ( 194174 )
          international keyboard is a setting of the US layout keyboard....

          type a " and e and you will get ë

    • Re: (Score:2)

      by JanneM ( 7445 )
      So you still need the old-style URLs or you'll need to explain how to get those umlauts etc to type in the url.

      How often do you ever type in an URL in the first place? You get the link from another web site, from Google, in an email or wherever. And AFAIK, the fallback representation is no less readable and typeable than many current domain names.

      Besides, if the website is already in the country's language, you won't be too likely to be interested in it anyway unless you know it (and, presumably, know how t
      • Getting it the URL from a mail will be all nice and dandy if the mail comes from someone who knows the input method. But if the person who got it wants to send the link to someone else they'd need to paste it instead of typing it (I often type URLs into mails instead of pasting them). Of course you can find the urls by other methods... but you'll just be pissing people off by making it more difficult to reach you. And there's much more easier ways to do that if you want to play that game.

        And I said "If y
    • So any company will do itself something good if they get the "local" and the english domain. I already have customers acting that way. Unfortuantely many companies aren't even aware of this drawback. :-( I'm really curious what this switch will bring us and what problems will arise with all the little programmes which are already hard to use, like WAP browsers.

    • Re: (Score:2)

      by Bogtha ( 906264 )

      If your company/organisation/you have any international contacts then you will NOT be using these international URLs.

      No, it means you can't rely on them. Which is pretty much the same for any new technology that requires client support.

      A practical way of using these domains is to set up an ASCII one that you advertise, and redirect to the canonical one with the umlauts etc. That way native speakers aren't alienated by the mangling of their language and don't get errors when they type in the rea

    • This is quite true. Only businesses who are exclusively local will have a single domain name that uses the high-order characters; everyone else will get two, at minimum -- one local one, and one that's the closest-possible ASCII approximation.

      It's not just a "doing business with Americans" (or other Westerners) problem, it's a 'doing business with anyone outside your area' problem. ASCII is the only character set where you have a good chance of ensuring that some other person will be able to type it. I.e.,
  • It can be cool (?).

    • Re: (Score:2)

      by zootm ( 850416 )

      / is a separator in URLs, so I suspect not.

  • They are internationalized urls. If they were international urls I would be able to enter them in my browser without doing funky stuff.
  • Pardon my ignorance, but couldn't they have just thought of an encoding scheme? Similar to how certain characters are encoded in the path of an URL ("&"-style or "%20"-style). Possibly a more complicated scheme would have been necessary, but surely it would have been possible without requiring changes to the ASCII nature of domains.

    • Re: (Score:2)

      by Tet ( 2721 )
      Pardon my ignorance, but couldn't they have just thought of an encoding scheme?

      Already been done. See Punycode (RFC3492). The problem with encoding schemes, though, is that they aren't memorable, and hence are problematic to typo into, say, the location bar of a browser.

      • The funny thing about Punycode is that it isn't even necessary, at least from the perspective of the DNS protocol. Since DNS labels are encoded as length+data, you can theoretically just put arbitrary UTF-8 characters directly into a DNS name. Unfortunately, I think BIND (in its infinite brokenness) didn't handle that very well or something.

        • Re: (Score:2)

          by amorsen ( 7485 )
          Unfortunately, I think BIND (in its infinite brokenness) didn't handle that very well or something.

          BIND seems to handle it just fine; I don't know of any problems with UTF-8 in BIND. I still don't get why punycode was invented, and this is the one issue where I agree with Daniel J. Bernstein. See his page [cr.yp.to] on the issue.

    • Re: (Score:1)

      by slart42 ( 694765 )
      >Pardon my ignorance, but couldn't they have just thought of an encoding scheme?

      This is exactly what is happening behind the scenes AFAIK. It's called Punycode.

      See http://en.wikipedia.org/wiki/Punycode [wikipedia.org]

  • English "X" vs. Cyrillic "khah" (Score:4, Insightful)

    by J.R. Random ( 801334 ) on Tuesday March 13, 2007 @10:42AM (#18333243)
    This is just common sense -- there's no reason why Chinese, Greeks, and Russians should have to use a character set meant for the English language. But any given URL should have a language associated with it and any character in that URL not associated with its language should be color coded. So English language URLs would get "omicron" flagged while Greek URLs would get "O" flagged. The "default" language could be English so that existing URLs are unchanged, for other languages their ISO code could precede the URL. Now this particular scheme might have some fatal flaw but something similar ought to be workable.
    • Couldn't these linguistically-heterogenous domain spaces still be universally linked through romanization? I see one possible solution: An intermediary DNS conversion server; i.e. type "[those were supposed to be Japanese kanji].co.jp" and your DNS request is treated the same as "rakuten.co.jp". Beyond the inability to rake in tons of money for new registrations, what might be the disadvantages of such a system?

      • Re: (Score:3, Interesting)

        by Nimey ( 114278 )
        For some languages, like Arabic, there is no one standard for romanization. A trivial example is Qu'ran/Koran.

    • Re: (Score:3, Insightful)

      by pavon ( 30274 )
      Agreed, although I think a dialog box should also be shown as an annoyance / deterant. Otherwise just imagine what the Web 2.0 folks will do when they realize they can redirect their site to one with cool multi-colored URLs, thus conditioning people to ignore the colored warning. And you thought del.icio.us was overly cute :)

    • Re: (Score:2)

      by glwtta ( 532858 )
      Good point; never thought of this.

      My suspicion is that the only way to deal with this is to completely disallow mixing of languages in the same URL (or at least in the domain name, which should be enforced by the registrars). Anything less leaves far too much room for abuse. Imagine the field-day phishers would have with this: register www.bankofamerica.com with an omicron and a digamma (ok, the lower case wouldn't look right - you know what I mean), and you control a domain visually indistinguishable
  • Also needed is automatic translation by, say, a Firefox extension, from the domain name's registered home language (if any) into the user's default language. How do you say "goatse" in Urdu?

    A good complement to the new system to preempt the huge coming problem of "glyph masquerade" would be registrations including a list of the domain name translated into different languages. Or at least a declaration of the home language. Without enforcement (ICANN doesn't even enforce name/address veracity) it won't be pr

  • Security minded questions (Score:3, Interesting)

    by merc ( 115854 ) <slashdot@upt.org> on Tuesday March 13, 2007 @10:50AM (#18333419) Homepage
    Will having non-ASCII data in FQDN's open us up to buffer-overflow attacks in various network-aware services?

  • Some Unanswered Questions About IDNs ... (Score:3, Interesting)

    by Ron Bennett ( 14590 ) on Tuesday March 13, 2007 @10:51AM (#18333453) Homepage
    Below is a quick copy and paste from one of my posts on DNForum regarding IDNs ... I own some IDNs and believe they have much potential, but there are still many unanswered questions...

    Excerpt from a post of mine on DNForum regarding IDNs:
    http://www.dnforum.com/showthread.php?p=732080 [dnforum.com]

    I'm running into a lot of issues that many IDN folks aren't discussing - probably because they've not consider them ...

    Various issues / threats / questions:

    ?? The existance of numerous diverse dialects, even totally different languages, etc in the same country ... it's among the reasons that English dominates in some areas; some natives, even if they can understand a particular dialect, will sometimes speak a totally non-native language, such as English, instead to avoid risk of offending the other party. One can't assume one language dominates an entire region - languages can also overlap many areas ... it's one of the reasons some are pushing for language / culture based TLDs, such as .CAT (among the dumbest ideas ever, but that's another discussion for the .CAT thread running here on DNF).

    ?? An IDN that contains western european characters that very close matches a non IDN ... ie. cafe.com verses café.com ... what happens? Will the IDN be highlighted / blocked by default? ... likely an easy UDRP target? ... introduction of a new IDN specific dispute procedure? -perhaps there already is one?

    ?? Trademark issues ... ie. an IDN that is similar / exact to a trademark in another country ... less obvious, what about an IDN that translates to that of a trademarked word / phrase? -I believe there's a thread discussing such an issue now on one of the other boards here.

    ?? language variants (more applicable to asian languages, etc) related issues ... how good / stable are the various language variant tables?

    ?? what happens when a language variant table changes? -how are conflicts handled?

    ?? what happens if a character variant (an IDN [IDL package] technically can comprise multiple character variants [code points]) is released? ... does the current registrant get first dibs? ... even if yes, it may not be quite that simple if a character variant occurs in numerous permutations.

    ?? What happens if a reserved character variant is changed to a preferred character variant? - while such a change would have little to no effect on affected IDNs (IDL packages), it could result in the appearance of some IDNs changing ... probably not a biggie compared to some other issues, but one to be aware of.

    ?? How reliable, especially for those in languages with numerous character variants, will IDN domain resolution be? ... IDN resolution depends on much client-side APIs.

    ?? How well will IDN resolution APIs be regulated ... I can easily envision scenerios in which a web browser and/or other applications (email, IM, etc) implement resolution differently ... ie. adding and/or ignoring one or more valid language associations for a particular IDN / converting similar-looking western european characters to standard A-Z characters, etc. A related concern is language table management - I'm a little hazy on if the tables will be internally stored by each app or remotely loaded for each session, etc.

    Rambling on, but there are a lot of things that one needs to be aware of with IDNs.
  • http://www.145/ [www.145]|-|D07.org

    Imagine it with different ANSI colors for each char.

  • Balkanising the internet? (Score:4, Interesting)

    by hcdejong ( 561314 ) <`hobbes' `at' `xmsnet.nl'> on Tuesday March 13, 2007 @10:53AM (#18333515)
    Would this lead to segregation of the internet into zones defined by the language used for the domain name? At the moment, I can access e.g. Japanese websites easily, even if the content of that site is in a language I don't understand [1].
    If non-Roman domain names become popular, will I still be able to access them, or will they disappear behind untypeable URLs? A search engine may be able to mitigate this problem somewhat, but ATM I sometimes get search results for Japanese-language pages only because my search term is present in the URL.

    1: yes, a site can still be useful in this case and no, despite the stereotype it's not just for porn.

    • Re: (Score:2)

      by Churla ( 936633 )
      You're looking at this from the perspective as a native English speaker.

      Imaging all the Japanese who don't know English, but have to learn/type english domain names. Very unintuitive for them.

      My concern would be for all the internet filtering and firewalling software which explicitly only allows ASCII in HTTP headers.

      • Re: (Score:3, Informative)

        by kimba ( 12893 )

        My concern would be for all the internet filtering and firewalling software which explicitly only allows ASCII in HTTP headers.


        IDN encoding is pure ASCII, in a similar way that MIME email attachments are. The protocol layer never sees anything other than letters, numbers and hyphens. All IDN encoded domains are prepended with "xn--" so that end-user interfaces can tell them apart and convert them back and forth.
      • Considering english is mandatory in schools there, the number of people who dont know any is quite low, and mainly an older segment of the populace (insert korea-old people-email joke). Also, Romanji (as roman characters are called there) are used everywhere, from signs to advertising to hillarious clothing [engrish.com]. But true enough, in many countries english domain names on a non english keyboard could be a real pain in the ass.

      • Re: (Score:3, Interesting)

        by badasscat ( 563442 )
        Imaging all the Japanese who don't know English, but have to learn/type english domain names. Very unintuitive for them.

        Bad example.

        The Japanese are probably the *least* likely of any non-English speaking country to use non-roman url's. The fact is the standard Japanese keyboard is the same exact QWERTY keyboard we use. They can type Japanese through software, which is how they normally work when writing to each other, but there's nothing "non-intuitive" in using an English keyboard in the way that it was
    • well, I am guessing that Google and other search engine/portal sites will be wetting their pants out of excitement, if what you fear becomes prevalent, as people will have to rely more and more on searching for the sites and clicking the link rather than typing in the address. But seriously, I think most navigations these days are done through clicking anyway, rather than actually typing the address into the navigation bar, and even then the auto-complete feature means you rarely have to type the entire ad
  • As far as I know, Japanese URLs have been working and in use for quite some time. I've visited several myself. Mind you, I'm surprised anyone in the anglophone sphere takes notice.

  • And there are quite some solutions to it. One of them (I think this is the one we're talking about) is converting the characters to ASCII and serialize them. Quite simple, let the browser do it.
  • http://pi.cr.yp.to/ [cr.yp.to]

    As a side note, it's interesting that Slashdot says this link is at cr.yp.to.
  • so how am i, on my gb keyboard suppose to conveniently type in all sorts of foreign characters?
    if there is going to be some traditional ASCII alternative url.. then just what are we doing?

    i am all for versatility, but there is always talk about unification, this would just segregate the web into 'things i can type' and 'things i can't'

    and considering that html is in american, and that most people take into account that english is a very common language when designing a page, are we not just creating some no

    • Re: (Score:2)

      by hyfe ( 641811 )
      First of, welcome to facing the problems the rest of the world have been for some time.

      so how am i, on my gb keyboard suppose to conveniently type in all sorts of foreign characters?

      You're not. Same way there is no convient way to write english chars on a russian keyboard. There's nothing to do but switch charset and try to remember where the characters were.

      The more important question is, why should countries with completely different alphabets than us be forced to use our alphabet? Right now, Russians ha

    • so how am i, on my gb keyboard suppose to conveniently type in all sorts of foreign characters?

      What are you saying -- that you actually TYPE URLs into the address bar? Have you never heard of del.icio.us? Or bookmarks? Or clicking on a link?

  • Already done (Score:3, Interesting)

    by kahei ( 466208 ) on Tuesday March 13, 2007 @12:03PM (#18334749) Homepage

    Once again, committees lag behind actual problems and actual solutions.

    Now if you'll excuse me I'll go back to browsing .jp.

    (I seem to recall that /. has issues of its own, so the ascii encoding of that would be http://xn--cckev5k8eta5k.jp/ [xn--cckev5k8eta5k.jp]. Anyway, the point is that characters beyond ASCII have been used for ages. Mostly by people who don't mind it when users from other countries can't access their site.)
  • If ASCII was good enough for the Apostles Peter and Paul then it ought to be good enough for everyone.

  • English is not my native language (as if you didn't notice) I still think this is not exactly the best idea ever, I actually think it is pretty bad... Phising has been named, but it also seems as a huge overcomplication. Most sites (aka youtube) already get to survive with totally cryptic URLs , so I don't really thing this is a problem at all.

Slashdot Top Deals

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Close