Кратко

  • RFC 5144 задаёт DCHK как облегчённый тип IRIS и строгую часть модели DREG.
  • active и inactive описывают публикацию в DNS, а не доступность регистрации.
  • reserved исключает обычную регистрацию даже при отсутствии имени в DNS.
  • Спор и льготные периоды не помещаются в бинарный индикатор.
  • Операция может быть pending или prohibited; её название не доказывает завершение.
  • Актор, область и авторитет подстатуса ограничивают смысл утверждения.
  • Время обновления исходной базы не совпадает со временем ответа или решения.
  • Ссылка на регистрацию указывает следующий сервис, но не переносит его полномочия.
  • XML-слой IRIS сам не обеспечивает аутентификацию и конфиденциальность.
  • Записи IANA подтверждают выделение идентификаторов, но не действующее внедрение.
  • Ссылка на устаревший Nameprep требует отдельной проверки совместимости IDN.
  • Для необратимого действия нужны отдельные квитанции политики, изменения и DNS.

Каталог не является датчиком

В IANA остались XML namespace и schema dchk1, прикладная метка S-NAPTR DCHK1 и URI профиля BEEP. RFC 5144 сохраняет статус Proposed Standard. Единственная подтверждённая errata исправляет написание “Straightforward-NAPTR”.

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

Та же дисциплина нужна при чтении ответа DCHK. Синтаксически корректная запись сообщает то, что позволил выразить информационный сервис. Она не является датчиком всех последующих систем.

inactive — состояние публикации

RFC 5144 определяет active как доступность через DNS посредством делегирования или прямой публикации. inactive означает недоступность через DNS. Это не пара «занято/свободно».

Статус reserved прямо говорит, что имя нельзя получить обычной процедурой регистрации. Оно может одновременно быть не опубликовано в DNS. Дополнительно модель хранит спор, соответствие политике и периоды после создания, продления, автоматического продления, переноса и удаления.

RFC 3915 показывает переходы после удаления: redemption, ожидаемое восстановление, ожидаемое окончательное удаление и лишь затем возможная повторная регистрация. Исчезновение DNS-записи не отменяет эти стадии.

Для create, delete, renew, restore, transfer и update предусмотрены pending и prohibited. Если интерфейс оставляет слово transfer, но выбрасывает pending, он меняет факт. RFC 5731 в модели EPP называет check подсказкой о возможном успехе create, поскольку требования определяет политика сервера. Обработанная трансформация также может ещё не завершиться.

У утверждения есть владелец и срок

Статус DCHK может включать дату применения, служебные билеты, описания и подстатус. Для подстатуса требуется указать авторитет, определивший его значение. actor различает registry, registrar и registrationServiceProvider, а scope задаёт контекст.

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

lastDatabaseUpdateDateTime датирует последнее обновление базы-источника. Быстрый HTTP-ответ не делает её свежей. Следует сохранять отдельно время источника, ответа, кэша, решения и команды. Иначе после конфликта нельзя отличить задержку репликации от смены политики или гонки заявителей.

Переход по ссылке не переносит власть

registrationReference может вести от результата registry к registrar или сервису registrant. IRIS поддерживает ссылки и продолжения поиска между типами и экземплярами, предупреждая о циклах.

Достижение адресата доказывает маршрутизацию запроса. Новый сервис может требовать аутентификацию, право участия, оплату и применять более свежую политику. Предыдущий сервер не может делегировать эти решения одной ссылкой.

RFC 3981 отдельно говорит, что XML-слой IRIS не обеспечивает собственные аутентификацию и privacy. RFC 5144 требует IRIS-LWZ, а XPC и BEEP оставляет опциональными. Защищённая сессия удостоверяет участника разговора, но не право изменить доменный объект.

Старое правило IDN — отдельная граница

Поле IDN в RFC 5144 ссылается на Nameprep из RFC 3491. Этот документ устарел; RFC 5891 описывает IDNA2008. Из этого нельзя заключить, что RFC 5144 формально отменён. Нельзя и считать старую нормализацию совместимой с современной политикой конкретного реестра без проверки.

RFC 9083 показывает более позднюю JSON-модель ответов RDAP. Здесь он служит свидетельством иной архитектуры представления, но не объявляется формальным преемником DCHK.

Лестница квитанций

Первая ступень хранит исходную строку, нормализацию, адресата, версию и полный ответ. Вторая — время базы, все статусы, actor, scope, disposition, билет и авторитет подстатуса. Третья — источник и адрес назначения ссылки.

Дальше начинаются отдельные решения: личность и право заявителя, версия политики, цена, отправка и принятие команды, проверка, подтверждённая мутация, публикация DNS и наблюдаемая работа сервиса. Каждая ступень разрешает следующую проверку, но не подменяет её результат.

Источники

  1. RFC 5144, HTML
  2. RFC 5144, текст
  3. Карточка RFC Editor
  4. Карточка IETF Datatracker
  5. История документа
  6. Поиск errata
  7. Версия с подтверждённой errata
  8. IANA XML Registry
  9. IANA S-NAPTR Parameters
  10. IANA BEEP Parameters
  11. RFC 3981: ядро IRIS
  12. RFC 3982: доменный тип IRIS
  13. RFC 3983: IRIS поверх BEEP
  14. RFC 4992: XML-конвейер для IRIS
  15. RFC 4993: облегчённый UDP-транспорт IRIS
  16. RFC 3915: льготные периоды EPP
  17. RFC 5731: доменное отображение EPP
  18. RFC 3491: Nameprep
  19. RFC 5891: IDNA2008
  20. RFC 9083: JSON-ответы RDAP
  21. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  22. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  23. Running-Code Primacy