Кратко

  • RFC 1911 заменял аналоговый межмашинный обмен через DTMF и проигрывание узким цифровым профилем на основе MIME и ESMTP.
  • Объявленная возможность или завершенная SMTP-транзакция не доказывала сохранение получателей, трассы и идентификатора, декодирование, правильный ящик или прослушивание.
  • По описанию RFC 2421, демонстрации EMA’96 и EMA’97 привели к существенным изменениям; испытание стало источником новой спецификации.

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

RFC 2421 прямо связывает обновление с доказательством концепции на EMA’96 и демонстрациями продуктов на EMA’97. Источник не дает полного перечня производителей, процента успеха или картины развертывания. Он дает более надежный факт: вторая версия заметно отличалась от RFC 1911.

RFC 1911 был опубликован в феврале 1996 года со статусом Experimental, а не Internet Standard. Это был открыто зафиксированный опыт минимального общего профиля, а не сертификат зрелости всей голосовой почты.

Из multipart/voice-message убрали зависимость смысла от позиции частей и строже ограничили допустимое содержимое. Уточнили пересылку и ответы. Добавили факс, сведения каталога и детали уведомлений. Несколько определений вынесли отдельно. Тестовый loopback объявили нежелательным по соображениям безопасности. Раздел об угрозах расширили.

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

Специализированный ящик не хранил всю Internet-почту

Целевой компьютер подключался к телефонной станции, отвечал на звонки и выдавал записи через трубку и цифровую клавиатуру. Ранее удаленную систему могли выбрать сигналами DTMF, а голос передать аналоговым проигрыванием. RFC 1911 решил использовать существующую инфраструктуру MIME и ESMTP.

Однако многие платформы не показывали текст. Они совмещали транспортный и пользовательский агент, выполняли окончательную локальную доставку и не ретранслировали сообщения. Хранилище могло не сохранить полный список адресатов, строки Received или Message-ID. Рассылки оставались локальными псевдонимами, а имена ящиков — короткими числами.

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

Общий минимум опирался на локальный каталог

Дополнительные форматы разрешались лишь при явном знании о получателе. RFC 1911 предлагал каталог возможностей, но оставлял его устройство и ведение местной администрации.

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

Даже ярлык VPIM не описывал версию, кодек, MIME-дерево, лимит, роль шлюза, результат SMTP и то, какие поля остались в ящике. Совместимость становилась проверяемой только после раскрытия этих деталей.

Набранное число еще не было адресом с доменом

Пользователь вводил цифры, а почтовому адресу требовались локальная часть и домен. Машина выбирала FQDN своим способом. Одинаковые добавочные номера могли существовать в разных организациях; локальная таблица могла ошибиться, хотя DNS правильно отвечал на уже выбранное имя.

Нужно было сохранять исходные цифры, правило и версию преобразования, DNS-ответ, SMTP-узел и итоговый ящик. postmaster служил обязательной диагностикой. Предложенный в первой версии loopback возвращал новое сообщение от postmaster, но следующая версия отказалась от него из-за риска. Удобный тест не получил бессрочного доверия.

SIZE измерял не время голоса

Для человека сообщение длилось несколько минут. SIZE считал байты, включая MIME-оболочку. Число зависело от кодека и от того, мог ли путь нести двоичные данные или требовал Base64.

Обязательным общим форматом стал Audio/32KADPCM. Иные зарегистрированные или частные кодеки требовали знания о получателе. Базовый формат давал общую возможность, но не доказывал качество конкретного декодера, понятность записи или успешное воспроизведение.

Объявление 8-битного, двоичного, фрагментированного транспорта или SIZE относилось к одному SMTP-партнеру. Оно не гарантировало свойства окончательного хранилища и не говорило за пользователя. Положительный ответ сервера оставался ограниченной квитанцией.

Машиночитаемый отчет должен был стать слышимым

Человека-оператора могло не быть, а пользователь располагал только телефоном. Поэтому структурированное уведомление требовалось преобразовать в понятное голосовое объяснение.

Но DSN описывал только известную его создателю стадию. Окончательная доставка могла предшествовать ошибке декодера. Потеря Message-ID нарушала корреляцию. Правильно созданное уведомление могло остаться непрослушанным. Отчет, представление и человеческое восприятие не были одним событием.

Уточнение тоже имело собственную роль

RFC 3801 позднее формально заменил RFC 2421 как устаревший, изложил VPIMv2 точнее и заявил, что не меняет протокол предыдущего документа. Это отделяет два вида ремонта: демонстрации привели к изменению поведения, а более поздний документ уменьшил неоднозначность записи уже принятого поведения.

RFC 1911 ценен не как рассказ о полном поглощении голосовой почты электронной. Он показывает узкий коридор между неравными системами. Проверка должна пройти от набранного номера и выбора домена через DNS, SMTP, EHLO, конверт, идентификатор, трассу, MIME, кодирование, формат и размер к доставке, хранению, декодированию, уведомлению, воспроизведению и слушанию. Ящик мог принять голос и не сохранить сообщение целиком.

Источники