[1] RFC 2295 (HTTP 透過内容折衝) 4.8 Feature negotiation
Feature negotiation intends to provide for all areas of negotiation not covered by the type, charset, and language dimensions. Examples are negotiation on
特徴折衝は、型、 charset、言語の各次元で覆われないすべての領域の折衝を提供することを目的としています。 例えば、
- * HTML extensions
- * Extensions of other media types
- * Color capabilities of the user agent
- * Screen size
- * Output medium (screen, paper, ...)
- * Preference for speed vs. preference for graphical detail
について折衝します。
The feature negotiation framework (section 6) is the principal means by which transparent negotiation offers extensibility; a new dimension of negotiation (really a sub-dimension of the feature dimension) can be added without the need for a new standards effort by the simple registration of a `feature tag'.
特徴折衝の枠組みは、透過折衝が拡張性を提供する主たる手段です。 新しい折衝の次元 (実際には特徴次元の下位次元) は新しい標準化努力の必要なしに、単に「特徴札」 を登録するだけで追加することができます。
[3] RFC 2295 (HTTP 透過内容折衝) 6 Feature negotiation
This section defines the feature negotiation mechanism. Feature negotiation has been introduced in section 4.8. Appendix 19 contains examples of feature negotiation.
→特徴札 (>>1)参照。
→特徴集合 (>>1)参照。
→特徴述語 (>>1)参照。
→変種記述//features (>>2) 参照。
This appendix contains examples of the use of feature tags in variant descriptions. The tag names used here are examples only, they do not in general reflect the tag naming scheme proposed in [4].
Feature tags can be used in variant lists to express the quality degradation associated with the presence or absence of certain features. One example is
{"index.html.plain" 0.7 }, {"index.html" 1.0 {features tables frames}}
Here, the "{features tables frames}" part expresses that index.html uses the features tagged as tables and frames. If these features are absent, the overall quality of index.html degrades to 0. Another example is
{"home.graphics" 1.0 {features !textonly}}, {"home.textonly" 0.7 }where the "{features !textonly}" part expresses that home.graphics requires the absence of the textonly feature. If the feature is present, the overall quality of home.graphics degrades to 0.
The absence of a feature need not always degrade the overall quality to 0. In the example
{"x.html.1" 1.0 {features fonts;-0.7}}the absence of the fonts feature degrades the quality with a factor of 0.7. Finally, in the example
{"y.html" 1.0 {features [blebber wolx] }}
The "[blebber wolx]" expresses that y.html requires the presence of the blebber feature or the wolx feature. This construct can be used in a number of cases:
- 1. blebber and wolx actually tag the same feature, but they were registered by different people, and some user agents say they support blebber while others say they support wolx.
- 2. blebber and wolx are HTML tags of different vendors which implement the same functionality, and which are used together in y.html without interference.
- 3. blebber and wolx are HTML tags of different vendors which implement the same functionality, and y.html uses the tags in a conditional HTML construct.
- 4. blebber is a complicated HTML tag with only a sketchy definition, implemented by one user agent vendor, and wolx indicates implementation of a well-defined subset of the blebber tag by some other vendor(s). y.html uses only this well-defined subset.
As an example of negotiation in a numeric area, the following variant list describes four variants with title graphics designed for increasing screen widths:
{"home.pda" 1.0 {features screenwidth=[-199] }}, {"home.narrow" 1.0 {features screenwidth=[200-599] }}, {"home.normal" 1.0 {features screenwidth=[600-999] }}, {"home.wide" 1.0 {features screenwidth=[1000-] }}, {"home.normal"}
The last element of the list specifies a safe default for user agents which do not implement screen width negotiation. Such user agents will reject the first four variants as unusable, as they seem to rely on a feature which they do not understand.
→特徴札 (>>2) 参照。