Network Working Group B. Lilly
Request for Comments: 4249 January 2006
Category: Informational
Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components
メッセージとMIMEパートヘッダフィールドとフィールドコンポーネントの実装者に優しい仕様
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer. This memo identifies information useful to implementers of header field generators and parsers.
ヘッダフィールドのジェネレータとパーサの実装は、これらのフィールドに関する特定の情報を必要とします。そのようなすべての情報は、明示的分野の技術仕様によって提供されるとの相互運用性が最も可能性が高いです。そのような明示的な情報を欠いている、実装者は推測すること、および相互運用性が低下することがあります。このメモは、ヘッダフィールド発生器とパーサーの実装に有用な情報を識別する。
Table of Contents
目次
1. Introduction ....................................................2
2. Scope ...........................................................2
3. Specification Items .............................................3
3.1. Established Conventions ....................................3
3.1.1. Standard Terminology ................................3
3.1.2. Naming Rules and Conventions ........................3
3.2. Common Specification Items .................................5
3.2.1. ABNF ................................................5
3.2.2. Minimum and Maximum Instances of Fields per Header ..6
3.2.3. Categorization ......................................7
3.3. Semantics ..................................................7
3.3.1. Producers, Modifiers, and Consumers .................7
3.3.2. What's it all about? ................................7
3.3.3. Context .............................................7
3.4. Overall Considerations .....................................7
3.4.1. Security ............................................8
3.4.2. Backward Compatibility ..............................8
3.4.3. Compatibility With Legacy Content ...................8
3.4.4. Interaction With Established Mechanisms .............9
4. Acknowledgements ................................................9
5. Security Considerations .........................................9
6. Internationalization Considerations .............................9
7. IANA Considerations .............................................9
Appendix A. Disclaimers ...........................................10
Normative References ..............................................11
Informative References ............................................11
Internet messages consist of a message header and a body [N1.STD11], [N2.RFC2822]. MIME content begins with a MIME-part header [N3.RFC2045], [N4.RFC2046]. Message headers and MIME-part headers consist of fields. While the Message Format and MIME specifications define their respective overall formats and some specific fields, they also have provision for extension fields. A number of extension fields have been specified, some more or less completely than others. Incomplete or imprecise specification has led to interoperability problems as implementers make assumptions in the absence of specifications. This memo identifies items of potential interest to implementers, and section 3 of this memo may serve as an informational guide for authors of specifications of extension fields and field components.
インターネット・メッセージが[N2.RFC2822]、メッセージヘッダとボディ[N1.STD11]から成ります。 MIME含量は[N4.RFC2046]、MIMEパートヘッダ[N3.RFC2045]から始まります。メッセージヘッダとMIMEパートヘッダフィールドから成ります。メッセージフォーマットとMIME仕様は、それぞれの全体的な形式といくつかの特定のフィールドを定義しますが、彼らはまた、拡張フィールドの規定を持っています。拡張フィールドの数が指定されている、いくつかの多かれ少なかれ完全に他より。実装者は、仕様が存在しない場合に仮定を行うと不完全または不正確な仕様は、相互運用性の問題につながっています。このメモは、実装に潜在的に関心のあるアイテムを識別し、このメモのセクション3は、拡張フィールドとフィールドコンポーネントの仕様の作者のための情報のガイドとして機能することができます。
This memo is intended as a non-binding informational supplement to various specifications, guidelines, and procedures for specification of header fields [N1.STD11], [N2.RFC2822], [N3.RFC2045], [N4.RFC2046], [N5.BCP9], [N6.BCP90]. It does not absolve authors of header field specifications from compliance with any provisions of those or other specifications, guidelines, and procedures. It offers clarification and supplementary suggestions that will promote interoperability and may spare specification authors many questions regarding incomplete header field specifications.
このメモは、ヘッダフィールドの仕様N5 [N1.STD11]、[N2.RFC2822]、[N3.RFC2045]、[N4.RFC2046]、[ための様々な仕様、ガイドライン、および手続きに非結合情報サプリメントとして意図されています.BCP9]、[N6.BCP90]。これは、これらまたは他の仕様、ガイドライン、および手続きのいずれかの規定に準拠からヘッダーフィールド仕様の作者を免除されません。これは、明確化と相互運用性を促進し、仕様の作者に不完全なヘッダフィールド仕様に関する多くの質問を惜しまも補足的な提案を提供しています。
A number of conventions exist for naming and specifying header fields. It would be unwise and confusing to specify a field that conflicts with those conventions.
規則の数は、ネーミングおよびヘッダフィールドを指定するために存在します。これらの規則と競合するフィールドを指定することが賢明と混乱することでしょう。
Terms related to the Internet Message Format are defined in [N2.RFC2822]. Authors specifying extension header fields should use the same terms in the same manner in order to provide clarity and avoid confusion. For example, a "header" [I1.FYI18], [N2.RFC2822] is comprised of "header fields", each of which has a "field name" and usually has a "field body". Each message may have multiple "headers", viz. a message header and MIME-part [N4.RFC2046] headers.
インターネットメッセージ形式に関連する用語は、[N2.RFC2822]で定義されています。拡張ヘッダフィールドを特定の著者は明快さを提供し、混乱を避けるために、同じ方法で同じ用語を使用すべきです。例えば、「ヘッダ」は、[I1.FYI18]、[N2.RFC2822「フィールド名」を有し、通常「フィールド体」をそれぞれ有する「ヘッダフィールド」から構成されています。各メッセージは、すなわちを複数の「ヘッダ」を有していてもよいです。メッセージヘッダとMIMEパート[N4.RFC2046]ヘッダー。
A message header has a Date header field (i.e., a field with field name "Date"). However, there is no "Date header"; use of such non-standard terms is likely to lead to confusion, possibly resulting in interoperability failures of implementations.
メッセージヘッダは、日付ヘッダフィールド（すなわち、フィールドのフィールド名を持つ「日」）を有します。しかし、「Dateヘッダは」ありません。このような非標準の用語の使用は、おそらく実装の相互運用性の障害が生じ、混乱を招く可能性があります。
Several rules and conventions have been established for naming of header fields. Rules are codified in published RFCs; conventions reflect common use.
いくつかのルールや規則は、ヘッダフィールドの命名のために確立されています。ルールは、公開されたRFCで成文化されています。規則は、一般的な使用を反映します。
Some RFCs define a particular prefix, reserving use of that prefix for specific purposes.
いくつかのRFCには、特定の目的のために、そのプレフィックスの使用を予約する、特定の接頭辞を定義します。
This prefix must be used for all MIME extension fields and must not be used for fields that are not MIME extension fields [N3.RFC2045] (section 9).
このプレフィックスは、すべてのMIME拡張フィールドのために使用されなければならず、[N3.RFC2045]（セクション9）MIME拡張フィールドではないフィールドのために使用してはなりません。
Specified for certain standard fields as given in [N1.STD11] (also used by [N2.RFC2822], although not specified as a prefix therein). If a Resent- version of a field is applicable, an author should say so explicitly and should provide a comprehensive specification of any differences between the plain field and the Resent- version.
[N1.STD11]（また、その中に接頭辞として指定されていないが、[N2.RFC2822]で使用される）で与えられる特定の標準フィールドに指定されました。フィールドのはResent-バージョンが適用される場合、著者はそう明示的に言うべき、プレーンフィールドとはResent-バージョン間の差異の包括的な仕様を提供しなければなりません。
Some prefixes have developed as conventions. Although not formally specified as reserved prefixes, these conventions are or have been in use in multiple fields with common semantics for each prefix.
いくつかのプレフィックスが慣習として開発しました。正式に予約済みの接頭辞として指定されていないが、これらの規則はあるか、各プレフィックスのための共通のセマンティクスを持つ複数のフィールドで使用されてきました。
This prefix should be used for all extension fields intended for use in content negotiation [I2.RFC2616] and should not be used for fields that are not intended for such use. An example may be found in [I3.RFC3282].
このプレフィックスは、[I2.RFC2616]コンテントネゴシエーションで使用することを意図し、すべての拡張フィールドに使用されなければならないと、このような使用のために意図されていないフィールドに使用すべきではありません。例は、[I3.RFC3282]に見出すことができます。
Used to indicate information about mailing lists when a list expansion takes place. Examples of defined fields can be found in [I4.RFC2369] and [I5.RFC2919].
リストの展開が行われるときメーリングリストに関する情報を示すために使用します。定義されたフィールドの例には、[I5.RFC2919] [I4.RFC2369]に見出すことができます。
This prefix provides a record of illegal content in a field when fields are transformed at a gateway [I6.RFC886].
このプレフィックスは、フィールドがゲートウェイ[I6.RFC886]に変換されるフィールドに違法なコンテンツの記録を提供します。
Specification of information used in conjunction with Message Disposition Notifications (MDNs) [I7.RFC3798].
メッセージ気質通知と併せて使用される情報の仕様（開封通知）[I7.RFC3798]。
Used to reference some content from a related message. Examples include Original-Message-ID as used by [I8.RFC3297] and [I7.RFC3798], Original-Encoded-Information-Types [I9.RFC2156], Original-Envelope-ID [I10.RFC3464], and Original-Recipient [I7.RFC3798].
関連するメッセージから一部のコンテンツを参照するために使用されます。 【I8.RFC3297]および[I7.RFC3798]、オリジナル・エンコード・インフォメーション・タイプ[I9.RFC2156]、オリジナルエンベロープ-ID [I10.RFC3464]、及びオリジナル受信者によって使用される例は、オリジナル・メッセージIDを含みます【I7.RFC3798]。
Specifies a host that generated a type of report, such as those defined in [I7.RFC3798], [I10.RFC3464].
[I10.RFC3464]、例えば[I7.RFC3798]で定義されたものなど、レポートのタイプを生成したホストを指定します。
Used in conversion from X.400 environments by gateways [I9.RFC2156].
[I9.RFC2156]ゲートウェイがX.400環境からの変換に使用されます。
Also used by gateways from X.400 [I9.RFC2156].
また、X.400 [I9.RFC2156]からゲートウェイによって使用されます。
Was used by X.400 gateways [I11.RFC987].
X.400ゲートウェイ[I11.RFC987]で使用されていました。
Also used by legacy X.400 gateways [I11.RFC987].
また、従来のX.400ゲートウェイ[I11.RFC987]で使用されます。
Several items are specified for standard header fields; these items should also be specified for extension fields.
いくつかの項目は、標準的なヘッダーフィールドに指定されています。これらの項目は、拡張フィールドに指定する必要があります。
[N1.STD11] is vague about where whitespace is permitted or required in header field syntax. [N2.RFC2822] addresses that issue by defining grammar productions such as FWS and CFWS, in conjunction with formal ABNF [N7.RFC4234] and in accordance with the necessity for specificity of such issues as noted in section 3.1 of [N7.RFC4234]. Extension field ABNF should clearly specify where comments, line folding, and whitespace are prohibited and permitted, and should use the [N2.RFC2822] grammar productions in ABNF for that purpose.
【N1.STD11]空白がヘッダフィールドの構文に許可または要求される場合に約あいまいです。組み合わせて、そのようなFWSとCFWSとして文法プロダクションを定義することによって[N2.RFC2822]はアドレスその問題を正式なABNF [N7.RFC4234】このような問題の特異性のために必要に応じてのセクション3.1で述べたようN7.RFC4234] 。拡張フィールドABNFはコメントは、行の折り畳み、および空白は禁止と許可されている場所を明確に指定する必要があり、そしてその目的のためにABNFで[N2.RFC2822]文法のプロダクションを使用する必要があります。
All ABNF must be carefully checked for ambiguities and to ensure that all productions resolve to some combination of terminal productions provided by a normative reference [N8.CKLIST] ("All ABNF must be checked"). [N7.RFC4234] provides several productions that may be useful. While use of suitable productions defined and in use is encouraged, specification authors are cautioned that some such productions have been amended by subsequently issued RFCs and/or by formal errata [I12.Errata].
すべてのABNFは慎重にあいまいさをチェックする必要があり、すべての作品が引用規格[N8.CKLIST]（「すべてのABNFをチェックしなければならない」）によって提供される端末作品のいくつかの組み合わせに解決することを確実にするために。 【N7.RFC4234】有用であり得るいくつかの作品を提供します。定義されており、使用に適し作品の使用が奨励されている間、仕様の作者は、このようないくつかの作品は、その後に発行されたRFCによっておよび/または正式なエラッタ[I12.Errata]によって修正されていることを警告しています。
Authors and designers should be careful not to mix syntax with disparate semantics within a single field. Examples of disparate semantics are [N2.RFC2822] comments (which use parentheses as delimiters), [I13.RFC2533] feature sets (which also use parentheses as delimiters, but not for comments), and [I14.RFC3986] Uniform Resource Identifiers (URIs), which permit parentheses in URI text.
著者やデザイナーは、単一のフィールド内の異なる意味を持つの構文を混在しないように注意する必要があります。異なるセマンティクスの例は、ユニフォームリソース識別子（（また、区切り文字としてではなく、コメントに括弧を使用）[N2.RFC2822]（区切り文字として括弧を使用）、コメント、[I13.RFC2533]機能セットであり、[I14.RFC3986] URIテキストに括弧を許可するURI）、。
It is sometimes necessary or desirable to define keywords as protocol elements in structured fields. Protocol elements should be case insensitive per the Internet Architecture [I15.RFC1958] (section 4.3). Keywords are typically registered by IANA; a specification using registered keywords must include an IANA Considerations section [N9.BCP26], [I16.RFC3692], and should indicate to readers of the specification precisely where IANA has set up the registry (authors will need to coordinate this with IANA prior to publication as an RFC). In many cases, it will be desirable to make provision for extending the set of keywords; that may be done by specifying that the set may be extended by publication of an RFC, or a formal review and registration procedure may be specified (typically as a BCP RFC).
構造化されたフィールドにプロトコル要素としてキーワードを定義することが必要な場合または望ましいです。プロトコル要素は、インターネットアーキテクチャ[I15.RFC1958]（セクション4.3）当たりの大文字と小文字を区別しなければなりません。キーワードは一般的にIANAによって登録されています。登録されたキーワードを用いて指定する[I16.RFC3692]、[N9.BCP26] IANA Considerations部を含んでいなければならない、とIANA前に著者はIANAでこれを調整する必要があります（レジストリを設定している場合、正確に仕様の読者に示すべきRFCとして刊行）。多くの場合、キーワードのセットを拡張するための規定を作ることが望ましいであろう。それは、セットが（典型的にはBCP RFCとして）指定することができるRFCの出版物、または正式なレビューおよび登録手順によって拡張することができることを指定することによって行うことができます。
If keywords are defined, and if there is any chance that the set of keywords might be expanded, a registry should be established via IANA. If a registry is not established initially, there is a good chance that initially-defined keywords will not be registered or will subsequently be registered with different semantics (this has happened!).
キーワードが定義されている場合は、キーワードのセットが展開されるかもしれないというチャンスがあるならば、そして、レジストリは、IANAによって確立されなければなりません。レジストリが最初に確立されていない場合は、最初に定義されたキーワードが登録されることはありませんか、その後に異なる意味に登録されます良いチャンスがあります（これが起こっています！）。
Provision may be made for experimental or private-use keywords. These typically begin with a case-insensitive "x-" prefix. Note that [N10.BCP82] has specific considerations for use of experimental keywords.
提供は、実験的または私的使用のキーワードを行うことができます。これらは通常、大文字と小文字を区別しない「X-」接頭辞で始まります。 [N10.BCP82]実験的なキーワードを使用するための具体的な注意事項があることに注意してください。
If some field content is to be considered human-readable text, there must be provision for specifying language in accordance with [N11.BCP18] (section 4.2). Header fields typically use the mechanism specified in [I17.RFC2047] as amended by [I18.RFC2231] and [I12.Errata] for that purpose. Note, however, that that mechanism applies only to three specific cases: unstructured fields, an RFC 822 "word" in an RFC 822 "phrase", and comments in structured fields. Any internationalization considerations should be detailed in an Internationalization Considerations section of the specification as specified in [N11.BCP18] (section 6).
いくつかのフィールドの内容が判読可能なテキスト考慮する必要がある場合は、[N11.BCP18]（セクション4.2）に合わせて言語を指定するための規定がなければなりません。 【I18.RFC2231]によって、および[I12.Errata】その目的のために修正されたヘッダフィールドは、典型的には、[I17.RFC2047]で指定されたメカニズムを使用します。ただし、そのメカニズムは唯一の3つの特定の例に適用されること：RFC 822「というフレーズ」で構造化されていないフィールド、RFC 822「言葉」、および構造化された分野でのコメント。 [N11.BCP18]（セクション6）で指定されるように、任意の国際化の考慮事項は、明細書の国際化の考慮事項のセクションで詳述されるべきです。
Some field bodies may include ABNF representing numerical values. Such ABNF, its comments, and supporting normative text should clearly indicate whether such a numerical value is decimal, octal, hexadecimal, etc.; whether or not leading and/or trailing zeroes are significant and/or permitted; and how any combinations of numeric fields are intended to be interpreted. For example, two numeric fields separated by a dot, exemplified by "001.100", "1.1", "1.075", and "1.75", might be interpreted in several ways, depending on factors such as those enumerated above.
いくつかのフィールドボディは、数値を表すABNFを含むことができます。そのようなABNF、そのコメント、および規範的テキストをサポートは、明らかに、このような数値は、10進数、8進数、16進数、等であるかどうかを示すべきです;先頭および/または末尾のゼロが重要であり、および/または許可か否かを判断します。そしてどのように数値フィールドの任意の組み合わせが解釈されることを意図しています。例えば、ドットで区切られた2つの数値フィールドは、「001.100」、「1.1」で例示、「1.075」、及び「1.75」は、上記に列挙したもののような要因に応じて、いくつかの方法で解釈されるかもしれません。
While ABNF [N7.RFC4234] is used by [N2.RFC2822] and is mentioned above, alternate formal syntax formats may be used in specifications [I19.Syntax].
ABNFは[N7.RFC4234] [N2.RFC2822]で使用され、上述されているが、代替の正式な構文フォーマットは、[I19.Syntax】仕様で使用することができます。
Some fields are mandatory, others are optional. It may make sense to permit multiple instances of a field in a given header; in other cases, at most a single instance is sensible. [N2.RFC2822] specifies
一部のフィールドは、他はオプションで、必須です。それは、与えられたヘッダ内のフィールドの複数のインスタンスを可能にするために意味をなすことができます。他の例では、最大で単一のインスタンスが賢明です。 [N2.RFC2822]を指定
a minimum and maximum count per header for each standard field in a message; specification authors should likewise specify minimum and maximum counts for extension fields.
メッセージ内の各標準フィールドのヘッダーあたりの最小および最大数。仕様の著者は、同様に、拡張フィールドの最小値と最大数を指定する必要があります。
[N2.RFC2822] defines categories of header fields (e.g., trace fields, address fields). Such categories have implications for processing and handling of fields. A specification author should indicate any applicable categories.
[N2.RFC2822（例えば、トレースフィールド、アドレスフィールド）ヘッダフィールドのカテゴリを定義します。このようなカテゴリはフィールドの処理及び取扱いのための意味を持っています。仕様作成者は、該当するカテゴリを示すべきです。
In addition to specifying syntax of a field, a specification document should indicate the semantics of each field. Such semantics are composed of several aspects:
フィールドの構文を指定することに加えて、仕様書には、各フィールドの意味を示す必要があります。そのような意味は、いくつかの側面で構成されています。
Some fields are intended for end-to-end communication between author or sender and recipient; such fields should not be generated or altered by intermediaries in the transmission chain [I20.Arch]. Other fields comprise trace information that is added during transport. Authors should clearly specify who may generate a field, who may modify it in transit, who should interpret such a field, and who is prohibited from interpreting or modifying the field.
一部のフィールドは、著者または送信者と受信者間のエンドツーエンド通信のために意図されています。このようなフィールドは、送信チェーン[I20.Arch]で仲介することによって生成または変更されるべきではありません。他のフィールドは、輸送中に追加されたトレース情報を含んでいます。著者は明らかに、このようなフィールドを解釈すべきであるトランジットでそれを修正することができ、フィールドを生成することができるユーザーを指定する必要があり、誰がフィールドを解釈するか、修正することは禁止されています。
When introducing a new field or modifying an existing field, an author should present a clear description of what problem or situation is being addressed by the extension or change.
新しいフィールドを導入するか、既存のフィールドを変更する場合、著者は、どのような問題や状況の明確な記述を提示しなければならない拡張や変更によって対処されています。
The permitted types of headers in which the field may appear should be specified. Some fields might only be appropriate in a message header, some might appear in MIME-part headers [N4.RFC2046] as well as message headers, still others might appear in specialized MIME media types.
フィールドが表示される可能性のあるヘッダの許可のタイプが指定されなければなりません。いくつかのフィールドのみがメッセージヘッダに適切であるかもしれない、いくつかは、MIMEパートヘッダ[N4.RFC2046]並びにメッセージヘッダーに表示されることがあり、さらに他の専門MIMEメディアタイプに表示されるかもしれません。
Several factors should be specified regarding how a field interacts with the Internet at large, with the applications for which it is intended, and in interacting with other applications.
いくつかの要因は、それが意図されているアプリケーションと、他のアプリケーションとの相互作用で、フィールドが広くインターネットとどのように相互作用するかについて指定する必要があります。
Every specification is supposed to include a carefully-considered Security Considerations section [N12.RFC2223] (section 9), [I21.BCP72].
すべての仕様は[I21.BCP72]、[N12.RFC2223]（セクション9）を慎重に検討さSecurity Considerations部を含めることになっています。
There is a large deployed base of applications that use header fields. Implementations that comprise that deployed base may change very slowly. It is therefore critically important to consider and specify the impact of a new or revised field or field component on that deployed base. A new field, or extensions to the syntax of an existing field or field component, might not be recognizable to deployed implementations. Depending on the care with which the authors of an extension have considered such backward compatibility, such an extension might, for example:
ヘッダフィールドを使用するアプリケーションの大規模な展開塩基があります。その展開のベースを構成する実装は非常にゆっくりと変化することがあります。その展開のベースに新規または改訂されたフィールドまたはフィールドの成分の影響を考慮して指定することが極めて重要です。新しいフィールド、または既存のフィールドまたはフィールドの構成要素の構文の拡張機能は、展開の実装を認識できない場合があります。拡張子の著者は、このような下位互換性を保つと考えているとケアに依存して、このような拡張かもしれない、例えば：
a. Cause a deployed implementation to simply ignore the field in its entirety. That is not a problem provided that it is a new field and that there is no assumption that such deployed implementations will do otherwise.
A。単に全体のフィールドを無視するように展開し、実装を引き起こします。それはそれは新しい分野であり、そのような展開の実装はそうでしょうという前提が存在しないことをことを提供する問題ではありません。
b. Cause a deployed implementation to behave differently from how it would behave in the absence of the proposed change, in ways that are not intended by the proposal. That is a failure of the proposal to remain backward compatible with the deployed base of implementations.
B。それは提案者が意図していない方法で、提案された変更が存在しない場合に振る舞うだろうかと異なる動作をするために配備実装を引き起こします。すなわち、実装の展開塩基との下位互換性を維持するために提案の障害です。
There are many subtleties and variations that may come into play. Authors should very carefully consider backward compatibility when devising extensions, and should clearly describe all known compatibility issues.
遊びに来るかもしれない多くの機微とバリエーションがあります。著者は、拡張子を考案する際に非常に慎重に後方互換性を考慮しなければならない、と明確にすべての既知の互換性の問題を記述する必要があります。
Content is sometimes archived for various reasons. It is sometimes necessary or desirable to access archived content, with the semantics of that archived content unchanged. It is therefore important that lack of presence of an extension field or field component should not be construed (by an extension specification) as conferring new semantics on a message or piece of MIME content that lacks that field or field component. Any such semantics should be explicitly specified.
コンテンツは時々、様々な理由のためにアーカイブされます。変わらず、そのアーカイブされたコンテンツのセマンティクスで、アーカイブされたコンテンツにアクセスすることが必要な場合または望ましいです。そのフィールドまたはフィールド成分を欠いているメッセージやMIMEコンテンツのピースに新しい意味論を与えるよう（拡張仕様によって）拡張フィールドまたはフィールド成分の存在の欠如は解釈されるべきではないことが重要です。そのような任意のセマンティクスが明示的に指定する必要があります。
Header fields are handled specially by gateways under various circumstances, e.g., message fragmentation and reassembly [N4.RFC2046]. If special treatment is required for a header field under such circumstances, it should be clearly specified by the author of the specification. [I7.RFC3798] is an example of how this might be handled (however, because that specification requires deployed RFC 2046-conforming implementations to be modified, it is not strictly backward compatible).
ヘッダフィールドはメッセージの断片化と再アセンブリは、[N4.RFC2046]、例えば、様々な状況下でゲートウェイによって特別に処理されます。特別な処置は、このような状況下でのヘッダフィールドのために必要とされる場合、それは明らか仕様の作成者によって指定されなければなりません。 【I7.RFC3798]これは（その仕様を変更する展開RFC 2046準拠の実装を必要とするため、しかし、それは互換性が厳密下位ない）に扱われるかもしれない方法の例です。
The author would like to acknowledge the helpful comments provided by members of the ietf-822 mailing list. In particular, Peter Koch and Keith Moore have made useful comments.
著者は、IETF-822メーリングリストのメンバーが提供する有益なコメントを承認したいと思います。特に、ピーター・コッホとキース・ムーアは有益なコメントをしました。
No new security considerations are addressed by this memo. The memo reinforces the need for careful consideration and specification of security issues.
新たなセキュリティ上の考慮事項は、このメモによって対処されていません。メモは、慎重に検討し、セキュリティ上の問題の特定の必要性を強調しています。
This memo does not directly have internationalization considerations; however, it reminds specification authors of the need to consider internationalization of textual field components.
このメモは直接国際化の考慮事項はありません。しかし、それは、テキストフィールドコンポーネントの国際化を検討する必要があるの仕様作成者を連想させます。
While no specific action is required of IANA in regard to this memo, it does note that some coordination between IANA and specification authors who do require IANA to set up registries is at least desirable, if not a necessity. IANA should also closely coordinate with the RFC Editor so that registries are set up and properly referenced at the time of publication of an RFC that refers to such a registry. IANA is also encouraged to work closely with authors and the RFC Editor to ensure that descriptions of registries maintained by IANA are accurate and meaningful.
具体的なアクションがこのメモに関してIANAの必要はありませんが、それは必要でない場合はレジストリを設定するためにIANAが必要なんIANAと仕様作成者の間にいくつかの調整は、少なくとも望ましいことに注意してくださいありません。 IANAはまた、密接にレジストリを設定し、適切にそのようなレジストリを指すRFCの発行時に参照されるように、RFCエディタと連携すべきです。 IANAは、IANAによって維持レジストリの記述が正確かつ有意義であることを保証するために、著者およびRFC編集者と緊密に協力することが奨励されます。
Appendix A. Disclaimers
付録A.免責事項
This document has exactly one (1) author.
この文書では、1つの（1）の著者を持っています。
In spite of the fact that the author's given name may also be the surname of other individuals, and the fact that the author's surname may also be a given name for some females, the author is, and has always been, male.
著者の与えられた名前は、他の人の姓、および著者の姓はまた、いくつかの女性のために与えられた名前かもしれないという事実かもしれないという事実にもかかわらず、作者であり、常に、男性となっています。
The presence of "/SHE", "their", and "authors" (plural) in the boilerplate sections of this document is irrelevant. The author of this document is not responsible for the boilerplate text.
この文書の定型セクション内の「/ SHE」、「その」、および「著者」（複数）の存在は無関係です。本書の著者は、ボイラープレート・テキストのための責任を負いません。
Comments regarding the silliness, lack of accuracy, and lack of precision of the boilerplate text should be directed to the IESG, not to the author.
愚か、正確性の欠如、およびボイラープレート・テキストの精度の欠如についてのコメントはありません作者に、IESGに向けられるべきです。
Normative References
引用規格
[N1.STD11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[N1.STD11]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[N2.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[N2.RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[N3.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[N3.RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[N4.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[N4.RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[N5.BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[N5.BCP9]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[N6.BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
【N6.BCP90] Klyne、G.、ノッティンガム、M.、およびJ.モーグル、 "メッセージヘッダフィールドの登録手順"、BCP 90、RFC 3864、2004年9月。
[N7.RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[N7.RFC4234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[N8.CKLIST] "Checklist for Internet-Drafts (IDs) submitted for RFC publication", http://www.ietf.org/ID-Checklist.html.
[N8.CKLIST]、http://www.ietf.org/ID-Checklist.html "RFC公開用に提出インターネットドラフト（IDS）のチェックリスト"。
[N9.BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[N9.BCP26] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[N10.BCP82] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[N10.BCP82] Narten氏、T.、 "役に立つと考えられた実験的でテスト番号の割り当て"、BCP 82、RFC 3692、2004年1月。
[N11.BCP18] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[N11.BCP18] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[N12.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
【N12.RFC2223]ポステル、J.、およびJ.レイノルズ、RFC 2223、1997年10月 "RFC作者への指示"。
Informative References
参考文献
[I1.FYI18] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
[I1.FYI18]マルキン、G.、 "インターネットユーザーの用語集"、FYI 18、RFC 1983、1996年8月。
[I2.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.
【I2.RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、「ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[I3.RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[I3.RFC3282] Alvestrand、H.、 "コンテンツ言語ヘッダ"、RFC 3282、2002年5月。
[I4.RFC2369] 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.
[I4.RFC2369]ノイフェルド、G.とJ.ベア、RFC 2369、1998年7月「コアメールリストコマンドとメッセージヘッダフィールドを通じてそれらの輸送のためのメタ構文としてのURLの使用」。
[I5.RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[I5.RFC2919] Chandhok、R.とG.ウェンガー、 "リスト-ID：メーリングリストの識別のための構造化フィールドと名前空間"、RFC 2919、2001年3月。
[I6.RFC886] Rose, M., "Proposed standard for message header munging", RFC 886, December 1983.
【I6.RFC886]ローズ、M.、RFC 886 "いじるメッセージヘッダの提案された標準"、1983年12月。
[I7.RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[I7.RFC3798]ハンセン、T.およびG.ボードルイ、 "メッセージ気質通知"、RFC 3798、2004年5月。
[I8.RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.
[I8.RFC3297] Klyne、G.、Iwazaki、R.、およびD.クロッカー、 "電子メールに基づいて、メッセージングサービスのためのコンテントネゴシエーション"、RFC 3297、2002年7月。
[I9.RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
【I9.RFC2156] Kille、S.、 "MIXER（MIMEインターネットX.400拡張リレー）：X.400およびRFC 822 / MIMEの間のマッピング"、RFC 2156、1998年1月。
[I10.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[I10.RFC3464]ムーア、K.とG.ボードルイ、RFC 3464、2003年1月、 "配信状態通知のための広げることができるメッセージフォーマット"。
[I11.RFC987] Kille, S., "Mapping between X.400 and RFC 822", RFC 987, June 1986.
、RFC 987、1986年6月[I11.RFC987] Kille、S.、 "X.400とRFC 822との間のマッピング"。
[I12.Errata] RFC-Editor errata page, http://www.rfc-editor.org/errata.html
[I12.Errata] RFC-エディタの正誤表ページ、http://www.rfc-editor.org/errata.html
[I13.RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
"メディア機能セットの記述のための構文" [I13.RFC2533] Klyne、G.、RFC 2533、1999年3月。
[I14.RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
【I14.RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[I15.RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[I15.RFC1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[I16.RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[I16.RFC3692] Narten氏、T.、 "役に立つと考えられた実験的でテスト番号の割り当て"、BCP 82、RFC 3692、2004年1月。
[I17.RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[I17.RFC2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[I18.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
、RFC 2231、1997年11月：[I18.RFC2231]、N.、およびK.ムーア、 "文字セット、言語、および継続のMIMEパラメータ値およびエンコードされたWordの拡張機能を" フリード。
[I19.Syntax] Carpenter, B., "Syntax for format definitions", http://ietf.org/IESG/STATEMENTS/syntax-format-def.txt
【I19.Syntax]カーペンター、B.、 "フォーマット定義の構文"、http://ietf.org/IESG/STATEMENTS/syntax-format-def.txt
[I20.Arch] Crocker, D., "Internet Mail Architecture", Work in Progress, March 2005.
[I20.Arch]クロッカー、D.、 "インターネットメールのアーキテクチャ"、進歩、2005年3月に作業。
[I21.BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[I21.BCP72]レスコラ、E.とB.コーバー、 "セキュリティの考慮事項の書き方RFCテキストのためのガイドライン"、BCP 72、RFC 3552、2003年7月。
Author's Address
著者のアドレス
Bruce Lilly
ブルース・リリー
EMail: blilly@erols.com
メールアドレス：blilly@erols.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書では、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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。