[要約] RFC 3864は、メッセージヘッダーフィールドの登録手続きに関する規定です。その目的は、新しいヘッダーフィールドの登録プロセスを定義し、インターネットメッセージの相互運用性を向上させることです。
Network Working Group G. Klyne
Request for Comments: 3864 Nine by Nine
BCP: 90 M. Nottingham
Category: Best Current Practice BEA
J. Mogul
HP Labs
September 2004
Registration Procedures for Message Header Fields
メッセージヘッダーフィールドの登録手順
Status of this Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.
この仕様では、インターネットメール、HTTP、NetNews、その他のアプリケーションで使用されるメッセージヘッダーフィールドの登録手順を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Structure of this Document . . . . . . . . . . . . . . . 3
1.2. Document Terminology and Conventions . . . . . . . . . . 4
2. Message Header Fields. . . . . . . . . . . . . . . . . . . . . 4
2.1. Permanent and Provisional Header Fields. . . . . . . . . 4
2.2. Definitions of Message Header Fields . . . . . . . . . . 5
2.2.1. Application-specific Message Header Fields. . . . 5
2.2.2. MIME Header Fields. . . . . . . . . . . . . . . . 6
3. Registry Usage Requirements. . . . . . . . . . . . . . . . . . 6
4. Registration Procedure . . . . . . . . . . . . . . . . . . . . 6
4.1. Header Field Specification . . . . . . . . . . . . . . . 7
4.2. Registration Templates . . . . . . . . . . . . . . . . . 7
4.2.1. Permanent Message Header Field Registration
Template. . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Provisional Message Header Field Submission
Template. . . . . . . . . . . . . . . . . . . . . 8
4.3. Submission of Registration . . . . . . . . . . . . . . . 10
4.4. Objections to Registration . . . . . . . . . . . . . . . 10
4.5. Change Control . . . . . . . . . . . . . . . . . . . . . 11
4.6. Comments on Header Definitions . . . . . . . . . . . . . 12
4.7. Location of Header Field Registry. . . . . . . . . . . . 12
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
This specification defines registration procedures for the message header field names used by Internet mail, HTTP, newsgroup feeds and other Internet applications. It is not intended to be a replacement for protocol-specific registries, such as the SIP registry [30].
この仕様では、インターネットメール、HTTP、ニュースグループフィード、その他のインターネットアプリケーションで使用されるメッセージヘッダーフィールド名の登録手順を定義します。SIPレジストリ[30]など、プロトコル固有のレジストリに代わるものではありません。
Benefits of a central registry for message header field names include:
メッセージヘッダーフィールド名の中央レジストリの利点は次のとおりです。
o providing a single point of reference for standardized and widely-used header field names;
o 標準化された広く使用されているヘッダーフィールド名の単一の参照ポイントを提供します。
o providing a central point of discovery for established header fields, and easy location of their defining documents;
o 確立されたヘッダーフィールドの中心的な発見ポイントを提供し、定義する文書の簡単な場所を提供します。
o discouraging multiple definitions of a header field name for different purposes;
o 異なる目的でヘッダーフィールド名の複数の定義を阻止します。
o helping those proposing new header fields discern established trends and conventions, and avoid names that might be confused with existing ones;
o 新しいヘッダーフィールドを提案する人々が確立された傾向と慣習を識別し、既存の傾向と混同される可能性のある名前を避けるのを支援します。
o encouraging convergence of header field name usage across multiple applications and protocols.
o 複数のアプリケーションとプロトコルにわたるヘッダーフィールド名の使用の収束を促進します。
The primary specification for Internet message header fields in email is the Internet mail message format specification, RFC 2822 [4]. HTTP/1.0 [10] and HTTP/1.1 [24] define message header fields (respectively, the HTTP-header and message-header protocol elements) for use with HTTP. RFC 1036 [5] defines message header elements for use with Netnews feeds. These specifications also define a number of header fields, and provide for extension through the use of new field-names.
電子メール内のインターネットメッセージヘッダーフィールドの主要な仕様は、インターネットメールメッセージ形式の仕様、RFC 2822 [4]です。HTTP/1.0 [10]およびHTTP/1.1 [24]は、HTTPで使用するためのメッセージヘッダーフィールド（それぞれHTTP-HeaderおよびMessage-Headerプロトコル要素）を定義します。RFC 1036 [5]は、NetNewsフィードで使用するメッセージヘッダー要素を定義します。これらの仕様は、多くのヘッダーフィールドを定義し、新しいフィールド名を使用して拡張を提供します。
There are many other Internet standards track documents that define additional header fields for use within the same namespaces, notably MIME [11] and related specifications. Other Internet applications that use MIME, such as SIP (RFC 3261 [30]) may also use many of the same header fields (but note that IANA maintains a separate registry of header fields used with SIP).
他の多くのインターネット標準は、同じ名前空間、特にMIME [11]および関連する仕様内で使用する追加のヘッダーフィールドを定義するドキュメントを追跡します。SIP（RFC 3261 [30]）などのMIMEを使用する他のインターネットアプリケーションは、同じヘッダーフィールドの多くを使用する場合があります（ただし、IANAはSIPで使用されるヘッダーフィールドの個別のレジストリを維持していることに注意してください）。
Although in principle each application defines its own set of valid header fields, exchange of messages between applications (e.g., mail to Netnews gateways), common use of MIME encapsulation, and the possibility of common processing for various message types (e.g., a common message archive and retrieval facility) makes it desirable to have a common point of reference for standardized and proposed header fields. Listing header fields together reduces the chance of an accidental collision, and helps implementers find relevant information. The message header field registries defined here serve that purpose.
原則として、各アプリケーションは有効なヘッダーフィールドの独自のセット、アプリケーション間のメッセージの交換（NetNewsゲートウェイへのメールなど）、MIMEカプセル化の一般的な使用、およびさまざまなメッセージタイプの一般的な処理の可能性を定義しています（例：一般的なメッセージ。アーカイブおよび検索施設）により、標準化および提案されたヘッダーフィールドの共通の参照ポイントを持つことが望ましい。ヘッダーフィールドを一緒にリストすると、偶発的な衝突の可能性が減り、実装者が関連情報を見つけるのに役立ちます。ここで定義されているメッセージヘッダーフィールドレジストリは、その目的に役立ちます。
Section 2 discusses the purpose of this specification, and indicates some sources of information about defined message header fields.
セクション2では、この仕様の目的について説明し、定義されたメッセージヘッダーフィールドに関する情報のソースを示します。
Section 4 defines the message header field name repositories, and sets out requirements and procedures for creating entries in them.
セクション4では、メッセージヘッダーのフィールド名リポジトリを定義し、それらにエントリを作成するための要件と手順を設定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されているように解釈される。
Many message header fields are defined in standards-track documents, which means they have been subjected to a process of community review and achieved consensus that they provide a useful and well-founded capability, or represent a widespread use of which developers should be aware. Some are defined for experimental use, typically indicating consensus regarding their purpose but not necessarily concerning their technical details. Many others have been defined and adopted ad-hoc to address a locally occurring requirement; some of these have found widespread use.
多くのメッセージヘッダーフィールドは、標準トラックドキュメントで定義されています。つまり、コミュニティレビューのプロセスにさらされ、有用で十分に根拠のある機能を提供するか、開発者が意識するべき広範な使用を表すコンセンサスを達成しました。いくつかは実験的な使用のために定義されており、通常はその目的に関するコンセンサスを示していますが、必ずしも技術的な詳細に関してはそうではありません。他の多くは、局所的に発生する要件に対処するために、アドホックを定義および採用しています。これらのいくつかは、広範囲にわたる使用を発見しました。
The catalogues defined here are intended to cater for all of these header fields, while maintaining a clear distinction and status for those which have community consensus. To this end, two repositories are defined:
ここで定義されているカタログは、これらのヘッダーフィールドのすべてに対応することを目的としていますが、コミュニティコンセンサスのある人に明確な区別とステータスを維持します。この目的のために、2つのリポジトリが定義されています。
o A Permanent Message Header Field Registry, intended for headers defined in IETF standards-track documents, those that have achieved a comparable level of community review, or are generally recognized to be in widespread use. The assignment policy for such registration is "Specification Required", as defined by RFC 2434 [3], where the specification must be published in an RFC (standards-track, experimental, informational or historic), or as an "Open Standard" in the sense of RFC 2026, section 7 [1].
o IETF標準トラックドキュメントで定義されているヘッダーを対象とした永続的なメッセージヘッダーフィールドレジストリ、同等のレベルのコミュニティレビューを達成した、または一般的に広く使用されていることが認識されているものです。RFC 2434 [3]で定義されているように、そのような登録の割り当てポリシーは「仕様が必要」です。ここで、仕様はRFC（標準トラック、実験、情報史、または歴史的）で公開するか、または「オープン標準」として公開する必要があります。RFC 2026の感覚、セクション7 [1]。
o A Provisional Message Header Field Repository, intended for any header field proposed by any developer, without making any claim about its usefulness or the quality of its definition. The policy for recording these is "Private Use", per RFC 2434 [3].
o 開発者が提案するヘッダーフィールドを対象とした暫定メッセージヘッダーフィールドリポジトリは、その有用性やその定義の品質について主張することなく。これらを記録するためのポリシーは、RFC 2434 [3]に従って「私的使用」です。
Neither repository tracks the syntax, semantics or type of field-values. Only the field-names, applicable protocols and status are registered; all other details are specified in the defining documents referenced by repository entries. Significant updates to such references (e.g., the replacement of a Proposed Standard RFC by a Draft Standard RFC, but not necessarily the revision of an Internet-draft) SHOULD be accompanied by updates to the corresponding repository entries.
どちらのリポジトリも、構文、セマンティクス、またはフィールド値のタイプを追跡しません。フィールド名、適用可能なプロトコル、ステータスのみが登録されています。他のすべての詳細は、リポジトリエントリで参照される定義文書で指定されています。このような参照の大幅な更新（例：提案された標準RFCのドラフト標準RFCによる置換は、必ずしもインターネットドラフトの改訂版ではありません）には、対応するリポジトリエントリへの更新を添付する必要があります。
RFC 2822 [4] defines a general syntax for message headers, and also defines a number of fields for use with Internet mail. HTTP/1.0 [10] and HTTP/1.1 [24] do likewise for HTTP. Additional field names are defined in a variety of standards-track RFC documents, including: RFC 1036 [5], RFC 1496 [6], RFC 1505 [7], RFC 1864 [9], RFC 2156 [14], RFC 2183 [15], RFC 2045 [11], RFC 2046 [12], RFC 2557 [23], RFC 2227 [16], RFC 2231 [17], RFC 2298 [18], RFC 2369 [19], RFC 2421 [21], RFC 2518 [22], RFC 2617 [25], RFC 2821 [26], RFC 2912 [27], RFC 2919 [28], RFC 2965 [29], and RFC 3282 [31].
RFC 2822 [4]は、メッセージヘッダーの一般的な構文を定義し、インターネットメールで使用する多くのフィールドを定義します。HTTP/1.0 [10]およびHTTP/1.1 [24]は、HTTPについても同様に行います。追加のフィールド名は、RFC 1036 [5]、RFC 1496 [6]、RFC 1505 [7]、RFC 1864 [9]、RFC 2156 [14]、RFC 2183を含む、さまざまな標準トラックRFCドキュメントで定義されています。15]、RFC 2045 [11]、RFC 2046 [12]、RFC 2557 [23]、RFC 2227 [16]、RFC 2231 [17]、RFC 2298 [18]、RFC 2369 [19]、RFC 2421 [21]、RFC 2518 [22]、RFC 2617 [25]、RFC 2821 [26]、RFC 2912 [27]、RFC 2919 [28]、RFC 2965 [29]、およびRFC 3282 [31]。
Internet applications that use similar message headers include Internet mail [26] [4], NNTP newsgroup feeds [5], HTTP web access [24] and any other that uses MIME [11] encapsulation of message content.
同様のメッセージヘッダーを使用するインターネットアプリケーションには、インターネットメール[26] [4]、NNTPニュースグループフィード[5]、HTTP Web Access [24]、およびメッセージコンテンツのMIME [11]のカプセル化を使用するその他のものが含まれます。
In some cases (notably HTTP [24]), the header syntax and usage is redefined for the specific application. This registration is concerned only with the allocation and specification of field names, and not with the details of header implementation in specific protocols.
場合によっては（特にHTTP [24]）、特定のアプリケーションに対してヘッダー構文と使用法が再定義されます。この登録は、フィールド名の割り当てと仕様のみに関係しており、特定のプロトコルでのヘッダー実装の詳細ではありません。
In some cases, the same field name may be specified differently (by different documents) for use with different application protocols; e.g., The Date: header field used with HTTP has a different syntax than the Date: used with Internet mail. In other cases, a field name may have a common specification across multiple protocols (ignoring protocol-specific lexical and character set conventions); e.g., this is generally the case for MIME header fields with names of the form 'Content-*'.
場合によっては、異なるアプリケーションプロトコルで使用するために、同じフィールド名が異なる（異なるドキュメントによって）指定される場合があります。たとえば、日付：HTTPで使用されるヘッダーフィールドには、インターネットメールで使用される日付とは異なる構文があります。それ以外の場合、フィールド名は複数のプロトコルにわたって共通の仕様を持つ場合があります（プロトコル固有の語彙および文字セットの規則を無視します）。たとえば、これは一般に、「コンテンツ*」という形式の名前を持つMIMEヘッダーフィールドの場合です。
Thus, we need to accommodate application-specific fields, while wishing to recognize and promote (where appropriate) commonality of other fields across multiple applications. Common repositories are used for all applications, and each registered header field specifies the application protocol for which the corresponding definition applies. A given field name may have multiple registry entries for different protocols; in the Permanent Message Header Field registry, a given header field name may be registered only once for any given protocol. (In some cases, the registration may reference several defining documents.)
したがって、複数のアプリケーションで他のフィールドの（必要に応じて）共通性を認識し、促進することを望みながら、アプリケーション固有のフィールドに対応する必要があります。一般的なリポジトリはすべてのアプリケーションに使用され、各登録ヘッダーフィールドは、対応する定義が適用されるアプリケーションプロトコルを指定します。特定のフィールド名には、異なるプロトコルの複数のレジストリエントリがあります。永続的なメッセージヘッダーフィールドレジストリでは、特定のプロトコルに対して特定のヘッダーフィールド名を1回だけ登録できます。（場合によっては、登録がいくつかの定義文書を参照する場合があります。）
Some header fields with names of the form Content-* are associated with the MIME data object encapsulation and labelling framework. These header fields can meaningfully be applied to a data object separately from the protocol used to carry it.
フォームコンテンツの名前を持つ一部のヘッダーフィールド - *は、MIMEデータオブジェクトのカプセル化とラベル付けフレームワークに関連付けられています。これらのヘッダーフィールドは、それを運ぶために使用されるプロトコルとは別にデータオブジェクトに有意に適用できます。
MIME is used with email messages and other protocols that specify a MIME-based data object format. MIME header fields used with such protocols are defined in the registry with the protocol "mime", and as such are presumed to be usable in conjunction with any protocol that conveys MIME objects.
MIMEは、MIMEベースのデータオブジェクト形式を指定する電子メールメッセージやその他のプロトコルで使用されます。このようなプロトコルで使用されるMIMEヘッダーフィールドは、プロトコル「MIME」でレジストリで定義されているため、MIMEオブジェクトを伝えるプロトコルと組み合わせて使用できると推定されます。
Other protocols do not convey MIME objects, but define a number of header fields with similar names and functions to MIME. Notably, HTTP defines a number of entity header fields that serve a purpose in HTTP similar to MIME header fields in email. Some of these header fields have the same names and similar functions to their MIME counterparts (though there are some variations). Such header fields must be registered separately for any non-MIME-carrying protocol with which they may be used.
他のプロトコルはMIMEオブジェクトを伝えませんが、MIMEと同様の名前と機能を持つ多くのヘッダーフィールドを定義します。特に、HTTPは、電子メールのMIMEヘッダーフィールドと同様のHTTPで目的を果たす多くのエンティティヘッダーフィールドを定義しています。これらのヘッダーフィールドのいくつかは、Mimeのカウンターパートと同じ名前と同様の機能を持っています（いくつかのバリエーションがあります）。このようなヘッダーフィールドは、使用される可能性のある非mimeキャリープロトコルのために個別に登録する必要があります。
It is poor practice to reuse a header field name from another protocol simply because the fields have similar (even "very similar") meanings. Protocols should share header field names only when their meanings are identical in all foreseeable circumstances. In particular, new header field names of the form Content-* should not be defined for non-MIME-carrying protocols unless their specification is exactly the same as in MIME.
フィールドが類似した（「非常に類似した」）意味を持っているという理由だけで、別のプロトコルからヘッダーフィールド名を再利用するのは貧弱な慣行です。プロトコルは、すべての予見可能な状況で意味が同一である場合にのみ、ヘッダーフィールド名を共有する必要があります。特に、形式のコンテンツの新しいヘッダーフィールド名 - *は、それらの仕様がMIMEとまったく同じでない限り、非MIME-Carryingプロトコルに対して定義されるべきではありません。
RFCs defining new header fields for Internet mail, HTTP, or MIME MUST include appropriate header registration template(s) (as given in Section 4.2) for all headers defined in the document in their IANA considerations section. Use of the header registry MAY be mandated by other protocol specifications, however, in the absence of such a mandate use of the registry is not required.
Internet Mail、HTTP、またはMIME用の新しいヘッダーフィールドを定義するRFCには、IANAの考慮事項セクションのドキュメントで定義されているすべてのヘッダーについて、適切なヘッダー登録テンプレート（セクション4.2に記載）を含める必要があります。ヘッダーレジストリの使用は、他のプロトコル仕様によって義務付けられる場合がありますが、レジストリのこのような委任状の使用が必要ありません。
The procedure for registering a message header field is:
メッセージヘッダーフィールドを登録する手順は次のとおりです。
1. Construct a header field specification
1. ヘッダーフィールド仕様を作成します
2. Prepare a registration template
2. 登録テンプレートを準備します
3. Submit the registration template
3. 登録テンプレートを送信します
Registration of a new message header field starts with construction of a proposal that describes the syntax, semantics and intended use of the field. For entries in the Permanent Message Header Field Registry, this proposal MUST be published as an RFC, or as an Open Standard in the sense described by RFC 2026, section 7 [1].
新しいメッセージヘッダーフィールドの登録は、構文、セマンティクス、およびフィールドの使用を目的とする提案の構築から始まります。永続的なメッセージヘッダーフィールドレジストリのエントリの場合、この提案はRFCとして、またはRFC 2026、セクション7 [1]で記述された意味でのオープン標準として公開されなければなりません。
A registered field name SHOULD conform at least to the syntax defined by RFC 2822 [4], section 3.6.8.
登録されたフィールド名は、少なくともRFC 2822 [4]、セクション3.6.8で定義された構文に適合する必要があります。
Further, the "." character is reserved to indicate a naming sub-structure and MUST NOT be included in any registered field name. Currently, no specific sub-structure is defined; if used, any such structure MUST be defined by a standards track RFC document.
さらに、「。」キャラクターは、命名サブ構造を示すために予約されており、登録されたフィールド名に含めてはなりません。現在、特定のサブ構造は定義されていません。使用する場合、そのような構造は標準トラックRFCドキュメントで定義する必要があります。
Header field names may sometimes be used in URIs, URNs and/or XML. To comply with the syntactic constraints of these forms, it is recommended that characters in a registered field name are restricted to those that can be used without escaping in a URI [20] or URN [13], and that are also legal in XML [32] element names.
ヘッダーフィールド名は、URI、URN、XMLで使用される場合があります。これらのフォームの構文制約に準拠するために、登録されたフィールド名の文字は、URI [20]またはuRN [13]で逃げることなく使用できる文字に制限され、XMLでも合法であることをお勧めします[32]要素名。
Thus, for maximum flexibility, header field names SHOULD further be restricted to just letters, digits, hyphen ('-') and underscore ('_') characters, with the first character being a letter or underscore.
したがって、最大限の柔軟性のために、ヘッダーフィールド名は、文字、数字、ハイフン（ ' - '）、およびアンダースコア（「_ '）文字だけに制限され、最初の文字は文字またはアンダースコアです。
The registration template for a message header field may be contained in the defining document, or prepared separately.
メッセージヘッダーフィールドの登録テンプレートは、定義ドキュメントに含まれるか、別々に作成される場合があります。
A header registered in the Permanent Message Header Field Registry MUST be published as an RFC or as an "Open Standard" in the sense described by RFC 2026, section 7 [1], and MUST have a name which is unique among all the registered permanent field names that may be used with the same application protocol.
永続的なメッセージヘッダーフィールドレジストリに登録されているヘッダーは、RFC 2026、セクション7 [1]で記述された意味でRFCまたは「オープン標準」として公開する必要があり、登録されたすべての永久の中で一意の名前が必要です。同じアプリケーションプロトコルで使用できるフィールド名。
The registration template has the following form.
登録テンプレートには次の形式があります。
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:
永久メッセージヘッダーフィールド登録テンプレート：
Header field name: The name requested for the new header field. This MUST conform to the header field specification details noted in Section 4.1.
ヘッダーフィールド名：新しいヘッダーフィールドに要求された名前。これは、セクション4.1に記載されているヘッダーフィールド仕様の詳細に準拠する必要があります。
Applicable protocol: Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616), "netnews" (RFC 1036), or cite any other standards-track RFC defining the protocol with which the header is intended to be used.
該当するプロトコル：「Mail」（RFC 2822）、「MIME」（RFC 2045）、「HTTP」（RFC 2616）、「NetNews」（RFC 1036）を指定するか、プロトコルを定義するその他の標準トラックRFCを指定します。ヘッダーは使用することを目的としています。
Status: Specify "standard", "experimental", "informational", "historic", "obsoleted", or some other appropriate value according to the type and status of the primary document in which it is defined. For non-IETF specifications, those formally approved by other standards bodies should be labelled as "standard"; others may be "informational" or "deprecated" depending on the reason for registration.
ステータス：「標準」、「実験」、「情報」、「歴史的」、「廃止」、または定義されている主要なドキュメントのタイプとステータスに従って、その他の適切な値を指定します。非etf仕様の場合、他の標準団体によって正式に承認されたものには「標準」とラベル付けされる必要があります。その他は、登録の理由に応じて「情報」または「非推奨」である場合があります。
Author/Change controller: For Internet standards-track, state "IETF". For other open standards, give the name of the publishing body (e.g., ANSI, ISO, ITU, W3C, etc.). For other specifications, give the name, email address, and organization name of the primary specification author. A postal address, home page URI, telephone and fax numbers may also be included.
著者/変更コントローラー：インターネット標準トラックの場合、「IETF」状態。その他のオープン標準については、出版機関の名前（ANSI、ISO、ITU、W3Cなど）を指定します。その他の仕様については、プライマリ仕様著者の名前、メールアドレス、および組織名を指定します。郵便アドレス、ホームページURI、電話、ファックス番号も含めることができます。
Specification document(s): Reference to document that specifies the header for use with the indicated protocol, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections MAY also be included, but is not required.
仕様文書：指定されたプロトコルで使用するヘッダーを指定するドキュメントへの参照。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことができます。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
Related information: Optionally, citations to additional documents containing further relevant information. (This part of the registry may also be used for IESG comments.) Where a primary specification refers to another document for substantial technical detail, the referenced document is usefully mentioned here.
関連情報：オプションで、関連する情報を含む追加のドキュメントの引用。（レジストリのこの部分は、IESGコメントにも使用できます。）主要な仕様では、実質的な技術的詳細については別のドキュメントを参照する場合、参照されるドキュメントはここで有用に言及されています。
Registration as a Provisional Message Header Field does not imply any kind of endorsement by the IETF, IANA or any other body.
暫定メッセージヘッダーフィールドとしての登録は、IETF、IANA、またはその他の機関によるいかなる種類の承認も意味するものではありません。
The main requirements for a header field to be included in the provisional repository are that it MUST have a citable specification, and there MUST NOT be a corresponding entry (with same field name and protocol) in the permanent header field registry.
暫定リポジトリに含まれるヘッダーフィールドの主な要件は、引用可能な仕様が必要であることであり、永続的なヘッダーフィールドレジストリに対応するエントリ（同じフィールド名とプロトコルを使用）を存在してはなりません。
The specification SHOULD indicate an email address for sending technical comments and discussion of the proposed message header.
仕様は、提案されたメッセージヘッダーの技術的なコメントと議論のための電子メールアドレスを示す必要があります。
The submission template has the following form.
提出テンプレートには次の形式があります。
PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:
暫定メッセージヘッダーフィールド送信テンプレート：
Header field name: The name proposed for the new header field. This SHOULD conform to the field name specification details noted in Section 4.1.
ヘッダーフィールド名：新しいヘッダーフィールドに提案された名前。これは、セクション4.1に記載されているフィールド名の仕様の詳細に準拠する必要があります。
Applicable protocol: Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616), "netnews" (RFC 1036), or cite any other standards-track RFC defining the protocol with which the header is intended to be used.
該当するプロトコル：「Mail」（RFC 2822）、「MIME」（RFC 2045）、「HTTP」（RFC 2616）、「NetNews」（RFC 1036）を指定するか、プロトコルを定義するその他の標準トラックRFCを指定します。ヘッダーは使用することを目的としています。
Status: Specify: "provisional". This will be updated if and when the header registration is subsequently moved to the permanent registry.
ステータス：指定：「暫定」。これは、その後、ヘッダー登録が永続的なレジストリに移動された場合に更新されます。
Author/Change controller: The name, email address, and organization name of the submission author, who may authorize changes to or retraction of the repository entry. A postal address, home page URI, telephone and fax numbers may also be included. If the proposal comes from a standards body working group, give the name and home page URI of the working group, and an email address for discussion of or comments on the specification.
著者/変更コントローラー：リポジトリエントリの変更または撤回を許可する可能性のある提出著者の名前、メールアドレス、および組織名。郵便アドレス、ホームページURI、電話、ファックス番号も含めることができます。提案がStandards Body Working Groupから来ている場合は、ワーキンググループの名前とホームページURI、および仕様に関する議論またはコメントのための電子メールアドレスを提供します。
Specification document(s): Reference to document that specifies the header for use with the indicated protocol. The document MUST be an RFC, a current Internet-draft or the URL of a publicly accessible document (so IANA can verify availability of the specification). An indication of the relevant sections MAY also be included, but is not required.
仕様文書：指定されたプロトコルで使用するヘッダーを指定するドキュメントへの参照。このドキュメントは、RFC、現在のインターネットドラフト、または公開されているドキュメントのURLである必要があります（IANAは仕様の可用性を確認できます）。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
NOTE: if the specification is available in printed form only, then an Internet draft containing full reference to the paper document should be published and cited in the registration template. The paper specification MAY be cited under related information.
注：仕様が印刷された形式でのみ利用可能である場合、ペーパードキュメントへの完全な参照を含むインターネットドラフトを登録テンプレートに公開して引用する必要があります。紙の仕様は、関連情報の下で引用される場合があります。
Related information: Optionally, citations to additional documents containing further relevant information.
関連情報：オプションで、関連する情報を含む追加のドキュメントの引用。
The registration template is submitted for incorporation in one of the IANA message header field repositories by one of the following methods:
登録テンプレートは、次の方法のいずれかによってIANAメッセージヘッダーフィールドリポジトリの1つに組み込まれるために提出されます。
o An IANA considerations section in a defining RFC, calling for registration of the message header and referencing information as required by the registration template within the same document. Registration of the header is then processed as part of the RFC publication process.
o RFCを定義するIANAの考慮事項セクション。メッセージヘッダーの登録を求め、同じドキュメント内の登録テンプレートで要求される情報を参照します。ヘッダーの登録は、RFC出版プロセスの一部として処理されます。
o Send a copy of the template to the designated email discussion list [33] [34]. Allow a reasonable period - at least 2 weeks - for discussion and comments, then send the template to IANA at the designated email address [35]. IANA will publish the template information if the requested name and the specification document meet the criteria noted in Section 4.1 and Section 4.2.2, unless the IESG or their designated expert have requested that it not be published (see Section 4.4). IESG's designated expert should confirm to IANA that the registration criteria have been satisfied.
o テンプレートのコピーを指定された電子メールディスカッションリスト[33] [34]に送信します。少なくとも2週間は、ディスカッションとコメントのために合理的な期間を許可し、指定された電子メールアドレス[35]でIANAにテンプレートを送信します。IESGまたはその指定専門家が公開されないように要求しない限り、IANAは要求された名前と仕様文書がセクション4.1とセクション4.2.2に記載されている基準を満たしている場合、テンプレート情報を公開します（セクション4.4を参照）。IESGの指定された専門家は、登録基準が満たされていることをIANAに確認する必要があります。
When a new entry is recorded in the permanent message header field registry, IANA will remove any corresponding entries (with the same field name and protocol) from the provisional registry.
永続的なメッセージヘッダーフィールドレジストリに新しいエントリが記録されると、IANAは暫定レジストリから対応するエントリ（同じフィールド名とプロトコルを使用）を削除します。
Listing of an entry in the provisional repository should not be lightly refused. An entry MAY be refused if there is some credible reason to believe that such registration will be harmful. In the absence of such objection, IANA SHOULD allow any registration that meets the criteria set out in Section 4.1 and Section 4.2.2. Some reasonable grounds for refusal might be:
暫定リポジトリのエントリのリストは、軽く拒否されるべきではありません。そのような登録が有害であると信じるいくつかの信頼できる理由がある場合、エントリは拒否される場合があります。このような異議がない場合、IANAはセクション4.1およびセクション4.2.2に記載されている基準を満たす登録を許可する必要があります。拒否の合理的な根拠は次のとおりです。
o There is IETF consensus that publication is considered likely to harm the Internet technical infrastructure in some way.
o IETFのコンセンサスは、出版物が何らかの形でインターネットの技術インフラストラクチャに害を及ぼす可能性が高いと考えられているということです。
o Disreputable or frivolous use of the registration facilities.
o 登録施設の不名誉または軽薄な使用。
o The proposal is sufficiently lacking in purpose, or misleading about its purpose, that it can be held to be a waste of time and effort.
o この提案は、目的に十分に不足しているか、その目的について誤解を招くように、時間と労力の無駄であると考えられる可能性があります。
o Conflict with some current IETF activity.
o 現在のIETFアクティビティとの対立。
Note that objections or disagreements about technical detail are not, of themselves, considered grounds to refuse listing in the provisional repository. After all, one of its purposes is to allow developers to communicate with a view to combining their ideas, expertise and energy to the maximum benefit of the Internet community.
技術的な詳細に関する異議や意見の相違は、それ自体では、暫定リポジトリのリストを拒否する根拠とは見なされないことに注意してください。結局のところ、その目的の1つは、開発者が自分のアイデア、専門知識、エネルギーをインターネットコミュニティの最大の利益と組み合わせるという観点からコミュニケーションをとることを可能にすることです。
Publication in an RFC or other form of Open Standard document (per RFC 2026 [1], section 7) is sufficient grounds for publication in the permanent registry.
RFCまたはその他の形式のオープン標準ドキュメント（RFC 2026 [1]、セクション7）への出版は、恒久的なレジストリに公開するのに十分な根拠です。
To assist IANA in determining whether or not there is a sustainable objection to any registration, IESG nominates a designated expert to liaise with IANA about new registrations. For the most part, the designated expert's role is to confirm to IANA that the registration criteria have been satisfied.
IANAが登録に対して持続可能な異議があるかどうかを判断するのを支援するために、IESGは、指定された専門家を新しい登録についてIANAと連絡させるために指名します。ほとんどの場合、指定された専門家の役割は、登録基準が満たされていることをIANAに確認することです。
The IESG or their designated expert MAY require any change or commentary to be attached to any registry entry.
IESGまたはその指定された専門家は、レジストリエントリに添付される変更または解説を必要とする場合があります。
The IESG is the final arbiter of any objection.
IESGは、異議の最後の仲裁人です。
Change control of a header field registration is subject to the same condition as the initial registration; i.e., publication (or reclassification) of an Open Standards specification for a Permanent Message Header Field, or on request of the indicated author/change controller for a Provisional Message Header (like the original submission, subject to review on the designated email discussion list [33].)
ヘッダーフィールド登録の変更制御は、最初の登録と同じ条件の対象となります。すなわち、永続的なメッセージヘッダーフィールドのオープン標準仕様の出版（または再分類）、または指定された著者/変更コントローラーの要求に応じて、暫定メッセージヘッダーの変更コントローラー（元の提出など、指定された電子メールディスカッションリストでレビューする場合があります[33]。）
A change to a permanent message header field registration MAY be requested by the IESG.
IESGによって、永続的なメッセージヘッダーフィールド登録への変更が要求される場合があります。
A change to or retraction of any Provisional Message Header Field Repository entry MAY be requested by the IESG or designated expert.
IESGまたは指定された専門家によって、暫定メッセージヘッダーフィールドリポジトリエントリの変更または撤回が要求される場合があります。
IANA MAY remove any Provisional Message Header Field Repository entry whose corresponding specification document is no longer available (e.g., expired Internet-draft, or URL not resolvable). Anyone may notify IANA of any such cases by sending an email to the designated email address [35]. Before removing an entry for this reason, IANA SHOULD contact the registered Author/Change controller to determine whether a replacement for the specification document (consistent with the requirements of section Section 4.2.2) is available.
IANAは、対応する仕様ドキュメントが使用できなくなった暫定メッセージヘッダーフィールドリポジトリエントリを削除する場合があります（例：有効期限が切れたインターネットドラフト、またはURLが解決できない）。誰でも、指定されたメールアドレス[35]にメールを送信することにより、IANAにそのようなケースを通知することができます。この理由でエントリを削除する前に、IANAは登録された著者/変更コントローラーに連絡して、仕様文書の交換（セクション4.2.2の要件と一致）が利用可能かどうかを判断する必要があります。
It is intended that entries in the Permanent Message Header Field Registry may be used in the construction of URNs (per RFC 2141 [13]) which have particular requirements for uniqueness and persistence (per RFC 1737 [8]). Therefore, once an entry is made in the Permanent Message Header Registry, the combination of the header name and applicable protocol MUST NOT subsequently be registered for any other purpose. (This is not to preclude revision of the applicable specification(s) within the appropriate IETF Consensus rules, and corresponding updates to the specification citation in the header registration.)
永続的なメッセージヘッダーフィールドレジストリのエントリは、URN（RFC 2141 [13]ごとに）の構築に使用されることを目的としています。したがって、永続的なメッセージヘッダーレジストリでエントリが作成されると、ヘッダー名と適用可能なプロトコルの組み合わせを、その後、他の目的で登録する必要はありません。（これは、適切なIETFコンセンサスルール内の該当する仕様の改訂を排除するものではなく、ヘッダー登録の仕様引用に対応する更新を排除することではありません。）
Comments on proposed registrations should be sent to the designated email discussion list [33].
提案された登録に関するコメントは、指定された電子メールディスカッションリスト[33]に送信する必要があります。
The message header field registry is accessible from IANA's web site http://www.iana.org/assignments/message-headers/ message-header-index.html
メッセージヘッダーフィールドレジストリは、IANAのWebサイトhttp://www.iana.org/assignments/message-headers/ message-header-index.htmlからアクセスできます。
This specification calls for:
この仕様には次のことが必要です。
o A new IANA registry for permanent message header fields per Section 4 of this document. The policy for inclusion in this registry is described in Section 4.1 and Section 4.2.1.
o このドキュメントのセクション4ごとに、永続的なメッセージヘッダーフィールドの新しいIANAレジストリ。このレジストリに含めるためのポリシーは、セクション4.1およびセクション4.2.1で説明されています。
o A new IANA repository listing provisional message header fields per Section 4 of this document. The policy for inclusion in this registry is described in Section 4.1 and Section 4.2.2.
o このドキュメントのセクション4ごとに、新しいIANAリポジトリリスト暫定メッセージヘッダーフィールド。このレジストリに含めるためのポリシーは、セクション4.1およびセクション4.2.2で説明されています。
o IESG appoints a designated expert to advise IANA whether registration criteria for proposed registrations have been satisfied.
o IESGは、提案された登録の登録基準が満たされているかどうかをIANAに助言するために指定された専門家を任命します。
No initial registry entries are provided.
初期レジストリエントリは提供されていません。
No security considerations are introduced by this specification beyond those already inherent in the use of message headers.
この仕様では、メッセージヘッダーの使用にすでに固有のものを超えて、この仕様によってセキュリティ上の考慮事項は導入されていません。
The shape of the registries described here owes much to energetic discussion of previous versions by many denizens of the IETF-822 mailing list.
ここで説明するレジストリの形状は、IETF-822メーリングリストの多くの住人による以前のバージョンのエネルギッシュな議論に大いに負っています。
The authors also gratefully acknowledge the contribution of those who provided valuable feedback on earlier versions of this memo: Charles Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle Cotton.
著者はまた、このメモの以前のバージョンに関する貴重なフィードバックを提供した人々の貢献に感謝します：チャールズ・リンジー、デイブ・クロッカー、ピート・レストニック、ジェイコブ・パルメ、ネッド・フリーム、ミシェル・コットン。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[4] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[4] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[5] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
[5] Horton、M。およびR. Adams、「Usenetメッセージの交換の標準」、RFC 1036、1987年12月。
[6] Alvestrand, H., Jordan, K., and J. Romaguera, "Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages", RFC 1496, August 1993.
[6] Alvestrand、H.、Jordan、K。、およびJ. Romaguera、「メッセージをX.400/88からX.400/84に格下げするための規則MIMEコンテンツタイプがメッセージに存在する場合」、RFC 1496、1993年8月。
[7] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1505, August 1993.
[7] Costanzo、A.、Robinson、D。、およびR. Ullmann、「インターネットメッセージのヘッダーフィールドのエンコード」、RFC 1505、1993年8月。
[8] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[8] Sollins、K。およびL. Masinter、「制服名の機能要件」、RFC 1737、1994年12月。
[9] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[9] Myers、J。およびM. Rose、「The Content-MD5ヘッダーフィールド」、RFC 1864、1995年10月。
[10] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[10] Berners-Lee、T.、Fielding、R。and H. Frystyk、「HyperText Transfer Protocol-HTTP/1.0」、RFC 1945、1996年5月。
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[11] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[12] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[13] Moats, R., "URN Syntax", RFC 2141, May 1997.
[13] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[14] Kille、S。、「Mixer（Mime Internet X.400 Enhanced Relay）：X.400とRFC 822/MIMEの間のマッピング」、RFC 2156、1998年1月。
[15] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[15] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージでのプレゼンテーション情報の伝達：コンテンツ - 分散ヘッダーフィールド」、RFC 2183、1997年8月。
[16] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting for HTTP", RFC 2227, October 1997.
[16] Mogul、J。およびP. Leach、「HTTPの単純なヒットメタリングと使用制限」、RFC 2227、1997年10月。
[17] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[17] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、および継続」、RFC 2231、1997年11月。
[18] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notification", RFC 3798, May 2004.
[18] Hansen、T。and G. Vaudreuil、eds。、「メッセージ処分通知」、RFC 3798、2004年5月。
[19] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.
[19] Neufeld、G。およびJ. Baer、「コアメールリストコマンドとメッセージヘッダーフィールドを介したトランスポートのメタシンタックスとしてのURLの使用」、RFC 2369、1998年7月。
[20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[20] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[21] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[21] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル - バージョン2（VPIMV2）」、RFC 3801、2004年6月。
[22] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[22] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。、およびD. Jensen、「分散オーサリング用のHTTP拡張 - WebDav」、RFC 2518、1999年2月。
[23] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[23] Palme、F.、Hopmann、A.、Shelness、N。、およびE. Stefferud、「HTML（MHTML）などの集計文書のMIMEカプセル化」、RFC 2557、1999年3月。
[24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[24] Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[25] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[25] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本およびダイジェストアクセス認証」、RFC 2617、1999年6月。
[26] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[26] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[27] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[27] Klyne、G。、「MIMEコンテンツのメディア機能を示す」、RFC 2912、2000年9月。
[28] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[28] Chandhok、R。and G. Wenger、「List-ID：メーリングリストの識別のための構造化されたフィールドと名前空間」、RFC 2919、2001年3月。
[29] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[29] Kristol、D。およびL. Montulli、「HTTP州管理メカニズム」、RFC 2965、2000年10月。
[30] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[30] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[31] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[31] Alvestrand、H。、「Content Language Headers」、RFC 3282、2002年5月。
[32] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C Recommendation xml, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[32] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C。、およびE. Maler、「拡張可能なマークアップ言語（XML）1.0（2番目のED）」、W3C推奨XML、2000年10月、<http：// www。w3.org/tr/2000/rec-xml-20001006>。
[33] "Mail address for announcement of new header field submissions", Mail address: ietf-message-headers@lists.ietf.org
[33] 「新しいヘッダーフィールド提出の発表のためのメールアドレス」、メールアドレス：ietf-message-headers@lists.ietf.org
[34] "Mail address for subscription to ietf-message-headers@lists.ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO THE MAILING LIST ITSELF)", Mail address: ietf-message-headers-request@lists.ietf.org
[34] 「ietf-message-headers@lists.ietf.orgのサブスクリプションのメールアドレス（メーリングリスト自体にサブスクリプションリクエストを送信しないでください）」、メールアドレス：ietf-message-headers-request@lists.ietf.org
[35] "Mail address for submission of new header field templates", Mail address: iana@iana.org
[35] 「新しいヘッダーフィールドテンプレートの提出のためのメールアドレス」、メールアドレス：iana@iana.org
Graham Klyne Nine by Nine
Graham Klyne Nine by Nine
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
Mark Nottingham BEA Systems 235 Montgomery St. Level 15 San Francisco, CA 94104 USA
マークノッティンガムビーシステム235モンゴメリーセントレベル15サンフランシスコ、カリフォルニア94104 USA
EMail: mnot@pobox.com
Jeffrey C. Mogul HP Labs 1501 Page Mill Road Palo Alto, CA 94304 US
ジェフリーC.モーグルHPラボ1501ページミルロードパロアルト、カリフォルニア州94304米国
EMail: JeffMogul@acm.org
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。