Nebudu zde rozepisovat, co a jak IDN dělá. Pokud vám tato oblast nic neříká, dovolím si vás odkázat na svůj zdejší starší článek, který vás uvede do problematiky původní verze, která je dnes označována jako IDNA2003 podle roku vydání RFC 3490 a spol. (Závěrečné „A“ ve zkratce pochází z „IDN for Applications“.)
Jaké byly důvody pro její změnu? Asi nejvýznamnější byla nepružnost původního návrhu, který se snažil definovat vše pod jednou střechou. Měnící se prostředí, zejména nové verze Unicode s postupně se rozšiřujícím sortimentem definovaných znaků, vedly k tomu, že postupně rostla skupina znaků stojících mimo původní IDN. Kromě toho – přestože se o nich oficiální důvody nezmiňují – svou roli nepochybně sehrála i rizika způsobená záměnou podobných znaků, s nimiž se původní návrh nedokázal důsledně vypořádat.
Práce na nové generaci IDN byly zahájeny v roce 2008, proto bývá označována jako IDNA2008. Do podoby RFC dospěla letos v srpnu. Tvoří ji následující rodinka dokumentů:
- RFC 5890 – celkový přehled a definice základních pojmů
- RFC 5891 – protokol
- RFC 5892 – znaky a pravidla jejich použitelnosti
- RFC 5893 – speciální pravidla pro jazyky psané zprava doleva
- RFC 5894 – zdůvodnění a komentáře k jednotlivým rozhodnutím
- RFC 5895 – doporučení pro mapování znaků v aplikacích před vstupem do IDN, formálně není součástí protokolu
IDNA2003 zahrnovalo kompletní zpracování doménového jména – výchozí Unicode řetězec byl rozdělen na jednotlivé jmenovky, znaky byly mapovány podle pravidel Nameprep, následně byly jmenovky zakódovány funkcí toASCII využívající algoritmus Punycode do podoby, která splňuje omezení pro doménová jména a lze ji uložit a poptávat ve stávajícím DNS. Při prezentaci doménového jména uživateli pak následoval zhruba opačný proces.
IDNA2008 mění především počáteční fáze celého postupu. Rozdělení výchozího řetězce znaků na jednotlivé jmenovky a případné mapování znaků vysunuje zcela mimo IDN. To na svém vstupu očekává sekvenci jmenovek, které mohou obsahovat znaky mimo základní ASCII. V oficiální terminologii se pro ně používá pojem U-jmenovky (U jako Unicode).
Přípravné práce má vykonat aplikace, pravděpodobně s podporou nějakých systémových funkcí. RFC 5895 poskytuje pouze doporučení, jak by zhruba mapování mělo probíhat (ve stručnosti: převést velká písmena na malá, provést dekompozici znaků podle databáze Unicode, mapovat znaky podle pravidel normalizovaného tvaru C Unicode).
Exkomunikace mapování z jádra IDN je dvousečná zbraň. Na jedné straně umožňuje se přizpůsobovat vývoji a respektovat specifika jednotlivých jazyků, na straně druhé hrozí nekonzistence jeho výsledků. Autoři jsou nicméně přesvědčeni, že toto je ta správná cesta.
Vlastní IDN na vstupu pouze zkontroluje jeho výsledky – zda jmenovky obsahují přípustné znaky. Tuto část má na starosti RFC 5892 a je definována nepochybně lépe. Uplatněním sady pravidel je každému znaku přiřazena jedna ze čtyř vlastností:
-
Platný (PVALID) je znak, který lze používat v U-jmenovkách. (Mohou se na něj vztahovat ale případná další pravidla, která omezí jeho použití.) Typickým příkladem znaků s touto vlastností jsou malá písmena (včetně těch s diakritickými znaménky) a číslice.
-
Kontextově závislý (CONTEXTJ nebo CONTEXTO) je znak, jehož přípustnost závisí na okolí – smí se vyskytovat jen v určitém kontextu. Ten musí být popsán pomocí omezujících pravidel, jejichž splnění IDNA kontroluje. Jen hrstka znaků je kontextově závislých, například znaky řídící spojování či nespojování okolních znaků.
-
Nepřípustný (DISALLOWED) je znak, který v U-jmenovkách nemá co dělat. Patří sem nepísmenné znaky jako interpunkční znaménka, oddělovače, „obrázkové“ znaky (srdíčka, šipky), ale i velká písmena nebo slitky.
-
Nepřiřazený (UNASSIGNED) je takový kód, kterému v dané verzi Unicode není přiřazen žádný význam.
RFC 5892 normativně popisuje pravidla, která jednotlivým znakům na základě jejich Unicode vlastností přiřadí čtyři výše uvedené vlastnosti. V příloze obsahuje výsledky jejich uplatnění na Unicode verze 5.2. Až vyjde nová verze Unicode, určený expert provede totéž a výsledky uplatnění pravidel budou zveřejněny na stránce s IDNA parametry. Jelikož jsou pravidla obecná, IDNA2008 se snadno vyrovná s rozrůstáním znakové sady.
Zatímco IDNA2003 bylo na vstupu liberální a zpracování řetězce si vyřešilo samo, nové IDNA2008 je velmi vybíravé a řadu problémů řeší kontrolou vstupu. Obsahuje-li jmenovka nepřípustné znaky, nepřiřazené znaky nebo kontextové znaky, u nichž nebylo splněno pravidlo, odmítne ji.
Tento přístup řeší několik problémů v jednom. Zákaz velkých písmen například usnadňuje vzájemné porovnávání jmenovek. To musí provádět servery a podle pravidel DNS nemají rozlišovat malá písmena od velkých (Lupa.cz je totéž co lupa.cz). Pro znaky národních abeced by ovšem takové porovnání vyžadovalo od serveru znalosti nad rámec původního DNS. Proto IDNA2008 velká písmena jednoduše vyloučilo ze hry, IDN jmenovky smí obsahovat jen malá a díky tomu je lze porovnávat velmi snadno.
Vstupním omezením se zároveň minimalizují potíže se záměnou znaků. Většina těch, které způsobovaly problémy (zejména ty vážné, jako znaky podobné tečce nebo lomítku) je dnes nepřípustných a do IDN se vůbec nedostane. Nemůžete si samozřejmě registrovat doménu s nepřípustným znakem ve jméně.
Záměna přesto není zcela vyloučena, protože zůstaly některé podobné znaky národních abeced. Například řecké „omikrón“ se dost podobá latinkovému „o“ (ο versus o). Tento problém mohou omezit registrační pravidla jednotlivých domén, která omezí znakovou sadu podle potřeb daného jazyka. Například není důvod, aby doména pl či de povolovala ve jménech poddomén řecké znaky. V gr už tak snadno neuniknou. Kromě toho nová generace IDN požaduje, aby klienti při zobrazování doménových jmen vizuálně upozornili (například barvou) na případné mísení znaků z různých skriptů a varovali tak uživatele před hrozící záměnou.
Po vstupní prohlídce už v IDNA2008 běží vše velmi podobně jako v jeho předchůdci. Opět přijde ke slovu algoritmus Punycode, který U-jmenovku zakóduje do ASCII podoby označované jako A-jmenovka (v IDNA2003 se jmenovala ACE). V té s ní pak pracuje DNS zcela standardním způsobem, protože splňuje veškerá jeho omezení. Punycode je jediným prvkem IDNA2003 převzatým beze změny do nové generace.
Změna přístupu ke vstupnímu textu vede ke dvěma nekompatibilitám mezi oběma verzemi IDN. Německé „ostré s“ (ß) se v IDNA2003 mapovalo na dvojici obyčejných „s“, zatímco v IDNA2008 je přípustným znakem. Naštěstí je německojazyčné domény nepřipouštějí. Je docela paradoxní, že si můžete registrovat doménu ořech.de, nikoli však nuß.de, ale teď se to velmi hodí.
Druhý problém je s řečtinou, kde se koncové sigma (ς) původně mapovalo na obyčejné sigma (σ), zatímco nově se opět jedná o přípustný znak. Řekové je v doménových jménech připouštějí, takže teď hrozí, že příslušná jména budou jinak zakódována podle IDNA2003 a jinak podle IDNA2008. Nicméně tento problém jistě půjde vyřešit nasazením vhodných aliasů (CNAME) do domény gr. Konsorcium Unicode kromě toho připravilo UTS #46, které definuje mapování znaků před vstupem do IDNA tak, aby se během přechodné fáze od IDNA2003 k IDNA2008 odstranily problémy s kompatibilitou obou verzí.
Nová generace IDN se samozřejmě zabývá technickými aspekty a nijak neřeší politické otázky kolem něj. (Aneb má mít držitel domény lupa.cz přednostní právo na doménu lupá.cz, a případně za jakých podmínek?) Ovšem už jenom díky tomu, že omezuje možnosti jeho zneužití, by bylo záhodno, aby co nejdříve nahradilo svého předchůdce.
