Vlákno názorů k článku Doménová jména s národními znaky opět na scéně od Bobinnho - Myslim si, ze to rozhodne neni dobry napad. Nicmene...
-
Myslim si, ze to rozhodne neni dobry napad.
Nicmene az s tim nekdo zacne experimentovat v realnem provozu, tak se dle meho soudu velice rychle vrati zpet k ASCII domene. Snad jen pro pouziti v ciste narodnich domenach to ma jakysi smysl. Odbornych webu se to netyka si myslim vubec, to je jasne. Predstava, jak se v terminalu pri ftp snazim psat URL a nejake norske krouzkovane "o" me desi, ale tohle si proste alespon trochu rozumnej admin na triko nevezme.
Muj predpoklad je ten, ze jakmile se spusti vetsi diskuse k tomuto tematu, prijde se na to, ze tech nevyhod je podstatne vice, nez vyhod...
O.
P.S. Jak to bude s mailovou komunikaci? To budu psat take @slunečnice.cz a mailovy klient to proste posle na "prelozenou" domenu? Co na to poskytovatele free mailovych sluzeb na webu...??? -
Co sa tyka mailov, tam to je tiez dost komplikovane...
pri resolvovani cielovej domeny by sa postupovalo tak, ako za beznych okolnosti pri resolvovani IDN domeny, cize by z toho vypadlo nieco ako xn--blablabla.cz, kam by sa normalne nadviazal socket.
Uz pri SMTP komunikacii by nastal prvy vaznejsi zadrhel, nakolko SMTP sa miestami (najma v adresach a subjektoch) nema rado s osembitovymi kodovaniami, takze by si to vyziadalo zakodovanie odosielatelovej a prijimatelovej adresy pomocou base64 asi nejako takto takto:
MAIL FROM: ventyl?B64?UTF-8?(base64 forma č v UTF-8)?ek@dom?B64?UTF-8?(base64 forma dlheho e v UTF-8)?nka.sk
Co sice nie je iste, ze by bolo nutne priamo pri SMTP komunikacii, ale pri kodovani Message headers by to bolo nutne 100%tne, nakolko tam je na to RFC.
potom uz len treba samotny mail delivery agent naucit tieto masochizmy dekodovat a rozoznavat.
Pouzitie ineho kodovania, ako UTF-8 je vylucene, pretoze ak by sa pouzilo napriklad latin2, tak odosielatelova adresa je bez XLAT prekladu napriklad v japonsku nespracovatelna. To by znacilo, ze by sa vsetky mailery museli stat UTF-8 aware, co je najma pre starsie systemy nemyslitelne. -
mnoho sluzieb ma na tychto e-mailovych adresach nahodene rozne sluzby (triedenie, filtrovanie, indexovanie mailov a pod.), takze sa tieto adresy casto pouzivaju este skor, nez dorazia do klienta (bezny mime-aware klient by mal tie prasaciny vediet dekodovat). Asi da rozum, ze tie filtre nemozu pracovat s tym vyssie uvedenym srotom, takze si to musia dekodovat.
Dalsia vec je komplikacia SMTP autentifikacie pre multiforemne domeny (pri autentifikacii sa musi napriklad brat v potaz, ze uzivatel sa moze autentifikovat pre domenu s bordelom v nazve aj bez bordelu v nazve)... atd. -
oldium (neregistrovaný)Nejak mi nedochazi, proc by ty sluzby nemohly pracovat se "srotem"? Srot se potrebuje dekodovat pouze pro zobrazeni, na druhou stranu se potrebuje zakodovat pri vstupu od uzivatele. Pokud admin zadava do konfigu nejakou domenu, tak ji zada jako srot (nebo si to ten program zakoduje, pokud umi).
Problem me napada pouze u indexovani, kde je lepsi indexovat bez srotu, protoze by mohly vzniknout problemy pri vyhledavani "Kolonka Komu obsahuje..." - to je ale vec indexovaciho programu stejne, protoze si navic musi umet poradit s ruznym kodovanim zprav. Vic me nenapada (protoze v tom nedelam), takze me klidne opravte. -
pretoze keby som si chcel napriklad nahodit na urovni MDA filter, aby maily obsahujuce v odosielatovi krásn[íáéý]*@doménka.sk, tak to proste musim dekodovat, chcem, ci nie, pretoze nemam garanciu v tom:
1) ci bude na zosrotovanie pouzity BASE64, alebo UUENCODE
2) ci bude srot zacinat prave tam, kde zacina diakritika (RFC to nepredpisuje)
3) ci nebude zosrotovany cely zvysok adresy pocnuc prvym diakritickym znakom (kolko srotov sa v sprave nachadza, RFC nepredpisuje)
Zakladny problem je v tom, ze pri srotovani udajov v Message headeroch nutne neplati, ze ked zosrotujem povodnu spravu, dostanem vzdy presne ten isty srot, nakolko jedna sprava sa da zosrotovovat konecne velkym poctom sposobov, kde pocet >> 1.
Cele srotovanie je rovnako neexaktne, ako cela norma mime. Kto o mime chce vediet viac, nech si dohlada starsi Torvaldsov vyrok na adresu autorov MIME :) -
Nepto (neregistrovaný)Vyrok som sice nenasiel, ale zato som zistil, ze Linus pouziva PINE, co je tiez zaujimave ;-)
http://lkml.org/lkml/2000/10/8/43
Ak niekto ma linku na ten vyrok na adresu MIME, poslite. THX. -
Linus Torvalds je znám svým odporem k MIME. Kdysi prohlásil, že autoři MIME by měli být na místě odstřeleni. Nyní je již trošku mírnější:
Mime is only acceptable to me if it actually works without me having to do silly things to see what it does.
zdroj: Linuxove Noviny 1 - 2 / 1999, Zasmali jsme se.
Kazdopadne k mailu v ktorom by sa nachadzal presne ten prvy vyrok o postrielani autorov mime, som sa nedopatral ani ja, ale po istych skusenostiach s mime sa s nim stotoznujem.
ČLÁNKY DO MAILU