機能タグ (HTTP)

特徴タグ (HTTP)

[16] 特徴タグ (feature tag) は、 内容折衝で選択基準となる何らかの種別を表すものです。

仕様書

意味

[9] 特徴タグは、折衝できるものを表します。例えば、 表現の特性、利用者エージェントの能力、 表現の種類についての利用者の好みなどです >>4

[18] 特徴タグには、その定義次第で、0個か1個、複数個の特徴タグを関連付けることができます。値の意味は特徴タグに依存します。 >>4

構文

[10] 特徴タグは、字句または引用文字列です >>4

  1. |
    1. 字句
    2. 引用文字列

[14] 特徴タグは、大文字・小文字不区別です >>4

[19] 特徴タグの値は、字句または引用文字列です >>4

  1. |
    1. 字句
    2. 引用文字列

[20] 特徴タグの値は、大文字と小文字を区別します >>4

[21] 特徴タグの値はパーセント符号化されたものとして扱います >>4

[22] UTF-8 と解釈すると思われます。

[15] 特徴タグでも値でも、 字句での表現と引用文字列での表現 (引用符を加えたもの) は等価です >>4

文脈

[13] 特徴タグは、特徴集合特徴述語で使われます。

特徴タグの種類

[11] RFC 2295IETF でプロトコル非依存の機能タグ登録簿を開発中である >>4 として、具体的な特徴タグは定義していません。

[17] RFC 2506 媒体特徴タグがその結果と思われますが、 RFC 2506 は謝辞で開発のきっかけとして RFC 2295 に触れるだけで、 なぜか特徴タグ媒体特徴タグの関係性は明記されていません。 RFC 2533 媒体特徴タグRFC 2295特徴タグが影響を与えたことには触れていますが、特に置き換えたり拡張したりする関係には無いようです。

[7] RFC 2295 は例示で HTML要素画面のサイズを特徴タグとして使えるとして挙げています >>6 (が定義はしていません)。

[8] 新しい特徴タグを定義する際は、現在の習慣に沿ったものが既定の場合となるように注意するべきです。例えば color という特徴タグを定義するとこの特徴タグに未対応の利用者エージェントにはモノクロの画像を提供することになってしまうので、 monochrome を定義するべきです。 >>6

[12] 実験的な特徴タグx. から始めることが推奨 (encouraged) されています >>4

[5] 特徴タグ透過内容折衝の仕様で規定されていますが、 透過内容折衝以外で使うこともでき、また透過内容折衝では使えない特徴タグを定義しても良い >>4 とされています。

歴史

[1] RFC 2295 (HTTP 透過内容折衝) 6.1 Feature tags

A feature tag (ftag) identifies something which can be negotiated on, for example a property (feature) of a representation, a capability (feature) of a user agent, or the preference of a user for a particular type of representation. The use of feature tags need not be limited to transparent content negotiation, and not every feature tag needs to be usable in the HTTP transparent content negotiation framework.

特徴札 (ftag)は、表現特性 (特徴) や利用者エージェントの能力 (特徴) や表現の特定の型についての利用者の好みなどの、 折衝に使用可能な何らかのものを識別します。 特徴札の使用は透過内容折衝に限定する必要はなく、 各特徴札は HTTP 透過内容折衝の枠組みで使用可能である必要はありません。

Note: A protocol-independent system for feature tag registration is currently being developed in the IETF. This specification does not define any feature tags. In experimental situations, the use of tags which start with "x." is encouraged.

注意 : プロトコル独立の特徴札登録システムは現在 IETF で開発中です。この仕様書は特徴札を何も定義しません。 実験的な状況では、 x. で始まる札を使用することを推奨します。

Feature tags are used in feature sets (section 6.2) and in feature predicates (section 6.3). Feature predicates are in turn used in features attributes (section 6.4), which are used in variant descriptions (section 5). Variant descriptions can be transmitted in Alternates headers (section 8.3).

特徴札は特徴集合特徴述語で使用します。 特徴述語は feature 属性で使用し、 feature 属性は変種記述で使用します。 変種記述は Alternates「 頭で転送することができます。

The US-ASCII charset is used for feature tags. Feature tag comparison is case-insensitive. A token tag XYZ is equal to a quoted-string tag "XYZ". Examples are

特徴札には US-ASCII charset を使います。 特徴札の比較は大文字・小文字を区別しません。 字句XYZquoted-string"XYZ" と同等です。例えば、

tables, fonts, blebber, wolx, screenwidth, colordepth

An example of the use of feature tags in a variant description is:

特徴札を変種記述で使った例 :

  • {"index.html" 1.0 {type text/html} {features tables frames}}

This specification follows general computing practice in that it places no restrictions on what may be called a feature. At the protocol level, this specification does not distinguish between different uses of feature tags: a tag will be processed in the same way, no matter whether it identifies a property, capability, or preference. For some tags, it may be fluid whether the tag represents a property, preference, or capability. For example, in content negotiation on web pages, a "textonly" tag would identify a capability of a text-only user agent, but the user of a graphical user agent may use this tag to specify that text-only content is preferred over graphical content.

6.1.1 Feature tag values

The definition of a feature tag may state that a feature tag can have zero, one, or more values associated with it. These values specialize the meaning of the tag. For example, a feature tag `paper' could be associated with the values `A4' and `A5'.

特徴札の定義は、その特徴札が零個か一個かそれ以上の関連付けられた値を持つことができると言明できます。 この値は札の意味を特別化します。例えば、特徴札 paper は値 A4A5 と関連付けることができることでしょう。

The US-ASCII charset is used for feature tag values. Equality comparison for tag values MUST be done with a case-sensitive, octet-by-octet comparison, where any ""%" HEX HEX" encodings MUST be processed as in [1]. A token value XYZ is equal to a quoted-string value "XYZ".

特徴札値には US-ASCII charset を使います。 札値の同等性比較は大文字・小文字を区別した、オクテット毎の比較により行わなければなりません。 このとき、 "%" HEX HEX 符号化は RFC2068 に従って処理しなければなりません。 字句値 XYZquoted-string"XYZ" と同等です。

[2] RFC 2295 (HTTP 透過内容折衝) 20.3 Feature tag design

When designing a new feature tag, it is important to take into account that existing user agents, which do not recognize the new tag will treat the feature as absent. In general, a new feature tag needs to be designed in such a way that absence of the tag is the default case which reflects current practice. If this design principle is ignored, the resulting feature tag will generally be unusable.

新しい特徴札を設計する時、既存の新しい札を認識しない利用者エージェントがその機能の欠けているものとして扱われるように考慮することが重要です。 通常、新しい特徴札は特徴札が欠けているとき現在の慣習を反映している既定の場合となるように設計する必要があります。 この設計原理を無視すると、結果出来る特徴札は通常使用不能なものとなってしまいます。

As an example, one could try to support negotiation between monochrome and color content by introducing a `color' feature tag, the presence of which would indicate the capability to display color graphics. However, if this new tag is used in a variant list, for example

例として、 color 特徴札を導入して白黒内容とカラー内容の間での折衝に対応しようとするとします。 この札が示されているとカラー画像表示能力があると示すことにします。 しかし、この新しい札を変種目録で使うと、例えば、

  • {"rainbow.gif" 1.0 {features color} }
  • {"rainbow.mono.gif" 0.6 {features !color}}

then existing user agents, which would not recognize the color tag, would all display the monochrome rainbow. The color tag is therefore unusable in situations where optimal results for existing user agents are desired. To provide for negotiation in this area, one must introduce a `monochrome' feature tag; its presence indicates that the user agent can only render (or the user prefers to view) monochrome graphics.

のようになりますが、既存の利用者エージェントで color 札を理解しないものは、すべて白黒の虹を表示することとなるでしょう。 従って、既存の利用者エージェントで最適な結果を望む状況では color 札は使用不能です。この領域での折衝を提供するためには、 monochrome 特徴札をどうにゅうしなければなりません。 この札は利用者エージェントが白黒図形だけしかレンダリングすることができない (又は利用者が白黒図形を表示することを好んでいる) ことを示します。

[3] draft-mutz-http-attributes-01 ( 版) http://tools.ietf.org/html/draft-mutz-http-attributes-01

[23] draft-mutz-http-attributes-02 - User-Agent Display Attributes ( ( 版)) http://tools.ietf.org/html/draft-mutz-http-attributes-02

[24] 媒体機能タグ