Кратко

  • RFC 3968 создал отсутствовавший в RFC 3261 реестр IANA для параметров и значений полей заголовка SIP, закрепив контекст имени и определяющие документы.
  • Запись подтверждала публичное назначение и снижала риск коллизий, но не доказывала реализацию, понимание конечной системой, принятие запроса, безопасное применение или исход вызова.

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

RFC 3261 разрешил новые параметры полей заголовка SIP и новые значения, но не учредил для них реестр IANA. RFC 3968 в декабре 2004 года заполнил пробел. Для записи требовались поле, имя параметра, признак ограниченного набора значений и ссылки на определяющие RFC.

Документ должен был полностью раскрывать синтаксис, назначение и семантику. Так независимые реализации получали общий источник, а пространство имён — защиту от случайных коллизий. Но общий источник ещё не означал общий код.

Прошедшее сообщение могло ничего не доказать

RFC 3261 предписывал серверу игнорировать непонятное поле заголовка и продолжать обработку, если поле не было необходимо для запроса. Благодаря этому старые узлы могли пропускать новые элементы. Та же устойчивость делала наблюдение неоднозначным.

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

Для некоторых расширений SIP имел отдельный механизм: Supported, Require, Proxy-Require, Unsupported и ответ 420. Узел мог заявить поддержку, потребовать понимания или назвать неподдержанное условие. Эти сведения исходили от конкретного участника конкретной транзакции.

Запись IANA не подменяла их. Она не знала версию программы, включённые модули, правила авторизации и финальный результат. Даже заявление Supported не гарантировало принятие конкретного запроса.

Имя без поля было неполным идентификатором

RFC 3968 разрешал одинаковое имя параметра в разных полях, но требовал уникальности внутри одного поля. Следовательно, q, tag или algorithm без имени поля могли указать на другой зарегистрированный объект.

Телеметрия должна хранить поле, параметр, набор ссылок и время наблюдения. Поиск по одной строке может быть точным технически и неверным по смыслу.

Зарегистрированные параметры и значения становились зарезервированными словами и должны были применяться согласно своим RFC. Частные определения не могли конфликтовать с ними. Незарегистрированные параметры оставались допустимыми, но рискованными: будущая регистрация могла занять то же имя.

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

Список значений жил в ссылках

Predefined Values: Yes не был полной таблицей. RFC 3968 регистрировал такие значения по ссылкам, чтобы не создавать множество подреестров. Исходный RFC и позднейшие документы вместе задавали набор; добавления отмечались двойными скобками.

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

Регистрация шла по политике IETF Consensus из RFC 2434 и требовала RFC, не обязательно стандарта. RFC 8126 позднее описал регистрацию как связь значения с назначением в пространстве имён. Эта связь назначает публичный смысл, а не устанавливает реализацию.

Префикс не удержал статус

RFC 3427 пытался выделить предварительные, частные и проприетарные поля префиксом P- и процедурой проверки. Причиной были риски безопасности и роста сложности SIP.

RFC 5727 зафиксировал неудачу границы: некоторые P--поля широко распространились за пределами закрытых сред, а установленная база сделала переименование неправдоподобным. Специальный процесс отменили.

RFC 6648 обобщил опыт для X-: по наличию или отсутствию префикса нельзя автоматически судить о стандартизации или безопасности. Статус должен находиться в явных метаданных и документах.

Начальные записи RFC 3968 ссылались на разные механизмы: RFC 3310 для аутентификации, RFC 3265 для событий, RFC 3455 для частных сетей и RFC 3329 для согласования безопасности. Одинаковые колонки не делали их одинаковыми по действию и риску.

Современный реестр параметров SIP IANA объединяет много живых подреестров. Карточка RFC Editor, исправления и IETF Datatracker подтверждают документальный статус, но не измеряют распространение и безопасность.

RFC 3968 сделал происхождение имени проверяемым. Понимание и действие конечной системы оставались следующими, отдельными фактами.

Источники