Кратко

  • Content-Duration: 33 позволял почтовому клиенту показать заявленные отправителем 33 секунды, не открывая медиаматериал. Длительность было легко узнать, но это не было независимым измерением.
  • RFC 2424 указывал, что точное время можно узнать, только открыв и воспроизведя содержимое. Обработка поля при получении остаётся локальным решением, а сам заголовок не подтверждает точный размер данных.

Сообщение ещё не воспроизводили, а число уже было указано: Content-Duration: 33. На небольшом экране клиент мог показать, сколько, по-видимому, длится голосовой фрагмент, до открытия вложения. Для такой подсказки не требовалось декодировать аудио. Удобство было реальным; столь же реальным оставался разрыв между числом в заголовке и наблюдением за самим медиаматериалом.

Именно эту узкую проблему решал RFC 2424, опубликованный на пути стандартизации в сентябре 1998 года. Он определил MIME-заголовок для контента, меняющегося во времени, — обычно аудио или видео. Синтаксис намеренно прост: за Content-Duration: следуют от одной до десяти десятичных цифр. Значение задаётся в секундах, без обозначения единицы измерения. В примере RFC число 33 означает 33 секунды.

Зачем выносить эти сведения в отдельный заголовок? Одни форматы уже содержат длительность, для других её можно точно вычислить по длине данных в байтах. В обоих случаях нужно работать с содержимым или разбираться в его кодировании. MIME-заголовок предлагает менее затратный путь: найти время при обработке внешней структуры сообщения, не открывая медиаматериал. В ограниченной системе голосовой почты даже простой MIME-клиент — или настольная программа без MIME — мог показать длительность до открытия аудио.

Простота поля также делает видимым, кто определяет его значение. RFC 2424 говорит о длительности, задаваемой отправителем. Она должна быть точной, но тут же оговаривает предел: точное время невозможно узнать, не открыв и не воспроизведя содержимое. Если важна точность, следует использовать именно этот способ. Следовательно, поле не является службой измерения. Это заявление отправителя, которое удобно передать и быстро прочитать; для проверки всё равно нужно исследовать медиаматериал.

Единый пользовательский интерфейс стандарт не предписывает. В нём перечислены возможные места отображения длительности — например, заголовки во входящих или открытое аудиовложение, — но фактическое использование при получении оставлено локальной реализации. Стандартизированы поле и его смысл, но не обязательность показа в каждом клиенте и не способ выделения на экране. Заголовок также не доказывает, что конкретная программа правильно декодировала медиаматериал. Стандартизированная подсказка может распространяться шире отдельного решения интерфейса, не унифицируя его.

Voice Profile for Internet Mail даёт полю конкретный контекст. Для audio/32KADPCM такой показатель мог помочь простому рабочему столу показать длительность голосового сообщения до открытия аудио. Но он не устанавливает, кто говорил, когда записали фрагмент, открывал ли пользователь сообщение и дослушал ли его до конца. Это другие факты; если они нужны, их приходится передавать или наблюдать отдельно.

Позднейшие документы показывают и преемственность, и расширение контекста. Опубликованный в 2004 году RFC 3803 заменил RFC 2424 и указал, что изменились только редакционные формулировки и стандартные блоки текста. Синтаксис и различие между значением отправителя и точностью, устанавливаемой воспроизведением, сохранились. В 2005 году RFC 4021 внёс Content-Duration в реестр MIME-заголовков на пути стандартизации как поле, указывающее длительность содержимого части сообщения в секундах. Запись в реестре облегчила поиск поля, но не превратила заявление в проверенное измерение.

Информационный документ о поведении клиентов, RFC 4024, подробнее разобрал задачу отображения. Размер текста можно указывать в килобайтах, длительность речи — в секундах, объём факса — в страницах. Для голосового сообщения документ отдаёт предпочтение Content-Duration основной аудиочасти, но допускает суммирование длительностей нескольких частей. Для смешанного сообщения отображаемый «размер» предлагается соотносить с основным типом контента. Это рекомендации для интерфейса, а не гарантия измерения или воспроизведения аудио.

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

Исторический вывод здесь сдержанный, но устойчивый: стандарт может сделать заявление дешёвым в передаче и удобным для показа, не упрощая в той же мере проверку описываемого свойства. RFC 2424 обозначает обе стороны: отправитель задаёт длительность для быстрого доступа, но точность требует открыть и воспроизвести содержимое. Клиент может показать первое до того, как произойдёт второе. Ни поле, ни экран не доказывают, что время совпало с воспроизведением, сообщение дошло целиком или кто-то его услышал. В заголовке значится 33 секунды; пока содержимое не проверено, доказательства этим и ограничиваются.