Кратко

  • RFC 3969 резервировал каждое имя URI-параметра и в SIP, и в SIPS, не позволяя одному написанию получить два смысла; двойная запись не доказывала применимость к обеим схемам.
  • Документ назвал политику «Specification Required», но потребовал standards-track RFC. RFC 5727 признал противоречие и уточнил: подразумевался Standards Action.

В RFC 3969 одна строка реестра выглядит шире, чем соответствующее поведение. Любое имя параметра регистрировалось и для SIP URI, и для SIPS URI. Тут же документ предупреждал: параметр может не относиться к одной из схем. Вторая регистрация закрывала имя для повторного назначения, а не включала функцию.

Пробел оставил RFC 3261: новые параметры и значения разрешались, но отдельного реестра IANA не было. Авторы двух расширений могли независимо выбрать одно слово для разных механизмов. Синтаксис оставался допустимым, тогда как смысл расходился. RFC 3969 в декабре 2004 года создал недостающую точку координации.

Два места сохраняли одно значение

Начальная таблица включала comp, lr, maddr, method, transport, ttl и user. comp ссылался на RFC 3486, остальные первоначально — на RFC 3261. Строка хранила имя, признак предопределённых значений и определяющие документы.

Отметка Predefined Values: Yes не была полным перечнем. Реестр регистрировал значения по ссылкам, и реализации требовалось прочитать все документы. В нынешнем реестре параметров SIP IANA строка transport ссылается на RFC 3261 и RFC 7118. Это живой указатель на нормы, а не готовая таблица парсера.

Зарегистрированные имена стали зарезервированными словами. Локальное незарегистрированное имя допускалось, но могло столкнуться с будущим публичным назначением. Вендорского дерева не предусматривалось. RFC 3427 предупреждал, что расширения SIP способны повысить сложность и навредить безопасности, поэтому публичное назначение требовало документировать синтаксис, назначение и семантику.

Но право на имя не означало работоспособность. RFC 5630 позднее уточнил обработку SIPS и ожидания безопасности; RFC 3263 описал поиск серверов и выбор транспорта. Двойная резервация не содержит этих условий и не подтверждает поддержку конкретным продуктом.

Название политики не совпало с её порогом

Раздел 4.2 применил термин «Specification Required» из RFC 2434, а следующей фразой потребовал standards-track RFC. Эти процедуры дают полномочия разным механизмам рассмотрения и потому не взаимозаменяемы.

RFC 5727 в 2010 году прямо назвал это противоречием, возникшим из неверного понимания категорий, и зафиксировал исходное намерение: Standards Action. Именно такую процедуру сегодня показывает IANA. RFC 8126 позже обновил словарь политик и подчёркивает, что метка определяет полномочия и требования к решению.

Текущий экран не должен стирать цепочку изменений. Карточка RFC Editor, поиск errata и IETF Datatracker фиксируют статус, сообщения об ошибках и историю документа. RFC 3986 задаёт общую архитектуру URI, а RFC 6648 позднее запретил выводить зрелость или безопасность лишь из префикса имени.

Проверка наблюдаемого параметра начинается со схемы, точного написания и времени. Затем находят строку на тот момент, проходят по всем ссылкам, читают область применения и безопасность. Только после этого исследуют версию ПО, конфигурацию, обработку транзакции и результат. Успешный вызов мог обойти параметр; зарегистрированное имя могло прийти в систему без реализации.

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

Источники