[8] 異体説明は、 URL、原始品質、0個以上の異体属性を連ねて
{ と } で括ったものです。ただし URL
は " で括ったものです。 >>1
[9] 仕様書の時代的に構文上明記されていませんが、 URL およびそれを括る "
や原始品質や異体属性の前後に空白を挿入することが認められていると思われます。
[3] 異体説明の URL は、異体を GET 要求によって取得できる
URL を表します >>2。
[10] 絶対URLでも、要求URLに対する相対URLでも構いません >>2。
[11] 指定された異体資源は要求に依存して変化するものであっても構いませんが、 それ自体が透過内容折衝によって変化するものであってはなりません >>2。
[12] 仕様上は RFC 2068 を通じて RFC 1738 と RFC 1808 が参照されています。 非ASCII文字は認められていません。
[4] Alternates: ヘッダーでは変種説明の他に
「フォールバック」を指定できます。フォールバックは属性や品質値がなく、
URL だけが指定されたものです。
- variant description
- A machine-readable description of a variant resource, usually found in a variant list. A variant description contains the variant resource URI and various attributes which describe properties of the variant. Variant descriptions are defined in section 5.
変種資源の機械可読な記述で、通常変種一覧に見える。 変種記述は変種資源 URI とその変種の特性を記述する種々の属性からなる。
[16] RFC 2295 (HTTP 透過内容折衝) 5 Variant descriptions
A variant can be described in a machine-readable way with a variant description.
変種は、変種記述によって機械可読な方法で記述できます。
variant-description =
"{" <"> URI <"> source-quality *variant-attribute"}"
source-quality = qvalue
variant-attribute = "{" "type" media-type "}"
| "{" "charset" charset "}"
| "{" "language" 1#language-tag "}"
| "{" "length" 1*DIGIT "}"
| "{" "features" feature-list "}"
| "{" "description"
quoted-string [ language-tag ] "}"
| extension-attribute
extension-attribute = "{" extension-name extension-value "}"
extension-name = token
extension-value = *( token | quoted-string | LWS
| extension-specials )
extension-specials =
<any element of tspecials except <"> and "}">The feature-list syntax is defined in section 6.4.
feature-list 構文は6.4節で定義します。
Examples are
The various attributes which can be present in a variant description are covered in the subsections below. Each attribute may appear only once in a variant description.
→.//URI (>>1) 参照
The type attribute of a variant description carries the same information as its Content-Type response header counterpart defined in [1], except for any charset information, which MUST be carried in the charset attribute. For, example, the header
- Content-Type: text/html; charset=ISO-8859-4
has the counterpart attributes
- {type text/html} {charset ISO-8859-4}
The language and length attributes carry the same information as their Content-* response header counterparts in [1]. The length attribute, if present, MUST thus reflect the length of the variant alone, and not the total size of the variant and any objects inlined or embedded by the variant.
Though all of these attributes are optional, it is often desirable to include as many attributes as possible, as this will increase the quality of the negotiation process.
Note: A server is not required to maintain a one-to-one correspondence between the attributes in the variant description and the Content-* headers in the variant response. For example, if the variant description contains a language attribute, the response does not necessarily have to contain a Content-Language header. If a Content-Language header is present, it does not have to contain an exact copy of the information in the language attribute.
→.//feature (>>1) 参照
The extension-attribute allows future specifications to incrementally define dimensions of negotiation which cannot be created by using the feature negotiation framework, and eases content negotiation experiments. In experimental situations, servers MUST ONLY generate extension-attributes whose names start with "x-". User agents SHOULD ignore all extension attributes they do not recognize. Proxies MUST NOT run a remote variant selection algorithm if an unknown extension attribute is present in the variant list.