RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6648
タイトル : RFC 6648 - アプリケーションプロトコルにおける「X-」接頭辞および類似の構文の廃止
翻訳編集 : 自動生成＆有志による翻訳・編集

[要約] この文書は、HTTPヘッダーや各種アプリケーションプロトコルにおいて、非標準な拡張項目に「X-」プレフィックスを付ける慣習を正式に廃止することを勧告しています（BCP 178）。拡張機能が標準化された際にプレフィックスを外す手間や相互運用性の問題を避けるため、最初から意味のある名前を使用することを求めています。

Internet Engineering Task Force (IETF)                    P. Saint-Andre
Request for Comments: 6648                           Cisco Systems, Inc.
BCP: 178                                                      D. Crocker
Category: Best Current Practice              Brandenburg InternetWorking
ISSN: 2070-1721                                            M. Nottingham
                                                               Rackspace
                                                               June 2012

Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

アプリケーションプロトコルにおける「X-」接頭辞および類似の構文の廃止

Abstract

概要

Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols.

歴史的に、アプリケーションプロトコルの設計者と実装者は、標準化されていないパラメータの名前に文字列「X-」や類似の構文を接頭辞として付けることで、標準化されたパラメータと標準化されていないパラメータを区別することがよくありました。実際には、この慣習は解決する問題よりも多くの問題を引き起こしています。そのため本文書は、アプリケーションプロトコルにおいて (数値ではなく) テキストの名前を持つ、新たに定義されるパラメータについて、この慣習を廃止します。

Status of This Memo

本文書の状態

This memo documents an Internet Best Current Practice.

この文書は、インターネットの現在の最良の慣行 (Best Current Practice) を記述したものです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.

この文書は、Internet Engineering Task Force (IETF) の成果物です。この文書は IETF コミュニティの合意を表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって発行が承認されました。BCP の詳細については、RFC 5741 の第2節を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6648.

この文書の現在の状態、正誤表、およびフィードバックの方法に関する情報は、http://www.rfc-editor.org/info/rfc6648 で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78 と、この文書の発行日に有効な IETF 文書に関する IETF Trust の法的規定 (http://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するあなたの権利と制限が記載されているため、注意深く確認してください。この文書から抽出されたコードコンポーネントには、Trust Legal Provisions の第4.e節に記載されている Simplified BSD License のテキストを含めなければならず、それらは Simplified BSD License に記載されているとおり無保証で提供されます。

Table of Contents

1. Introduction ....................................................2
2. Recommendations for Implementers of Application Protocols .......4
3. Recommendations for Creators of New Parameters ..................4
4. Recommendations for Protocol Designers ..........................4
5. Security Considerations .........................................5
6. IANA Considerations .............................................5
7. Acknowledgements ................................................5
Appendix A.  Background ............................................6
Appendix B.  Analysis ..............................................7
References ........................................................10
   Normative References ...........................................10
   Informative References .........................................10

   1. Introduction ....................................................2

   1. はじめに ........................................................2

   2. Recommendations for Implementers of Application Protocols .......4

   2. アプリケーションプロトコルの実装者への推奨事項 ..................4

   3. Recommendations for Creators of New Parameters ..................4

   3. 新しいパラメータの作成者への推奨事項 ............................4

   4. Recommendations for Protocol Designers ..........................4

   4. プロトコル設計者への推奨事項 ....................................4

   5. Security Considerations .........................................5

   5. セキュリティに関する考慮事項 ....................................5

   6. IANA Considerations .............................................5

   6. IANAに関する考慮事項 ............................................5

   7. Acknowledgements ................................................5

   7. 謝辞 ............................................................5

   Appendix A.  Background ............................................6

   Appendix A.  背景 ..................................................6

   Appendix B.  Analysis ..............................................7

   Appendix B.  分析 ..................................................7

   References ........................................................10

   参考文献 ..........................................................10

      Normative References ...........................................10

      引用文献 .......................................................10

      Informative References .........................................10

      参考引用 .......................................................10

1. Introduction

1. はじめに

Many application protocols use parameters with textual (as opposed to numerical) names to identify data (media types, header fields in Internet mail messages and HTTP requests, vCard parameters and properties, etc.). Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs (e.g., "x."), where the "X" is commonly understood to stand for "eXperimental" or "eXtension".

多くのアプリケーションプロトコルは、データ (メディアタイプ、インターネットメールメッセージや HTTP リクエストのヘッダフィールド、vCard のパラメータやプロパティなど) を識別するために、(数値ではなく) テキストの名前を持つパラメータを使用しています。歴史的に、アプリケーションプロトコルの設計者と実装者は、標準化されていないパラメータの名前に文字列「X-」や類似の構文 (たとえば「x.」) を接頭辞として付けることで、標準化されたパラメータと標準化されていないパラメータを区別することがよくありました。この「X」は、一般に「eXperimental (実験的)」または「eXtension (拡張)」を表すものと理解されています。

Under this convention, the name of a parameter not only identified the data, but also embedded the status of the parameter into the name itself: a parameter defined in a specification produced by a recognized standards development organization (or registered according to processes defined in such a specification) did not start with "X-" or similar constructs, whereas a parameter defined outside such a specification or process started with "X-" or similar constructs.

この慣習の下では、パラメータの名前はデータを識別するだけでなく、パラメータの状態を名前そのものに埋め込んでいました。つまり、公認された標準化団体が作成した仕様で定義された (またはそのような仕様で定義された手続きに従って登録された) パラメータは「X-」や類似の構文で始まらず、そのような仕様や手続きの外で定義されたパラメータは「X-」や類似の構文で始まっていました。

As explained more fully under Appendix A, this convention was encouraged for many years in application protocols such as file transfer, email, and the World Wide Web. In particular, it was codified for email by [RFC822] (via the distinction between "Extension-fields" and "user-defined-fields"), but then removed by [RFC2822] based on implementation and deployment experience. A similar progression occurred for SIP technologies with regard to the "P-" header, as explained in [RFC5727]. The reasoning behind those changes is explored under Appendix B.

付録Aでより詳しく説明するように、この慣習は、ファイル転送、電子メール、World Wide Web などのアプリケーションプロトコルにおいて長年にわたり推奨されてきました。特に電子メールについては、[RFC822] で ("Extension-fields" と "user-defined-fields" の区別を通じて) 明文化されましたが、その後、実装と運用の経験に基づいて [RFC2822] で削除されました。[RFC5727] で説明されているように、SIP 技術でも "P-" ヘッダに関して同様の経緯をたどりました。これらの変更の背景にある理由は、付録Bで検討します。

In short, although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space.

要するに、理論上は「X-」の慣習は、標準化されたパラメータと標準化されていないパラメータの衝突 (およびそれに伴う相互運用性の問題) を回避する良い方法でした。しかし実際には、標準化されていないパラメータが標準の領域に漏れ出すことに伴うコストが、そのメリットを上回ってきました。

This document generalizes from the experience of the email and SIP communities by doing the following:

本文書は、電子メールと SIP のコミュニティの経験を一般化し、次のことを行います。

1. Deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such as was done for email in [RFC822].

1. 確立済みのプロトコルの新しいパラメータを含め、アプリケーションプロトコルで新たに定義されるパラメータについて「X-」の慣習を廃止します。この変更は、[RFC822] の電子メールの場合のように、「X-」の慣習が明示的に定められておらず暗黙的なものにすぎなかった場合にも適用されます。

2. Makes specific recommendations about how to proceed in a world without the distinction between standardized and unstandardized parameters (although only for parameters with textual names, not parameters that are expressed as numbers, which are out of the scope of this document).

2. 標準化されたパラメータと標準化されていないパラメータの区別がない世界でどのように進めるべきかについて、具体的な推奨事項を示します (ただし、対象はテキストの名前を持つパラメータのみであり、数値で表現されるパラメータは本文書の範囲外です)。

3. Does not recommend against the practice of private, local, preliminary, experimental, or implementation-specific parameters, only against the use of "X-" and similar constructs in the names of such parameters.

3. 私的、ローカル、暫定的、実験的、または実装固有のパラメータを使う慣行そのものには反対せず、そのようなパラメータの名前に「X-」や類似の構文を使うことにのみ反対します。

4. Makes no recommendation as to whether existing "X-" parameters ought to remain in use or be migrated to a format without the "X-"; this is a matter for the creators or maintainers of those parameters.

4. 既存の「X-」パラメータを使い続けるべきか、「X-」のない形式に移行すべきかについては推奨を示しません。これは、それらのパラメータの作成者または保守者が判断すべき事柄です。

5. Does not override existing specifications that legislate the use of "X-" for particular application protocols (e.g., the "x-name" token in [RFC5545]); this is a matter for the designers of those protocols.

5. 特定のアプリケーションプロトコルについて「X-」の使用を定めている既存の仕様 (たとえば [RFC5545] の "x-name" トークン) を上書きしません。これは、それらのプロトコルの設計者が判断すべき事柄です。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

本文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているとおりに解釈されます。

2. Recommendations for Implementers of Application Protocols

2. アプリケーションプロトコルの実装者への推奨事項

Implementations of application protocols MUST NOT make any assumptions about the status of a parameter, nor take automatic action regarding a parameter, based solely on the presence or absence of "X-" or a similar construct in the parameter's name.

アプリケーションプロトコルの実装は、パラメータの名前に「X-」や類似の構文が含まれるかどうかだけに基づいて、そのパラメータの状態について何らかの仮定をしたり、そのパラメータに関して自動的な処理を行ったりしてはなりません (MUST NOT)。

3. Recommendations for Creators of New Parameters

3. 新しいパラメータの作成者への推奨事項

Creators of new parameters to be used in the context of application protocols:

アプリケーションプロトコルの文脈で使用される新しいパラメータの作成者は、次のようにします。

1. SHOULD assume that all parameters they create might become standardized, public, commonly deployed, or usable across multiple implementations.

1. 自分が作成するすべてのパラメータが、標準化される、公開される、広く展開される、または複数の実装にわたって使用可能になる可能性があると想定すべきです (SHOULD)。

2. SHOULD employ meaningful parameter names that they have reason to believe are currently unused.

2. 現在使用されていないと信じる根拠のある、意味のあるパラメータ名を使用すべきです (SHOULD)。

3. SHOULD NOT prefix their parameter names with "X-" or similar constructs.

3. パラメータ名に「X-」や類似の構文を接頭辞として付けるべきではありません (SHOULD NOT)。

Note: If the relevant parameter name space has conventions about associating parameter names with those who create them, a parameter name could incorporate the organization's name or primary domain name (see Appendix B for examples).

注: 該当するパラメータの名前空間に、パラメータ名とその作成者を関連付ける慣習がある場合、パラメータ名に組織名やプライマリドメイン名を含めることができます (例については付録Bを参照してください)。

4. Recommendations for Protocol Designers

4. プロトコル設計者への推奨事項

Designers of new application protocols that allow extensions using parameters:

パラメータを使った拡張を可能にする新しいアプリケーションプロトコルの設計者は、次のようにします。

1. SHOULD establish registries with potentially unlimited value-spaces, defining both permanent and provisional registries if appropriate.

1. 値空間が潜在的に無制限となるレジストリを設け、適切であれば恒久的なレジストリと暫定的なレジストリの両方を定義すべきです (SHOULD)。

2. SHOULD define simple, clear registration procedures.

2. 簡潔で明確な登録手順を定義すべきです (SHOULD)。

3. SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names.

3. パラメータ名の形式にかかわらず、私的でないすべてのパラメータの登録を義務付けるべきです (SHOULD)。

4. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered.

4. 「X-」接頭辞や類似の構文を持つパラメータの登録を禁止すべきではありません (SHOULD NOT)。

5. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized.

5. 「X-」接頭辞や類似の構文を持つパラメータを標準化されていないものとみなす必要がある、と規定してはなりません (MUST NOT)。

6. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized.

6. 「X-」接頭辞や類似の構文を持たないパラメータを標準化されたものとみなす必要がある、と規定してはなりません (MUST NOT)。

5. Security Considerations

5. セキュリティに関する考慮事項

Interoperability and migration issues with security-critical parameters can result in unnecessary vulnerabilities (see Appendix B for further discussion).

セキュリティ上重要なパラメータに関する相互運用性や移行の問題は、不必要な脆弱性につながる可能性があります (詳しい議論については付録Bを参照してください)。

As a corollary to the recommendation provided under Section 2, implementations MUST NOT assume that standardized parameters are "secure" whereas unstandardized parameters are "insecure", based solely on the names of such parameters.

第2節の推奨事項から導かれる帰結として、実装は、パラメータの名前だけに基づいて、標準化されたパラメータは「安全」であり標準化されていないパラメータは「安全でない」と仮定してはなりません (MUST NOT)。

6. IANA Considerations

6. IANAに関する考慮事項

This document does not modify registration procedures currently in force for various application protocols. However, such procedures might be updated in the future to incorporate the best practices defined in this document.

本文書は、各種アプリケーションプロトコルで現在有効な登録手順を変更しません。ただし、そのような手順は、本文書で定義する最良の慣行を取り入れるために、将来更新される可能性があります。

7. Acknowledgements

7. 謝辞

Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Ralph Droms, Martin Duerst, Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman, Eric Johnson, Scott Kelly, Scott Kitterman, John Klensin, Graham Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke, Randy Presuhn, Julian Reschke, Dan Romascanu, Doug Royer, Andrew Sullivan, Henry Thompson, Martin Thomson, Matthew Wild, Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga for their feedback.

Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Ralph Droms, Martin Duerst, Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman, Eric Johnson, Scott Kelly, Scott Kitterman, John Klensin, Graham Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke, Randy Presuhn, Julian Reschke, Dan Romascanu, Doug Royer, Andrew Sullivan, Henry Thompson, Martin Thomson, Matthew Wild, Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga の各氏からのフィードバックに感謝します。

Appendix A. Background

付録A. 背景

The beginnings of the "X-" convention can be found in a suggestion made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]:

「X-」の慣習の起源は、1975年に Brian Harvey が FTP のパラメータに関して行った提案 [RFC691] に見ることができます。

Thus, FTP servers which care about the distinction between Telnet print and non-print could implement SRVR N and SRVR T. Ideally the SRVR parameters should be registered with Jon Postel to avoid conflicts, although it is not a disaster if two sites use the same parameter for different things. I suggest that parameters be allowed to be more than one letter, and that an initial letter X be used for really local idiosyncracies [sic].

したがって、Telnet の印字と非印字の区別を気にする FTP サーバは、SRVR N と SRVR T を実装できます。理想的には、衝突を避けるために SRVR パラメータを Jon Postel に登録するべきですが、2つのサイトが同じパラメータを別の目的に使ったとしても大惨事にはなりません。私は、パラメータを2文字以上にできるようにし、本当にローカルな独自の用途には先頭の文字 X を使うことを提案します [sic]。

This "X" prefix was subsequently used in [RFC737], [RFC743], and [RFC775]. This usage was noted in [RFC1123]:

この「X」接頭辞は、その後 [RFC737]、[RFC743]、[RFC775] で使用されました。この使い方は [RFC1123] で次のように言及されています。

      FTP allows "experimental" commands, whose names begin with "X".
      If these commands are subsequently adopted as standards, there may
      still be existing implementations using the "X" form....  All FTP
      implementations SHOULD recognize both forms of these commands, by
      simply equating them with extra entries in the command lookup
      table.

The "X-" convention has been used for email header fields since at least the publication of [RFC822] in 1982, which distinguished between "Extension-fields" and "user-defined-fields" as follows:

「X-」の慣習は、少なくとも1982年の [RFC822] の発行以来、電子メールのヘッダフィールドに使われてきました。[RFC822] は "Extension-fields" と "user-defined-fields" を次のように区別しています。

The prefatory string "X-" will never be used in the names of Extension-fields. This provides user-defined fields with a protected set of names.

前置文字列「X-」が Extension-fields の名前に使用されることは決してありません。これにより、ユーザ定義フィールドのために保護された名前の集合が提供されます。

That rule was restated by [RFC1154] as follows:

この規則は、[RFC1154] で次のように言い換えられました。

Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-".

「X-」で始まるキーワードは、実装固有の用途のために永久に予約されています。標準として登録されるエンコーディングキーワードが「X-」で始まることは決してありません。

This convention continued with various specifications for media types ([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068], [RFC2616]), vCard parameters and properties ([RFC2426]), Uniform Resource Names ([RFC3406]), Lightweight Directory Access Protocol (LDAP) field names ([RFC4512]), and other application technologies.

この慣習は、メディアタイプ ([RFC2045]、[RFC2046]、[RFC2047])、HTTP ヘッダ ([RFC2068]、[RFC2616])、vCard のパラメータとプロパティ ([RFC2426])、Uniform Resource Names ([RFC3406])、Lightweight Directory Access Protocol (LDAP) のフィールド名 ([RFC4512])、その他のアプリケーション技術の各種仕様に引き継がれました。

However, use of the "X-" prefix in email headers was effectively deprecated between the publication of [RFC822] in 1982 and the publication of [RFC2822] in 2001 by removing the distinction between the "extension-field" construct and the "user-defined-field" construct (a similar change happened with regard to Session Initiation Protocol "P-" headers when [RFC3427] was obsoleted by [RFC5727]).

しかし、電子メールヘッダにおける「X-」接頭辞の使用は、1982年の [RFC822] の発行から2001年の [RFC2822] の発行までの間に、"extension-field" 構文と "user-defined-field" 構文の区別が取り除かれたことで、事実上廃止されました (Session Initiation Protocol の "P-" ヘッダについても、[RFC3427] が [RFC5727] によって廃止された際に同様の変更が起こりました)。

Despite the fact that parameters containing the "X-" string have been effectively deprecated in email headers, they continue to be used in a wide variety of application protocols. The two primary situations motivating such use are:

「X-」文字列を含むパラメータは電子メールヘッダでは事実上廃止されているにもかかわらず、さまざまなアプリケーションプロトコルで使われ続けています。そのような使用の動機となる主な状況は、次の2つです。

1. Experiments that are intended to possibly be standardized in the future, if they are successful.

1. 成功すれば将来標準化される可能性があることを想定した実験。

2. Extensions that are intended to never be standardized because they are intended only for implementation-specific use or for local use on private networks.

2. 実装固有の用途やプライベートネットワークでのローカルな用途だけを意図しているため、標準化されることを決して想定していない拡張。

Use of this naming convention is not mandated by the Internet Standards Process [BCP9] or IANA registration rules [BCP26]. Rather, it is an individual choice by each specification that references the convention or each administrative process that chooses to use it. In particular, some Standards Track RFCs have interpreted the convention in a normative way (e.g., [RFC822] and [RFC5451]).

この命名の慣習の使用は、インターネット標準化プロセス [BCP9] や IANA の登録規則 [BCP26] で義務付けられているものではありません。むしろ、この慣習を参照する各仕様や、この慣習を使うことを選んだ各管理手続きが、個別に選択したものです。特に、一部の標準化過程 (Standards Track) の RFC は、この慣習を規範的に解釈しています (たとえば [RFC822] や [RFC5451])。

Appendix B. Analysis

付録B. 分析

The primary problem with the "X-" convention is that unstandardized parameters have a tendency to leak into the protected space of standardized parameters, thus introducing the need for migration from the "X-" name to a standardized name. Migration, in turn, introduces interoperability issues (and sometimes security issues) because older implementations will support only the "X-" name and newer implementations might support only the standardized name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means that the unstandardized name has become a de facto standard (thus obviating the need for segregation of the name space into standardized and unstandardized areas in the first place).

「X-」の慣習の主な問題は、標準化されていないパラメータが、標準化されたパラメータのために保護された領域に漏れ出す傾向があり、その結果「X-」付きの名前から標準化された名前への移行が必要になることです。そして移行は、相互運用性の問題 (場合によってはセキュリティの問題) をもたらします。古い実装は「X-」付きの名前しかサポートせず、新しい実装は標準化された名前しかサポートしない可能性があるためです。相互運用性を保つために、新しい実装は結局「X-」付きの名前をいつまでもサポートし続けることになります。これは、標準化されていない名前が事実上の標準になったことを意味します (したがって、そもそも名前空間を標準化された領域と標準化されていない領域に分ける必要がなくなります)。

We have already seen this phenomenon at work with regard to FTP in the quote from [RFC1123] in Appendix A. The HTTP community had the same experience with the "x-gzip" and "x-compress" media types, as noted in [RFC2068]:

この現象が実際に起きていることは、付録Aで引用した [RFC1123] の FTP に関する記述ですでに見ました。HTTP のコミュニティも、[RFC2068] で述べられているように、"x-gzip" と "x-compress" のメディアタイプで同じ経験をしました。

For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.

HTTP の以前の実装との互換性のために、アプリケーションは "x-gzip" と "x-compress" を、それぞれ "gzip" と "compress" と同等とみなすべきです。

A similar example can be found in [RFC5064], which defined the "Archived-At" message header field but also found it necessary to define and register the "X-Archived-At" field:

同様の例は [RFC5064] にも見られます。[RFC5064] は "Archived-At" メッセージヘッダフィールドを定義しましたが、"X-Archived-At" フィールドも定義して登録する必要があると判断しました。

For backwards compatibility, this document also describes the X-Archived-At header field, a precursor of the Archived-At header field. The X-Archived-At header field MAY also be parsed, but SHOULD NOT be generated.

後方互換性のために、本文書では Archived-At ヘッダフィールドの前身である X-Archived-At ヘッダフィールドについても説明します。X-Archived-At ヘッダフィールドは解析してもよいですが (MAY)、生成すべきではありません (SHOULD NOT)。

One of the original reasons for segregation of name spaces into standardized and unstandardized areas was the perceived difficulty of registering names. However, the solution to that problem has been simpler registration rules, such as those provided by [RFC3864] and [RFC4288]. As explained in [RFC4288]:

名前空間を標準化された領域と標準化されていない領域に分けた当初の理由の1つは、名前の登録が難しいと受け止められていたことでした。しかし、その問題の解決策となってきたのは、[RFC3864] や [RFC4288] で規定されているような、より簡素な登録規則です。[RFC4288] では次のように説明されています。

[W]ith the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both "x-" and "x." forms is discouraged.

[上記で] 説明したベンダーツリーと個人ツリーの簡素化された登録手順があれば、登録されていない実験的なタイプを使う必要が生じることは、あったとしてもまれなはずです。したがって、"x-" 形式と "x." 形式のどちらの使用も推奨されません。

For some name spaces, another helpful practice has been the establishment of separate registries for permanent names and provisional names, as in [RFC4395].

名前空間によっては、[RFC4395] のように、恒久的な名前と暫定的な名前のために別々のレジストリを設けることも有用な慣行となってきました。

Furthermore, often standardization of a unstandardized parameter leads to subtly different behavior (e.g., the standardized version might have different security properties as a result of security review provided during the standardization process). If implementers treat the old, unstandardized parameter and the new, standardized parameter as equivalent, interoperability and security problems can ensue. Analysis of unstandardized parameters to detect and correct flaws is, in general, a good thing and is not intended to be discouraged by the lack of distinction in element names. If an originally unstandardized parameter or protocol element is standardized and the new form has differences that affect interoperability or security properties, it would be inappropriate for implementations to treat the old form as identical to the new form.

さらに、標準化されていないパラメータを標準化すると、微妙に異なる動作になることがよくあります (たとえば、標準化の過程で行われるセキュリティレビューの結果として、標準化された版は異なるセキュリティ特性を持つ可能性があります)。実装者が古い標準化されていないパラメータと新しい標準化されたパラメータを同等のものとして扱うと、相互運用性やセキュリティの問題が生じる可能性があります。欠陥を検出して修正するために標準化されていないパラメータを分析することは一般に良いことであり、要素名に区別がなくなることによってそれが妨げられることは意図していません。もともと標準化されていなかったパラメータやプロトコル要素が標準化され、新しい形式に相互運用性やセキュリティ特性に影響する違いがある場合、実装が古い形式を新しい形式と同一のものとして扱うことは不適切です。

For similar considerations with regard to the "P-" convention in the Session Initiation Protocol, see [RFC5727].

Session Initiation Protocol における "P-" の慣習に関する同様の考察については、[RFC5727] を参照してください。

In some situations, segregating the parameter name space used in a given application protocol can be justified:

状況によっては、あるアプリケーションプロトコルで使われるパラメータの名前空間を分けることが正当化される場合があります。

1. When it is extremely unlikely that some parameters will ever be standardized. In this case, implementation-specific and private-use parameters could at least incorporate the organization's name (e.g., "ExampleInc-foo" or, consistent with [RFC4288], "VND.ExampleInc.foo") or primary domain name (e.g., "com.example.foo" or a Uniform Resource Identifier [RFC3986] such as "http://example.com/foo"). In rare cases, truly experimental parameters could be given meaningless names such as nonsense words, the output of a hash function, or Universally Unique Identifiers (UUIDs) [RFC4122].

1. 一部のパラメータが標準化される可能性が極めて低い場合。このとき、実装固有のパラメータや私的利用のパラメータには、少なくとも組織名 (たとえば "ExampleInc-foo"、または [RFC4288] に沿った "VND.ExampleInc.foo") やプライマリドメイン名 (たとえば "com.example.foo"、または "http://example.com/foo" のような Uniform Resource Identifier [RFC3986]) を含めることができます。まれなケースでは、真に実験的なパラメータに、無意味な単語、ハッシュ関数の出力、Universally Unique Identifier (UUID) [RFC4122] といった意味を持たない名前を付けることもできます。

2. When parameter names might have significant meaning. This case too is rare, since implementers can almost always find a synonym for an existing term (e.g., "urgency" instead of "priority") or simply invent a more creative name (e.g., "get-it-there-fast"). The existence of multiple similarly named parameters can be confusing, but this is true regardless if there is an attempt to segregate standardized and unstandardized parameters (e.g., "X-Priority" can be confused with "Urgency").

2. パラメータ名が重要な意味を持つ可能性がある場合。このケースもまれです。実装者は、ほとんどの場合、既存の用語の同義語 (たとえば "priority" の代わりに "urgency") を見つけるか、単により独創的な名前 (たとえば "get-it-there-fast") を考案できるからです。似た名前のパラメータが複数存在すると混乱を招く可能性がありますが、これは標準化されたパラメータと標準化されていないパラメータを分けようとするかどうかにかかわらず当てはまります (たとえば "X-Priority" は "Urgency" と混同される可能性があります)。

3. When parameter names need to be very short (e.g., as in [RFC5646] for language tags). In this case, it can be more efficient to assign numbers instead of human-readable names (e.g., as in [RFC2939] for DHCP options) and to leave a certain numeric range for implementation-specific extensions or private use (e.g., as with the codec numbers used with the Session Description Protocol [RFC4566]).

3. パラメータ名を非常に短くする必要がある場合 (たとえば、言語タグに関する [RFC5646] のように)。このとき、人間が読める名前の代わりに番号を割り当て (たとえば、DHCP オプションに関する [RFC2939] のように)、一定の数値範囲を実装固有の拡張や私的利用のために残しておく (たとえば、Session Description Protocol [RFC4566] で使われるコーデック番号のように) ほうが効率的な場合があります。

There are three primary objections to deprecating the "X-" convention as a best practice for application protocols:

アプリケーションプロトコルの最良の慣行として「X-」の慣習を廃止することには、主に3つの反対意見があります。

1. Implementers might mistake one parameter for another parameter that has a similar name; a rigid distinction such as an "X-" prefix can make this clear. However, in practice, implementers are forced to blur the distinction (e.g., by treating "X-foo" as a de facto standard), so it inevitably becomes meaningless.

1. 実装者は、あるパラメータを似た名前を持つ別のパラメータと取り違える可能性があります。「X-」接頭辞のような厳格な区別があれば、これを明確にできます。しかし実際には、実装者はその区別を曖昧にせざるを得ないため (たとえば "X-foo" を事実上の標準として扱うことによって)、区別は必然的に意味を失います。

2. Collisions are undesirable, and it would be bad for both a standardized parameter "foo" and a unstandardized parameter "foo" to exist simultaneously. However, names are almost always cheap, so an experimental, implementation-specific, or private-use name of "foo" does not prevent a standards development organization from issuing a similarly creative name such as "bar".

2. 衝突は望ましくなく、標準化されたパラメータ "foo" と標準化されていないパラメータ "foo" が同時に存在するのは好ましくありません。しかし、名前はほとんどの場合安価に用意できるため、実験的、実装固有、または私的利用の "foo" という名前があっても、標準化団体が "bar" のような同様に独創的な名前を発行することは妨げられません。

3. [BCP82] is entitled "Assigning Experimental and Testing Numbers Considered Useful" and therefore implies that the "X-" prefix is also useful for experimental parameters. However, BCP 82 addresses the need for protocol numbers when the pool of such numbers is strictly limited (e.g., DHCP options) or when a number is absolutely required even for purely experimental purposes (e.g., the Protocol field of the IP header). In almost all application protocols that make use of protocol parameters (including email headers, media types, HTTP headers, vCard parameters and properties, URNs, and LDAP field names), the name space is not limited or constrained in any way, so there is no need to assign a block of names for private use or experimental purposes (see also [BCP26]).

3. [BCP82] のタイトルは "Assigning Experimental and Testing Numbers Considered Useful" であり、したがって「X-」接頭辞も実験的なパラメータに有用であることを示唆しています。しかし BCP 82 が扱っているのは、番号のプールが厳しく制限されている場合 (たとえば DHCP オプション) や、純粋に実験的な目的であっても番号が絶対に必要な場合 (たとえば IP ヘッダの Protocol フィールド) におけるプロトコル番号の必要性です。プロトコルパラメータを利用するほぼすべてのアプリケーションプロトコル (電子メールヘッダ、メディアタイプ、HTTP ヘッダ、vCard のパラメータとプロパティ、URN、LDAP のフィールド名を含む) では、名前空間はまったく制限も制約もされていないため、私的利用や実験目的のために名前のブロックを割り当てる必要はありません ([BCP26] も参照してください)。

Therefore, it appears that segregating the parameter space into a standardized area and a unstandardized area has few, if any, benefits and has at least one significant cost in terms of interoperability.

したがって、パラメータ空間を標準化された領域と標準化されていない領域に分けることには、利点があるとしてもわずかであり、相互運用性の面では少なくとも1つの重大なコストがあると考えられます。

References

参考文献

Normative References

引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Informative References

参考引用

[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[BCP82] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.

[RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975.

[RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737, October 1977.

[RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743, December 1977.

[RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory oriented FTP commands", RFC 775, December 1980.

[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.

[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

[RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for internet messages", RFC 1154, April 1990.

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.

[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.

[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", RFC 3427, December 2002.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.

[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[RFC5064] Duerst, M., "The Archived-At Message Header Field", RFC 5064, December 2007.

[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.

[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.

[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.

[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.

Authors' Addresses

著者の連絡先

Peter Saint-Andre Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA

   Phone: +1-303-308-3282
   EMail: psaintan@cisco.com

Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA USA

   Phone: +1.408.246.8253
   EMail: dcrocker@bbiw.net
   URI:   http://bbiw.net

Mark Nottingham Rackspace

   EMail: mnot@mnot.net
   URI:   http://www.mnot.net