/
875.txt
160 lines (126 loc) · 8.34 KB
/
875.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
* 仕様書
[REFS[
- [4] '''[CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-6.1>'''
]REFS]
* 文脈
[5] [[特徴タグ]]は[[透過内容折衝]]の仕様で規定されていますが、
[[透過内容折衝]]以外で使うこともでき、また[[透過内容折衝]]では使えない[[特徴タグ]]を定義しても良い [SRC[>>4]] とされています。
* 歴史
[FIG(quote)[
[FIGCAPTION[
[1] RFC 2295 (HTTP 透過内容折衝) 6.1 Feature tags
]FIGCAPTION]
> 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.
[DFN[特徴札 (ftag)]]は、[[表現]]の[[特性]] ([[特徴]])
や[[利用者エージェント]]の能力 (特徴) や表現の特定の型についての利用者の好みなどの、
折衝に使用可能な何らかのものを識別します。
特徴札の使用は[[透過内容折衝]]に限定する必要はなく、
各特徴札は HTTP 透過内容折衝の枠組みで使用可能である必要はありません。
>
- [CODE(ABNF)[ftag = token | quoted-string]]
> 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
で開発中です。この仕様書は特徴札を何も定義しません。
実験的な状況では、 [CODE(feature)[[[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).
特徴札は[[特徴集合]]や[[特徴述語]]で使用します。
特徴述語は [CODE(conneg)[feature]] 属性で使用し、
[CODE(conneg)[feature]] 属性は[[変種記述]]で使用します。
変種記述は [CODE(HTTP)[[[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]] を使います。
特徴札の比較は大文字・小文字を区別しません。
[[字句]]札 [CODE(feature)[XYZ]] は [CODE(ABNF)[[[quoted-string]]]]
札 [CODE(feature)["XYZ"]] と同等です。例えば、
> tables, fonts, blebber, wolx, screenwidth, colordepth
> An example of the use of feature tags in a variant description is:
特徴札を変種記述で使った例 :
>
- [SAMP(conneg)[ {"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'.
特徴札の定義は、その特徴札が零個か一個かそれ以上の関連付けられた値を持つことができると言明できます。
この値は札の意味を特別化します。例えば、特徴札 [CODE(feature)[[[paper]]]]
は値 [CODE(feature)[[[A4]]]] や [CODE(feature)[[[A5]]]]
と関連付けることができることでしょう。
>
- [CODE(ABNF)[tag-value = token | quoted-string]]
> 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 を使います。
札値の同等性比較は大文字・小文字を区別した、オクテット毎の比較により行わなければ'''なりません'''。
このとき、 [CODE(ABNF)["%" [[HEX]] HEX]] 符号化は [[RFC2068]]
に従って処理しなければ'''なりません'''。
字句値 [CODE(feature)[XYZ]] は [CODE(ABNF)[[[quoted-string]]]]
値 [CODE(feature)["XYZ"]] と同等です。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[2] RFC 2295 (HTTP 透過内容折衝) 20.3 Feature tag design
]FIGCAPTION]
> 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
例として、 [CODE(feature)[[[color]]]] 特徴札を導入して白黒内容とカラー内容の間での折衝に対応しようとするとします。
この札が示されているとカラー画像表示能力があると示すことにします。
しかし、この新しい札を[[変種目録]]で使うと、例えば、
>
- [SAMP(conneg)[{"rainbow.gif" 1.0 {features color} }]]
- [SAMP(conneg)[{"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.
のようになりますが、既存の利用者エージェントで [CODE(feature)[color]]
札を理解しないものは、すべて白黒の虹を表示することとなるでしょう。
従って、既存の利用者エージェントで最適な結果を望む状況では [CODE(feature)[color]]
札は使用不能です。この領域での折衝を提供するためには、
[CODE(feature)[[[monochrome]]]] 特徴札をどうにゅうしなければなりません。
この札は利用者エージェントが白黒図形だけしかレンダリングすることができない
(又は利用者が白黒図形を表示することを好んでいる)
ことを示します。
]FIG]
[3]
[CITE@en[draft-mutz-http-attributes-01]] ([TIME[2007-02-23 04:30:20 +09:00]] 版) <http://tools.ietf.org/html/draft-mutz-http-attributes-01>