293.txt

[45] [DFN[[CODE(HTTP)@en[[[Alternates:]]]]]] [[ヘッダー]]は、
当該[[対象資源]]について利用できる[[異体]]の一覧を含めるものです。
[[HTTP]] [[内容折衝]]の仕組みの一部として規定されていますが、
あまり使われていない[[内容折衝]]の中でも特にほとんど使われていません。

* 仕様書

[REFS[
- [25] '''[CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-8.3>'''
- [8] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-8.5>
- [48] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-9.1>
- [49] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-9.2>
- [51] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-10.1>
- [53] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-10.2>
- [55] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-10.3>
- [57] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-10.4>
- [62] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-12>
- [63] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-13>
- [21] [CITE@en[RFC 7168 - The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)]] ([TIME[2014-10-12 17:41:43 +09:00]] 版) <http://tools.ietf.org/html/rfc7168#section-2.1.1>
]REFS]

* 意味

[28] [CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]は、
[[折衝可能資源]]の[[異体]]の一覧や[[内容折衝]]に関する[[指令]]を示すものです [SRC[>>25]]。

[64] [CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]で伝達できる[[異体説明]]の一覧のことを[[異体リスト]]といいます。

* 構文

[31] [CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]の値は1つ[[以上]]の[[変種説明]]
(またはフォールバック指定) や[[指令]]の[[リスト]] ([CODE(HTTP)[#]])
です [SRC[>>25]]。

[FIG(railroad)[
= |
== [[変種説明]]
== [CODE(ABNF)@en[[[fallback-variant]]]]
== [[指令]]
= *
== [[OWS]]
== [CODE(HTTP)@en[[[,]]]]
== [[OWS]]
== |
=== [[変種説明]]
=== [CODE(ABNF)@en[[[fallback-variant]]]]
=== [[指令]]
]FIG]

;; [39] フォールバックを複数指定することは禁止されていないようですが、
意味は無さそうです。

[40] 必要があれば同じ[[変種]]を (違う説明で) 複数指定しても構いません [SRC[>>25]]。

[32] [[引数]] ([[指令]]) は名前のみ、または名前と [CODE(HTTP)[[[=]]]] と値を指定するものです。
名前は[[字句]]、値は[[字句]]または[[引用文字列]]です。 [SRC[>>25]]

[FIG(railroad)[
= [[字句]]
= ?
== [CODE(HTTP)[[[=]]]]
== |
=== [[字句]]
=== [[引用文字列]]
]FIG]

;; [37] 名前の解釈は明記されていませんが、唯一の[[引数]]では構文より[[大文字・小文字不区別]]となっています。

;; [38] 同名の[[引数]]の可否や処理は明記されていません。

* 文脈

[52] [[リスト応答]]には [CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]を含まなければ[['''なりません''']] [SRC[>>51]]。

[54] [[選択応答]]には [CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]を含めるのが良いとされています [SRC[>>53]]。

[56] [[臨時応答]]には [CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]を含めることができます
[SRC[>>55]]。

[61] [[要求]]に [CODE(HTTP)@en[[[Negotiate:]] [[vlist]]]] や
[CODE(HTTP)@en[[[Negotiate:]] [[guess-small]]]] が指定された場合には、
原則として[[応答]]に [CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]を含めなければ[['''なりません''']]
[SRC[>>62]]。

[29] [[透過的折衝可能資源]]からの[[応答]]に [CODE(HTTP)@en[[[Alternates:]]]]
[[ヘッダー]]を含める場合には、[[折衝可能資源]]に束縛された[[変種リスト]]の完全なものを含めなければ[['''なりません''']] [SRC[>>25]]。

[30] [[透過内容折衝]]に対応しない[[資源]]からの[[応答]]にも [CODE(HTTP)@en[[[Alternates:]]]]
[[ヘッダー]]を含めることができます [SRC[>>25]]。

[46] [CODE(HTTP)@en[[[TCN:]] [[re-choose]]]] を含めた[[応答]]には
[CODE(HTTP)@en[[[Alternates:]]]] も含めなければ[['''なりません''']] [SRC[>>8]]。

[26] [CODE(URI)[[[/]]]] への [CODE(MIME)@en[[[message/coffeepot]]]] [[要求]]に対する[[応答]]は
[CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]を含む[['''べきです''']] [SRC[>>21]]。

;; [CODE(MIME)@en[[[message/coffeepot]]]] も参照。

[27] [CODE(URI)[[[/]]]] への [CODE(MIME)@en[[[message/teapot]]]] [[要求]]に対する[[応答]]は
[CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]を含まなければ[['''なりません''']] [SRC[>>21]]。
茶はまだ沸かしません。

[43] この[[ヘッダー]]は複数指定できます。

* 基底 URL

[33] この[[ヘッダー]]の[[変種説明]] (やフォールバック) の [[URL]]
は、[[要求URL]]に対するものです [SRC[>>25]]。

* 指令

[41] 次の[[指令]]が規定されています。
[FIG(short list)[
- [CODE(HTTP)@en[[[proxy-rvsa]]]]
]FIG]

[42] 理解できない[[指令]]は無視する[['''べきです''']] [SRC[>>25]]。

[44] [[IANA登録簿]]は用意されていないようです。

* 処理モデル

[34] [[利用者エージェント]]はどの[[変種説明]]も受け入れられない時は、
フォールバックの指定があればそれを選択する[['''べきです''']] [SRC[>>25]]。

[35] [[利用者エージェント]]は同位の[[変種]]が複数ある時は、
最初のものを選択する[['''べきです''']] [SRC[>>25]]。

;; [36] フォールバックが複数ある場合も最初のものを選択するのでしょうか。

[24] [[HTCPCP-TEA]] [[クライアント]]は [CODE(HTTP)@en[[[BREW]]]] [[要求]]に対する[[応答]]の
[CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]の内容を検査して、
適切な [[URL]] を選んで次の[[要求]]を送信しなければ[['''なりません''']] [SRC[>>21]]。

[47] [[キャッシュ]]は、複数の[[応答]]が同じ[[異体リスト検証子]]を持つなら、
両者の [CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]は[[等価]]として扱うことができます。
(ただし両者が同一である必要はありません。) [SRC[>>48]]

[58] [[キャッシュ]]は、[[折衝可能資源]]が[[キャッシュ可能]]で[[新鮮]]で
[CODE(HTTP)@en[[[ETag:]]]] と [CODE(HTTP)@en[[[Alternates:]]]]
を持っていれば、 [CODE(HTTP)@en[[[Alternates:]]]] と[[異体リスト検証子]]を取り出して、
[[利用者エージェント]]に代わって折衝したり、
[[選択応答]]を構築したりするために再利用して構いません。 [SRC[>>57, >>63]]

;; [60] その場合 [CODE(HTTP)@en[[[Vary:]]]] も再利用できます。
[CODE(HTTP)@en[[[Vary:]]]] 参照。

[59] [CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]の[[齢]]は、
それが含まれていた[[応答]]の[[齢]]です [SRC[>>57]]。

* 歴史

** RFC 2068

[FIG(quote)[
[FIGCAPTION[
[12] RFC 2068 (HTTP/1.1) 19.6.2.1 Alternates
]FIGCAPTION]

> The Alternates response-header field has been proposed as a means for
the origin server to inform the client about other available
representations of the requested resource, along with their
distinguishing attributes, and thus providing a more reliable means
for a user agent to perform subsequent selection of another
representation which better fits the desires of its user (described
as agent-driven negotiation in section 12).

[CODE(HTTP)[Alternates]] 応答頭欄は、
[[要求]]された[[資源]]に他の利用可能な[[表現]]があることを、
その分別属性と共に[[起源サーバー]]が[[クライアント]]に知らせる手段として提案されています。
これによって、利用者エージェントが利用者の希望により合致する他の表現の選択を行うにあたってのより信頼できる手段を提供することとなります
(12章で[[エージェント駆動折衝]]として説明されています)。

> The Alternates header field is orthogonal to the Vary header field in
that both may coexist in a message without affecting the
interpretation of the response or the available representations. It
is expected that Alternates will provide a significant improvement
over the server-driven negotiation provided by the Vary field for
those resources that vary over common dimensions like type and language.

[CODE(HTTP)[Alternates]] 頭欄は [CODE(HTTP)[[[Vary]]]] 頭欄と直交するので、
応答の解釈や利用可能な表現に影響なくメッセージに共存できます。
[CODE(HTTP)[Alternates]] によって、型や言語のように共通な次元で変化する資源の
[CODE(HTTP)[Vary]] 欄による[[サーバー駆動折衝]]が極めて向上することが期待されます。

> The Alternates header field will be defined in a future specification.

[CODE(HTTP)[[[Alternates]]]] 頭欄は将来の仕様書で定義されます。
]FIG]

[2] RFC 2068 よ、そこまで期待させておいて [WEAK[(ほんとはしてないけど☆)]] 最後にそういう落ちかよって突っ込みたくなるような(w

[3] [CODE(HTTP)[Alternates]] 欄は今はなき
[CODE(HTTP)[[[URI:]]]] 欄の代替の一翼を担うと期待されていました。
(RFC 2068 19.6.2.5 参照。)

** RFC 2295

- [1] ''The Alternates Header Field'' <http://www.watersprings.org/pub/id/draft-ietf-http-alternates-01.txt>

[FIG(quote)[
[FIGCAPTION[
[13] RFC 2295 (HTTP 透過内容折衝) 8.3 Alternates
]FIGCAPTION]

> The Alternates response header is used to convey the list of variants
bound to a negotiable resource.  This list can also include
directives for any content negotiation process.  If a response from a
transparently negotiable resource includes an Alternates header, this
header MUST contain the complete variant list bound to the negotiable
resource.  Responses from resources which do not support transparent
content negotiation MAY also use Alternates headers.

[CODE(HTTP)[Alternates]] 応答頭は、[[折衝可能資源]]に束縛された[[変種]]の目録を伝達するのに使います。
この目録は任意の内容折衝手続きの[[指令]]を含めることもできます。
[[透過折衝可能資源]]からの応答が [CODE(HTTP)[Alternates]] 頭を含んでいる場合は、
この頭は折衝可能資源に束縛された完全な[[変種目録]]を含まなければ'''なりません'''。
透過内容折衝に対応していない資源からの応答も [CODE(HTTP)[Alternates]]
頭を使って'''構いません'''。

>
[PRE[
       Alternates = "Alternates" ":" variant-list

       variant-list = 1#( [[variant-description]]
                        | fallback-variant
                        | list-directive )

       fallback-variant = "{" <"> [[URI]] <"> "}"

       list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> )
                        | extension-list-directive

       extension-list-directive =
                        token [ "=" ( [[token]] | [[quoted-string]] ) ]
]PRE]

> An example is
[PRE[
     Alternates: {"paper.1" 0.9 {type text/html} {language en}},
                 {"paper.2" 0.7 {type text/html} {language fr}},
                 {"paper.3" 1.0 {type application/postscript}
                     {language en}},
                 proxy-rvsa="1.0, 2.5"
]PRE]

> Any relative URI specified in a variant-description or fallback-variant field is relative to the request-URI.  Only one fallback-variant field may be present.  If the variant selection algorithm of
the user agent finds that all described variants are unacceptable,
then it SHOULD choose the fallback variant, if present, as the best
variant.  If the user agent computes the overall quality values of
the described variants, and finds that several variants share the
highest value, then the first variant with this value in the list
SHOULD be chosen as the best variant.

[CODE(ABNF)[variant-description]] 欄や [CODE(ABNF)[fallback-variant]]
欄に指定されている[[相対URI]] は [CODE(ABNF)[[[Request-URI]]]]
について相対です。 [CODE(ABNF)[fallback-variant]]
欄は1つだけ指定できます。[[利用者エージェント]]の[[変種選択算法]]がすべての記述された変種が受け入れ不能であるとわかったときには、
fallback 変種があればこれを最善の変種として選ぶ'''べきです'''。
利用者エージェントが記述された変種の[[全体品質値]]を計算し、
複数の変種が同位最高値を取るとわかったときには、
そのうちの目録中で最初の変種を最善の変種として選ぶ'''べきです'''。

> The proxy-rvsa directive restricts the use of remote variant
selection algorithms by proxies. If present, a proxy MUST ONLY use
algorithms which have one of the version numbers listed, or have the
same major version number and a higher minor version number as one of
the versions listed.  Any restrictions set by proxy-rvsa come on top
of the restrictions set by the user agent in the Negotiate request
header.  The directive proxy-rvsa="" will disable variant selection
by proxies entirely.  Clients SHOULD ignore all extension-list-directives they do not understand.

[CODE(HTTP)[[[proxy-rvsa]]]] 指令は、[[串]]による[[遠隔変種選択算法]]の使用を制限します。
この指令があるときは、串は列挙された版番号か、大版番号が同じで小版番号が列挙されたものよりも大きい版の算法'''だけ'''を使わなければ'''なりません'''。
[CODE(HTTP)[proxy-avsa]] 指令によって設定された制限は、
[CODE(HTTP)[[[Negotiate]]]] 要求頭で利用者エージェントによって設定された制限の上にきます。
指令 [CODE(HTTP)[proxy-avsa=""]] は、串による変種選択を完全に無効化します。
クライアントは、その理解しないすべての [CODE(ABNF)[extension-list-directive]]
を無視する'''べきです'''。

>  A variant list may contain multiple differing descriptions of the
same variant.  This can be convenient if the variant uses conditional
rendering constructs, or if the variant resource returns multiple
representations using a multipart media type.

変種目録は同じ変種についての複数の異なる記述を含んでいても構いません。
これはその変種が条件付レンダリング構造を使っているか、
その変種資源が[[複数部分]][[媒体型]]を使って複数の[[表現]]を返す時に便利でしょう。
]FIG]

[FIG(quote)[
[FIGCAPTION[
[14] RFC 2295 (HTTP 透過内容折衝) 10.4 Reusing the Alternates header
]FIGCAPTION]

[6]
> If a proxy cache has available a negotiated response which is
cacheable, fresh, and has ETag and Alternates headers, then it MAY
extract the Alternates header and associated variant list validator
from the response, and reuse them (without unnecessary delay) to
negotiate on behalf of the user agent (section 13) or to construct a
choice response (section 10.2).  The age of the extracted Alternates
header is the age of the response from which it is extracted,
calculated according to the rules in the HTTP/1.1 specification [1].

[[串キャッシュ]]が[[キャッシュ可能]]で[[新鮮]]で [CODE(HTTP)[[[ETag]]]]
頭と [CODE(HTTP)[[[Alternates]]]] 頭を持った折衝応答を利用可能なときは、
[[応答]]から [CODE(HTTP)[Alternates]] 頭と関連付けられた[[変種目録検証子]]を取り出して
(不要な遅延なく) [[利用者エージェント]]の代わりに折衝したり[[選択応答]]を構築したりするのに再利用しても'''構いません'''。
取り出した [CODE(HTTP)[Alternates]] 頭の[[齢]]は HTTP/1.1
仕様書の規則に従って算出した、それを取り出した応答の齢です。
]FIG]

** RFC 2616

[4] [[RFC 2616]] はあまり使われていない [SRC[>>14]] として削除しています。
[[RFC 2295]] にはなぜか言及していません。

;; [17] [[RFC 2295]] を[[廃止]]しようとするものでも無さそうです。

[REFS[
- [16] [CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2014-09-07 04:14:53 +09:00]] 版) <http://tools.ietf.org/html/rfc2616#page-175>
]REFS]

** RFC 4429

[19] [[IANA登録簿]]へは [[RFC 4429]] が [[RFC 2295]] を出典として登録しています [SRC[>>15, >>18]]。

[REFS[
- [15] [CITE@en[RFC 4229 - HTTP Header Field Registrations]] ([TIME[2014-11-02 09:53:20 +09:00]] 版) <http://tools.ietf.org/html/rfc4229#section-2.1.11>
- [18] [CITE[Message Headers]] ([TIME[2014-10-31 18:26:49 +09:00]] 版) <http://www.iana.org/assignments/message-headers/message-headers.xhtml>
]REFS]

[20] 状態は「[[実験的]]」とされています [SRC[>>15]]。ただし一覧表では空欄になっています [SRC[>>18]]。

** RFC 723x

[10] [[RFC 2616]] の改訂である [[RFC 7231]] も、失敗した提案として
[CODE(HTTP)@en[[[Alternates:]]]] に言及しています (が [[RFC 2295]] は今回も無視しています)。

;; [11] 代案として [CODE(HTTP)@en[[[Link:]] ... [[rel]]=[[alternate]]]]
に言及していますが、あまり本気でもなさそうです。

[REFS[
- [9] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-6.4.1>
]REFS]

* 実装

[7] [[Virata-EmWeb]] というサーバーが送出するようです。

* 関連

[50] [[構造化実体タグ]]に含まれる[[異体リスト検証子]]は、
[CODE(HTTP)@en[[[Alternates:]]]] [[ヘッダー]]についての[[検証子]]となります。

;; [[構造化実体タグ]]および[[異体リスト検証子]]を参照。

* 例

[EG[
[22] [[HTCPCP-TEA]] [[鯖]]の[[応答]]の例 [SRC[>>21]]
[PRE(HTTP code)[
Alternates: {"/darjeeling" {type message/teapot}},
            {"/earl-grey" {type message/teapot}},
            {"/peppermint" {type message/teapot}}
]PRE]
]EG]

[EG[
[23] [[HTCPCP]] と [[HTCPCP-TEA]] 兼用の[[鯖]]の例 [SRC[>>21]]
[PRE(HTTP code)[
Alternates: {"/" {type message/coffeepot}},
            {"/pot-0/darjeeling" {type message/teapot}},
            {"/pot-0/earl-grey" {type message/teapot}},
            {"/pot-1/peppermint" {type message/teapot}}
]PRE]
]EG]

* メモ

[5] この欄も、なんちゅーか、時代の流れに翻弄され続けたというか何と言うか、結局使われてない。。。