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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.
この仕様は、インターネットメール、HTTP、ネットニュースや他のアプリケーションによって使用されるメッセージヘッダーフィールドの登録手続きを定義します。
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ヘッダおよびメッセージヘッダプロトコル要素）メッセージヘッダーフィールドを定義します。 RFC 1036 [5]ネットニュースフィードと共に使用するためのメッセージヘッダ要素を定義します。これらの仕様はまた、ヘッダフィールドの数を定義し、新たなフィールド名の使用を通じて拡張を提供します。
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などMIMEを使用する他のインターネットアプリケーション、（RFC 3261 [30]）も、同じヘッダフィールドの多くを使用する（ただし、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.
原理的には、各アプリケーションは、有効なヘッダフィールド、アプリケーション（例えば、ネットニュース・ゲートウェイへのメール）、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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].
IETF標準トラック文書、コミュニティレビューの同等のレベルを達成している、または一般的に広く使用さであると認識されているもので定義されたヘッダーのためのもの常設メッセージヘッダフィールドレジストリ、O。 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ウェブアクセス[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で使用されるヘッダフィールドは日付とは異なる構文を持つ：インターネットメールを使用します。他の場合には、フィールド名は、複数のプロトコル（プロトコル固有の語彙と文字セットの規則を無視する）に共通仕様を有していてもよいです。例えば、これは、一般的にフォーム「のContent *」の名前を持つ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.)
複数のアプリケーション間で他のフィールドの（適切な）の共通性を認識し、促進することを希望しながら、このように、我々は、アプリケーション固有のフィールドに対応する必要があります。共通リポジトリは、すべての用途に使用され、登録された各ヘッダフィールドは、対応する定義が適用されるアプリケーションプロトコルを指定します。指定されたフィールド名が異なるプロトコルのために複数のレジストリエントリを有していてもよいです。永久メッセージヘッダフィールドのレジストリに、所定のヘッダフィールド名は、任意の特定のプロトコルのために一度だけ登録されていてもよいです。 （いくつかのケースでは、登録は、いくつかの定義文書を参照することができます。）
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.
フォームたContent *の名前を持ついくつかのヘッダーフィールドは、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と全く同じでない限り、特に、フォームのContent *の新しいヘッダフィールド名は、非MIME担持プロトコルのために定義されるべきではありません。
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.
（セクション4.2で与えられたような）インターネットメール、HTTP、またはMIMEのための新しいヘッダフィールドを定義するRFCは、それらのIANA問題部内の文書で定義されたすべてのヘッダーに適切なヘッダ登録テンプレート（単数または複数）を含まなければなりません。ヘッダレジストリの使用が必要とされないレジストリのような任務の使用の非存在下で、しかし、他のプロトコル仕様によって要求されるかもしれません。
The procedure for registering a message header field is:
メッセージヘッダフィールドを登録するための手順は以下のとおりです。
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として、またはRFC 2026、セクション7で説明した意味で「オープン・スタンダード」として公開する必要があり[1]、およびすべての登録永久間で一意の名前を持たなければなりません同一のアプリケーションプロトコルで使用されるフィールド名。
The registration template has the following form.
登録テンプレートは次の形式を持っています。
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:
PERMANENT MESSAGEヘッダフィールド登録テンプレート：
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.
該当するプロトコル：、 "メール"（RFC 2822）を指定し、 "MIME"（RFC 2045）、 "HTTP"（RFC 2616）、 "ネットニュース"（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.
状態：指定し、「標準」、「実験的」、「情報」、「歴史」、「廃止」、あるいはそれが定義されている主要文書の種類や状態に応じていくつかの他の適切な値。非IETF仕様については、正式には他の標準化団体によって承認されたものは、「標準」と表示されるはずです。他の人は、登録のための理由に応じて「情報」または「非推奨」であってもよいです。
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.
仕様書（S）：好ましくは、文書のコピーを取得するために使用することができる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:
暫定メッセージヘッダフィールド提出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.
該当するプロトコル：、 "メール"（RFC 2822）を指定し、 "MIME"（RFC 2045）、 "HTTP"（RFC 2616）、 "ネットニュース"（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、電話番号、ファックス番号も含まれていてもよいです。この提案は、標準化団体ワーキンググループから来ている場合は、名前とワーキンググループのホームページ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.
仕様書（S）：示されたプロトコルと共に使用するためのヘッダを指定したドキュメントへの参照。文書は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メッセージヘッダフィールドリポジトリのいずれかに組み込むために提出されます。
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.
定義RFC中のO IANA Considerations部、メッセージヘッダの登録を要求し、同じドキュメント内の登録テンプレートによって要求される情報を参照します。ヘッダの登録は、その後、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にテンプレートを送信します。要求された名前と仕様書は、セクション4.1および4.2.2項で述べた基準を満たしている場合IESGまたはその指定された専門家は、それが公開されることはないことを要求していない限り、IANAは、テンプレートの情報を公開します（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.
技術的な詳細について異議または意見の相違は、自分自身の、暫定リポジトリに上場拒否すると考える根拠はないことに注意してください。結局、その目的の一つは、開発者がインターネットコミュニティの最大の利益のために自分のアイデア、専門知識とエネルギーを組み合わせることを視野に通信できるようにすることです。
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.)
それは永久メッセージヘッダフィールドレジストリのエントリは（RFC 2141あたり[13]）のURN一意性と永続性のための特定の要件を持っているの構築に使用され得ることが意図されている（RFC 1737ごとに[8]）。エントリが永続的メッセージヘッダレジストリに行われるとそのため、ヘッダ名と該当するプロトコルの組み合わせは、その後、他の目的のために登録してはいけません。 （これは、ヘッダ登録における仕様引用に適切なIETFコンセンサスルール内の該当する仕様（S）、および対応する更新のリビジョンを排除するものではありません。）
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/メッセージ・ヘッダーの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.
このドキュメントのセクション4あたり永久メッセージヘッダーフィールドのための新しいIANAレジストリO。このレジストリに含めるための政策は、セクション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.
このドキュメントのセクション4あたり仮メッセージヘッダフィールドをリスト新しいIANAリポジトリO。このレジストリに含めるための政策は、セクション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]ブラドナーの、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[5] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
[5]ホートン、M.およびR.アダムス、 "標準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.、ヨルダン、K.、およびJ. Romaguera、RFC 1496、 "からのメッセージをダウングレードするためのルールX.400 / 88のMIMEコンテンツタイプは、メッセージ中に存在する場合、X.400 / 84"、 1993年8月。
[7] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1505, August 1993.
[7]コスタンツォ、A.、ロビンソン、D.、およびR.ウルマン、 "インターネットメッセージのエンコーディングヘッダーフィールド"、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]マイヤーズ、J.とM.ローズ、 "コンテンツ-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]バーナーズ=リー、T.、フィールディング、R.、およびH. Frystyk、 "ハイパーテキスト転送プロトコル - 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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[12]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[13] Moats, R., "URN Syntax", RFC 2141, May 1997.
[13]堀、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インターネットX.400拡張リレー）：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.、ドルナー、S.、およびK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、RFC 2183、1997年8月。
[16] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting for HTTP", RFC 2227, October 1997.
[16]モーグル、J.およびP.リーチ、 "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]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年11月。
[18] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notification", RFC 3798, May 2004.
[18]ハンセン、T.およびG.ボードルイ、編、 "メッセージ気質通知"、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]ノイフェルド、G.とJ.ベア、RFC 2369、1998年7月「コアメールリストコマンドとメッセージヘッダフィールドを通じてそれらの輸送のためのメタ構文としてのURLの使用」。
[20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[20]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[21] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[21]ヴォードルイユ、G.とG.パーソンズ、 "インターネットメール用の音声プロファイル - バージョン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.、ホワイトヘッド、E.、フェッチ、A.、カーター、S.、およびD.ジェンセン、 "分散オーサリングの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]パルメ、F.、Hopmann、A.、Shelness、N.、およびE. Stefferud、RFC 2557、1999年3月 "は、HTML（MHTML）として集約文書のMIMEカプセル化"。
[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]フィールディング、R.、ゲティス、J.、モーグル、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[26] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[26] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[27] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[27] Klyne、G.、RFC 2912、2000年9月 "MIMEコンテンツのメディアの特徴を示します"。
[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.とG.ウェンガー、 "リスト-ID：メーリングリストの識別のための構造化フィールドと名前空間"、RFC 2919、2001年3月。
[29] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[29]クリストル、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[31] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[31] Alvestrand、H.、 "コンテンツ言語ヘッダ"、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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第2版）"、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
ナインにより、グラハムKlyneナイン
EMail: GK-IETF@ninebynine.org URI: http://www.ninebynine.net/
電子メール：GK-IETF@ninebynine.org URI：http://www.ninebynine.net/
Mark Nottingham BEA Systems 235 Montgomery St. Level 15 San Francisco, CA 94104 USA
マーク・ノッティンガムBEAシステムズ235モンゴメリー聖レベル15サンフランシスコ、CA 94104 USA
EMail: mnot@pobox.com
メールアドレス：mnot@pobox.com
Jeffrey C. Mogul HP Labs 1501 Page Mill Road Palo Alto, CA 94304 US
ジェフリーC.モーグルHP Labsの1501ページミルロードパロアルト、CA 94304米国
EMail: JeffMogul@acm.org
メールアドレス：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。