Umiędzynarodowiona nazwa domeny

„IDNA” przekierowuje tutaj. Nie mylić z Idną .
Przykład greckiej nazwy IDN z nazwą domeny w alfabecie innym niż łaciński : ουτοπία.δπθ.gr ( Punycode to xn--kxae4bafwg.xn--pxaix.gr)

Umiędzynarodowiona nazwa domeny ( IDN ) to nazwa domeny internetowej , która zawiera co najmniej jedną etykietę wyświetlaną w aplikacjach , w całości lub w części, zapisaną pismem innym niż łaciński lub alfabetem , takim jak arabski , bengalski , chiński ( mandaryński , uproszczony lub tradycyjny ), cyrylicy (w tym bułgarski , rosyjski , serbski i ukraińskim ), dewanagari , greckim , hebrajskim , hindi , tamilskim lub tajskim lub alfabetem łacińskim ze znakami diakrytycznymi lub ligaturami , takimi jak francuski , niemiecki , włoski , polski , portugalski lub hiszpański . Te systemy pisma są kodowane przez komputery w wielobajtowym formacie Unicode . Międzynarodowe nazwy domen są przechowywane w systemie nazw domen (DNS) jako ciągi ASCII przy użyciu transkrypcji Punycode .

DNS, który wykonuje usługę wyszukiwania w celu przetłumaczenia nazw przyjaznych dla użytkownika na adresy sieciowe w celu zlokalizowania zasobów internetowych, jest w praktyce ograniczony do używania znaków ASCII, co jest praktycznym ograniczeniem, które początkowo wyznaczyło standard akceptowanych nazw domen. Internacjonalizacja nazw domen to rozwiązanie techniczne umożliwiające tłumaczenie nazw zapisanych w skryptach rodzimych dla danego języka na tekstową ASCII zgodną z DNS. Międzynarodowych nazw domen można używać wyłącznie z aplikacjami specjalnie zaprojektowanymi do takiego użytku; nie wymagają zmian w infrastrukturze Internetu.

IDN została pierwotnie zaproponowana w grudniu 1987 r. przez Martina Dürsta i wdrożona w 1990 r. przez Tan Juay Kwang i Leong Kok Yong pod kierownictwem Tan Tin Wee. [ potrzebne źródło ] Po wielu debatach i wielu konkurencyjnych propozycjach system o nazwie Internacjonalizacja nazw domen w aplikacjach (IDNA) został przyjęty jako standard i został wdrożony w kilku domenach najwyższego poziomu .

W IDNA termin umiędzynarodowiona nazwa domeny oznacza w szczególności dowolną nazwę domeny składającą się wyłącznie z etykiet, do których można z powodzeniem zastosować algorytm IDNA ToASCII (patrz poniżej). W marcu 2008 r. IETF utworzył nową grupę roboczą IDN w celu aktualizacji obecnego protokołu IDNA. W kwietniu 2008 r. UN-ESCWA wraz z Rejestrem Zainteresowania Publicznego (PIR) i Afilias uruchomiła Grupę Roboczą ds. Skryptów Arabskich w IDN (ASIWG), w skład której weszli eksperci w dziedzinie DNS, ccTLD operatorzy, biznes, środowisko akademickie, a także członkowie organizacji regionalnych i międzynarodowych. Obsługiwany przez Ram Mohana z Afilias, ASIWG ma na celu opracowanie ujednoliconej tabeli IDN dla alfabetu arabskiego i stanowi przykład współpracy społeczności, która pomaga lokalnym i regionalnym ekspertom zaangażować się w rozwój globalnej polityki, a także standaryzację techniczną.

W październiku 2009 r. Internet Corporation for Assigned Names and Numbers (ICANN) zatwierdziła tworzenie w Internecie umiędzynarodowionych krajowych domen najwyższego poziomu (IDN ccTLD), które używają standardu IDNA dla skryptów w języku ojczystym. W maju 2010 r. w strefie głównej DNS zainstalowano pierwsze domeny IDN ccTLD .

Umiędzynarodowienie nazw domen w aplikacjach

Internacjonalizacja nazw domen w aplikacjach (IDNA) to mechanizm zdefiniowany w 2003 r. do obsługi umiędzynarodowionych nazw domen zawierających znaki inne niż ASCII .

Chociaż system nazw domen obsługuje znaki inne niż ASCII, aplikacje takie jak poczta e-mail i przeglądarki internetowe ograniczają znaki, które mogą być używane jako nazwy domen do celów takich jak nazwa hosta . Ściśle mówiąc, to protokoły sieciowe, z których korzystają te aplikacje, mają ograniczenia dotyczące znaków, które mogą być używane w nazwach domen, a nie aplikacje, które mają te ograniczenia lub sam DNS. [ potrzebne źródło ] Aby zachować kompatybilność wsteczną z zainstalowaną bazą, grupa robocza IETF IDNA zdecydowała, że ​​umiędzynarodowione nazwy domen powinny zostać przekonwertowane do odpowiedniej postaci opartej na ASCII, która mogłaby być obsługiwana przez przeglądarki internetowe i inne aplikacje użytkownika. [ potrzebne źródło ] Identyfikator IDNA określa sposób przeprowadzania konwersji między nazwami zapisanymi znakami spoza zestawu ASCII a ich reprezentacją opartą na ASCII. [ potrzebne źródło ]

Aplikacja obsługująca identyfikator IDNA może konwertować nazwę domeny między reprezentacją międzynarodową a reprezentacją ASCII . Używa formularza ASCII do wyszukiwania DNS, ale może prezentować umiędzynarodowiony formularz użytkownikom, którzy prawdopodobnie wolą czytać i zapisywać nazwy domen w skryptach innych niż ASCII, takich jak arabski lub Hiragana. Aplikacje, które nie obsługują identyfikatora IDNA, nie będą w stanie obsługiwać nazw domen zawierających znaki inne niż ASCII, ale nadal będą mogły uzyskiwać dostęp do takich domen, jeśli otrzymają (zwykle raczej tajemniczy) odpowiednik ASCII.

ICANN wydała wytyczne dotyczące korzystania z IDNA w czerwcu 2003 r., a rejestracja domen .jp przy użyciu tego systemu była już możliwa w lipcu 2003 r., A domen .info w marcu 2004 r. Kilka innych rejestrów domen najwyższego poziomu zaczęło przyjmować rejestracje w 2004 i 2005 r. Wytyczne dotyczące IDN zostały po raz pierwszy opracowane w czerwcu 2003 r. i zostały zaktualizowane w celu reagowania na phishing w listopadzie 2005 r. Grupa robocza ICANN zajmująca się krajowymi nazwami domen najwyższego szczebla została utworzona w listopadzie 2007 r. i promowana wspólnie przez organizację wspierającą kody krajów i Rządowy Komitet Doradczy. Ponadto ICANN wspiera kierowaną przez społeczność Universal Acceptance Steering Group, której celem jest promowanie użyteczności IDN i innych nowych gTLDS we wszystkich aplikacjach, urządzeniach i systemach.

Mozilla 1.4, Netscape 7.1 i Opera 7.11 były jednymi z pierwszych aplikacji obsługujących IDNA. Wtyczka przeglądarki jest dostępna dla Internet Explorera 6, aby zapewnić obsługę IDN. Internet Explorer 7.0 i Windows Vista zapewniają natywną obsługę sieci IDN.

ToASCII i ToUnicode

Konwersje między formami ASCII i innymi niż ASCII nazwy domeny są realizowane przez parę algorytmów zwanych ToASCII i ToUnicode. Algorytmy te nie są stosowane do nazwy domeny jako całości, ale raczej do poszczególnych etykiet. Na przykład, jeśli nazwa domeny to www.example.com, etykiety to www , example i com . ToASCII lub ToUnicode są stosowane do każdego z tych trzech oddzielnie.

Szczegóły tych dwóch algorytmów są złożone. Są one określone w RFC 3490. Poniżej znajduje się przegląd ich działania.

ToASCII pozostawia niezmienione etykiety ASCII. Nie powiedzie się, jeśli etykieta jest nieodpowiednia dla systemu nazw domen. W przypadku etykiet zawierających co najmniej jeden znak inny niż ASCII, ToASCII stosuje Nameprep . To konwertuje etykietę na małe litery i wykonuje inną normalizację. ToASCII następnie tłumaczy wynik na ASCII, używając Punycode . Na koniec dołącza czteroznakowy ciąg „ xn-- ”. Ten czteroznakowy ciąg nosi nazwę kodowania kompatybilnego z ASCII ( ACE ) prefiks. Służy do odróżnienia etykiet zakodowanych w Punycode od zwykłych etykiet ASCII. Algorytm ToASCII może zawieść na kilka sposobów. Na przykład końcowy ciąg może przekraczać limit 63 znaków etykiety DNS. Etykieta, dla której ToASCII nie powiedzie się, nie może być używana w międzynarodowej nazwie domeny.

Funkcja ToUnicode odwraca działanie ToASCII, usuwając prefiks ACE i stosując algorytm dekodowania Punycode. Nie odwraca przetwarzania Nameprep, ponieważ jest to jedynie normalizacja iz natury jest nieodwracalna. W przeciwieństwie do ToASCII, ToUnicode zawsze się udaje, ponieważ po prostu zwraca oryginalny ciąg, jeśli dekodowanie się nie powiedzie. W szczególności oznacza to, że ToUnicode nie ma wpływu na ciąg, który nie zaczyna się od prefiksu ACE.

Przykład kodowania IDNA

Kodowanie IDNA można zilustrować za pomocą przykładowej domeny Bücher.example . ( niemiecki : Bücher , dosł.   „książki”). Ta nazwa domeny ma dwie etykiety, Bücher i example . Druga etykieta to czysty ASCII i pozostaje niezmieniona. Pierwsza etykieta jest przetwarzana przez Nameprep w celu uzyskania bücher , a następnie konwertowana na Punycode w celu uzyskania bcher-kva . Jest on następnie poprzedzony przedrostkiem xn-- w celu wytworzenia xn--bcher-kva . Wynikowa nazwa odpowiednia do użycia w rekordach DNS i zapytaniach to zatem xn--bcher-kva.example .

Grupa robocza arabskich skryptów IDN (ASIWG)

Podczas gdy region arabski reprezentuje 5 procent światowej populacji, odpowiada za zaledwie 2,6 procent globalnego korzystania z Internetu. Co więcej, odsetek użytkowników Internetu wśród ludności świata arabskiego jest niski i wynosi 11 procent, w porównaniu do światowego wskaźnika 21,9 procent. Jednak korzystanie z Internetu w regionie wzrosło o 1426 procent w latach 2000-2008, co stanowi duży wzrost, szczególnie w porównaniu ze średnią światową stopą wzrostu wynoszącą 305,5 procent w tym samym okresie. Rozsądnie jest zatem wnioskować, że wzrost wykorzystania mógłby być jeszcze bardziej znaczący, gdyby DNS był dostępny w alfabecie arabskim. Wprowadzenie IDN oferuje wiele potencjalnych nowych możliwości i korzyści arabskim użytkownikom Internetu, umożliwiając im zakładanie domen w ich rodzimych językach i alfabetach oraz tworzenie całej gamy usług i zlokalizowanych aplikacji na tych domenach.

Implementacja domeny najwyższego poziomu

W 2009 roku ICANN zdecydowała się na wdrożenie nowej klasy domen najwyższego poziomu, przypisywanych do krajów i niezależnych regionów, podobnie jak zasady dotyczące krajowych domen najwyższego poziomu . Nazwy domen mogą jednak składać się z dowolnych pożądanych ciągów znaków, symboli lub glifów w alfabecie lub skrypcie charakterystycznym dla danego języka, innym niż łaciński, języka wnioskodawcy, zgodnie z pewnymi wytycznymi, aby zapewnić wystarczającą niepowtarzalność wizualną.

Proces instalacji krajowych domen kodowych IDN rozpoczął się od długiego okresu testowania zestawu subdomen w testowej domenie najwyższego poziomu. W jedenastu domenach używano rodzimych pism lub alfabetów, takich jak „δοκιμή”, co oznacza test w języku greckim .

Wysiłki te zakończyły się utworzeniem pierwszych umiędzynarodowionych krajowych domen najwyższego poziomu (IDN ccTLD) do użytku produkcyjnego w 2010 roku.

W systemie nazw domen domeny te używają reprezentacji ASCII składającej się z przedrostka „ xn-- ”, po którym następuje tłumaczenie Punycode reprezentacji Unicode alfabetu specyficznego dla języka lub glifów pisma. Na przykład cyrylica nazwy rosyjskiej domeny IDN ccTLD to „рф”. W reprezentacji Punycode jest to „ p1ai ”, a jego nazwa DNS to „ xn--p1ai ”.

Rejestry inne niż IDNA lub ICANN obsługujące nazwy domen inne niż ASCII

Istnieją inne rejestry obsługujące nazwy domen spoza zestawu ASCII. Firma ThaiURL.com w Tajlandii obsługuje rejestracje domeny „.com” za pośrednictwem własnego kodowania IDN, ThaiURL . Jednakże, ponieważ większość nowoczesnych przeglądarek rozpoznaje tylko IDNA/Punycode IDN, domeny zakodowane w ThaiURL muszą być wpisywane lub łączone w ich zakodowanej formie i będą wyświetlane w pasku adresu. To ogranicza ich użyteczność; jednak nadal są to domeny ważne i powszechnie dostępne.

Kilka rejestrów obsługuje znaki emoji Punycode jako domeny emoji .

Problemy związane z fałszowaniem ASCII

Główny artykuł: Atak homografem IDN

Użycie Unicode w nazwach domen potencjalnie ułatwia fałszowanie witryn internetowych, ponieważ wizualna reprezentacja ciągu IDN w przeglądarce internetowej może sprawić, że fałszywa witryna będzie wyglądać na nie do odróżnienia od legalnej witryny, która jest sfałszowana, w zależności od użytej czcionki. Na przykład znak Unicode U+0430 — mała litera a cyrylicy — może wyglądać identycznie jak znak Unicode U+0061 ( łacińska mała litera a ), używany w języku angielskim. Jako konkretny przykład, używając liter cyrylicy а , е , і , р ( a ; następnie „Ie”/„Ye” U + 0435, wyglądający zasadniczo identycznie jak łacińska litera e ; następnie U + 0456, zasadniczo identyczny z łacińską literą i ; i „Er” U+0440, zasadniczo identyczny z literą łacińską p ), powstaje adres URL wіkіреdіа.org , który jest praktycznie nie do odróżnienia od wizualnej reprezentacji legalnej wikipedia.org (prawdopodobnie w zależności od czcionek).

Domeny najwyższego poziomu akceptujące rejestrację IDN

Wiele domen najwyższego poziomu zaczęło akceptować międzynarodowe rejestracje nazw domen na drugim lub niższym poziomie. Afilias (.INFO) zaoferował pierwsze rejestracje gTLD IDN drugiego poziomu w 2004 roku w języku niemieckim.

DotAsia, rejestrator TLD Asia , przeprowadziła 70-dniowy okres wschodu słońca , który rozpoczął się 11 maja 2011 r. dla rejestracji domen drugiego poziomu w alfabetach chińskim, japońskim i koreańskim .

Oś czasu

  • 1996-12: oryginalny Internet Draft Martina Dürsta proponujący UTF5 (pierwszy przykład tego, co jest dziś znane jako kodowanie zgodne z ASCII (ACE)) - UTF-5 został po raz pierwszy zdefiniowany na Uniwersytecie w Zurychu
  • 1998-03: Early Research on IDN na National University of Singapore (NUS), Center for Internet Research (dawniej Internet Research and Development Unit – IRDU) kierowany przez Tan Tin Wee (TW Tan) (zespół projektu IDN – Tan Juay Kwang i Leong Kok Yong), a następnie kontynuował w zespole Bioinformatrix Pte. Ltd. (BIX Pte. Ltd.) – spółka spin-off NUS kierowana przez S. Subbiaha.
  • 1998-06: System nazw domen w języku koreańskim został opracowany przez Kang, Hee-Seung w KAIST (Korea Advanced Institute of Science and Technology)
  • 1998-07: Genewa konferencja INET'98 z BoF [ wymagane wyjaśnienie ] dyskusja na walnym zgromadzeniu iDNS i APNG oraz spotkaniu grupy roboczej.
  • 1998-07: Asia Pacific Networking Group (APNG, obecnie nadal istnieje i różni się od zgromadzenia znanego jako APSTAR) utworzono grupę roboczą iDNS.
  • 1998-10: James Seng , były student Tan Tin Wee w Sheares Hall, NUS oraz badacz w Technet i IRDU, Computer Center, NUS, został zatrudniony przez dyrektora generalnego S. Subbiaha do kierowania dalszym rozwojem IDN w BIX Pte. Sp. z o.o.
  • 1999-02: Platforma testowa iDNS uruchomiona przez BIX Pte. z oo pod auspicjami APNG z udziałem CNNIC , JPNIC , KRNIC, TWNIC, THNIC, HKNIC i SGNIC pod przewodnictwem Jamesa Senga
  • 1999-02: Prezentacja raportu o IDN na wspólnym spotkaniu APNG-APTLD na APRICOT'99
  • 1999-03: Zatwierdzenie raportu IDN na Walnym Zgromadzeniu APNG 1 marca 1999 r.
  • 1999-06: Wniosek o grant złożony przez APNG wspólnie z Centre for Internet Research (CIR), National University of Singapore, dla International Development Research Center (IDRC), międzynarodowej organizacji finansowanej przez rząd Kanady, w celu pracy nad IDN dla IPv6. Ten projekt APNG został sfinansowany w ramach ogólnoazjatyckiego grantu badawczo-rozwojowego administrowanego w imieniu IDRC przez Kanadyjski Komitet ds. Bezpieczeństwa i Higieny Pracy (CCOHS). Główny badacz: Tan Tin Wee z National University of Singapore.
  • 1999-07 Tout, Walid R. (WALID Inc.) złożył wniosek patentowy IDNA numer US1999000358043 „Metoda i system internacjonalizacji nazw domen”. Opublikowano 2001-01-30.
  • 1999-07: Projekt internetowy dotyczący UTF5 autorstwa Jamesa Senga, Martina Dürsta i Tan Tin Wee. Odnowiony 2000.
  • 1999-08: APTLD i APNG tworzą grupę roboczą do zbadania kwestii IDN, której przewodniczy Kilnam Chon.
  • 1999-10: BIX Pte. Ltd. i National University of Singapore wraz z nowojorskimi inwestorami Venture Capital, General Atlantic Partners , podzielili IDN na 2 nowe spółki singapurskie – i-DNS.net International Inc. i i-Email.net Pte. Ltd., która stworzyła pierwszą komercyjną implementację rozwiązania IDN odpowiednio dla nazw domen i adresów e-mail IDN.
  • 1999-11: IETF IDN Birds-of-Feather [ wymagane wyjaśnienie ] w Waszyngtonie zostało zainicjowane przez i-DNS.net na prośbę urzędników IETF.
  • 1999-12: i-DNS.net InternationalPte. Ltd. uruchomiła pierwszą komercyjną IDN. Było to na Tajwanie i pisane chińskimi znakami pod domeną najwyższego poziomu IDN TLD „.gongsi” (co oznacza luźno „.com”) z aprobatą Ministra Komunikacji Tajwanu i niektórych głównych tajwańskich dostawców usług internetowych, z doniesieniami o ponad 200 000 sprzedanych nazw w tygodniowo na Tajwanie, Hongkongu, Singapurze, Malezji, Chinach , Australii i USA.
  • Koniec 1999: Kilnam Chon inicjuje grupę zadaniową ds. IDNS, która doprowadziła do powstania MINC, konsorcjum wielojęzycznych nazw internetowych.
  • 2000-01: Grupa robocza IETF IDN utworzona pod przewodnictwem Jamesa Senga i Marca Blancheta.
  • 2000-01: Drugim w historii komercyjnym uruchomieniem IDN były domeny TLD IDN w języku tamilskim, odpowiadające .com, .net, .org i .edu. Zostały one uruchomione w Indiach przy wsparciu Ministerstwa IT przez i-DNS.net International.
  • 2000-02: Wielojęzyczne Konsorcjum Nazw Internetowych (MINC) Propozycja BoF [ wymagane wyjaśnienie ] w IETF Adelaide.
  • 2000-03: APRICOT 2000 Wielojęzyczna sesja DNS.
  • 2000-04: WALID Inc. (z zgłoszeniem patentowym IDNA 6182148) rozpoczęło rejestrację i rozwiązywanie wielojęzycznych nazw domen.
  • 2000-05: Grupa Robocza ds. Testów Interoperacyjności, spotkanie MINC. San Francisco, pod przewodnictwem Billa Manninga i Y. Yoneya, 12 maja 2000 r. [ potrzebne źródło ]
  • 2000-06: Inauguracyjne uruchomienie Konsorcjum Wielojęzycznych Nazw Internetowych (MINC) w Seulu w celu stymulowania wspólnego wdrażania IDN począwszy od regionu Azji i Pacyfiku.
  • 2000-07: Joint Engineering TaskForce (JET) został zainicjowany w Jokohamie w celu zbadania kwestii technicznych pod kierownictwem JPNIC (K.Konishi) i TWNIC (Kenny Huang).
  • 2000-07: Oficjalne utworzenie CDNC ( konsorcjum chińskich nazw domen ) w celu rozwiązania problemów związanych z nazwami domen znaków Han i ich wdrożenia, założone przez CNNIC , TWNIC, HKNIC i MONIC w maju 2000 r.
  • 2001-03: Utworzenie grupy roboczej IDN zarządu ICANN .
  • 2001-07: Japońskie Stowarzyszenie Nazw Domen: Ceremonia uruchomienia JDNA (13 lipca 2001) w Tokio, Japonia.
  • 2001-07: Urdu Internet Names System (28 lipca 2001) w Islamabadzie w Pakistanie, zorganizowany wspólnie przez SDNP i MINC.
  • 2001-07: Prezentacja na temat IDN na posiedzeniu Komitetu Rady Informatyki i Telekomunikacji, National Academies USA (11-13 lipca 2001) w Szkole Zarządzania i Systemów Informacji Uniwersytetu Kalifornijskiego w Berkeley, Kalifornia.
  • 2001-08: Prezentacja MINC i zasięg na dorocznej konferencji Asia Pacific Advanced Network, Penang, Malezja, 20 sierpnia 2001
  • 2001-10: Wspólne spotkanie MINC-CDNC w Pekinie 18–20 października 2001 r.
  • 2001-11: Utworzenie Komitetu ICANN IDN, Ram Mohan (Afilias) mianowany Członkiem Karty.
  • 2001-12: Wspólne sympozjum ITU-WIPO na temat wielojęzycznych nazw domen zorganizowane we współpracy z MINC, 6–7 grudnia 2001 r., Międzynarodowe Centrum Konferencyjne, Genewa.
  • 2003-01: Utworzono grupę roboczą ICANN IDN Guidelines z członkami wiodących rejestrów gTLD i ccTLD.
  • 2003-01: Wydanie darmowej implementacji stringprep, Punycode i IDNA w GNU Libidn.
  • 2003-03: Publikacja RFC 3454, RFC 3490, RFC 3491 i RFC 3492.
  • 2003-06: Publikacja wytycznych ICANN IDN dla rejestrów. Przyjęte przez rejestry .cn, .info, .jp, .org i .tw.
  • 2004-05: Publikacja dokumentu RFC 3743, Wytyczne wspólnego zespołu inżynierów (JET) dotyczące rejestracji i administrowania międzynarodowymi nazwami domen (IDN) dla języka chińskiego , japońskiego i koreańskiego.
  • 2005-03: Pierwsza grupa badawcza 17 spotkania ITU-T w sprawie umiędzynarodowionych nazw domen.
  • 2005-05: .IN ccTLD (Indie) tworzy ekspercką grupę roboczą IDN w celu stworzenia rozwiązań dla 22 języków urzędowych. Ram Mohan został wyznaczony na kierownika technicznego wdrożenia. C-DAC powołał eksperta językowego.
  • 2006-04: Spotkanie grupy badawczej ITU 17 w Korei ostatecznie zatwierdziło pytanie dotyczące międzynarodowych nazw domen.
  • 2006-06: Warsztaty na temat IDN na spotkaniu ICANN w Marakeszu, Maroko.
  • 2006-11: Grupa robocza ICANN GNSO IDN utworzona w celu omówienia implikacji politycznych IDN TLD. Ram Mohan wybrany na przewodniczącego Grupy Roboczej IDN.
  • 2006-12: Spotkanie ICANN w São Paulo omawia status testów laboratoryjnych IDN w katalogu głównym. [ wyjaśnij ]
  • 2007-01: Praca nad tabelami wariantów tamilskich i malajalam zakończona przez indyjskie C-DAC i Afilias .
  • 2007-03: Grupa robocza ICANN GNSO IDN kończy pracę, Ram Mohan przedstawia raport na spotkaniu ICANN Lisboa.
  • domen najwyższego poziomu IDNA zostało dodanych do głównych serwerów nazw w celu oceny wykorzystania IDNA na najwyższym poziomie DNS.
  • 2008-01: ICANN: Pomyślne oceny domen TLD .test IDN.
  • 2008-02: Warsztaty IDN: IDN w językach i skryptach indyjskich, ICANN, DIT, Afilias, C-DAC, prowadzenie NIXI.
  • 2008-04: IETF IDNAbis WG pod przewodnictwem Vinta Cerfa kontynuuje prace nad aktualizacją IDNA.
  • 2008-04: Arabic Script IDN Working Group (ASIWG) założona przez Ram Mohan (Afilias) i Alexa Raad (PIR) w Dubaju.
  • 2008-06: Rada ICANN głosuje za opracowaniem ostatecznej propozycji szybkiej ścieżki wdrożenia dla ograniczonej liczby IDN ccTLDS.
  • 2008-06: Liczba członków grupy roboczej Arabic Script IDN (ASIWG) zostaje rozszerzona o Egipt, Iran, Kuwejt, Pakistan, Arabię ​​​​Saudyjską, Syrię, Zjednoczone Emiraty Arabskie, Malezję, UN ESCWA, APTLD, ISOC Africa oraz zaproszonych ekspertów Michaela Eversona i Johna Klensina.
  • 2008-10: ICANN szuka zainteresowania szybkim procesem IDN ccTLD.
  • 2009-09: ICANN umieszcza propozycję IDN ccTLD w porządku obrad spotkania w Seulu w październiku 2009.
  • 2009-10: ICANN zatwierdza rejestrację nazw IDN w katalogu głównym DNS w ramach procesu IDN ccTLD Fast-Track na spotkaniu w Seulu, 26–30 października 2009 r.
  • 2010-01: ICANN ogłasza, że ​​Egipt, Federacja Rosyjska, Arabia Saudyjska i Zjednoczone Emiraty Arabskie były pierwszymi krajami, które pomyślnie przeszły szybką ocenę ciągów znaków w ramach procesu składania wniosków o domenę IDN ccTLD.
  • Uruchomiono pierwsze wdrożenia [ wymagane wyjaśnienie ] . Są to ccTLD w alfabecie arabskim dla Egiptu, Arabii Saudyjskiej i Zjednoczonych Emiratów Arabskich.
  • 2010-08: IETF publikuje zaktualizowane specyfikacje „IDNA2008” jako RFC 5890–5894.
  • 2010-12: Utworzenie grupy roboczej ds. wariantów IDN zarządu ICANN w celu nadzorowania i śledzenia projektu IDN Variant Issues Project. Członkami grupy roboczej są Ram Mohan (przewodniczący), Jonne Soininen, Suzanne Woolf i Kuo-Wei Wu.
  • 2012-02: Standaryzacja międzynarodowej poczty e-mail z wykorzystaniem IDN.

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Internationalized_domain_name&oldid=1141490612 ”