[要約] RFC 4249は、メッセージとMIMEパートのヘッダーフィールドとフィールドコンポーネントの実装者向けの仕様を提供しています。このRFCの目的は、ヘッダーフィールドとコンポーネントの構造と意味を明確に定義し、実装者がこれらを正しく解釈できるようにすることです。
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
メッセージとマイムパートのヘッダーフィールドとフィールドコンポーネントの実装者に優しい仕様
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).
Copyright（c）The Internet Society（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.
インターネットメッセージは、メッセージヘッダーとボディ[n1.std11]、[n2.rfc2822]で構成されています。MIMEコンテンツは、MIME-PARTヘッダー[N3.RFC2045]、[N4.RFC2046]で始まります。メッセージヘッダーとマイムパートヘッダーはフィールドで構成されています。メッセージ形式と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.
このメモは、ヘッダーフィールドの仕様[N1.STD11]、[N2.RFC2822]、[N3.RFC2046]、[N4.RFC2046]、[N5.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-Part [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.
メッセージヘッダーには、日付ヘッダーフィールド（つまり、フィールド名「日付」のフィールド）があります。ただし、「日付ヘッダー」はありません。このような標準以外の用語の使用は、混乱につながる可能性が高く、おそらく実装の相互運用性の障害をもたらす可能性があります。
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拡張フィールドに使用する必要があり、MIME拡張フィールドではないフィールド[N3.RFC2045]（セクション9）に使用しないでください。
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]でも使用されますが、そこには接頭辞として指定されていません）。フィールドのres版が適用される場合、著者は明示的に言う必要があり、プレーンフィールドと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].
リストの拡張が行われたときにメーリングリストに関する情報を示すために使用されます。定義されたフィールドの例は、[i4.rfc2369]および[i5.rfc2919]にあります。
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].
メッセージ処分通知（MDNS）と組み合わせて使用される情報の仕様[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]で使用されている元のメッサージID、オリジナルエンコードインフォメーションタイプ[i9.RFC2156]、元のエンベロープID [I10.RFC3464]、および元のレチピエント[i7.RFC3798]が含まれます。
Specifies a host that generated a type of report, such as those defined in [I7.RFC3798], [I10.RFC3464].
[i7.rfc3798]、[i10.rfc3464]で定義されているレポートなど、レポートの種類を生成したホストを指定します。
Used in conversion from X.400 environments by gateways [I9.RFC2156].
ゲートウェイによるX.400環境からの変換で使用されます[i9.RFC2156]。
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]は、ヘッダーフィールドの構文で、Whitespaceが許可または必要な場所についてあいまいです。[N2.RFC2822]は、FWSやCFWSなどの文法制作を定義し、正式なABNF [N7.RFC4234]と併せて、[N7.RFC4234]のセクション3.1に記載されているような問題の特異性の必要性に従って、その問題に対処します。拡張フィールド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]は、有用ないくつかのプロダクションを提供します。定義され、使用中の適切なプロダクションの使用が奨励されていますが、仕様著者は、そのようなプロダクションがその後RFCSおよび/または正式なErrata [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]統一資源識別子（URIS）、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によって登録されます。登録されたキーワードを使用した仕様には、IANAの考慮事項セクション[n9.BCP26]、[i16.RFC3692]を含める必要があり、IANAがレジストリを設定した仕様の読者に正確に示す必要があります（著者は、RFCとして公開される前にIANAと調整する必要があります）。多くの場合、キーワードのセットを拡張するための規定を作成することが望ましいでしょう。これは、RFCの公開によってセットが拡張されるか、正式なレビューおよび登録手順を指定することができることを指定することで行うことができます（通常はBCP 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進、octal、16進数などであるかどうかを明確に示す必要があります。リーディングおよび/またはトレーリングゼロが重要または/または許可されているかどうか。数値フィールドの組み合わせがどのように解釈されるか。たとえば、「001.100」、「1.1」、「1.075」、および「1.75」で例示されるドットで区切られた2つの数値フィールドは、上記のような要因に応じて、いくつかの方法で解釈される場合があります。
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 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]メッセージ内の各標準フィールドのヘッダーごとに最小カウントと最大カウントを指定します。仕様著者は、同様に、拡張フィールドの最小および最大カウントを指定する必要があります。
[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-Partヘッダー[N4.RFC2046]に表示される可能性があります。
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].
すべての仕様には、慎重に考慮されたセキュリティに関する考慮事項セクション[N12.RFC2223]（セクション9）、[I21.BCP72]が含まれることになっています。
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は、著者やRFCエディターと緊密に連携して、IANAが維持しているレジストリの説明が正確で意味のあることを確認することも奨励されています。
This document has exactly one (1) author.
このドキュメントには、ちょうど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.
このドキュメントのボイラープレートセクションに「/he」、「shey」、および "Authors」（複数）の存在は無関係です。このドキュメントの著者は、ボイラープレートテキストについて責任を負いません。
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] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[N2.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[N2.RFC2822] Resnick、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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、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] Freed、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] Bradner、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.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、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] Crocker、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]「RFC出版物のために提出されたインターネットドラフト（IDS）のチェックリスト」、http://www.ietf.org/id-checklist.html。
[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] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
Informative References
参考引用
[I1.FYI18] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
[i1.fyi18] Malkin、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "Hypertext Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[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] Neufeld、G。およびJ. Baer、「コアメールリストコマンドとメッセージヘッダーフィールドを介したトランスポートのメタシンタックスとしてのURLの使用」、RFC 2369、1998年7月。
[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。and G. Wenger、「List-ID：メーリングリストの識別のための構造化されたフィールドと名前空間」、RFC 2919、2001年3月。
[I6.RFC886] Rose, M., "Proposed standard for message header munging", RFC 886, December 1983.
[i6.rfc886] Rose、M。、「メッセージヘッダーマンギングの提案された標準」、RFC 886、1983年12月。
[I7.RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[i7.RFC3798] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、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. Crocker、「電子メールに基づくメッセージングサービスのコンテンツ交渉」、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 Internet X.400 Enhanced Relay）：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] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[I11.RFC987] Kille, S., "Mapping between X.400 and RFC 822", RFC 987, June 1986.
[I11.RFC987] Kille、S。、「X.400とRFC 822のマッピング」、RFC 987、1986年6月。
[I12.Errata] RFC-Editor errata page, http://www.rfc-editor.org/errata.html
[i12.errata] rfc-editor errataページ、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、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.
[I18.RFC2231] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、継続」、RFC 2231、1997年11月。
[I19.Syntax] Carpenter, B., "Syntax for format definitions", http://ietf.org/IESG/STATEMENTS/syntax-format-def.txt
[i19.syntax] Carpenter、B。、「フォーマット定義の構文」、http：//ietf.org/isg/statements/syntax-format-def.txt
[I20.Arch] Crocker, D., "Internet Mail Architecture", Work in Progress, March 2005.
[i20.arch] Crocker、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] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
Author's Address
著者の連絡先
Bruce Lilly
ブルース・リリー
EMail: blilly@erols.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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://ww.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）によって提供されます。