feature

特徴折衝 (HTTP)

仕様書

構成

文脈

歴史

[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
  • HTML 拡張
  • 他の媒体型の拡張
  • 利用者エージェントの色能力
  • 画面の寸法
  • 出力媒体 (画面、紙、・・・)
  • 速度と図形的詳細のどちらを優先させるか

について折衝します。

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.

6.1 Feature tags

特徴札 (>>1)参照。

6.2 Feature sets

特徴集合 (>>1)参照。

6.3 Feature predicates

特徴述語 (>>1)参照。

6.4 Features attribute

変種記述//features (>>2) 参照。

[6] RFC 2295 20 Appendix: feature negotiation examples

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].

20.1 Use of feature tags

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.

20.2 Use of numeric feature tags

[5]

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.

20.3 Feature tag design

特徴札 (>>2) 参照。