Кратко

  • На встрече в ISI 11 января 1982 года участники выбрали расширение username @ hostname до username @ host.domain. Новую иерархию целиком поместили справа от единственного @, оставив локальные правила имён пользователей в покое.
  • Для верхних доменных имён требовалась мировая уникальность, а ответы службы имён следовало различать по назначению. Программам ещё предстояло научиться читать точки в поле хоста; DARPA получила поручение определить дату общего перехода.

У старого почтамта стоят ящики с табличками, которые жильцы подписывали по своим правилам. На некоторых табличках есть точка. Архитектор предлагает пристроить новый корпус и заодно заменить каждую старую надпись. Почтальон уже видит мешок возвратов. Примерно такую проблему обсуждали инженеры на встрече 11 января 1982 года в ISI. Её записал Jon Postel в RFC 805. Пристройку решили разместить справа от @, не переименовывая ящики слева.

На столе лежал более изящный чертёж: unique-id @ location-id. Постоянный идентификатор ящика можно было бы отделить от места доставки. Переезд менял бы местоположение, но не личность адресата. Однако в работе уже была форма user @ host, а вариантов локального поля user накопилось множество. Ради глобальной красоты пришлось бы переделывать чужие работающие программы. Участники отложили эту идею и занялись расширением знакомого адреса.

Размещать уровни слева или справа от @? В каком порядке? По объёму сведений варианты были сходны, по ущербу для существующих имён — нет. Точка уже встречалась внутри некоторых пользовательских имён. Если объявить её там общемировым разделителем, вчерашний правильный адрес завтра будет прочитан иначе. Поэтому вся новая структура ушла в часть хоста. Предлагался ровно один @; справа узлы, разделённые точками, шли от наиболее конкретного к наиболее общему. Пример в документе — Postel @ F.ISI.IN. Имена верхнего уровня должны были быть уникальными в мире, а их выбор — административно управляемым. Общая карта мест возникала без приказа каждому двору переписать имена жильцов.

Протокол встречи различает абсолютное иерархическое имя и относительный исходный маршрут. Он также раскладывает «поиск имени» на три разные работы: найти человека по признакам, связать постоянную личность с местом и преобразовать место в числовой сетевой адрес. Срочной была только третья. Запрос мог вернуть окончательный адрес машины, указание на нижестоящий сервер имён или пересыльщик. Программа должна понимать тип ответа: указатель на следующую стойку не равен адресу получателя. В мире, где рядом существовали NCP/FTP и TCP/SMTP, сведения о почтовой службе и протоколе тоже обсуждались отдельно.

Для самих данных предлагали текстовый файл, доступный по FTP, и запросы через соединения типа TCP или датаграммы UDP. Центральный сервер мог запустить дело; серверы по доменам и несколько копий каждой базы позволили бы распределить управление и пережить сбой. Это варианты из обсуждения, а не сообщение о готовности позднейшей системы имён. Ближайшая задача заключалась в пересмотре почтовых документов, переходного плана и программ, которым предстояло принять точку в поле хоста.

Наконец, понадобилась дата. Duane Adams из DARPA должен был к 1 марта 1982 года определить день, после которого отправители могли бы применять хосты с точками по всей ARPANET и Internet без возражений получателей. RFC 805 фиксирует поручение и срок; о завершении перехода к этому числу он не свидетельствует. Напечатать новый адрес легче, чем обновить каждый старый сортировщик на другом конце сети.

Главный ход оказался простым: слева от @ живёт местное имя, справа растёт согласованное место. Чертёж пристройки позволял сохранить старые ящики. Чтобы открыть новый корпус, требовалось ещё договориться о дне, когда почтальоны начнут туда ходить.