Данная статья была написана в период, когда идея создания многоязычных доменов достигла такой популярности, что ряд компаний параллельно принялись разрабатывать стандарты системы мультиязычных доменов. Сегодня уже известно, что одобрение получила одна из описываемых в статье архитектур (разработчик - VeriSign Inc.), но мы настоятельно рекомендуем читателю ознакомиться с этим материалом, так как в нем содержится история технологии многоязычных доменов. - прим. редакции от 20.11.2003 г.
В настоящее время все усилия по внедрению
многоязычных доменов сосредоточены на
использовании национальных алфавитов в Интернете
(т.е. в URL ресурсов, доступ к которым осуществляется
по протоколу HTTP).
Внедрение поддержки для других сервисов (например, e-mail и FTP)
предполагается начать после принятия стандарта
IETF.
Существующая архитектура и протоколы Internet
накладывают определенные, достаточно жесткие
ограничения на внедрение и использования не ASCII
символов в именах хостов.
Практически все технические решения,
предложенные на сегодняшний день, предполагают
установку специальных программ на клиентских
машинах. В зависимости от архитектуры
технического решения, эти программы (IDN-клиенты)
выполняют те или иные действия, позволяющие
обойти существующие ограничения на
использование не ASCII символов.
Несмотря на то, что все решения предполагают
установку дополнительных программ, имеются
существенные отличия в архитектуре решений.
Первый подход - обрабатывать все запросы на
преобразования доменных имен на стороне сервера.
Второй - все делать на клиентской машине и
"выпускать" запросы, содержащие только ASCII
символы. Оба подхода имеют свои
преимущества и недостаки. Судя по всему, до тех пор,
пока не будет принят стандарт IETF и производители операционных
систем не приведут программную реализацию резолверов в
соответствие этому стандарту, для разных языков будут применяться
различные решения.
Прежде, чем перейти к рассмотрению
существующих решений преобразования
многоязычных доменов в IP-адреса, приведем
краткий обзор того, как функционирует
существующая система доменных имен и как
браузер клиента взаимодействует с DNS и WEB-сервером:
После установки той или иной программы,
выполняющей функции IDN-клиента, процесс
взаимодействия браузера с WEB-сервером, PROXY и
службой DNS в принципе не изменяется. Основные
изменения касаются процесса преобразования
имени домена в IP-адрес (процесса резолвинга) на
клиентском компьютере. Ниже приведены три
архитектуры, каждая из которых имеет свои
преимущества и недостатки.
Архитектура 1. Все преобразования происходят на стороне DNS, PROXY или WEB-сервера:
При использовании решений, основанной на этой
архитектуре, все запросы, посылаемые компьютером
пользователя, содержат национальные символы. Их
обработка требует модификации существующей
инфраструктуры Internet (DNS, PROXY и WEB-сервера, в
зависимости от конкретной реализации).
Архитектура 2. Преобразования на стороне клиента:
При использовании решений, основанных на этой
архитектуре, все запросы, посылаемые компьютером
пользователя, содержат только ASCII символы.
Модификация существующей инфраструктуры Internet не
требуется. Необходима только установка на
пользовательский компьютер IDN-клиента.
Проект регистрации многоязычных доменов, предложенный
для реализации в зоне .RU, использует
именно эту архитектуру.)
-->
Архитектура 3. Смешанная:
При использовании решений, основанной на этой
архитектуре, запросы, посылаемые компьютером
пользователя в альтернативную систему DNS
содержат символы национальных алфавитов, а на PROXY
и WEB-серверы посылаются запросы, содержащие только ASCII символы.
Требуется создание альтернативной системы DNS и
установка на пользовательский компьютер IDN-клиента.