/
849.txt
310 lines (228 loc) · 13.4 KB
/
849.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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
[30] [DFN[[CODE[[[X-[VAR[*]]]]]]]] やそれに類する記法 ([DFN[[CODE[[[X[VAR[*]]]]]]]]、
[DFN[[CODE[[[X_[VAR[*]]]]]]]]、[DFN[[CODE[[[X.[VAR[*]]]]]]]] など)
は、飾りです。偉い人にはそれがわからないかもしれません。
[HISTORY[
[52] 元々は標準で定められた名前や登録された名前に対して、非標準だったり実験用だったりする名前を区別することを意図していました。
しかし実際にはその意図があまり浸透しませんでした。
]HISTORY]
* IETF による非推奨
[29] [CODE[[[X-*]]]] やそれに類する記法は極めて多くの [[IETF]] プロトコル (やその他のプロトコル)
で使われていますが、それによって標準と非標準の名前を区別したところで、 [CODE[X-]]
の付いた名前が使われると実装はずっとそれに対応し続けなければならず、意味が無いどころか無駄なので、
[[非推奨]]としています。
[REFS[
- [27] [CITE@en[RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols]]
( ([TIME[2012-06-26 04:07:48 +09:00]] 版))
<http://tools.ietf.org/html/rfc6648>
- [25] [CITE@en[draft-saintandre-xdash-considered-harmful-01 - "X-" Considered Harmful]]
( ([TIME[2011-02-16 00:52:50 +09:00]] 版))
<http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful-01>
]REFS]
[EG[
[40] 例えば[[電子メール]]の [CODE(822)@en[[[Archived-At:]]]] [[ヘッダー]]は、
既存の [CODE(822)@en[[[X-Archived-At:]]]] [[ヘッダー]]を標準化したものでした。
別名の新しい[[ヘッダー]]を追加する形の標準化により、[[相互運用性]]は却って低下しました。
]EG]
[EG[
[42] [[HTTP]] [CODE(HTTP)@en[[[Content-Encoding:]]]] では初期から
[CODE[[[x-gzip]]]] という値が使われており、 [[RFC 1945]] ではこれが規定されていました。
ところが [[RFC 2068]] は [CODE[[[gzip]]]] という新たな値を規定し、
[CODE[[[x-gzip]]]] も互換性のために対応するべきとしていました。
]EG]
[EG[
[43] [[IETF charset]] の実装の中には、 [CODE[[[x-]]]] を除去してから比較するものもあります。
]EG]
[39] この方針転換があってから、 [CODE[X-]] を[[私用]]に予約する規定は新しいプロトコルには設けられず、
既存のプロトコルの改訂時には削除されています。既存の [CODE[X-]] を使った名前を
[[IANA登録簿]]に登録することも認められるようになっています。
[EG[
[41] [[Web]] では90年代からずっと [CODE(MIME)@en[[[application/x-www-form-urlencoded]]]]
という[[MIME型]]を使っていました。この[[MIME型]]は00年代になって
[[IANA登録簿]]に登録されました。
[54] 後から [CODE[x-]] の付かない形を登録したとしても、切り替えるのは不可能だったと思われます。
[CODE[x-]] を実験用に使い、 [CODE[x-]] に付かないものを正式に登録してから広く使う、
というモデルは [[Web]] の進化の速度に耐えられませんでした。
[55] [[IETF]] が方針転換せずに [CODE[x-]] の登録を認めないままだったとしたら、
[[IANA登録簿]]はますますその存在意義が低下するところでした。
]EG]
* [CODE[x-*]] を使っているプロトコル要素
[1]
[[BEEP]] ([[RFC 3080]]) は、 [[IANA]]
に登録''しない''[[機能識別]]が [CODE@en[[[x-]]]]
で始まることを求めています。
しかし、 [[IANA]] が [CODE@en[[[x-]]]]
で始まる[[文字列]]を登録してはいけないとは述べられていません。
[[大文字]]と[[小文字]]の区別には言及がありません。
[2]
[[vCard]] [CODE@en[[[IMPP]]]] [[型]] ([[RFC 4770]])
は、 [CODE@en[[[TYPE]]]] [[引数]]の値の一部として
[CODE(ABNF)@en[[[x-name]]]] の使用を認めています。
[CODE(ABNF)@en[[[x-name]]]] の定義は [[RFC 2426]]
にあって、非標準な利用のためのものとされています。
[3]
[CITE@en-us[XLIFF 1.1 Specification]] ([CODE[2006-07-08 02:30:08 +09:00]] 版) <http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20031031.htm#Struct_Extension>
([[名無しさん]] [sage])
[4]
[CITE@en-us[XLIFF 1.1 Specification]] ([CODE[2006-07-08 02:30:08 +09:00]] 版) <http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20031031.htm#Struct_Extension_Values>
([[名無しさん]] [sage])
[5]
[CITE@en-us[XLIFF 1.1 Specification]] ([CODE[2006-07-08 02:30:08 +09:00]] 版) <http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20031031.htm#mtype>
[17] [CITE[XLIFF 1.2 Specification]] ([TIME[2008-02-05 00:30:42 +09:00]] 版) <http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#Struct_Extension>
[6]
[CITE[Global Information Management eXchange Metrics Volume 1.0 Specification]] ([CODE[2007-02-24 17:44:10 +09:00]] 版) <http://www.lisa.org/standards/gmx/GMX-V.html#CountExtension>
([[名無しさん]] [sage])
[7]
[CITE[Global Information Management eXchange Metrics Volume 1.0 Specification]] ([CODE[2007-02-24 17:44:10 +09:00]] 版) <http://www.lisa.org/standards/gmx/GMX-V.html#Attr_state>
([[名無しさん]] [sage])
[8]
[CITE@en-us[TMX Specification]] ([CODE[2007-02-24 17:51:20 +09:00]] 版) <http://www.lisa.org/standards/tmx/tmx.html#prop>
([[名無しさん]] [sage])
[9]
[CITE@en[RFC 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1]] ([CODE[2007-02-14 19:02:25 +09:00]] 版) <http://tools.ietf.org/html/rfc4408#section-7>
[11] [CITE[SMIL 3.0 Content Control]] ([TIME[2008-12-02 00:45:09 +09:00]] 版) <http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-content.html#adef-systemBaseProfile>
[10] [CITE[SMIL 3.0 Structure Module]] ([TIME[2008-12-02 00:45:09 +09:00]] 版) <http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-structure.html#adef-baseProfile>
[26] [[CGI]] では [CODE(CGI)@en[[[X_*]]]] があります。
[32] [[言語タグ]]の[[拡張]]「[CODE(lang)@en[[[t]]]]」 には [CODE(lang)@en[[[x0]]]]
があります。
* 他のもの
[12] [[名前空間]]を使うもの (e.g. [[XML]] 系[[マーク付け言語]]、[[XPointer scheme]])
[13] [CITE[JSON-RPC 1.1 Working Draft 7 August 2006]] ([TIME[2007-01-11 07:38:32 +09:00]] 版) <http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html#ObjectExtensions>
[CODE(char)[[[$]]]] で始まるもの。
[14] [[vnd.*]]、[[prs.*]]: [[媒体型]]
[15] [[-[VAR[vendor]]-*]] ([[vendor prefix]]): [[CSS]]、[[選択子]]
[16] [[[[vendor]]*]]、[[[VAR[Vendor]]*]] ([[vendor prefix]]): [[DOM]]
[28] [CODE[[[P-*]]]]: [[SIP]]
* メモ
[18] [CITE[IRC logs: freenode / #whatwg / 20090918]]
([TIME[2009-11-03 01:07:53 +09:00]] 版)
<http://krijnhoetmer.nl/irc-logs/whatwg/20090918>
[19] [CITE@en[Web Applications 1.0 r5307 use vendor--feature instead of _vendor-feature since Apple engineers think underscores are ugly.Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590]]
( ([TIME[2010-08-17 07:14:00 +09:00]] 版))
<http://html5.org/tools/web-apps-tracker?from=5306&to=5307>
[20] [CITE@en[Speech Synthesis Markup Language (SSML) Version 1.1]]
( ([TIME[2010-09-08 00:26:19 +09:00]] 版))
<http://www.w3.org/TR/2010/REC-speech-synthesis11-20100907/#edef_phoneme>
[21] [CITE@en[Web Applications 1.0 r5562 Change how vendor extensions are marked up.Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590]]
( ([TIME[2010-09-30 07:38:00 +09:00]] 版))
<http://html5.org/tools/web-apps-tracker?from=5561&to=5562>
[22] [CITE[IRC logs: freenode / #whatwg / 20100930]]
( ([TIME[2010-10-11 01:27:16 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20100930>
[23] [CITE['''['''whatwg''']''' '''['''html5''']''' r5307 - '''['''giow''']''' (0) use vendor--feature instead of _vendor-feature since Apple engineers '''['''...''']''']]
([TIME[2010-12-01 08:44:16 +09:00]] 版)
<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-November/029256.html>
[24] [CITE@en[Tantek-Mozilla-projects - MozillaWiki]]
( ([TIME[2011-01-15 07:24:20 +09:00]] 版))
<https://wiki.mozilla.org/Tantek-Mozilla-projects#DOM_API_vendor_prefixing>
[31] [CITE@en[RFC 6838 - Media Type Specifications and Registration Procedures]]
( ([TIME[2013-06-27 23:37:19 +09:00]] 版))
<http://tools.ietf.org/html/rfc6838>
[33] [CITE@en[RFC 3507 - Internet Content Adaptation Protocol (ICAP)]]
( ([TIME[2014-06-08 07:17:07 +09:00]] 版))
<http://tools.ietf.org/html/rfc3507#section-4.3>
[34] [CITE@en[draft-stecher-icap-subid-00 - ICAP Extensions]]
( ([TIME[2014-08-31 17:09:58 +09:00]] 版))
<http://tools.ietf.org/html/draft-stecher-icap-subid-00>
[35] [CITE@en[RFC 4387 - Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP]]
( ([TIME[2014-06-08 08:24:17 +09:00]] 版))
<http://tools.ietf.org/html/rfc4387#page-9>
[36] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]]
( ([TIME[2014-08-07 05:54:02 +09:00]] 版))
<https://tools.ietf.org/html/rfc7231#section-8.3.1>
[37] [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-5.7>
[38] [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>
[44] [CITE@en[RFC 4716 - The Secure Shell (SSH) Public Key File Format]]
([TIME[2015-05-03 17:31:57 +09:00]] 版)
<https://tools.ietf.org/html/rfc4716#section-5>
[FIG(quote)[
[FIGCAPTION[
[45] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]]
([TIME[2015-03-22 13:14:46 +09:00]] 版)
<http://tools.ietf.org/html/rfc2046#section-5.1>
]FIGCAPTION]
> "X-" fields may be created for
> experimental or private purposes, with the recognition that the
> information they contain may be lost at some gateways.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[46] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]]
([TIME[2015-03-22 13:14:46 +09:00]] 版)
<http://tools.ietf.org/html/rfc2046#section-5.2.3.1>
]FIGCAPTION]
> Future values, except for
> experimental values beginning with "X-", must be
> registered with IANA, as described in RFC 2048.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[47] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]]
([TIME[2015-03-22 13:14:46 +09:00]] 版)
<http://tools.ietf.org/html/rfc2046#section-6>
]FIGCAPTION]
> A media type value beginning with the characters "X-" is a private
> value, to be used by consenting systems by mutual agreement. Any
> format without a rigorous and public definition must be named with an
> "X-" prefix, and publicly specified values shall never begin with
> "X-". (Older versions of the widely used Andrew system use the "X-
> BE2" name, so new systems should probably choose a different name.)
> In general, the use of "X-" top-level types is strongly discouraged.
> Implementors should invent subtypes of the existing types whenever
> possible. In many cases, a subtype of "application" will be more
> appropriate than a new top-level type.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[48] [CITE@en[RFC 7529 - Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar)]]
([TIME[2015-05-02 05:59:07 +09:00]] 版)
<https://tools.ietf.org/html/rfc7529>
]FIGCAPTION]
>
> / x-name) ; A non-standard, experimental
> ; calendar system name.
> ; Names are case insensitive,
> ; but uppercase values are preferred.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[49] [CITE@en[RFC 5546 - iCalendar Transport-Independent Interoperability Protocol (iTIP)]]
([TIME[2015-04-19 16:20:38 +09:00]] 版)
<https://tools.ietf.org/html/rfc5546#section-3.7.3>
]FIGCAPTION]
>
> To make iCalendar objects extensible, new component, property, or
> property parameters can be used. Two types of extensions are defined
> by '''['''RFC5545''']''': IANA-registered tokens ("iana-token") and experimental
> use tokens ("x-name"). A client SHOULD save "iana-token's" and MAY
> use them in replies. A client MAY save "x-name's" and MAY use them
> in replies. When delegating or forwarding messages to other CUs, a
> client SHOULD include "iana-token's" and "x-names's".
]FIG]
[FIG(quote)[
[FIGCAPTION[
[50] [CITE@en-US[Specification | Swagger]]
([TIME[2015-06-10 11:50:18 +09:00]] 版)
<http://swagger.io/specification/#vendorExtensions>
]FIGCAPTION]
> The extensions properties are always prefixed by "x-" and can have any valid JSON format value.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[51] [CITE@en[RAML 0.8]]
([TIME[2015-03-29 03:33:13 +09:00]] 版)
<http://raml.org/spec.html#other>
]FIGCAPTION]
> x-{other} The API's authentication relies in another authentication method.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[53] [CITE@en-US[Specification | Swagger]]
([TIME[2015-11-09 11:28:52 +09:00]] 版)
<http://swagger.io/specification/>
]FIGCAPTION]
> ^x- Any Allows extensions to the Swagger Schema. The field name MUST begin with x-, for example, x-internal-id. The value can be null, a primitive, an array or an object.
]FIG]