[30] X-* やそれに類する記法 (X*、 X_*、X.* など) は、飾りです。偉い人にはそれがわからないかもしれません偉い人にはそれがわからんのです。

[52] 元々は標準で定められた名前や登録された名前に対して、非標準だったり実験用だったりする名前を区別することを意図していました。 しかし実際にはその意図があまり浸透せず、 想定外の使われ方ばかりでした。

IETF による非推奨

[29] X-* やそれに類する記法は極めて多くの IETF プロトコル (やその他のプロトコル) で使われていますが、それによって標準と非標準の名前を区別したところで、 X- の付いた名前が使われると実装はずっとそれに対応し続けなければならず、意味が無いどころか無駄なので、 非推奨としています。

[40] 例えば電子メールの Archived-At: ヘッダーは、 既存の X-Archived-At: ヘッダーを標準化したものでした。 別名の新しいヘッダーを追加する形の標準化により、相互運用性は却って低下しました。

[42] HTTP Content-Encoding: では初期から x-gzip という値が使われており、 RFC 1945 ではこれが規定されていました。 ところが RFC 2068 は gzip という新たな値を規定し、 x-gzip も互換性のために対応するべきとしていました。

[43] IETF charset の実装の中には、 x- を除去してから比較するものもあります。

[39] この方針転換があってから、 X- を私用に予約する規定は新しいプロトコルには設けられず、 既存のプロトコルの改訂時には削除されています。既存の X- を使った名前を IANA登録簿に登録することも認められるようになっています。

[41] Web では90年代からずっと application/x-www-form-urlencoded というMIME型を使っていました。このMIME型は00年代になって IANA登録簿に登録されました。

[54] 後から x- の付かない形を登録したとしても、切り替えるのは不可能だったと思われます。 x- を実験用に使い、 x- に付かないものを正式に登録してから広く使う、 というモデルは Web の進化の速度に耐えられませんでした。

[55] IETF が方針転換せずに x- の登録を認めないままだったとしたら、 IANA登録簿はますますその存在意義が低下するところでした。

x-* を使っているプロトコル要素

[1] BEEP (RFC 3080) は、 IANA に登録しない機能識別が x- で始まることを求めています。 しかし、 IANA が x- で始まる文字列を登録してはいけないとは述べられていません。 大文字と小文字の区別には言及がありません。

[2] vCard IMPP 型 (RFC 4770) は、 TYPE 引数の値の一部として x-name の使用を認めています。 x-name の定義は RFC 2426 にあって、非標準な利用のためのものとされています。

[3] XLIFF 1.1 Specification (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] XLIFF 1.1 Specification (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] XLIFF 1.1 Specification (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] XLIFF 1.2 Specification ( 版) http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#Struct_Extension

[6] Global Information Management eXchange Metrics Volume 1.0 Specification (2007-02-24 17:44:10 +09:00 版) http://www.lisa.org/standards/gmx/GMX-V.html#CountExtension (名無しさん [sage])

[7] Global Information Management eXchange Metrics Volume 1.0 Specification (2007-02-24 17:44:10 +09:00 版) http://www.lisa.org/standards/gmx/GMX-V.html#Attr_state (名無しさん [sage])

[8] TMX Specification (2007-02-24 17:51:20 +09:00 版) http://www.lisa.org/standards/tmx/tmx.html#prop (名無しさん [sage])

[9] RFC 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 (2007-02-14 19:02:25 +09:00 版) http://tools.ietf.org/html/rfc4408#section-7

[11] SMIL 3.0 Content Control ( 版) http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-content.html#adef-systemBaseProfile

[10] SMIL 3.0 Structure Module ( 版) http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-structure.html#adef-baseProfile

[26] CGI では X_* があります。

[32] 言語タグの拡張「t」 には x0 があります。

[70] URL scheme もかつては採用していました。

[73] FIPA MTSメッセージの slot 名は将来の拡張を X-FIPA-、 独自の拡張を X-CompanyName- から始めることとしていました。

[79] RFC 4566: SDP: Session Description Protocol, , https://www.rfc-editor.org/rfc/rfc4566.html#section-5.8

[82] Microsoft Word - A-100-1.doc - a_100_1.pdf, https://web.archive.org/web/20060927005115/http://www.atsc.org/standards/a_100_1.pdf#page=42

[63] x- を採用

x-* 要素 (HTML)

[83] HTML のカスタム要素名は - を含むことが条件ですが、 開発当初案では x- から始まることが条件でした。 カスタム要素名

x-* 属性 (HTML)

[75] HTML には data-* 属性がありますが、 非標準の x-* 属性が使われることがあります。

[77] この種の属性の利用は不適切です。 data-* を使うべきです。

[78] また、非標準のこのような属性を使うライブラリーは作者の HTML 仕様への無理解の現れですから、品質に不安があります。 安易に使うべきではありません。

[76] Alpine.js, https://alpinejs.dev/

他のもの

[12] 名前空間を使うもの (e.g. XML 系マーク付け言語、XPointer scheme)

[13] JSON-RPC 1.1 Working Draft 7 August 2006 ( 版) http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html#ObjectExtensions

$ で始まるもの。

[14] vnd.*、prs.*: 媒体型

[15] -vendor-* (vendor prefix): CSS、選択子

[16] vendor*、Vendor* (vendor prefix): DOM

[28] P-*: SIP

[60] i-*

[61] NID 仮登録

[84] 実験用識別子

[85] 私用

関連

[74] ISO 4217 通貨符号では X から始まる符号は特殊用とされ、 私用の符号は提供されていません。

[86] 非標準空間が標準化される

メモ

[18] IRC logs: freenode / #whatwg / 20090918 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20090918

[19] 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 ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5306&to=5307

[20] Speech Synthesis Markup Language (SSML) Version 1.1 ( ( 版)) http://www.w3.org/TR/2010/REC-speech-synthesis11-20100907/#edef_phoneme

[21] Web Applications 1.0 r5562 Change how vendor extensions are marked up.Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590 ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5561&to=5562

[22] IRC logs: freenode / #whatwg / 20100930 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20100930

[23] [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...] ( 版) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-November/029256.html

[24] Tantek-Mozilla-projects - MozillaWiki ( ( 版)) https://wiki.mozilla.org/Tantek-Mozilla-projects#DOM_API_vendor_prefixing

[31] RFC 6838 - Media Type Specifications and Registration Procedures ( ( 版)) http://tools.ietf.org/html/rfc6838

[33] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3

[34] draft-stecher-icap-subid-00 - ICAP Extensions ( ( 版)) http://tools.ietf.org/html/draft-stecher-icap-subid-00

[35] RFC 4387 - Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP ( ( 版)) http://tools.ietf.org/html/rfc4387#page-9

[36] RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content ( ( 版)) https://tools.ietf.org/html/rfc7231#section-8.3.1

[37] RFC 2295 - Transparent Content Negotiation in HTTP ( ( 版)) http://tools.ietf.org/html/rfc2295#section-5.7

[38] RFC 2295 - Transparent Content Negotiation in HTTP ( ( 版)) http://tools.ietf.org/html/rfc2295#section-6.1

[44] RFC 4716 - The Secure Shell (SSH) Public Key File Format ( 版) https://tools.ietf.org/html/rfc4716#section-5

[45] RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ( 版) http://tools.ietf.org/html/rfc2046#section-5.1

"X-" fields may be created for

experimental or private purposes, with the recognition that the

information they contain may be lost at some gateways.

[46] RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ( 版) http://tools.ietf.org/html/rfc2046#section-5.2.3.1

Future values, except for

experimental values beginning with "X-", must be

registered with IANA, as described in RFC 2048.

[47] RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ( 版) http://tools.ietf.org/html/rfc2046#section-6

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.

[48] RFC 7529 - Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) ( 版) https://tools.ietf.org/html/rfc7529

/ x-name) ; A non-standard, experimental

; calendar system name.

; Names are case insensitive,

; but uppercase values are preferred.

[49] RFC 5546 - iCalendar Transport-Independent Interoperability Protocol (iTIP) ( 版) https://tools.ietf.org/html/rfc5546#section-3.7.3

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

[50] Specification | Swagger ( 版) http://swagger.io/specification/#vendorExtensions

The extensions properties are always prefixed by "x-" and can have any valid JSON format value.

[51] RAML 0.8 ( 版) http://raml.org/spec.html#other

x-{other} The API's authentication relies in another authentication method.

[53] Specification | Swagger ( 版) http://swagger.io/specification/

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

[56] RFC 8098 - Message Disposition Notification () https://tools.ietf.org/html/rfc8098#section-2.2

[57] PWG 5100.13 – IPP: Job and Printer Extensions – Set 3 ( ()) http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext3v10-20120727-5100.13.pdf#page=24

Standard keywords are

defined in The Dublin Core Metadata Element Set [RFC5013] and DCMI Metadata Terms

[DCMITERMS]. Vendor or customer-defined keywords MUST use the prefix string "x-" to

avoid future keyword name conflicts, for example "x-vendor-foo" or "x-customer-bar".

[58] Standardize "nosniff" · Issue #35 · whatwg/fetch () https://github.com/whatwg/fetch/issues/35

[59] RFC 4791 - Calendaring Extensions to WebDAV (CalDAV) () https://tools.ietf.org/html/rfc4791#section-5.3.3

[62] OpenRPC Specification | spec (, ) https://spec.open-rpc.org/#specification-extensions

[64] ISO/IEC 26300 (JIS X 4401:2014) 附属書Cは、 MIME型を登録作業中として x- を含まない名前で示しながら、 登録されるまで x- をつけるのが望ましいと定めていました。

[65] RFC 2801 - Internet Open Trading Protocol - IOTP Version 1.0, , https://tools.ietf.org/html/rfc2801#section-12.2

[66] RFC Errata Report » RFC Editor, https://www.rfc-editor.org/errata_search.php?rfc=2978

[67] RFC 3080 - The Blocks Extensible Exchange Protocol Core (, ) https://tools.ietf.org/html/rfc3080#section-5.2

[68] rfc3977, https://datatracker.ietf.org/doc/html/rfc3977#section-3.3.3

[69] rfc3977, https://datatracker.ietf.org/doc/html/rfc3977#section-8.1

[71] rfc3659 () https://datatracker.ietf.org/doc/html/rfc3659#section-7.5

[72] rfc3939 () https://datatracker.ietf.org/doc/html/rfc3939#section-3.3

[87] raml-spec/versions/raml-10/raml-10.md at master · raml-org/raml-spec · GitHub, https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md/#security-scheme-types