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

原文URL : https://datatracker.ietf.org/doc/html/rfc6648
タイトル : RFC 6648 - アプリケーションプロトコルでの「X-」プレフィックスと同様の構成の廃止
翻訳編集 : 自動生成

[要約] RFC 6648は、アプリケーションプロトコルでの「X-」接頭辞や類似の構造の非推奨化に関するものです。その目的は、これらの構造を廃止し、より一貫性のあるプロトコル設計を促進することです。

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.

このメモは、インターネットの現在のベストプラクティスを文書化したものです。

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.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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トラストの法的規定（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

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。」）を付けることにより、標準化されたパラメータと標準化されていないパラメータを区別してきました。「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]で説明されているように、 "P-"ヘッダーに関してSIPテクノロジーでも同様の進展が見られました。これらの変更の背後にある理由については、付録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-」または同様の構成の有無のみに基づいて、パラメータのステータスについていかなる仮定も行わず、パラメータに関する自動アクションを実行してはなりません。

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. それらが作成するすべてのパラメータが、標準化され、公開され、一般に展開され、または複数の実装にわたって使用可能になる可能性があると想定する必要があります。

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

2. 現在未使用であると考える理由がある意味のあるパラメーター名を使用する必要があります。

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

3. パラメータ名の前に「X-」または同様の構成体を付けないでください。

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. シンプルで明確な登録手順を定義する必要があります。

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

3. パラメータ名の形式に関係なく、すべての非プライベートパラメータの登録を義務付ける必要があります。

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-」接頭辞または同様の構造を持つパラメータは、標準化されていないものとして理解する必要があることを規定してはなりません。

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

6. 「X-」接頭辞または同様の構成のないパラメータは、標準化されたものとして理解する必要があることを規定してはなりません。

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で提供される推奨事項の結果として、実装は、標準化されたパラメーターが「安全」であると仮定してはなりません。

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、JD Falk、Ned Freed、Tony Finch、Randall Gellens、Tony Hansen、Ted Hardieのおかげで、ジョー・ヒルデブランド、アルフレッド・ホーネス、ポール・ホフマン、エリック・ジョンソン、スコット・ケリー、スコット・キッターマン、ジョン・クレンシン、グラハム・クライン、マレー・クチェラウィ、エリオット・リア、ジョン・レバイン、ビル・マッキヤン、アレクセイ・メルニコフ、サブラマニアン・ムーネサミー、キース・ムーア、ベン・ニヴェン・ジェンキンス、 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、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-」規約の始まりは、FTPパラメータ[RFC691]に関して1975年にブライアンハーヴェイが行った提案にあります。

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に登録して競合を回避する必要があります。別のもののパラメータ。パラメータを複数の文字にすることを許可し、最初の文字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]の発行以来、電子メールヘッダーフィールドに使用されており、次のように「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-」は、拡張フィールドの名前には使用されません。これにより、ユーザー定義フィールドに保護された名前のセットが提供されます。

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]）、ユニフォームリソース名（[ RFC3406]）、ライトウェイトディレクトリアクセスプロトコル（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 "コンストラクト（[RFC3427]が[RFC5727]によって廃止されたとき、セッション開始プロトコル" P- "ヘッダーに関して同様の変更が発生しました）。

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]では義務付けられていません。むしろ、それを使用することを選択する規約または各管理プロセスを参照するのは、各仕様による個別の選択です。特に、いくつかのスタンダードトラック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コミュニティは、「x-gzip」および「x-compress」メディアタイプで同じ経験をしました。 RFC2068]：

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]にも同様の例があり、「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ヘッダーフィールドも解析できますが、生成しないでください。

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

セッション開始プロトコルの「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. パラメータ名に重要な意味がある場合。ほとんどの場合、実装者は既存の用語の同義語（たとえば、「優先度」ではなく「緊急度」）を見つけることができるため、またはより創造的な名前を作成することができる（たとえば、「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]のように）、特定の数値範囲を実装固有の拡張またはプライベート使用（たとえば、セッション記述プロトコルで使用されるコーデック番号[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]は「実験番号とテスト番号の割り当てが有用と見なされる」というタイトルが付けられているため、「X-」接頭辞も実験パラメータに役立つことを意味します。ただし、BCP 82は、そのような番号のプールが厳密に制限されている場合（DHCPオプションなど）、または純粋に実験的な目的であっても絶対に必要な場合（IPヘッダーのプロトコルフィールドなど）に、プロトコル番号の必要性に対応します。プロトコルパラメーター（電子メールヘッダー、メディアタイプ、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.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

Informative References

参考引用

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

[BCP9] Bradner、S.、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。

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

[BCP26] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。

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

[BCP82] Narten、T。、「Assigning Testing and Testing Numbers考慮されたUseful」、BCP 82、RFC 3692、2004年1月。

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

[RFC691] Harvey、B。、「FTPのもう1つの試み」、RFC 691、1975年6月。

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

[RFC737] Harrenstien、K。、「FTP拡張：XSEN」、RFC 737、1977年10月。

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

[RFC743] Harrenstien、K。、「FTP拡張：XRSQ / XRCP」、RFC 743、1977年12月。

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

[RFC775] Mankins、D.、Franklin、D。、およびA. Owen、「ディレクトリ指向のFTPコマンド」、RFC 775、1980年12月。

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

[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。

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

[RFC1123] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。

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

[RFC1154] Robinson、D.およびR. Ullmann、「インターネットメッセージのエンコーディングヘッダーフィールド」、RFC 1154、1990年4月。

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

[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。

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

[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。

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

[RFC2047]ムーアK。、「MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのメッセージヘッダー拡張」、RFC 2047、1996年11月。

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

[RFC2068] Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、1997年1月。

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

[RFC2426] Dawson、F。、およびT. Howes、「vCard MIME Directory Profile」、RFC 2426、1998年9月。

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

[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2616、1999年6月。

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

[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。

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

[RFC2939] Droms、R。、「新しいDHCPオプションとメッセージタイプの定義のための手順とIANAガイドライン」、BCP 43、RFC 2939、2000年9月。

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

[RFC3406] Daigle、L.、van Gulik、D.、Iannella、R。、およびP. Faltstrom、「Uniform Resource Names（URN）Namespace Definition Mechanisms」、BCP 66、RFC 3406、2002年10月。

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

[RFC3427] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J。、およびB. Rosen、「セッション開始プロトコル（SIP）の変更プロセス」、RFC 3427、12月2002年

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

[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。

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

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。

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

[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「Universally Unique IDentifier（UUID）URN Namespace」、RFC 4122、2005年7月。

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

[RFC4288] Freed、N。およびJ. Klensin、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 4288、2005年12月。

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

[RFC4395] Hansen、T.、Hardie、T。、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、2006年2月。

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

[RFC4512] Zeilenga、K。、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：ディレクトリ情報モデル」、RFC 4512、2006年6月。

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

[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。

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

[RFC5064] Duerst、M。、「The Archived-At Message Header Field」、RFC 5064、2007年12月。

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

[RFC5451] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 5451、2009年4月。

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

[RFC5545] Desruisseaux、B。、「Internet Calendaring and Scheduling Core Object Specification（iCalendar）」、RFC 5545、2009年9月。

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

[RFC5646] Phillips、A。およびM. Davis、「Tags for Identificationing Languages」、BCP 47、RFC 5646、2009年9月。

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

[RFC5727] Peterson、J.、Jennings、C。、およびR. Sparks、「Session Initiation Protocol（SIP）およびReal-time Applications and Infrastructure Areaの変更プロセス」、BCP 67、RFC 5727、2010年3月。

Authors' Addresses

著者のアドレス

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

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

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