Кратко

  • Версия 15 проекта RDAP Extensions предлагает дату устаревания в реестре IANA. Зарегистрированный контакт сможет запросить её для своей записи, IESG — для любой. Это меняет статус метки, но не удаляет чужой код.
  • Проект версионирования публикует в /help начало, окончание, версию по умолчанию, предшественника и преемника, указывает версию конкретного ответа и принимает предпочтение клиента. Он координирует переход, не перечисляя всех клиентов.
  • Нужна квитанция вывода из эксплуатации, где отдельно записаны полномочие реестра, объявленное и наблюдаемое состояние серверов, измеренный спрос и остаточная неизвестность. Это предложение Daniel Kade, а не требование IETF.

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

draft-ietf-regext-rdap-extensions-15 от 13 августа 2026 года описывает RDAP как сеть раздельных источников полномочий. Клиент проходит через начальную службу, перенаправления и ссылки к серверам TLD, регистраторов или RIR. Ни один оператор не обязан знать всю популяцию программ на другом конце.

Документ остаётся активным проектом рабочей группы REGEXT с предполагаемым статусом Standards Track. Datatracker указывает, что из-за вопроса рабочей группы нужна новая редакция; ответственный Area Director отсутствует. Версия 07 проекта версионирования от 31 июля также не является RFC или свидетельством внедрения.

Полномочие над общей меткой

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

Версия 15 добавляет Deprecation Date. Контакт в реестре может попросить признать устаревшим собственное расширение, а IESG — любое расширение RDAP. IANA фиксирует полную дату по RFC 3339. Так возникает проверяемая цепочка изменения публичного статуса.

Её полномочие ограничено реестром. IANA не удаляет поле JSON с независимого сервера и не обновляет библиотеку клиента. Пометка направляет читателя к актуальному выбору, но не подтверждает завершение развёртывания.

Проект просит поставить 21 августа 2025 года для уже помеченных OBSOLETED идентификаторов icann_rdap_response_profile_0 и icann_rdap_technical_implementation_guide_0. Действующий реестр, обновлённый 1 сентября 2026 года, показывает их и преемников версии 1, но не отдельную колонку даты. Это не основание обвинять IANA: новое поле пока предложено только черновиком.

Политика Specification Required с Expert Review решает другую задачу. Ссылка должна быть стабильной, доступной и достаточно подробной для независимой совместимой реализации. Версия 15 предлагает минимум трёх экспертов и повторную проверку каждой заявки. Это контроль общего словаря, а не перепись установленного ПО.

Сервер отвечает за собственный срок

В проекте версионирования versioning_help сообщает через /help поддерживаемые версии, значение по умолчанию, документацию, отношения предшественника и преемника, start и end. versioning_data отмечает версию конкретного ответа. versioning_list позволяет клиенту назвать желаемую.

Поддержка, фактический ответ и запрос клиента — разные утверждения. Сервер может сохранять старую версию, но выдавать новую по умолчанию. Новый ответ не доказывает удаления старого. Молчание клиента может означать лишь принятие значения по умолчанию, а не готовность к новой семантике.

end — обещание сервера закончить поддержку. После этого времени объект версии должен исчезнуть; отсутствие end означает, что срок не запланирован. Это точная политика данного сервера, но не аттестация внешних клиентов.

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

Проект расширений прямо говорит: поскольку между сервером и клиентом RDAP нет обязательной связи, нельзя абсолютно установить, что ломающая перемена не затронет ни одного клиента. Неопределённость не должна становиться вечным запретом. Бессрочная совместимость тоже закрепляет стоимость и неоднозначность.

Измерение без досье

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

Бессрочное хранение объектов запросов, адресов и отпечатков программ превратит миграцию в наблюдение. Публичная метрика должна указывать окно, серверы, агрегирование, исключения и срок хранения. Нулевое число наблюдений в выборке допустимо; отсутствие всех зависимостей в мире из него не следует.

Квитанция вывода

Первая часть называет идентификатор, версию, уполномоченного заявителя, запись IANA и дату. Вторая описывает предшественника, преемника, несовместимости, удаляемые элементы и стабильную ссылку.

Третья часть для каждого сервера хранит датированные снимки /help, смену значения по умолчанию, начало и конец, versioning_data, ошибки для старых запросов, правило отката и наблюдаемое удаление. План нельзя задним числом переписать как факт.

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

Так IANA отвечает за статус имени, оператор — за выдаваемый интерфейс, владелец клиента — за обновление. Координация связывает их действия, не назначая одному участнику несуществующие сквозные полномочия.

Источники