RFC4249 日本語訳
4249 Implementer-Friendly Specification of Message and MIME-PartHeader Fields and Field Components. B. Lilly. January 2006. (Format: TXT=28731 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Lilly Request for Comments: 4249 January 2006 Category: Informational
コメントを求めるワーキンググループB.リリー要求をネットワークでつないでください: 4249 2006年1月のカテゴリ: 情報
Implementer-Friendly Specification of Message and MIME-Part Header
Fields and Field Components
メッセージ、MIME部分ヘッダーフィールド、および分野コンポーネントのImplementerに優しい仕様
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)インターネット協会(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.
ヘッダーフィールドのジェネレータとパーサの実現はそれらの分野のある情報を必要とします。 分野に関する技術仕様書で明らかにそのようなすべての情報を提供するとき、相互運用性は最もありそうです。 そのような明示的な情報を欠いていて、implementersは推測するかもしれません、そして、相互運用性に苦しむかもしれません。 このメモはヘッダーフィールドジェネレータとパーサのimplementersの役に立つ情報を特定します。
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
1. 序論…2 2. 範囲…2 3. 仕様項目…3 3.1. コンベンションを設立します…3 3.1.1. 標準の用語…3 3.1.2. 規則とコンベンションを命名します…3 3.2. 一般的な仕様項目…5 3.2.1. ABNF…5 3.2.2. 1ヘッダーあたりの分野の最小の、そして、最大の例。6 3.2.3. 分類…7 3.3. 意味論…7 3.3.1. 生産者、修飾語、および消費者…7 3.3.2. それは何に関しますか? ................................7 3.3.3. 文脈…7 3.4. 総合的な問題…7 3.4.1. セキュリティ…8 3.4.2. 後方の互換性…8 3.4.3. 遺産内容との互換性…8
Lilly Informational [Page 1] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[1ページ]のRFC4249Specification
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
3.4.4. 確立したメカニズムとの相互作用…9 4. 承認…9 5. セキュリティ問題…9 6. 国際化問題…9 7. IANA問題…9 付録A.注意書き…10 標準の参照…11 有益な参照…11
1. Introduction
1. 序論
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]から成ります。 [N4.RFC2046]、MIME内容はMIME部分ヘッダー[N3.RFC2045]と共に始まります。 メッセージヘッダーとMIME部分ヘッダーは分野から成ります。 また、Message FormatとMIME仕様がそれらのそれぞれの総合的な書式といくつかの特定の分野を定義している間、それらには拡大分野への支給があります。 多くの拡大分野は他のものよりそれほどどんな完全にもそれ以上で指定されないというわけではありませんでした。 implementersが仕様がないとき仮定をするとき、不完全であるか不正確な仕様は相互運用性問題を引き起こしました。 このメモはimplementersへの潜在的関心の項目を特定します、そして、このメモのセクション3は拡大分野と分野コンポーネントの仕様の作者のための情報のガイドとして勤めるかもしれません。
2. Scope
2. 範囲
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.RFC2045]、[N4.RFC2046]、[N5.BCP9]、[N6.BCP90。] それはそれらに関するどんな条項か他の仕様と、ガイドラインと、手順への承諾からもヘッダーフィールド仕様の作者を解放しません。 それは相互運用性を促進して、仕様作者を割くかもしれない明確化と補っている提案に、不完全なヘッダーフィールド仕様に関する多くの質問を提供します。
Lilly Informational [Page 2] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[2ページ]のRFC4249Specification
3. Specification Items
3. 仕様項目
3.1. Established Conventions
3.1. 設立されたコンベンション
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.
多くのコンベンションが、ヘッダーフィールドを命名して、指定するために存在します。 それらのコンベンションと衝突する分野を指定するのは、賢明でなくて、紛らわしいでしょう。
3.1.1. Standard Terminology
3.1.1. 標準の用語
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.
インターネットMessage Formatに関連する用語は[N2.RFC2822]で定義されます。 拡大ヘッダーフィールドを指定する作者は、明快を提供して、混乱を避けるのに同じ方法による同じ用語を使用するべきです。 例えば、「ヘッダー」[I1.FYI18]、[N2.RFC2822]は、「ヘッダーフィールド」から成って、通常、「分野本体」を持っています。それはそれぞれ「フィールド名」を持っています。 各メッセージは、複数の「ヘッダー」、つまりメッセージヘッダーがあって、[N4.RFC2046]ヘッダーをMIMEで分けるかもしれません。
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ヘッダーフィールド(すなわち、「日付」というフィールド名がある分野)があります。 しかしながら、「日付のヘッダー」が全くありません。 ことによると実現の相互運用性失敗をもたらして、そのような非標準の用語の使用は混乱に通じそうです。
3.1.2. Naming Rules and Conventions
3.1.2. 規則とコンベンションを命名します。
Several rules and conventions have been established for naming of header fields. Rules are codified in published RFCs; conventions reflect common use.
いくつかの規則とコンベンションはヘッダーフィールドの命名のために確立されました。 規則は発行されたRFCsで成文化されます。 コンベンションは一般の使用を反映します。
3.1.2.1. Naming Rules
3.1.2.1. 規則を命名します。
Some RFCs define a particular prefix, reserving use of that prefix for specific purposes.
特定の目的でその接頭語の使用を控えて、いくつかのRFCsが特定の接頭語を定義します。
3.1.2.1.1. Content- prefix rule
3.1.2.1.1. 内容接頭語規則
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)でない分野に使用されてはいけません。
3.1.2.1.2. Resent- prefix rule
3.1.2.1.2. 接頭語規則に憤慨してください。
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バージョンのどんな違いの包括的な仕様も提供するべきです。
Lilly Informational [Page 3] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[3ページ]のRFC4249Specification
3.1.2.2. Naming Conventions
3.1.2.2. 命名規則
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.
いくつかの接頭語がコンベンションとして展開しました。 予約された接頭語として正式に指定されませんが、これらのコンベンションは、あるか、または各接頭語に、複数の分野で一般的な意味論で使用中です。
3.1.2.2.1. Accept- prefix convention
3.1.2.2.1. 接頭語コンベンションを受け入れてください。
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]で見つけられるかもしれません。
3.1.2.2.2. List- prefix convention
3.1.2.2.2. リスト接頭語コンベンション
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]で定義された分野に関する例を見つけることができます。
3.1.2.2.3. Illegal- prefix convention
3.1.2.2.3. 不法な接頭語コンベンション
This prefix provides a record of illegal content in a field when fields are transformed at a gateway [I6.RFC886].
分野がゲートウェイ[I6.RFC886]で変えられるとき、この接頭語は違法コンテンツに関する記録を分野に提供します。
3.1.2.2.4. Disposition-Notification- prefix convention
3.1.2.2.4. 気質、-コンベンションを通知で前に置いてください。
Specification of information used in conjunction with Message Disposition Notifications (MDNs) [I7.RFC3798].
情報の仕様はMessage Disposition Notificationsに関連して(MDNs)[I7.RFC3798]を使用しました。
3.1.2.2.5. Original- prefix convention
3.1.2.2.5. オリジナルの接頭語コンベンション
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]、Originalが情報タイプをコード化しているOriginal Envelope ID[I10.RFC3464]、およびOriginal-受取人[I7.RFC3798]によって使用されるように例はOriginal Message IDを含んでいます。
3.1.2.2.6. Reporting- prefix
3.1.2.2.6. 報告接頭語
Specifies a host that generated a type of report, such as those defined in [I7.RFC3798], [I10.RFC3464].
[I7.RFC3798]で定義されたものなどのように一種のレポート[I10.RFC3464]を発生させたホストを指定します。
3.1.2.2.7. X400- prefix convention
3.1.2.2.7. X400接頭語コンベンション
Used in conversion from X.400 environments by gateways [I9.RFC2156].
変換では、X.400環境から、ゲートウェイ[I9.RFC2156]のそばで使用されています。
3.1.2.2.8. Discarded-X400- prefix convention
3.1.2.2.8. 捨てられたX400-接頭語のコンベンション
Also used by gateways from X.400 [I9.RFC2156].
また、X.400[I9.RFC2156]からのゲートウェイのそばで使用されています。
Lilly Informational [Page 4] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[4ページ]のRFC4249Specification
3.1.2.2.9. P1- prefix convention
3.1.2.2.9. P1接頭語コンベンション
Was used by X.400 gateways [I11.RFC987].
X.400ゲートウェイ[I11.RFC987]で、使用されました。
3.1.2.2.10. Delivery-Report-Content- prefix convention
3.1.2.2.10. 配送レポート満足している接頭語のコンベンション
Also used by legacy X.400 gateways [I11.RFC987].
また、遺産X.400ゲートウェイ[I11.RFC987]のそばで使用されています。
3.2. Common Specification Items
3.2. 一般的な仕様項目
Several items are specified for standard header fields; these items should also be specified for extension fields.
数個の項目が標準のヘッダーフィールドに指定されます。 また、これらの項目は拡大分野に指定されるべきです。
3.2.1. ABNF
3.2.1. ABNF
[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]は空白がヘッダーフィールド構文で受入れられるか、または必要であるところに関してあいまいです。 [N2.RFC2822]は、正式なABNF[N7.RFC4234]に関連した[N7.RFC4234]のセクション3.1で注意されるような問題の特異性の必要性に従ってFWSやCFWSなどの文法創作を定義することによって、その問題を記述します。 拡大分野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].
あいまいさ、すべての創作が、端末の創作の何らかの組み合わせに、[N8.CKLIST]が引用規格で提供していた(「すべてのABNFをチェックしなければならない」)と決議するのを保証するために丹念にすべてのABNFをチェックしなければなりません。 [N7.RFC4234]はいくつかの役に立つかもしれない創作を提供します。 定義されて使用中の適当な創作の使用は奨励されますが、仕様作者はそのようないくつかの創作が次に発行されたRFCs正式な誤字[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]Uniform Resource Identifier(URI)です。(そのUniform Resource Identifierは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
構造化された分野でキーワードをプロトコル要素と定義するのは、時々必要であるか、または望ましいです。 プロトコル要素はインターネットArchitecture[I15.RFC1958](セクション4.3)単位で大文字と小文字を区別しないはずです。 キーワードはIANAによって通常登録されます。 登録されたキーワードを使用する仕様が、IANA Considerations部[N9.BCP26]、[I16.RFC3692]を含まなければならなくて、IANAが正確にどこに登録をセットアップしたかを仕様の読者に示すべきである、(作者
Lilly Informational [Page 5] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[5ページ]のRFC4249Specification
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).
公表の前のIANAと共にRFCとしてこれを調整する意志の必要性) 多くの場合、キーワードのセットを広げることへの設備をするのは望ましいでしょう。 セットが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つの特定のケースだけに適用されることに注意してください: 不統一な分野、RFC822のRFC822「単語」は、構造化された分野で「言葉で表し」て、コメントします。 どんな国際化問題も[N11.BCP18](セクション6)の指定されるとしての仕様のInternationalization Considerations部で詳細であるべきです。
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と、コメントと、標準のテキストを支持するのは、そのような数値が小数、8進、16進であるかどうかなどを明確に示すべきです。 主である、そして/または、引きずるか否かに関係なく、ゼロは、重要である、そして/または、受入れられます。 そして、数字フィールドのどんな組み合わせも解釈されることをどう意図するか。 例えば、2つの数字フィールドが例示されたドットで分離した、「1.1インチ、「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]で使用されるかもしれません。
3.2.2. Minimum and Maximum Instances of Fields per Header
3.2.2. 1ヘッダーあたりの分野の最小の、そして、最大の例
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]は指定します。
Lilly Informational [Page 6] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[6ページ]のRFC4249Specification
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.
最小限と最大はヘッダー単位でメッセージのそれぞれの標準の分野に重要です。 仕様作者は同様に拡大分野のための最小の、そして、最大のカウントを指定するべきです。
3.2.3. Categorization
3.2.3. 分類
[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]はヘッダーフィールド(例えば、跡の分野、アドレス・フィールド)のカテゴリを定義します。 そのようなカテゴリに、分野の処理と取り扱いのための意味があります。 仕様作者はどんな適切なカテゴリも示すべきです。
3.3. Semantics
3.3. 意味論
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:
分野の構文を指定することに加えて、仕様ドキュメントはそれぞれの分野の意味論を示すはずです。 そのような意味論はいくつかの局面で構成されます:
3.3.1. Producers, Modifiers, and Consumers
3.3.1. 生産者、修飾語、および消費者
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]の仲介者は、そのような分野を発生するべきではありませんし、また変更するべきではありません。 他の分野は輸送の間に加えられるトレース情報を包括します。 作者は、だれがだれが分野を発生させるかもしれないか、そして、だれがトランジットでそれを変更するかもしれないか、そして、だれがそのような分野を解釈するべきであるか、そして、分野を解釈するか、または変更するのが禁止されているかを明確に指定するべきです。
3.3.2. What's it all about?
3.3.2. それは何に関しますか?
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.
新しい野原を挿入するか、または既存の分野を変更するとき、作者は、どんな問題か状況が拡大で記述されるかに関する明確な記述を提示するべきであるか、または変化するべきです。
3.3.3. Context
3.3.3. 文脈
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メディアタイプで現れるかもしれません。
3.4. Overall Considerations
3.4. 総合的な問題
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.
分野がそれが意図するアプリケーションと、他のアプリケーションと対話する際にどう全体のインターネットと対話するかに関していくつかの要素が指定されるべきです。
Lilly Informational [Page 7] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[7ページ]のRFC4249Specification
3.4.1. Security
3.4.1. セキュリティ
Every specification is supposed to include a carefully-considered Security Considerations section [N12.RFC2223] (section 9), [I21.BCP72].
[I21.BCP72]、あらゆる仕様が慎重に考えられたSecurity Considerations部[N12.RFC2223](セクション9)を含むべきです。
3.4.2. Backward Compatibility
3.4.2. 後方の互換性
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.
プレーに入るかもしれない多くの微妙さと変化があります。 作者は、拡大について工夫するとき、非常に慎重に後方の互換性を考えるべきであり、明確にすべての知られている互換性の問題について説明するべきです。
3.4.3. Compatibility With Legacy Content
3.4.3. 遺産内容との互換性
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内容のメッセージか断片に新しい意味論を授与するとして拡大分野か分野コンポーネントの存在の不足を解釈しないのは(ファイル拡張仕様書で)重要です。 どんなそのような意味論も明らかに指定されるべきです。
Lilly Informational [Page 8] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[8ページ]のRFC4249Specification
3.4.4. Interaction With Established Mechanisms
3.4.4. 確立したメカニズムとの相互作用
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]がこれがどう扱われるかもしれないかに関する例である、(しかしながら、その仕様が、2046を従わせている配備されたRFC実現が変更されるのを必要とするのでそれが厳密に後方でない、コンパチブル、)
4. Acknowledgements
4. 承認
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メーリングリストのメンバーによって提供された役に立つコメントを承諾したがっています。 ピーター・コッホとキース・ムーアは役に立つコメントを特に、しました。
5. Security Considerations
5. セキュリティ問題
No new security considerations are addressed by this memo. The memo reinforces the need for careful consideration and specification of security issues.
どんな新しいセキュリティ問題もこのメモで記述されません。 メモは安全保障問題の熟慮と仕様の必要性を補強します。
6. Internationalization Considerations
6. 国際化問題
This memo does not directly have internationalization considerations; however, it reminds specification authors of the need to consider internationalization of textual field components.
このメモには、国際化問題が直接ありません。 しかしながら、それは、原文の分野コンポーネントの国際化を考えるように必要性の仕様作者に思い出させます。
7. IANA Considerations
7. IANA問題
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 Editorと共に密接に調整するはずであるので、登録は、セットアップされて、そのような登録について言及するRFCの公表時点で、適切に参照をつけられます。 また、IANAがIANAによって維持された登録の記述が確実に正確で重要になるようにするために作者とRFC Editorと共に緊密に働くよう奨励されます。
Lilly Informational [Page 9] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[9ページ]のRFC4249Specification
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.
「」 /の存在、彼女、」、「」 このドキュメントの決まり文句の部のそれらの「作者」(複数)は無関係です。 このドキュメントの作者は決まり文句のテキストに責任がありません。
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に向けられるべきです。
Lilly Informational [Page 10] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[10ページ]のRFC4249Specification
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インターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[N2.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[N2.RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[N5.BCP9] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[N5.BCP9] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、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.ムガール人、「メッセージヘッダーフィールドのための登録手順」BCP90、2004年9月のRFC3864。
[N7.RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[N7.RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[N8.CKLIST] "Checklist for Internet-Drafts (IDs) submitted for RFC
publication", http://www.ietf.org/ID-Checklist.html.
[N8.CKLIST] 「インターネット草稿(ID)のためのチェックリストはRFC公表のために提出した」 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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[N10.BCP82] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[N10.BCP82] Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、2004年1月。
[N11.BCP18] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[N11.BCP18] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[N12.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997.
[N12.RFC2223] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
Informative References
有益な参照
[I1.FYI18] Malkin, G., "Internet Users' Glossary", FYI 18, RFC
1983, August 1996.
[I1.FYI18] マルキン、G.、「インターネットユーザの用語集」、FYI18、RFC1983、1996年8月。
Lilly Informational [Page 11] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[11ページ]のRFC4249Specification
[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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[I3.RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002.
[I3.RFC3282]Alvestrand(H.、「満足している言語ヘッダー」、RFC3282)は2002がそうするかもしれません。
[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.ベヤー、「CoreメールList CommandsとMessage Headerフィールズを通した彼らのTransportのためのMeta構文としてのURLのUse」、RFC2369、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.、およびG.ウェンガー、「リストイド:」 「メーリングリストの識別のための構造化された分野と名前空間」(RFC2919)は2001を行進させます。
[I6.RFC886] Rose, M., "Proposed standard for message header
munging", RFC 886, December 1983.
[I6.RFC886] ローズ、M.、「メッセージヘッダーの変更を加えることの提案された標準」、RFC886、1983年12月。
[I7.RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[I7.RFC3798] ハンセン、T.、およびG.ボードルイ(「メッセージ気質通知」、RFC3798)は2004がそうするかもしれません。
[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.クロッカー、「メッセージサービスのためのNegotiationがメールに基礎づけた内容」、RFC3297、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.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、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.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[I11.RFC987] Kille, S., "Mapping between X.400 and RFC 822", RFC
987, June 1986.
[I11.RFC987]Kille、S.、「X.400とRFC822インチの間のマッピング、RFC987、6月1986日
[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] 1999年3月のKlyne、G.、「特徴が設定するメディアを説明するための構文」RFC2533。
[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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[I15.RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[I15.RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
Lilly Informational [Page 12] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[12ページ]のRFC4249Specification
[I16.RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[I16.RFC3692] Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、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.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、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]、N.、およびK.ムーア、「パラメタ値をまねてください、そして、コード化されて、拡大を言い表してください」 「文字コード、言語、および続刊」、RFC2231、11月1997日
[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.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
Author's Address
作者のアドレス
Bruce Lilly
ブルース・リリー
EMail: blilly@erols.com
メール: blilly@erols.com
Lilly Informational [Page 13] RFC 4249 Specification of Header Fields January 2006
ヘッダーフィールド2006年1月のリリー情報[13ページ]のRFC4249Specification
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Lilly Informational [Page 14]
リリーInformationalです。[14ページ]
一覧
スポンサーリンク
