Кратко

  • RFC 3191 определил минимальное представление телефонного номера в локальной части интернет-адреса, но разрешил толковать селектор услуги, номер и уточнения только MTA, отвечающему за домен справа от знака @.
  • Корректная форма не доказывала исполнение: визуальные разделители игнорировались, неизвестные уточнения сохранялись, несколько субадресов превращались в отдельных получателей, а успех DNS или SMTP не подтверждал ни личность абонента, ни доставку устройству.

Смысл возникал не из похожей на команду строки

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

RFC 3191 предложил небольшой общий формат. Локальная часть начиналась селектором услуги, знаком равенства и представлением номера; за ними могли идти зарегистрированные уточнения. После @ располагался домен шлюза.

Документ сохранил обычное правило почты: локальную часть должен интерпретировать лишь MTA, обслуживающий правый домен. Промежуточный сервер способен прочитать VOICE=+..., однако распознавание знаков не даёт ему ни контекста, ни права инициировать вызов. Его роль — перенести строку к назначенному интерпретатору.

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

Минимальная грамматика не подменяла телефонный справочник

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

Знак плюс имел другую силу: он резервировался для глобальной формы. Шлюз мог поддерживать локальные или частные планы набора, но им нельзя было занимать этот маркер и выдавать себя за глобальные. RFC не нормализовал всю мировую телефонию, а очертил границу своего пространства имён.

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

Непонятное уточнение оставалось частью исходного распоряжения

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

Базовая реализация могла не исполнять незнакомое уточнение. Но RFC 3191 требовал сохранить все полученные элементы. Разница принципиальна: игнорирование фиксирует ограничение текущего обработчика, тогда как удаление превращает его незнание в окончательное решение за все последующие системы.

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

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

Исторический след принимали на входе, но не объявляли образцом

Полный объект оставался почтовым addr-spec и подчинялся правилам цитирования. Получатели также должны были принимать необязательные косые черты вокруг телефонной конструкции: они могли оставаться после прохождения через другие шлюзы, включая маршруты X.400.

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

Сам RFC 3191 заменил RFC 2303. Он переосмыслил PSTN с «Public» как GSTN с «Global», поскольку телефония больше не укладывалась в модель одного или нескольких публичных операторов. Некоторые старые имена переменных ABNF при этом сохранились ради развернутого кода. Институциональное описание обновили, не ломая интерфейс ради терминологической аккуратности.

Один телефонный ящик мог потребовать нескольких почтовых получателей

Один номер телефонной услуги мог содержать несколько субадресов. Почта отслеживает принятие, отказ и повторную попытку по каждому получателю. Поэтому RFC 3191 требовал создавать несколько элементов pstn-email, если указано несколько субадресов.

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

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

DNS выбирал путь письма, а не устанавливал телефонный факт

Правый домен направлял письмо к шлюзу, поэтому раздел безопасности выделял манипуляции DNS. Скомпрометированный сервер, поддельный ответ или заражённые дополнительные данные могли увести сообщение к враждебному MTA.

Проверка авторитетного DNS-ответа усиливает доказательство выбора маршрута. Она не подтверждает правильность программы шлюза, свежесть базы номеров, разрешение политики или ответ устройства. Даже реально назначенный номер может принадлежать не тому человеку, которого подразумевал отправитель.

Надёжная история должна раздельно хранить исходную строку, DNS-ответ, принятие SMTP, решение парсера, команду телефонной сети и возможное конечное подтверждение. Фраза «адрес сработал» сливает границы, на которых полномочия переходили от одного участника к другому.

Минимальный формат оказался полезен, потому что не присваивал себе итог

RFC 2846 позже описал более богатое надмножество для локального набора, последовательностей после набора, субадресов и данных получателя. RFC 3192 применил минимальную схему к факсу. Ни один из них не превратил RFC 3191 в универсальный механизм исполнения.

Его достижение было уже: разные шлюзовые услуги получили маленький общий конверт и управляемое расширение. Транзитные системы переносили то, чего не имели права толковать. Шлюзы узнавали зарегистрированные слова, не обещая реальность каждого синтаксически допустимого назначения.

Слева от @ находилось телефоноподобное представление, справа — выбор интерпретатора. Окончательного эффекта не было ни в одной из строк. Совместимость стала возможной потому, что стандарт распределил полномочия и оставил результат отдельным наблюдением.