Кратко

  • RFC 3362 зарегистрировал image/t38 как обозначение среды в SDP для факсимильного потока T.38 реального времени; кодирование и процедуры оставались в рекомендации ITU-T T.38.
  • Метка устраняла неоднозначность названия, но не доказывала принятие потока, совместимость транспорта, шифрование, работу шлюза, полноту страниц или получение документа.

Запись в реестре может пережить оборудование, компании и способы эксплуатации. Именно поэтому важно не приписывать ей лишнее. Строка image/t38 сообщает, о каком типе потока идёт речь. Она не сообщает, дошёл ли лист бумаги.

RFC 3362 была опубликована в 2002 году как небольшой мост между разными областями стандартизации. Рекомендация ITU-T T.38 описывала технические свойства передачи факсов группы 3 в реальном времени по сетям IP. SIP и SDP задавали механизмы установления и описания сеанса. RFC зарегистрировала общий подтип среды, который можно было указать в SDP.

Документ не присваивал себе определение кодирования. Он прямо ссылался на T.38. Там же отмечалось, что в зависимости от среды обслуживания может применяться TCP или UDP. Процедуры Annex D, опиравшиеся на ранние версии SIP и SDP, могли использоваться и с пересмотренным SIP из RFC 3261.

Разделение ответственности было свойством архитектуры. ITU-T поддерживала факсимильное поведение, IETF — сеансовые протоколы, IANA — стабильный идентификатор. Реализацию выбирали разработчики, эксплуатацию — операторы. Хранитель записи не становился владельцем всей работающей цепочки.

Регистрация была предельно компактной. Обязательных параметров нет, необязательных тоже нет, данные бинарные, предполагаемое применение — common. Пустые поля параметров определяли границу: в метке не был спрятан полный профиль совместимости. Дополнительные решения оставались в T.38, SIP, SDP и конфигурации.

Контекст был частью значения. RFC 3362 предназначала тип для обозначения T.38 в SDP и отдельно исключала электронную почту. Почтовое применение не было определено и потому не гарантировало совместимости с потоком T.38. Слово image не превращало сеанс в обычное вложение.

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

SDP оставалась описанием, а не транспортом. RFC 2327, затем RFC 4566 и нынешняя RFC 8866 определяют формат описания мультимедийного сеанса и прямо отделяют его от транспортного протокола. Записанные адрес и порт не перемещают пакеты.

Следующий рубеж — ответ другой стороны. В RFC 3264 одна сторона формирует offer со своим желаемым представлением, другая даёт answer. Полная картина требует обоих сообщений. Ответ может отклонить поток, установив порт в ноль. Поэтому корректный image/t38 в offer доказывает предложение, а не согласие.

Согласие также не завершает цепочку. Оба конца должны выполнять совместимые процедуры T.38. Выбранный TCP или UDP должен пройти сеть. Потери, задержка и перестановка должны оставаться допустимыми. Шлюзы должны верно преобразовать ритм пакетной сети в поведение факсимильного терминала. Установленный сеанс может закончиться оборванной страницей.

Нужен раздельный журнал доказательств. Запись IANA доказывает регистрацию и ссылку на RFC 3362. Инвентаризация может доказать распознавание типа программой. Offer доказывает предложение. Answer — принятие или отказ. Трассировка пакетов — наблюдавшийся транспорт. События шлюза — попытки преобразования. Счётчики страниц и сигналы завершения — техническую доставку. Получение человеком или бизнес-процессом требует следующего подтверждения.

Эти факты нельзя складывать в одно слово «поддерживается». Регистрация не является переписью внедрения. Распознавание не является принятием. Принятие не является транспортом. Транспорт не является полной и читаемой страницей.

Общие процедуры регистрации менялись. Во время выхода RFC 3362 действовала RFC 2048, позже рамку пересмотрели RFC 4288 и RFC 6838. Экспертиза, уникальность и стабильные ссылки уменьшают неоднозначность. Они не включают функцию на оборудовании оператора.

RFC 2119 и RFC 8174 показывают ту же границу для нормативного языка. Ключевые слова определяют требования к соответствующей реализации. Они не удостоверяют действия конкретного устройства. Между требованием и фактом нужен тест или наблюдение.

Современная запись IANA полезна: она сохраняет image/t38 и ссылку спустя десятилетия. Это подтверждение непрерывности реестра, а не числа работающих шлюзов, выбранного транспорта, доли шифрования или успешных страниц.

Два текста Lu Heng используются как открыто указанные аналитические рамки. «Minimum Initial Specification» предлагает оставлять в общей части только необходимое и локально проверяемое, а принятие отдавать участникам с работающим кодом. Узкая связка RFC 3362 показывает достоинство этого подхода. «On Reality Layers» не позволяет смешивать символическую запись с эксплуатационной реальностью. Регистрация, предложение, принятие, транспорт и получение — разные слои.

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

Источники