要約

  • Content-Duration: 33があれば、メールクライアントはメディアを開かずに、送信者が示した33秒という再生時間を表示できる。時間を簡単に知る仕組みであって、独立した測定ではない。
  • RFC 2424は、正確な再生時間を知るには内容を開いて再生する必要があると述べた。受信側での扱いは実装に委ねられ、正確なデータサイズの推定にも使えない。

メッセージはまだ再生されていない。それでも数字はすでに届いている。Content-Duration: 33。小さな画面でも、添付音声を開く前に再生時間の目安を表示できる。便利さは確かにある。しかし、ヘッダーの値とメディアを実際に確かめた結果との間には、埋められていない差が残る。

この簡潔な問題を扱ったのが、1998年9月に標準化の段階へ進んだ RFC 2424 だ。時間とともに変化するコンテンツ、主に音声や動画を対象とするMIMEヘッダーフィールドを定義した。書式は短い。Content-Duration: の後に1〜10桁の数字を置く。単位表示はなく、値は秒を表す。RFCの例では33が33秒に当たる。

なぜメディアとは別のヘッダーに時間を置くのか。形式によっては再生時間が内部に記録されているし、データのバイト数から正確に計算できる場合もある。どちらの方法でも、まず内容を扱うか、その符号化を理解しなければならない。MIMEヘッダーなら、メッセージの外側の構造を処理するだけで時間を取り出せる。音声メールのような制約された環境では、音声を開く前に、簡易なMIMEクライアントや非MIMEのデスクトップでも長さを示せる可能性があった。

その簡潔さは、誰が値を決めるのかも見えやすくする。RFC 2424が示すのは送信者によって決められた時間だ。値は正確であるべきだとしながら、直後にその限界も置く。内容を開いて再生しなければ、正確な時間は分からない。正確さが必要なら、その方法を使うべきだという。つまり、これは測定機能ではない。アクセスしやすくするため送信者が付けた宣言であり、検証に必要な観察は別にある。

この規格は表示方法を一つに決めなかった。受信箱の一覧に載せる、音声を開いた後に示す、といった使い方を挙げつつ、受信側が実際にどう使うかはローカルな実装に任せるとした。フィールドの意味は標準化されたが、すべてのクライアントが表示するとも、目立たせ方が同じとも限らない。まして、特定のクライアントがメディアを正しくデコードした証拠にはならない。標準のヒントは個別の画面設計より広く伝わっても、画面上の動作までそろえるわけではない。

Voice Profile for Internet Mailでは、このフィールドの用途が具体化する。audio/32KADPCMの音声データに添えれば、簡素なデスクトップでも中身を開く前に長さを見せられる。ただし、それで話者、録音時刻、ユーザーが開いたかどうか、最後まで聴いたかどうかが分かるわけではない。これらは別の事実であり、他の方法で記録または観察されない限り、このフィールドからは分からない。

後続の標準化記録には、意味の継続と適用範囲の広がりが見える。RFC 3803 は2004年にRFC 2424を置き換え、変更は編集上の修正と定型文に限ると述べた。構文も、送信者の値と再生後に確かめる正確さの区別も残った。2005年の RFC 4021 は Content-Duration を標準化過程にあるMIMEヘッダーフィールドとして登録し、ボディーパートの再生時間を秒で示すものとした。登録簿で見つけやすくなったからといって、宣言が検証済みの値に変わったわけではない。

情報提供文書の RFC 4024 は、画面設計上の問題をさらに明確にした。テキストはキロバイト、音声は秒、ファクスはページ数で大きさを示せる。同文書は音声メッセージでは主要な音声パートの Content-Duration を表示に使う方法を優先し、複数の音声パートを合算することも認めている。混在メディアでは、主要なコンテンツ種別に合わせて表示する。これらはクライアント表示についての推奨であり、値の実測や再生を保証するものではない。

RFC 2424は、メディアの属性をその外側に出すことで、情報の露出も変わると注意している。一部の環境では、ヘッダーで時間を明示すること自体がセキュリティ上の懸念になり得る。また、この値をデータの正確なサイズの根拠として信頼してはならない。正確な長さはデータそのものを調べて決める。秒とバイトは別の問いへの答えだ。送信者の再生時間をバイト検査の代わりにはできないし、バイト数だけで特定のデコーダーが何秒再生するかも証明できない。

ここにある歴史的な教訓は控えめだが、今も有効だ。標準は、ある主張を安く運び、簡単に表示できるようにできる。しかし、その主張が指す性質を安く検証できるとは限らない。RFC 2424は、便利な送信者申告と、内容を開いて再生して初めて分かる正確さの両方を記した。クライアントは後者が起きる前に前者を示せる。どちらも、表示時間が実際の再生と一致したこと、メッセージが欠損なく届いたこと、誰かが聴いたことまでは証明しない。ヘッダーは33秒と言う。内容を確かめるまでは、証拠はそこまでだ。