Network Working Group B. Lilly
Request for Comments: 4249 January 2006
Category: Informational
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
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
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.
Internet消息由消息头和正文组成[N1.STD11]，[N2.RFC2822]。MIME内容以MIME部分头[N3.RFC2045]、[N4.RFC2046]开头。消息头和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.
本备忘录旨在作为标题字段规范[N1.STD11]、[N2.RFC2822]、[N3.RFC2045]、[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]中定义了与互联网消息格式相关的术语。指定扩展标题字段的作者应该以相同的方式使用相同的术语，以提供清晰性并避免混淆。例如，“header”[I1.FYI18]，[N2.RFC2822]由“header字段”组成，每个字段都有一个“字段名”，并且通常有一个“字段体”。每条消息可能有多个“标题”，即。消息头和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.
消息头有一个日期头字段（即字段名为“日期”的字段）。但是，没有“日期标题”；使用此类非标准术语可能会导致混淆，可能导致实现的互操作性失败。
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]使用，但未在其中指定为前缀）。如果某个字段的最新版本是适用的，那么作者应该明确地这样说，并且应该提供一个关于普通字段和最新版本之间任何差异的全面规范。
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].
与消息处置通知（MDN）一起使用的信息规范[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]对于头字段语法中允许或需要空格的位置含糊不清。[N2.RFC2822]通过定义语法产物，如FWS和CFW，结合正式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]提供了几种可能有用的产品。虽然鼓励使用已定义和正在使用的合适产品，但规范作者应注意，一些此类产品已通过随后发布的RFC和/或正式勘误表[I12.勘误表]进行了修订。
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
有时有必要或希望在结构化字段中将关键字定义为协议元素。根据互联网体系结构[I15.RFC1958]（第4.3节），协议元素应不区分大小写。关键词通常由IANA注册；使用注册关键字的规范必须包括IANA注意事项部分[N9.BCP26]，[I16.RFC3692]，并应向规范读者准确指出IANA在何处设置了注册表（作者）
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).
在作为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节）规定指定语言。标题字段通常使用[I17.RFC2047]中指定的机制，并由[I18.RFC2231]和[I12.Errata]对此进行了修订。但是，请注意，该机制仅适用于三种特定情况：非结构化字段、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、其注释和支持性规范性文本应明确说明此类数值是否为十进制、八进制、十六进制等。；前导零和/或尾随零是否有效和/或允许；以及如何解释数字字段的任何组合。例如，以“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].
虽然[N2.RFC2822]使用ABNF[N7.RFC4234]并在上面提到过，但在规范[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.rfc246]以及消息头中，还有一些字段可能出现在专门的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].
每个规范都应该包括一个经过仔细考虑的安全注意事项部分[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.
本文件样板部分中的“/她”、“他们的”和“作者”（复数）与此无关。本文件的作者不对样板文本负责。
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，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年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，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年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发布的互联网草稿（ID）检查表”，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，“在RFC中编写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.“互联网用户词汇表”，FYI18，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.，弗里斯蒂克，H.，马斯特，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.，“内容语言标题”，RFC32822002年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.和G.Wenger，“列表Id：用于识别邮件列表的结构化字段和名称空间”，RFC 2919，2001年3月。
[I6.RFC886] Rose, M., "Proposed standard for message header munging", RFC 886, December 1983.
[I6.RFC886]Rose，M.，“消息头munging的拟议标准”，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.，“混音器（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]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 page,
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.“描述媒体功能集的语法”，RFC2533，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，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[I15.RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[I15.RFC1958]Carpenter，B.，“互联网的架构原则”，RFC 19581996年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]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非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 22311997年11月。
[I19.Syntax] Carpenter, B., "Syntax for format definitions",
http://ietf.org/IESG/STATEMENTS/syntax-format-def.txt
[I19.Syntax] Carpenter, B., "Syntax for format definitions",
http://ietf.org/IESG/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
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。