Кратко

  • RFC 3966 разрешал при сравнении tel URI отбросить визуальные разделители, регистр и порядок записи параметров, но сохранял различие локальной и глобальной формы, phone-context и каждый параметр.
  • Равенство относилось к ресурсу в рамках контракта идентификатора; оно не подтверждало актуальное назначение номера, доступность, маршрут, личность, согласие или исход звонка.

Телефонный номер служит не только машинным ключом, но и текстом для человека. Цифры разбивают на группы, окружают скобками, разделяют дефисами. Если база признаёт равными лишь байты, оформление порождает ложные дубликаты. Если очиститель оставляет только цифры, он рискует слить разные пространства нумерации. Опубликованный в декабре 2004 года RFC 3966 провёл границу иначе: перечислил несущественные различия и сохранил структурные.

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

Так RFC 3966 сузил область предшествующего RFC 2806. Из схемы исчезли выбор оператора, действия контекста набора, формы факса и модема, паузы и посленаборные строки. Идентификатор остался, действия ушли в свой слой. Соседняя история строк с телефонными действиями сохранилась в RFC 3601, но это не механизм равенства данной статьи.

Компаратор забывал только разрешённое

Перед сравнением из номера удалялись визуальные разделители , ., ( и ). Регистр букв не учитывался. Параметры сопоставлялись по именам, а не по месту в исходной строке. Поэтому две глобальные либо две локальные формы могли быть равны при разном внешнем виде.

Однако такая нормализация имела предел. Оба URI должны были быть либо локальными, либо глобальными. Локальная и глобальная записи не становились равными только потому, что оператор считал их путями к одному месту. Если имя параметра присутствовало лишь с одной стороны, пара была неравна. Для локального номера в идентичность входил phone-context; расширение ext, ISDN-подадрес isub и обязательные дополнения также сохраняли значение.

Синтаксис предлагал канонический порядок сериализации: сначала isub или ext, затем phone-context, после них остальные параметры лексикографически. Это помогало окружающим системам, всё ещё сравнивавшим символы. Но семантическое правило сопоставляло параметры по именам независимо от порядка получения. Каноническая запись и доказательство равенства — связанные, но разные средства контроля.

RFC 3986 дал общую модель URI. RFC 3261 применил синтаксис телефонного абонента в SIP и показал среды, где посимвольная обработка по-прежнему существенна. Поэтому проверяемая система отдельно хранит исходные октеты, разобранную структуру, журнал преобразований и каноническое представление. Производная запись не должна заменять первичное свидетельство.

Контекст создавал имя, а не прокладывал маршрут

Спецификация предпочитала глобальную форму, но внутренние номера АТС, экстренные коды и другие локальные службы не всегда можно выразить глобально. Локальному номеру требовался phone-context: контролируемое доменное имя либо начальные цифры действительного глобального номера. Вместе с локальными цифрами он должен был образовать глобально уникальный идентификатор.

Контекст не являлся префиксом для склейки. 911 в контексте +1 не превращался в +1-911. Доменному контексту даже не требовалось разрешаться в хост; он должен был находиться под административным контролем управляющего локальной нумерацией. Совпадение контекста поэтому не подтверждало DNS-шлюз, рабочий маршрут, текущее назначение или право пользования.

Получатель, которому URI нужен только как имя, мог считать контекст непрозрачным значением. Для совершения вызова требовалось понимать его и уметь работать внутри него. Сам RFC предупреждал: даже глобальный номер может устареть или быть недоступен из некоторого места. Установление тождества ресурса и попытка достичь его требуют разных доказательств.

Одинаковый набор мог остаться непригодным

ext обозначал внутреннюю станцию за не-ISDN АТС, isub — ISDN-подадрес; вместе они не допускались. Позднее RFC 4715 уточнил кодирование подадреса. RFC 4694, RFC 4759 и RFC 4904 продолжили историю параметров переносимости номера, ENUM-запроса и транковой группы.

Для будущих обязательных параметров RFC 3966 зарезервировал префикс m-. Если реализация не понимала такой параметр, использовать URI было нельзя. Неизвестный необязательный параметр разрешалось игнорировать. Так появились два самостоятельных решения: совпадают ли структуры и способен ли получатель действовать? Совпадение одного неизвестного m- по обе стороны не даёт программе недостающего понимания.

RFC 5341 позднее создал процедуру регистрации параметров, а современный реестр IANA tel URI Parameters публикует согласованный словарь. Зарегистрированное имя можно найти, но регистрация не доказывает истинность или свежесть конкретного значения, полномочия отправителя и поддержку получателя. Равенство, корректность, способность и власть нельзя свести к одному флагу.

Ресурс не заменял человеческую личность

Во время установления вызова один tel URI мог переводиться в несколько других URI. Сигнализация согласовывала вид услуги; у точки завершения могло быть несколько идентификаторов; один номер не обязан был выбирать единственный аппарат или человека. RFC 6116 позднее описал ENUM-преобразование номеров E.164 в услуги и URI. Оно добавляет свидетельство о возвращённых записях и времени запроса, но не превращает равенство RFC 3966 в проверку личности ответившего.

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

Информационная страница RFC Editor, поиск исправлений и карточка IETF Datatracker подтверждают статус документа и зарегистрированные исправления. Они не сообщают уровень внедрения, число коллизий или результат звонков. Для аудита нужны исходные байты и отображение; локальная или глобальная форма; цифры до и после удаления разделителей; изменение регистра; множество параметров и порядок получения; канонический порядок; вид и владелец контекста; ext или isub; распознавание обязательных параметров; версия парсера; правило и результат сравнения. Актуальность назначения, преобразование набора, сигнальная цель, маршрут, согласие, ответ терминала, ответ человека, услуга и стоимость записываются отдельно.

RFC 3966 сделал сравнение полезным, забывая только то, что сам контракт объявил оформлением. Обратный вывод столь же важен: реальность, которую правило не наблюдало, нельзя незаметно вложить в слово «тот же».

Источники