要約

  • RFC 2447 は iTIP をメールで運ぶ方法を定め、MIME の境界と予定オブジェクトの境界をつないだ。
  • 普通の文章と text/calendar は同じ予定を異なる読み手に示すもので、異なる時刻を並べる選択肢ではない。

一通のメールを開くと、別のプロトコルが現れる

メールの差出人欄と件名は、人には予定の全体像のように見える。カレンダーソフトは、どこに構造化された予定があり、どの処理を指すのかを別に判断しなければならない。RFC 2447（iMIP）は1998年、この継ぎ目を埋めた。iCalendar が予定データを定義し、iTIP がスケジューリング操作を定義し、MIME がそれを電子メール内のパーツとして運ぶ。iMIP はそれらを統合して一つの万能な「招待プロトコル」にしたのではなく、メールを既存のカレンダープロトコルの運搬路にした。

その運搬路では、カレンダー部分を text/calendar として識別する。さらに MIME ヘッダーの method パラメーターは、オブジェクト内の METHOD プロパティと同じ値でなければならない。外側の型情報だけではオブジェクトの意味を置き換えられず、内側の値だけでは MIME パーツの扱いを決められない。両者が対応して、メール処理系はカレンダー部分を見つけ、予定表処理系はそれを解釈できる。複数のオブジェクトが別々のメソッドを持つ場合は、各々を別の text/calendar パーツとし、multipart/mixed にまとめる。

人間向けの文章は、第二の予定表ではない

当時のメールソフトすべてがカレンダー形式を理解できたわけではない。そこで MIME は、同じメッセージに通常の文章と構造化されたカレンダーオブジェクトを含められるようにした。テキスト表示しかできないソフトでも日時や場所を読める一方、対応クライアントは text/calendar を処理できる。multipart/alternative が結び付けるのは、同じ予定の異なる表現である。

この意味を取り違え、二つの開始時刻を別々の VEVENT として「alternative」に入れると、利用者はどちらが招待でどちらが訂正なのか判断できない。MIME の別表現は表示能力の差を埋めるためのものだ。時刻の提案や変更は iTIP の操作で表す。封筒の構造と予定の意思決定は別の層にある。

文字コードと転送エンコーディングは、この構造がメール経路で壊れずに運ばれるための条件だった。US-ASCII の外にある文字を含む場合の charset 宣言や、経路の制限に合わせた転送方式が仕様化された。RFC 6047 は2010年に RFC 2447 を置き換え、メッセージ形式と S/MIME の要件を更新した。正しくデコードできることは表現の保全を示すが、受信箱への配達や予定表への保存を示さない。

添付を参照する Content-ID や Message-ID も注意を要する。識別子だけを予定オブジェクトに記しても、受信側に参照先へのアクセス権があるとは限らない。RFC 2447 は、可能なら参照する MIME パーツも一緒に送ることを勧めた。場所を示す情報は、内容のコピーでも閲覧許可でもない。

メールの Sender が予定の Organizer と同じとも限らない。転送者が封筒の差出人となり、メールソフトはカレンダー上の役割を Reply-To に写す義務を負っていない。そのため RFC 2447 は、text/calendar の ORGANIZER と ATTENDEE を確認するよう求めた。RFC 1847 の MIME セキュリティ多部分は認証の選択肢を与え、RFC 6047 は S/MIME 認証を要求した。ただし、署名は保護された部分についての根拠であり、配達、クライアントの処理、出席への同意を証明しない。

RFC 2447 は1998年11月に Standards Track として公開され、2010年に RFC 6047 によって obsolete となった。この年表はトランスポート接続層が更新されたことを示すが、製品の普及率を示すものではない。歴史的な要点はむしろ分離にある。予定の意味はカレンダーオブジェクトにあり、MIME はその梱包を定め、メールはそれを運ぶ。送信済みという状態を、予定が適用された証拠に変えてはならない。

出典