#?SuikaWiki/0.9
[[#comment]]
* 仕様書から
** 定義
[1]
> [INS[[[RFC2295]] 2.2 抜粋]]
:variant list:
A list containing variant descriptions, which can be bound to a
transparently negotiable resource.

:変種一覧:
[[透過折衝可能資源]]と束縛することができる、
[[変種記述]]を含む一覧。
** RFC 2295 (HTTP 透過内容折衝) 4.9 Length of variant lists
[2]
> As a general rule, variant lists should be short: it is expected that
a typical transparently negotiable resource will have 2 to 10
variants, depending on its purpose.  Variant lists should be short
for a number of reasons:

一般的な規則として、変種目録は短くあるべきです。
典型的な[[透過折衝可能資源]]は、その目的により、
2〜10個の変種を持つことが想定されています。
変種目録はいくつかの理由により短くあるべきです。

>
- 1. The user must be able to pick a variant by hand to correct a
bad automatic choice, and this is more difficult with a long variant list.
- 2. A large number of variants will decrease the efficiency of
internet proxy caches.
- 3. Long variant lists will make some transparently negotiated responses longer.

- 利用者は悪い自動選択を正すために変種を手動で選ぶことができなければなりませんが、
これは長い変種目録だとより難しくなります。
- 変種が沢山あるとインターネット串キャッシュの効率が低減します。
- 長い変種目録のせいで透過折衝応答が長くなってしまいます。

> In general, it is not desirable to create a transparently negotiable
resource with hundreds of variants in order to fine-tune the
graphical presentation of a resource.  Any graphical fine-tuning
should be done, as much as possible, by using constructs which act at
the user agent side, for example

通常、資源の図形的表現をよく調整するために数百に及ぶ変種のある透過折衝可能資源を作成するのは望ましからぬことです。
図形的表現をよく調整するのはできる限り利用者エージェント側で動作する構造を使って、
例えば

>
[PRE[
      <center><img src=titlebanner.gif width=100%
      alt="MegaBozo Corp"></center>
]PRE]

のようにするべきです。

> In order to promote user agent side fine tuning, which is more
scalable than fine tuning over the network, user agents which
implement a scripting language for content rendering are encouraged
to make the availability of this language visible for transparent
content negotiation, and to allow rendering scripts to access the
capabilities and preferences data used for content negotiation, as
far as privacy considerations permit this.

ネットワーク上での調整よりも細かに設定できる利用者エージェント側での調整を推進するために、
内容のレンダリングのための[[スクリプト言語]]を実装している利用者エージェントは、
この言語の利用可能性を透過内容折衝から可視とし、
レンダリング・スクリプトがプライバシーを考慮して許せる範囲内において内容折衝に使う能力・希望データに接触可能とすることを推奨します。

** RFC の部分の License
[[RFCのライセンス]]
* メモ