[2] 透過内容折衝に対応した資源を透過的折衝可能資源といいます。
[3] RFC 2295 はしばしば折衝可能資源という (未定義の) 用語を使っていますが、これも同義と思われます。
[26] 透過的折衝可能資源は、単一の URL で識別され、 複数の表現 (異体) が関連付けられている資源です >>25。
[27] 透過的折衝可能資源の URL にアクセスすると、 透過内容折衝によって最善の異体を選択できます。 >>25
[28] 透過的折衝可能資源には常に異体リストが束縛されています。
この異体リストは Alternates:
ヘッダーで示されます。 >>25
[14] 透過的折衝可能資源では、 2xx
と 3xx
(304
以外)
の応答には TCN:
ヘッダーと
list
、choice
、adhoc
のいずれかを含めなければなりません >>4, >>22。
リスト応答、選択応答、臨時応答以外を返してはなりません >>11。
[15] 透過的折衝可能資源の他の応答には、 >>14 の3つの値以外の
TCN:
ヘッダーを含めて構いません >>4, >>22。
[12] 起源鯖は、 GET
要求に対してリスト応答を送信できなければなりません >>11。
HEAD
要求に対してもリスト応答を送信できるべきです >>11。
[13] 起源鯖は、要求に Negotiate: vlist
や
Negotiate: trans
が含まれており、
鯖が最善の異体を選択することを認める指令が含まれていなければ、
リスト応答を送信しなければなりません。
ただしバグ互換性のために鯖側上書きする場合を除きます。 >>11
[16] 起源鯖は、要求に Negotiate: vlist
や
Negotiate: guess-small
が含まれている場合には、
Alternates:
ヘッダーを送信しなければなりません。
ただしバグ互換性のために鯖側上書きする場合を除きます。 >>11
[17] 起源鯖は、 Negotiate:
ヘッダーで認められていれば、
遠隔異体選択アルゴリズムを実行して構いません。
最善の異体を決定するのに十分な情報があれば、
最善の異体の選択応答を返して構いません。 >>11
[18] 起源鯖は、透過内容折衝に対応していない利用者エージェントからの要求に対して独自の方法でリスト応答、 選択応答、暫定応答のいずれかを選んで構いません。 >>11
[29] キャッシュは、透過内容折衝に特別に対応しなくとも、 通常の HTTP のキャッシュの規定に従い処理できます。
[24] 透過内容折衝に対応するキャッシュは、通常の HTTP のキャッシュの仕組みに加えて次の最適化を行えます >>21, >>23。
[6] 利用者エージェントは、透過内容折衝の結果得られた異体であって埋め込まれたオブジェクトでないものを表示する時は、次のようにします。 埋め込まれたオブジェクトでも同様とすることを推奨しますが、必須ではありません。 >>5
[7] 利用者が折衝可能資源に束縛されたすべての異体の一覧を表示し、
手動で異体を選択できるようにするべきです。
これは折衝可能資源の Alternates:
ヘッダーの情報からメニューを生成する形でも構いませんし、
Negotiate: trans
付きの GET
要求を送信してリスト応答を取得し、その payload body
を表示する形でも構いません。 >>5
[8] 利用者インターフェイス上に通常の資源ではなく内容折衝された資源であることを提示すると共に、
Alternates:
ヘッダーの異体リストを利用者が調べられるようにするべきです。 >>5
[9] 利用者には異体の URL ではなく、折衝可能資源の URL を示すべきです。しかし表示中の異体の URL を調べる方法も用意するべきです。 >>5
[10] 利用者が後から参照できるように利用者エージェントが URL を保存する場合には、異体の URL ではなく、折衝可能資源の URL を保存するべきです >>5。
GET
とHEAD
にのみ適用されます >>11。