Как стать автором
Обновить
«Мой адрес не дом и не улица, Мой адрес сегодня такой: www.leningrad.spb.ru». В 2002 году всем было очевидно, что адрес интернет-сайта или электронной почты должен быть записан именно латиницей. Ну не бывает же не-ASCII-символов в названии домена! А сейчас возможны варианты. Уже 10 лет наряду с латинскими символами в доменах верхнего уровня используются символы национальных алфавитов: от китайских и корейских иероглифов до кириллицы и арабской вязи. Под катом — о том, как это стало возможным, как осуществляется поддержка символов Unicode в доменных именах, и как обстоят дела с кириллическими адресами в интернете.
Спойлер: всё хорошо
Всего голосов 51: ↑49 и ↓2 +47
Просмотры 18K
Комментарии 81

Комментарии 81

В стандарте unicode 25 типов пробелов. Направления письма. Модификаторы цвета кожи и пола.


Скажите, должен ли L5-router учитывать модификатор цвета кожи при выборе аплинка?

Видимо вопрос надо переадресовать авторам BGP (а потом — всяким цискам с huawei а также возможно неполиткорректному коммьюнити кто не поддерживает новые стандарты).

BGP? Для L5?

Я перепроверил, по модели OSI http — это 7ой уровень, а не пятый. Так что L7-балансировщик. Но проблема с юникодом там, где его не ждут остаётся всё равно.

Уровень 7 в OSI это прикладные программы (кто не верит, читайте исходные документы — а то тут даже википедия несёт чушь). HTTP относится очень частично к уровню 7 потому, что определяет, как его должны использовать программы, но основное его содержание на 5-м. Поэтому ошибки не было, тут как раз L5.

Общепринято, что HTTP(S) — L7. Тот, кто говорит обратное — белая ворона, и попросту не будет понят большинством.

Общепринято, что HTTP(S) — L7. Тот, кто говорит обратное — белая ворона, и попросту не будет понят большинством.

Вот я и удивляюсь, что это "общепринятое" грубо противоречит общедоступным оригиналам. Настолько жёсткий вариант нечитателей ещё сложно найти.

Все потому что https://habr.com/ru/post/376709/
или


Они изучали многие, применяемые на то время, модели и в результате придумали модель OSI, релиз которой состоялся в 1984 году. Проблема ее была только в том, что ее разрабатывали около 7 лет. Пока специалисты спорили, как ее лучше сделать, другие модели модернизировались и набирали обороты. В настоящее время модель OSI не используют. Она применяется только в качестве обучения сетям. Мое личное мнение, что модель OSI должен знать каждый уважающий себя админ как таблицу умножения. Хоть ее и не применяют в том виде, в каком она есть, принципы работы у всех моделей схожи с ней.

https://habr.com/ru/post/307252/
или
https://packetpushers.net/seven-layer-model-dead/

Не вижу прямой связи. OSI имеет ряд изначальных проблем и существенных противоречий с современной практикой, это безусловно. Но ничего из этого не заставляет придумывать протоколы 7-го уровня или сминать многоуровневую модель в один более высокий уровень.


Если же принять ваши аргументы за существенные, то вообще не надо рассматривать любые отличия выше L4 — надо все L5-L7 свести в один (как это сделано в формальной модели TCP/IP).

Если же принять ваши аргументы за существенные, то вообще не надо рассматривать любые отличия выше L4 — надо все L5-L7 свести в один (как это сделано в формальной модели TCP/IP).

так так и делают (!)

Я не против (в том смысле, что если им обычно не нужно — то их проблемы), но не надо называть его OSI L7.

никто не называет его OSI, просто "L7"

«общепринятое» грубо противоречит общедоступным оригиналам

Такое происходит очень часто, и не только в IT.
Пример, который первым приходит в голову: в церковнославянском Евангелии написано «иже еси на небесех», но все живые люди, кого я слышал, произносят в рифму «иже еси на небеси». (Это искажение влияет на смысл: то ли небо одно, то ли небес много.)
Наверное это зависит от того, пользуется он blacklist или denylist
Погоди-погоди! Ты чего тут разжигаешь?! Тебе всё равно делать нечего — раз настроил и сидишь денежку получаешь за то, что оборудование пашет. А тут ещё поработаешь ручками, говоловой, почитаешь, вникнешь, поможешь решить не очевидные проблемы… Работай, нигер! (сарказм)

Вынужден поддержать. А á — это a + ́‎ или нет?

хейчу кириллические домены

аналогично. А еще китайские. Немецкие. И прочие другие

согласен, жесть

По-моему, очень сомнительная штука. Реальной пользы, кроме как «проще зайти для бабушек или для китайцев, выучивших 6500 иероглифов, но не желающих выучить 23 буквы латинского алфавита» нет, так как обычно за национальным доменом идёт переадресация на написанный ASCII.
Знаете ли вы хоть один популярный домен, который назван в Unicode?
Даже vkontakte.ru, пытаясь показать себя социальной сетью международного масштаба, стал именно vk.com, притом за большущие деньги.
А вот проблем с внедрением, дыр в безопасности интернационализация вызывает немало. Стоит ли игра свеч? Возможно, в будущем, когда принятие достигнет определенного уровня, будет польза только от почты в кириллице с переадресацией на обычную, просто чтобы не приходилось в очередной раз читать заклинания в духе «С как доллар».

Английского алфавита маловато, чтобы обеспечить комофортными доменными именами всех пользователей интернета в 2020.

Вся проблема в том, что UTF не использовался изначально. Да, можно было бы использовать ограниченный UTF, с одним пробелом, с одним дефизом (автоматически преобразовывать тождественные символы в один), но технически это не было реализовано изначально и теперь представляет проблему.
Поэтому штука сомнительная лишь потому, что обновить весь технический стек для поддержки utf сложно.

Комфортное для кого? Домены в национальном формате комфортны только для тех, кто пользуется национальной раскладкой. Да и то, мне, например, комфортнее написать kremlin.ru, чем переключить раскладку, написать президент.рф, и ещё раз переключить раскладку. Так что комфортность спорна.
Попробуйте написать домен с иероглифами без копипасты.
Интернет — это проявление глобализации. И так уж получилось, что все базовые вещи в интернете сделали американцы, и базовым алфавитом стала латиница. Её почти все знают, а английский язык — самый распространенный в мире. Так что тут вроде особых проблем не должно быть.
Чтобы был комфорт выбора варианта названия, не обязательно делать домен в .com, сейчас очень много TLD, где вполне реально сделать даже двухбуквенный домен за сравнительно (по сравнению с .com) небольшие деньги.
А домены в национальных раскладках можно использовать, как я уже написал, в качестве ALIAS’ов для тех, кому по каким-то привинам сложно набирать латиницей. Но, я надеюсь, что со временем таких будет всё меньше ввиду дальнейшего внедрения образования, а соответственно и пользы от таких доменов — тоже.
P.S. В дополнение про комфортность, занимательный факт. Японцы зачастую набирают текст на клавиатуре (в том числе иероглифы) не хираганой, а латиницей (которую называют романзи), которая уже тут же преобразуется в кану и позволяет выбрать иероглиф(ы) с соответствующим звучанием. При том, что хирагана на клавиатуре у них есть.

И так уж получилось, что все базовые вещи в интернете сделали американцы,

Брехня.
По крайней мере кое-что из базовых вещей в интернете (тот самый HTML, например) сделали европейцы в Европе.


и базовым алфавитом стала латиница.

Сущая правда.

Да, слово все было явно лишним ;)

http / html, это не базовая вещь, а просто ещё один (самый популярный) протокол, который бегает по сети благодаря тем самым базовым штукам (tcp/udp/ip, DNS, BGP и вот этому вот всему). В условном будущем его вполне может заменить какой-нить YTP, при этом действительно базовые вещи(которые и затрагивает локализация) останутся на месте.

Все протоколы не могут существовать бесконечно. И все они будут когда-то заменены.
Тот же IPv4 заменяется (не слишком успешно, но все же заменяется) на другой протокол — IPv6 (в чем-то похожий, но все же сильно отличающийся). На DNS тоже зубы точат, и, может быть, тоже поменяют на что-то иное. Протоколы маршрутизации так вообще плодятся как кролики. И точно так же интернет может вполне однажды остаться вообще без BGP, выбросив его за ненадобностью.


А связка HTTP-HTML на данный момент таки живее всех остальных (в смысле на нее пока никто всерьез не покушается) и обеспечивает доставку значительной (если не подавляющей) части смысловой нагрузки в сети.
Хотя справедливости ради надо отметить, что HTTP/2 уже совсем не тот, что был исходный HTTP, и на подходе еще одно обновление (хотя старый HTTP еще не добили). Но HTML (хотя это не протокол, но все же не все базовые вещи интернета являются протоколами) цветет и пахнет без существенных изменений основ. Только разрастается дополнениями.
И отказывать этой связке в базовости… Не вижу никакого серьезного основания.

IPv6 появился еще в 1996г. на замену древнему IPv4 (1981г.!), но к настоящему времени уже давно успел устареть, так и не вытеснив полностью IPv4; да и IPv4 еще живее всех живых.
Финальный черновик HTTP/2 появился еще в 2015г. на замену старой рабочей лошадке — HTTP/1.x. HTTP/2 имеет значительные преимущества, по сравнению с предыд. версией (кроме того, является бинарным), однако не известно, когда начнется его массовое внедрение. Еще не успели выпустить финальную версию HTTP/2 — уже ведутся работы по разработке HTTP/3 (работает на транспорте QUIC).
TCP появился в 1981г., и также уже, конечно, давно устарел: имеет уязвимости (в т.ч. к атакам типа SYN-флуд), проблемы с MSS (в т.ч. при использовании VPN) и т.д. Аж в 2000г. выпущен стандарт более современного транспортного протокола STCP (основные достоинства — многопоточность и стойкость к атакам SYN-flood), но он так и не заменил TCP. Также в качестве преемника TCP можно рассматривать QUIC.
Устаревших протоколов — большое количество. Но мы не можем никак отказаться от их использования в пользу др. более современных протоколов, т.к. внедрить новые массово сразу и везде пока не представляется возможным, т.к. не можем сразу отказаться от старых (парадокс такой получается). И многие протоколы успевают безнадежно устареть еще до внедрения в массы.

Поддержка легаси — это вечное. А потому старые протоколы будут тянуться до тех пор, пока количество случаев их использования не станет исчезающе малым.
Устаревание технологий до выхода из эксплуатации старых — тоже обычное дело. Это как конвейер, когда одновременно в обороте может находиться несколько технологий на разной стадии устаревания, поскольку замена элементов в системе, особенно базовых, обычно не происходит одномоментно.
Устаревание технологий до появления новых — тоже обычное явление. Не всегда успевают разработать новое до устаревания актуального. Иногда даже не пытаются новое разрабатывать до тех пор, пока актуальное явно не начнет создавать проблемы из-за своей устарелости.
Да даже официально похороненный флэш, думаю, еще долго будет жить. И я даже не уверен, что Win3.11 похоронили окончательно, загнав исключительно в нишу компьютерной археологии.
Кобол до сих пор жив.
Но развитие идет, и данные технологии уже не являются актуальными. То же когда-нибудь ждет и IPv4, и IPv6, и TCP с UDP, и HTTP c HTML.
Опять же, не всегда смена технологий делает жизнь проще (или не для всех делает проще, а для части людей, напротив, все усложняет).
И учитывая, что локализация всего, включая доменные имена, стала модным трендом, данное направление будет только развиваться, как бы это не портило жизнь системным администраторам и не увеличивало возможности для мимикрии адресов за счет похожих символов.

Комфортный домен — это такой домен, который можно набрать вместе с именем протокола, не переключая раскладку.

Правильно. Мне тоже как-то не очень нравятся домены с использованием национальных алфавитов.
А ведь есть еще и эмодзи-домены. (Хотел привести неск. ссылок на эмодзи-домены, но Хабр эмодзи-символы вырезает.) При вводе таких URL и эмодзи-символы не так просто найти.
Вся проблема в том, что UTF не использовался изначально.

Например потому, что SMTP создали в 1982, DNS — в 1983, а UTF-8 — только в 1993?
Знаете ли вы хоть один популярный домен, который назван в Unicode?

экоспб.рф/ekomobili

Бюрократам чхать на разумные соображения. Им лишь бы придумать способ обеспечить себя работой на следующие десятилетия. Отличный рынок, между прочим — куча доделок софта, рынок средств мониторинга соответствию стандарта и рынок средствв мониторинга уязвимостей.

Кстати, с 2016 года работает @Почта.рус — сервис регистратуры соответствующего домена верхнего уровня, где уже можно завести себе кириллический адрес.

У меня сложилось впечатление что весь пост продвигает @Почту.рус и Поддерживаю.РФ.


И в случае первого там всё как-то очень плохо с HTTPS, хотя сайт предлагает регистрировать почту, а там явно хочется иметь нормальную безопасность.
Причём оригинальная брендированная ссылка https://u.tmtm.ru/cctld_mail ведёт именно на HTTP-версию, а значит при её формировании знали что HTTPS лучше не показывать.


Вот так выглядит сертификат в данный момент:


Google Chrome


Файл сертификата
-----BEGIN CERTIFICATE-----
MIICvDCCAaQCCQDFArfiy4upPzANBgkqhkiG9w0BAQUFADAgMR4wHAYDVQQDExVs
b2NhbGhvc3QubG9jYWxkb21haW4wHhcNMTEwNTA2MTQxOTI4WhcNMjEwNTAzMTQx
OTI4WjAgMR4wHAYDVQQDExVsb2NhbGhvc3QubG9jYWxkb21haW4wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxQaGdHiwKxPn55O83b0j+FjQF3ZGTItXw
rrEj06pTTiReRgQefnrVi2xCZayJr4Alwuq1m/t0v+1bY/zOQY6eEsLwCJf2bc2c
YwDWV492meHUQa02OP0tNYXDyNGSFHFo1GyByVMl0B8wiXsArG2ibZjtZANIXbiX
KVmJmTIcAQk02cCWtX0u3ygHc4/hyPoDGrYY1WVC6gTiHGgqzUtOTg84yEGgBfAO
HpxFW/SNd1ujQXc3kxq37MLs6yP32CD8mITysH8yrabCAReGKAQ5+h1vlQCWft6Q
iF4qJP1XDZLRg8n5Fyry45mmMBBYGxZ+AIuxJ58F1ek/P7SHz4FHAgMBAAEwDQYJ
KoZIhvcNAQEFBQADggEBALCQnLMaJmRw51dPQG1j3oGW2kVCJUZ2aDrIQAVhbIyX
T7LVWxlCk8OP0jWM9VuAh2YDoipoBd1Rkb06WY8e68OZac1VenQoVKa0nE9bp7W6
kAUPUj6HDelH1o9avKAnfi2W849QcNXRQyNY01PQTgNQFpZZ3mVWQ826QD5eiiPN
HoHNlJ009cAr65GTj5qmykVMOPDoquyb1Hg173jFZB2PNYc1DtIPtOUa4f9VJmuH
//Gyd1ySbht4GRerSZIh3BYwVJrUx0oJFv61fLxvUt1dG4aKdZnoCmEzpJVHGheE
BBbwrl4gU288lza1py+Lr7Np3lgfkcfSIBaFvjV3Uyw=
-----END CERTIFICATE-----

Плюс ещё какие-то артефакты копипасты:


надежными инстру¬ментами безопасности

У меня сложилось впечатление что весь пост продвигает @Почту.рус и Поддерживаю.РФ.

вроде бы все посты на Хабре с заголовком в большой картинке как здесь, или с пометками «мегапост», «интересно», так или иначе рекламные… Никогда их не читаю, тут просто из любопытства зашёл.
К слову о большой картинке:



Глазу, привыкшему к русскому и к латинице, здесь видится хорошо знакомое слово, а не национальный TLD.
Только за первые сутки было зарегистрировано 240 тыс. доменов.
За 10 лет в зоне.РФ зарегистрировано 730 тыс. доменных имён. Чуть больше четверти (26%) зарегистрированы за последний год. 0,8% из них существует с 2010 года.


Што, простите? 0.8% это 240 от 730? или все 240 закрылись за 10 лет?
Когда юникод только пришёл в url, ходила шутка о продаже/развале/любом другом закрытии Майкрософта. Даже «пруф» был — micrоsoft.com. Правда, давно уже не работает, с того времени много багов памяти воды утекло. Рисовалась инфа о закрытии домена вроде бы.

Шутка не всегда удавалась. Когда мне скинули ссылку, я не ткнул на неё, а открыл браузер, набрал адрес руками и попал на настоящий сайт мелких.

Вот месяц назад настраивал ради прикола личный домен с emoji на почту, Postfix по дефолту вам подкинет свинью с Dovecot в паре. Postfix умеет и хочет в SMTPUTF8 из коробки (выключается через smtputf8_enable = no), а Dovecot LMTP не умеет и скорее всего не скоро научится (больше 7 лет данную тему поднимают и все никак), результат? Relay access denied от Gmail (ну и от других почтовиков) который умеет в SMTPUTF8 и от своих же клиентов которые будут слать с клиента почту с поддержкой UTF8 (Thunderbird, etc): SMTPUTF8 is required, but was not offered by host. Под host подразумевается Dovecot. Так же из тех почтовых систем что принимали не ascii символы в адресе получателя я смог найти только 2: gmail и zoho.eu. Причем Zoho был более серверо-независимым — он больше опирался на frontend отображение чем на реально поддержку SMTPUTF8 на стороне получателя, тогда как Gmail принудительно использовал преобразовывал punycode в Unicode своим frontendom всегда. Другие свободные почтовики типа yahoo, yandex, mail.ru, prothonmail etc не имеют поддержки Unicode на сегодняшний день. Вообщем: оно вам надо помнить домен lmao.com как xn--lmao-kp63c.com и каждый раз чуть что пользоватся Win+; и https://www.punycoder.com/?


P.s. habr.com сьел моего инопланетянина т_Т

mail.ru не анонсирует SMTPUTF8, но поддерживает Unicode-домены (для их поддержки SMTPUTF8 не требуется). Но смотрите комментарий ниже — домен xn--lmao-kp63c.com (как и домен из emoji в практически любой зоне) не является валидным Unicode для использования в почте. В лучшем случае он будет показан как punycode, в худшем при вводе как unicode вообще будет восприниматься как неправильный, т.к. тот же SMTPUTF8 использования punycode уже не подразумевает.

Удачи, введите в поле To не ASCII домен в mail.ru и попробуйте отправить. Ну а без поддержки SMTPUTF8 за отображение неASCII должен пектись только frontend — который к слову вам тоже покажен xn--. По последнему утвердению, "нарушают рекомендацию":


  1. Я чётко выразился в цели "Вот месяц назад настраивал ради прикола личный домен с emoji"
  2. Рекомендация не MUST так что вопрос закрыт :) и в любом кейсе этим доменом я и не собирался пользоваться ибо я считаю что почта на IDN домене это полный изврат, как и в принципе их существование.
письма с/на Unicode домены и принимаются и доставляются, отображаются они при этом как unicode (punycode в письмах декодируется), и уже очень давно, практически с момента запуска домена .рф

ascii@idn.ascii, ascii@chinise.ascii, ascii@arabic.ascii, arabic.arabic@arabic из ваших примеров напрямую нарушают рекомендации UTS 39
www.unicode.org/reports/tr39/#Email_Security_Profiles
Вам стоит выкинуть эти примеры из тестов и учесть в методике, т.к. они не являются валидными по текущим стандартам.

По этой же причине, почту в доменах типа idn.ascii держать нельзя от слова совсем, даже если получается его зарегистрировать.
Вы не могли бы пояснить свою мысль? Почему именно ascii@idn.ascii и RTL почтовые адреса нарушают рекомендации и как именно? Какие уязвимости они открывают?

Выкидывать же подобные тестовые примеры определенно не стоит, потому как уже достаточно много кто пользуется такой почтой, пусть и не как основной, но тем не менее. И вряд ли этот тренд будет иметь отрицательную динамику в будущем.
Стандарт требует в реализации выбрать (отдельно для локальной части адреса и домена) уровни ограничения (restrictions level).
1. ASCII-Only
2. Single Script
3. Highly Restrictive
4. Moderately Restrictive
5. Minimally Restrictive
6. Unrestricted

даже moderately restrictive профиль запрещает использование одновременно кириллицы и латиницы (т.е. idn.ascii в случае кириллицы пройдет только для Minimally Restrictive или Unrestricted). Очевидно, что большая часть реализаций будет выбирать для адресов почты moderately или highly restrictive. В рекомендациях M3AAWG (организация, в которую входят все крупные интернет компании, в том числе и российские) использовать highly restrictive профиль для адресов + рекомендация не принимать или класть в спам письма, адреса в которых не соответствуют этому профилю.

P.S. mail.ru использует highly restrictive, но проверяет отдельно по каждой доменной зоне, поэтому адреса с доменов типа idn.ascii принимаются. Но ждать нормального функционирования таких доменов не стоит, т.к. работа с ними относится к обработке нестандартных случаев.

К счастью, домены .ru и.рф так же позволяют регистрацию только латиницы и кириллицы соответственно, большая часть регистраторов в доменах типа .com так же начали использовать профили, поэтому надеюсь, что использование таких доменов франкенштейна для не-европейских языков все-таки будет иметь отрицательную динамику.
В этих рекомендациях речь идет о запрете некоторых редких символов и смешения скриптов в одной метке (см раздел Background): «The M3AAWG best practices approach is to disallow certain characters not in common usage, as well as the combining of confusable scripts within a single label...» Причем здесь idn.ascii? Да и вопрос был: какие именно уязвимости с ним связаны? Если атаки с использованием омоглифов, то смешение языковых скриптов в одной метке запрещены на уровне правил Регистратур и такой домен просто не зарегистрировать.
At receive time, MAIL FROM, FROM header, REPLY TO, and SENDER fields should be checked for validity and tested under the specifics in the Unicode TR39 Highly Restrictive level, as well as the normal RFC 5322 2 and RFC 53213 syntax and validity checks. Messages with invalid addresses may be rejected or delivered to the spam folder.


highly restrictive level в принципе запрещает mixed script (т.е. смешивание символов с разным написанием, в частности латиницу с кириллицей) с исключением для корейских, японских и китайских алфавитов, которые разрешается смешивать с латиницей.

По TR39 проверка адреса емейл идет для домена в целом, а не для отдельной его части.
В таком случае, отбрасывая омоглифы, чем так принципиально опасен idn.ascii?
Не надо их отбрасывать, ими и опасен. Например 1c.com vs 1c.com, EBAY.COM vs ЕВАУ.COM, HABP.com vs НАВР.com, Habr.com vs Наьг.com и т.д.
Так это справедливо и для ASCII, цифра 0 и буква O; заглавная I, прописная l и цифра 1; vv и w и т.д. Запрет IDN принципиально проблему спуфинга доменных имен не решает.
Да, совершенно верно, поэтому в стандарте дальше рассматриваются подходы (confusable detection) в т.ч. single-script confusables и рекомендации и то что домен соответствует профилю еще не означает что он будет принят. Но мне не совсем понятно, у меня вы что хотите уточнить? Вы показываете метрики, предлагаете методики и рекомендации. Я предлагаю вам в них учесть требования уже имеющихся стандартов и рекомендаций, потому что предлагать метрики, методики и рекомендации без учета стандартов и BCP странно. Зафиксируйте профиль Unicode, с которым вы тестируете на адекватном уровне, на котором ожидается реальная поддержка Unicode в почте, нет смысла тестировать на мусорных доменах, которые поддерживаться никогда не будут.

Единственной рекомеднацией по домену ascii@idn.ascii может быть не использовать его для почты, т.к. он невалиден для почты, а не ждать когда его станут лучше поддерживать.
Вы так и не объяснили почему вы считаете, что домен idn.ascii невалиден для почты? Это я и пытаюсь уточнить. Если причина в спуфинге с использованием омоглифов, то он присутствует и в доменах ascii.ascii. В упомянутом стандарте Unicode нет запрета на использование idn.ascii в почтовых адресах. Есть отнесение к определенным профилям и рекомендации по работе с этими профилями. Google и Yandex поддерживают почту на своем домене и домен может быть вида idn.ascii. Так откуда у Mail.ru столь категоричное убеждение?
незнание латинского алфавита, который необходим для поиска нужных ресурсов.

Что?


  • Во-первых, основной трафик приходит из поисковиков и руками обычные пользователи очень редко вбивают адреса. Они могут это делать на родном языке.
  • Во-вторых, все 26 букв латинского алфавита написаны у пользователя на клавиатуре. Если б там были абстрактные символы, это бы никак не изменило ситуацию.

Универсальное принятие

Это универсальное непринятие.


  • Национальные домены сложно набрать, не имея нужной расладки, а преобразовать в голове в punycode невозможно вообще.
  • Распознавать множество алфавитов многократно сложнее, чем запомнить 26 символов, даже человеку, который не знает ни одного из европейских языков, использующих варианты латиницы или относительно близкой к ней кирилицы.

gTLD

gTLD — раковая опухоль на теле системы доменных имён. 1200 доменов верхнего уровня, из которых только 4 имеют больше миллиона зарегистрированных имён и ещё 10 — больше 100К. Единственное added value — ICANN заработала ~220 миллионов долларов на их продаже, получив финансирование.

1. Неужели ни разу не сталкивались с ситуацией, когда адрес электронной почты приходилось диктовать по телефону? Куда удобней это делать на родном языке, безо всяких «эс как доллар». Да и множество, например, русских брендов хотят иметь эквивалентные домены на русском языке. Так что дело не только в незнание латиницы, а в желании иметь возможность регистрировать домены и адреса электронной почты на национальных языках. И поскольку это желание в мире однозначно растет, разработчикам остается только принять сей факт и научиться адаптироваться.

2. Punycode — это не решение, а временная мера, «костыли», используемые до тех пор, пока DNS не адаптируется к юникоду. Да, безусловно распознавать символы Unicode куда сложнее чем ASCII, но это неизбежный эволюционные процесс. Глобальная сеть вряд ли будет идти по траектории упрощения, любой «организм» в ходе развития становится сложнее, тем более такой как Интернет.

3. Для конечных пользователей added value — это конкуренция с монополией ccTLD и старых дженериков. А также удар по киберсквоттерам. Если ты можешь купить короткий домен в New gTLD зоне, созвучный с твоим брендом, зачем тебе платить в десятки раз дороже киберсквоттерам или покупать длинный корявый домен в старых зонах?
любой «организм» в ходе развития становится сложнее

Это неправда. Многие паразиты по мере развития и приспособления к паразитическому образу жизни упрощаются.

Сравнение сети Интернет с паразитирующей сущностью конечно любопытно, но весьма спорно :)
Вот когда DNS окончательно адаптируется к юникоду, чую мы опять получим волну дыр связанных с безопасностью и прочим фишингом.
Внедрение новых технологий почти всегда влечет с собой определенные риски, однако юникод используется уже во всех операционках, контент веба в UTF-8 и т.д. В DNS есть конечно свои нюансы, но они решаемы технически. А вот с реакционностью и бюрократией административной составляющей, я думаю, эта адаптация произойдет, к сожалению, еще очень не скоро.
Куда удобней это делать на родном языке,

Продиктуйте мне китайский email с unicode по телефону. Пусть даже не китайский, а финский / шведский / немецкий — я при всём желании не смогу набрать эти символы. Больше того, есть подозрение, что 'i' из украинского алфавита не равна латинской 'i', т.е. и на таких близких языках возникают проблемы.


безо всяких «эс как доллар»

С "M as in Mancy". Проблема обозначить буквы деградантам на другом конце провода не решается родным алфавитом — они его не лучше знают.


любой «организм» в ходе развития становится сложнее,

Технологии к живым организмам относятся очень опосредованно и последний век по планете шагает глобализация и стандартизация.


А также удар по киберсквоттерам. Если ты можешь купить короткий домен в New gTLD зоне, созвучный с твоим брендом, зачем тебе платить в десятки раз дороже киберсквоттерам или покупать длинный корявый домен в старых зонах?

На практике, это означает покупку во всех популярных доменных зонах. Google, например, принадлежит не только google.com / национальные домены, но и "google.co". Пользователи путаются и уходят не туда.

Продиктуйте мне китайский email с unicode по телефону. Пусть даже не китайский, а финский / шведский / немецкий — я при всём желании не смогу набрать эти символы.

Вы китаец? Фин/швед/немец? Я к тому, что носителю языка не надо переспрашивать как пишется к примеру андрей@почта.рус в отличии от andrey@pochta.rus, вот классические вопросы: i или y на конце? Почта через ch? Да у нас даже на транслитерацию отнюдь не один стандарт… Объективно носителю языка проще воспринимать слова на слух на своем родном языке, не так ли?

Организм, был приведен лишь как иллюстрация эволюции информационных технологий. Оглянитесь на последние 10 или 20 лет, насколько сложнее стали информационные системы и взаимодействие между ними.

Google, например, принадлежит не только google.com / национальные домены, но и «google.co». Пользователи путаются и уходят не туда.

Вы сами в браузер вбить google.co пытались? Там редирект на google.com, куда «не туда» уходят пользователи?
Я к тому, что носителю языка не надо переспрашивать как пишется к примеру андрей@почта.рус в отличии от andrey@pochta.rus, вот классические вопросы: i или y на конце?

Вроде, во французском то, что звучит на слух как «рено», можно записать десятком ПРАВИЛЬНЫХ способов!
Да и, в русском языке были яти, так что когда-то «мир» и «мiр» было возможно перепутать на слух.
Цель примера и смысловой акцент комментария на том, что
проще воспринимать слова на слух на своем родном языке
А если язык не родной?
Английский худо-бедно хотя бы знают почти все. :)
А а вот адрес на суахили — я, например, не пойму. :(
Бизнесам, работающим на суахили, совершенно не важно, сможете или нет вы записать на слух их адрес. Им гораздо важнее, смогут или нет записать их адрес их суахилиговорящие клиенты.
+1

Речь о возможности использовать почту на национальных языках там, где это удобней латиницы.
Я к тому, что носителю языка не надо переспрашивать как пишется к примеру андрей@почта.рус в отличии от andrey@pochta.rus

Переспрашивать не станет, просто напишет с ошибками. Андройдов и Тайландов в комментариях на Хабрахабре никогда не встречали? С «Ё» ситуация ещё печальнее, некоторые даже встретив её в тексте, прочтут как «Е».


С «Й», кстати, отдельный прикол: от маководов оно нередко приходит в виде двух символов, «И» отдельно, кратка отдельно. Какой-то софт сделает нормализацию, какой-то нет — вот нам ещё одна точка отказа.

RFC-5891 предписывает нормализацию доменных имён; эквивалентность U+0439 и U+0438 U+0306 технически ничем не отличается от эквивалентности заглавной I и строчной i внутри доменного имени.
Продиктуйте мне китайский email с unicode по телефону

lol
— в китайском языке, есть тона, которые лаовай перепутает
— есть диалекты, которые тоже без опыта, есть риск перепутать
— а ещё среди сложных иероглифов бывают очень похожие
Больше того, есть подозрение, что 'i' из украинского алфавита не равна латинской 'i', т.е. и на таких близких языках возникают проблемы.

++++


С "M as in Mancy". Проблема обозначить буквы деградантам на другом конце провода не решается родным алфавитом — они его не лучше знают.

+++

Неужели ни разу не сталкивались с ситуацией, когда адрес электронной почты приходилось диктовать по телефону? Куда удобней это делать на родном языке, безо всяких «эс как доллар»

нет. КАРОВА@mail.ru или КОРОВА@mail.ru? Как были проблемы, так и остались. Я уж не говорю о том, что сейчас нельзя будет защитить свой почтовый адрес, просто написав его символами другого алфавита с аналогичным написанием (лишь бы юзер не копипастил, а вводил нормально).


Punycode — это не решение, а временная мера, «костыли», используемые до тех пор, пока DNS не адаптируется к юникоду

согласен, что костыли, но DNS не надо адаптировать к юникоду.


Для конечных пользователей added value — это конкуренция с монополией ccTLD и старых дженериков.

конечно-конечно /sarcasm/


Если ты можешь купить короткий домен в New gTLD зоне, созвучный с твоим брендом

киберсквоттеры все равно успеют раньше

Честно говоря, я не понимаю, зачем и почему в XXI веке я должен к любому имени всё время приписывать.рф или .ru?

В прошлом веке, как бы, понятно ОЗУ 64 Кб, диски 2,5 Мб и 1 миллион операций или немного меньше, требовали экономить на всём. Но сейчас, а тем более в будущем, зачем?
Не так давно использование русского текста и в теле емейла вызывало технические затруднения:
Недавно мне было нужно разослать одно сообщение на кириллице через mailing list нескольким десяткам людей с разными серверами (одни перекодируют КОИ8<->1251, другие нет) и мэйлерами (от Eudor’ы до Bmail’a). Думаю, надо сделать так, чтобы кириллица у всех была сразу же видна без переключения фонтов или кодировок. Поэтому включаю в письмо четыре куска: (1) English, (2) КОИ8, (3) 1251 и (4) такой, который должен превратиться в КОИ8 в случае перекодировки POP-сервером или софтом получателя по таблице КОИ8->1251. Ну и? Все равно от одного из Dmail’oвских адресатов пришел ответ: “не могу прочесть письмо, так как в нем нет строки begin” (???). Оказывается, один серверок по дороге оказался еще умнее меня и зачем-то закатал мое письмо в Base64.

С телом в итоге справились, справятся и с адресами.
А как быть с фишингом, когда вместо «bank.com» написали с кириллицей «bаnk.соm», или для кириллического домена «банк.ком» сделали копию с латиницей «бaнк.кoм»?
Проблема спуфинга доменов и размещения фишинг-страниц на них появилась отнюдь не с появлением IDN. Например, bank.co и bank.com или vvolf.com и wolf.com Как быть? Бороться не жалея сил, с каждым отдельно взятым случаем :)

Кириллические домены — очередной шаг в сторону русской посконности и изоляции от окружающего мира.

А арабские, китайские, деванагарийские?
«Русский, с китайцем, братья навек!»
но масштабно эта технология пока не работает — доставка сообщений возможна только между системами, поддерживающими новый стандарт, а их пока немного.

дай Бог, что это не станет мейнстримом. Я такой представляю какой простор для фишинга будет. Например, пришло письмо с support@gооgle.com — попробуй угадай, что это фишинговое письмо. Просто фейспальм. А если в адресах имейл еще и управляющие символы (типа left-to-right mark (LRM)) появятся, то проще сразу застрелиться.

Например, пришло письмо с support@gооgle.com — попробуй угадай, что это фишинговое письмо.

Вообще-то адресу, написанном в поле From:, доверять нельзя что с юникодом, что без — ибо подделывается он как два пальца об асфальт.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.