Network Working Group K. Murchison, Ed.
Request for Comments: 5536 Carnegie Mellon University
Obsoletes: 1036 C. Lindsey
Category: Standards Track University of Manchester
D. Kohn
Healing Thresholds
November 2009
Network Working Group K. Murchison, Ed.
Request for Comments: 5536 Carnegie Mellon University
Obsoletes: 1036 C. Lindsey
Category: Standards Track University of Manchester
D. Kohn
Healing Thresholds
November 2009
Netnews Article Format
网络新闻文章格式
Abstract
摘要
This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents.
本文档指定了互联网消息格式（RFC 5322）和多用途互联网邮件扩展（MIME）（RFC 2045）上下文中Netnews文章的语法。本文件废除了RFC 1036，提供了反映当前实践的更新规范，并纳入了其他文件中规定的增量变更。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。未从控制人处获得足够的许可证
the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
此类材料、本文件的版权不得在IETF标准流程之外进行修改，其衍生作品不得在IETF标准流程之外创建，除非将其格式化为RFC或将其翻译为英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Basic Concepts .............................................4
1.2. Scope ......................................................4
1.3. Requirements Notation ......................................4
1.4. Syntax Notation ............................................5
1.5. Definitions ................................................5
1.6. Structure of This Document .................................7
2. Format ..........................................................7
2.1. Base .......................................................7
2.2. Header Fields ..............................................8
2.3. MIME Conformance ...........................................9
3. News Header Fields ..............................................9
3.1. Mandatory Header Fields ...................................10
3.1.1. Date ...............................................11
3.1.2. From ...............................................11
3.1.3. Message-ID .........................................11
3.1.4. Newsgroups .........................................13
3.1.5. Path ...............................................14
3.1.6. Subject ............................................16
3.2. Optional Header Fields ....................................16
3.2.1. Approved ...........................................17
3.2.2. Archive ............................................17
3.2.3. Control ............................................17
3.2.4. Distribution .......................................18
3.2.5. Expires ............................................19
3.2.6. Followup-To ........................................19
3.2.7. Injection-Date .....................................20
3.2.8. Injection-Info .....................................20
3.2.9. Organization .......................................22
3.2.10. References ........................................22
3.2.11. Summary ...........................................23
3.2.12. Supersedes ........................................23
3.2.13. User-Agent ........................................23
3.2.14. Xref ..............................................24
3.3. Obsolete Header Fields ....................................25
3.3.1. Lines ..............................................25
4. Internationalization Considerations ............................25
5. Security Considerations ........................................25
6. IANA Considerations ............................................26
7. References .....................................................31
7.1. Normative References ......................................31
7.2. Informative References ....................................32
Appendix A. Acknowledgments ......................................34
Appendix B. Differences from RFC 1036 and Its Derivatives ........34
Appendix C. Differences from RFC 5322 ............................35
1. Introduction ....................................................4
1.1. Basic Concepts .............................................4
1.2. Scope ......................................................4
1.3. Requirements Notation ......................................4
1.4. Syntax Notation ............................................5
1.5. Definitions ................................................5
1.6. Structure of This Document .................................7
2. Format ..........................................................7
2.1. Base .......................................................7
2.2. Header Fields ..............................................8
2.3. MIME Conformance ...........................................9
3. News Header Fields ..............................................9
3.1. Mandatory Header Fields ...................................10
3.1.1. Date ...............................................11
3.1.2. From ...............................................11
3.1.3. Message-ID .........................................11
3.1.4. Newsgroups .........................................13
3.1.5. Path ...............................................14
3.1.6. Subject ............................................16
3.2. Optional Header Fields ....................................16
3.2.1. Approved ...........................................17
3.2.2. Archive ............................................17
3.2.3. Control ............................................17
3.2.4. Distribution .......................................18
3.2.5. Expires ............................................19
3.2.6. Followup-To ........................................19
3.2.7. Injection-Date .....................................20
3.2.8. Injection-Info .....................................20
3.2.9. Organization .......................................22
3.2.10. References ........................................22
3.2.11. Summary ...........................................23
3.2.12. Supersedes ........................................23
3.2.13. User-Agent ........................................23
3.2.14. Xref ..............................................24
3.3. Obsolete Header Fields ....................................25
3.3.1. Lines ..............................................25
4. Internationalization Considerations ............................25
5. Security Considerations ........................................25
6. IANA Considerations ............................................26
7. References .....................................................31
7.1. Normative References ......................................31
7.2. Informative References ....................................32
Appendix A. Acknowledgments ......................................34
Appendix B. Differences from RFC 1036 and Its Derivatives ........34
Appendix C. Differences from RFC 5322 ............................35
"Netnews" is a set of protocols for generating, storing, and retrieving news "articles" (whose format is a subset of that for Email messages), and for exchanging them amongst a readership that is potentially widely distributed. It is organized around "newsgroups", with the expectation that each reader will be able to see all articles posted to each newsgroup in which he participates. These protocols most commonly use a flooding algorithm, which propagates copies throughout a network of participating servers. Typically, only one copy is stored per server, and each server makes it available on demand to readers who are able to access that server.
“网络新闻”是一套协议，用于生成、存储和检索新闻“文章”（其格式是电子邮件格式的子集），以及在可能广泛分布的读者群之间交换新闻。它是围绕“新闻组”组织的，期望每个读者都能看到他所参与的每个新闻组的所有文章。这些协议通常使用泛洪算法，该算法通过参与服务器的网络传播副本。通常，每台服务器只存储一份副本，并且每台服务器都使能够访问该服务器的读者可以根据需要使用该副本。
This document specifies the syntax of Netnews articles in the context of the Internet Message Format [RFC5322] and Multipurpose Internet Mail Extensions (MIME) [RFC2045]. This document obsoletes [RFC1036], updating the syntax of Netnews articles to reflect current practice and incorporating changes and clarifications specified in other documents such as [Son-of-1036].
本文档指定了互联网消息格式[RFC5322]和多用途互联网邮件扩展（MIME）[RFC2045]上下文中Netnews文章的语法。本文件废除了[RFC1036]，更新了Netnews文章的语法以反映当前实践，并纳入了其他文件（如[Son-of-1036]）中规定的变更和澄清。
This is the first in a set of documents that obsolete [RFC1036]. This document focuses on the syntax and semantics of Netnews articles. [RFC5537] is also a Standards Track document and describes the protocol issues of Netnews articles, independent of transport protocols such as the Network News Transfer Protocol (NNTP) [RFC3977]. [USEAGE], "Usenet Best Practice", describes implementation recommendations to improve interoperability and usability.
这是一组过时的文档[RFC1036]中的第一个。本文档重点介绍Netnews文章的语法和语义。[RFC5537]也是一份标准跟踪文档，描述了Netnews文章的协议问题，独立于传输协议，如网络新闻传输协议（NNTP）[RFC3977]。[USEAGE]“Usenet最佳实践”描述了改进互操作性和可用性的实施建议。
This specification is intended as a definition of what article content format is to be passed between systems. Although many news systems locally store articles in this format (which eliminates the need for translation between formats), local storage is outside of the scope of this standard.
本规范旨在定义系统之间要传递的文章内容格式。尽管许多新闻系统在本地以这种格式存储文章（这消除了格式之间转换的需要），但本地存储不在本标准的范围之内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Header fields defined in this specification use the Augmented Backus-Naur Form (ABNF) notation (including the Core Rules) specified in [RFC5234] as well as many constructs defined in [RFC5322], [RFC2045] as updated by [RFC2231], and [RFC3986]. Specifically:
本规范中定义的标题字段使用[RFC5234]中指定的扩展巴科斯诺尔形式（ABNF）表示法（包括核心规则）以及[RFC5322]、[RFC2045]中定义的许多构造（由[RFC2231]和[RFC3986]更新）。明确地：
token = <see RFC 2045 Section 5.1>
value = <see RFC 2045 Section 5.1>
parameter = <see RFC 2231 Section 7>
attribute = <see RFC 2231 Section 7>
token = <see RFC 2045 Section 5.1>
value = <see RFC 2045 Section 5.1>
parameter = <see RFC 2231 Section 7>
attribute = <see RFC 2231 Section 7>
FWS = <see RFC 5322 Section 3.2.2>
comment = <see RFC 5322 Section 3.2.2>
CFWS = <see RFC 5322 Section 3.2.2>
atext = <see RFC 5322 Section 3.2.3>
dot-atom-text = <see RFC 5322 Section 3.2.3>
phrase = <see RFC 5322 Section 3.2.5>
date-time = <see RFC 5322 Section 3.3>
mailbox = <see RFC 5322 Section 3.4>
mailbox-list = <see RFC 5322 Section 3.4>
address-list = <see RFC 5322 Section 3.4>
body = <see RFC 5322 Section 3.5>
fields = <see RFC 5322 Section 3.6>
FWS = <see RFC 5322 Section 3.2.2>
comment = <see RFC 5322 Section 3.2.2>
CFWS = <see RFC 5322 Section 3.2.2>
atext = <see RFC 5322 Section 3.2.3>
dot-atom-text = <see RFC 5322 Section 3.2.3>
phrase = <see RFC 5322 Section 3.2.5>
date-time = <see RFC 5322 Section 3.3>
mailbox = <see RFC 5322 Section 3.4>
mailbox-list = <see RFC 5322 Section 3.4>
address-list = <see RFC 5322 Section 3.4>
body = <see RFC 5322 Section 3.5>
fields = <see RFC 5322 Section 3.6>
IPv6address = <see RFC 3986 Section 3.2.2>
IPv4address = <see RFC 3986 Section 3.2.2>
IPv6address = <see RFC 3986 Section 3.2.2>
IPv4address = <see RFC 3986 Section 3.2.2>
ALPHA = <see RFC 5234 Appendix B.1>
CRLF = <see RFC 5234 Appendix B.1>
DIGIT = <see RFC 5234 Appendix B.1>
DQUOTE = <see RFC 5234 Appendix B.1>
SP = <see RFC 5234 Appendix B.1>
VCHAR = <see RFC 5234 Appendix B.1>
ALPHA = <see RFC 5234 Appendix B.1>
CRLF = <see RFC 5234 Appendix B.1>
DIGIT = <see RFC 5234 Appendix B.1>
DQUOTE = <see RFC 5234 Appendix B.1>
SP = <see RFC 5234 Appendix B.1>
VCHAR = <see RFC 5234 Appendix B.1>
Additionally, Section 3.1.3 specifies a stricter definition of <msg-id> than the syntax in Section 3.6.4 of [RFC5322].
此外，第3.1.3节规定了比[RFC5322]第3.6.4节中的语法更严格的<msg id>定义。
An "article" is the unit of Netnews, analogous to an [RFC5322] "message". A "proto-article" is one that has not yet been injected into the news system. In contrast to an article, a proto-article may lack some mandatory header fields.
“文章”是网络新闻的单位，类似于[RFC5322]“消息”。“原始文章”是尚未注入新闻系统的文章。与文章不同，原型文章可能缺少一些必需的标题字段。
A "message identifier" (Section 3.1.3) is a unique identifier for an article, usually supplied by the user agent that posted it or, failing that, by the "news server". It distinguishes the article
“消息标识符”（第3.1.3节）是文章的唯一标识符，通常由发布该文章的用户代理提供，否则由“新闻服务器”提供。它区分了这篇文章
from every other article ever posted anywhere. Articles with the same message identifier are treated as if they are the same article regardless of any differences in the body or header fields.
从任何地方张贴的其他文章。具有相同消息标识符的项目将被视为相同的项目，而不考虑正文或标题字段中的任何差异。
A "newsgroup" is a forum having a name and that is intended for articles on a specific topic. An article is "posted to" a single newsgroup or several newsgroups. When an article is posted to more than one newsgroup, it is said to be "crossposted"; note that this differs from posting the same text as part of each of several articles, one per newsgroup.
“新闻组”是一个有名称的论坛，用于发表特定主题的文章。一篇文章“发布到”单个新闻组或多个新闻组。当一篇文章被发布到多个新闻组时，它被称为“交叉发布”；请注意，这不同于将相同的文本作为多篇文章的一部分发布，每个新闻组发布一篇。
A newsgroup may be "moderated", in which case submissions are not posted directly, but mailed to a "moderator" for consideration and possible posting. Moderators are typically human but may be implemented partially or entirely in software.
一个新闻组可能会被“主持人”，在这种情况下，提交的内容不会直接发布，而是邮寄给“主持人”，以供考虑和可能的发布。版主通常是人，但可以部分或全部在软件中实现。
A "poster" is the person or software that composes and submits a potentially compliant article to a user agent.
“海报”是编写并向用户代理提交潜在合规文章的人员或软件。
A "reader" is the person or software reading Netnews articles.
“读者”是指阅读网络新闻文章的人或软件。
A "followup" is an article containing a response to the contents of an earlier article, its "precursor". Every followup includes a "References" header field identifying that precursor (but note that non-followup articles may also use a References header field).
“后续”是一篇文章，包含对前一篇文章（即其“前身”）内容的回应。每个后续文章都包含一个“References”标题字段，用于标识该前驱体（但请注意，非后续文章也可能使用References标题字段）。
A "control message" is an article that is marked as containing control information; a news server receiving such an article may (subject to the policies observed at that site) take actions beyond just filing and passing on the article.
“控制信息”是标记为包含控制信息的物品；接收此类文章的新闻服务器可能（根据该网站遵守的政策）采取的行动不仅仅是归档和传递文章。
A news server is software that may accept articles from a user agent, and/or make articles available to user agents, and/or exchange articles with other news servers.
新闻服务器是一种软件，它可以接受来自用户代理的文章，和/或使文章可供用户代理使用，和/或与其他新闻服务器交换文章。
A "user agent" is software that may help posters submit proto-articles to a news server, and/or fetch articles from a news server and present them to a reader, and/or assist the reader in creating articles and followups.
“用户代理”是一种软件，可以帮助海报向新闻服务器提交原型文章，和/或从新闻服务器获取文章并将其呈现给读者，和/或帮助读者创建文章和后续文章。
The generic term "agent" is used when describing requirements that apply to both user agents and news servers.
通用术语“代理”用于描述适用于用户代理和新闻服务器的需求。
An agent is said to "generate" a construct if it did not exist before the agent created it. Examples are when a user agent creates a message from text and addressing information supplied by a user, or when a news server creates an "Injection-Info" header field for a newly posted message.
如果在代理创建一个构造之前它不存在，那么代理被称为“生成”一个构造。例如，用户代理根据用户提供的文本和地址信息创建消息，或者新闻服务器为新发布的消息创建“注入信息”标题字段。
An agent is said to "accept" a construct if some other entity generates it and passes it to the agent in question, and the agent processes it without treating it as a format or protocol error.
如果某个其他实体生成一个构造并将其传递给相关的代理，则代理称为“接受”该构造，并且代理处理该构造时不会将其视为格式或协议错误。
This document uses a cite-by-reference methodology, rather than repeating the contents of other standards, which could otherwise result in subtle differences and interoperability challenges. Although this document is as a result rather short, it requires complete understanding and implementation of the normative references to be compliant.
本文档使用引用方法，而不是重复其他标准的内容，否则可能导致细微差异和互操作性挑战。尽管本文件因此相当简短，但它要求完全理解和执行规范性参考文件，以符合要求。
Section 2 defines the format of Netnews articles. Section 3 details the header fields necessary to make an article suitable for the Netnews environment.
第2节定义了Netnews文章的格式。第3节详细介绍了使文章适合Netnews环境所需的标题字段。
An article is said to be conformant to this specification if it conforms to the format specified in Section 3 of [RFC5322] and to the additional requirements of this specification.
如果物品符合[RFC5322]第3节规定的格式和本规范的附加要求，则称其符合本规范。
An article that uses the obsolete syntax specified in Section 4 of [RFC5322] is NOT conformant to this specification, except for the following two cases:
使用[RFC5322]第4节中规定的过时语法的文章不符合本规范，以下两种情况除外：
o Articles are conformant if they use the <obs-phrase> construct (use of a phrase like "John Q. Public" without the use of quotes, see Section 4.1 of [RFC5322]), but agents MUST NOT generate productions of such syntax.
o 如果文章使用<obs phrase>结构（使用“John Q.Public”之类的短语而不使用引号，请参见[RFC5322]第4.1节），则文章是一致的，但代理不得生成此类语法的产物。
o Articles are conformant if they use the "GMT" <zone>, as specified in Section 3.1.1.
o 按照第3.1.1节的规定，如果物品使用“GMT”<zone>，则物品符合规定。
This document, and specifications that build upon it, specify how to handle conformant articles. Handling of non-conformant articles is outside the scope of this specification.
本文档及其基础规范规定了如何处理一致性条款。不合格品的处理不在本规范范围内。
Agents conforming to this specification MUST generate only conformant articles.
符合本规范的代理必须仅生成符合要求的物品。
The text below uses ABNF to specify restrictions on the syntax specified in [RFC5322]; this grammar is intended to be more restrictive than the [RFC5322] grammar. Articles must conform to the
下面的文本使用ABNF指定对[RFC5322]中指定语法的限制；该语法比[RFC5322]语法更具限制性。物品必须符合规定
ABNF specified in [RFC5322] and also to the restrictions specified here, both those that are expressed as text and those that are expressed as ABNF.
[RFC5322]中规定的ABNF，以及此处规定的限制，包括以文本表示的限制和以ABNF表示的限制。
NOTE: Other specifications use the term "header" as a synonym for what [RFC5322] calls "header field". This document follows the terminology in Section 2 of [RFC5322] in using the terms "line", "header field", "header field name", "header field body", and "folding", based on a belief that consistent terminology among specifications that depend on each other makes the specifications easier to use in the long run.
注：其他规范使用术语“标题”作为[RFC5322]所称“标题字段”的同义词。本文件遵循[RFC5322]第2节中的术语，使用术语“行”、“标题字段”、“标题字段名称”、“标题字段正文”和“折叠”，基于这样一种信念，即相互依赖的规范之间的一致术语使规范更易于长期使用。
All header fields in a Netnews article are compliant with [RFC5322]; this specification, however, is less permissive in what can be generated and accepted by agents. The syntax allowed for Netnews article headers is a strict subset of the Internet Message Format headers, making all headers compliant with this specification inherently compliant with [RFC5322]. Note however that the converse is not guaranteed to be true in all cases.
Netnews文章中的所有标题字段都符合[RFC5322]；然而，该规范对代理可以生成和接受的内容不太允许。Netnews文章标题所允许的语法是Internet消息格式标题的严格子集，使所有符合本规范的标题内在地符合[RFC5322]。然而，请注意，并非所有情况下都保证相反。
General rules that apply to all header fields (even those documented in [RFC5322] and [RFC2045]) are listed below, and those that apply to specific header fields are described in the relevant sections of this document.
下面列出了适用于所有标题字段（即使是[RFC5322]和[RFC2045]中记录的标题字段）的一般规则，本文档的相关章节介绍了适用于特定标题字段的一般规则。
o All agents MUST generate header fields so that at least one space immediately follows the ':' separating the header field name and the header field body (for compatibility with deployed software, including NNTP [RFC3977] servers). News agents MAY accept header fields that do not contain the required space.
o 所有代理都必须生成标头字段，以便在分隔标头字段名称和标头字段正文的“：”后面紧跟至少一个空格（以便与部署的软件兼容，包括NNTP[RFC3977]服务器）。新闻代理可以接受不包含所需空间的标题字段。
o Every line of a header field body (including the first and any that are subsequently folded) MUST contain at least one non-whitespace character.
o 标题字段正文的每一行（包括第一行和随后折叠的任何行）必须至少包含一个非空白字符。
NOTE: This means that no header field body defined by or referenced by this document can be empty. As a result, rather than using the <unstructured> syntax from Section 3.2.5 of [RFC5322], this document uses a stricter definition:
注意：这意味着本单据定义或引用的表头字段主体不能为空。因此，本文件没有使用[RFC5322]第3.2.5节中的<unstructured>语法，而是使用了更严格的定义：
unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSP
unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSP
NOTE: The [RFC5322] specification sometimes uses [FWS] at the beginning or end of ABNF describing header field content. This specification uses *WSP in such cases, also in cases where this specification redefines constructs from [RFC5322]. This is
注：[RFC5322]规范有时在ABNF的开头或结尾使用[FWS]来描述标题字段内容。本规范在这种情况下使用*WSP，在本规范从[RFC5322]重新定义构造的情况下也使用*WSP。这是
done for consistency with the restriction described here, but the restriction applies to all header fields, not just those where ABNF is defined in this document.
这样做是为了与此处描述的限制保持一致，但该限制适用于所有标题字段，而不仅仅是本文档中定义了ABNF的字段。
o Compliant software MUST NOT generate (but MAY accept) header field lines of more than 998 octets. This is the only limit on the length of a header field line prescribed by this standard. However, specific rules to the contrary may apply in particular cases (for example, according to [RFC2047], lines of a header field containing encoded words are limited to 76 octets). [USEAGE] includes suggested limits for convenience of display by user agents.
o 兼容软件不得生成（但可以接受）超过998个八位字节的头字段行。这是本标准规定的标题字段行长度的唯一限制。然而，在特定情况下可以应用相反的特定规则（例如，根据[RFC2047]，包含编码字的报头字段的行被限制为76个八位字节）。[使用]包括为方便用户代理显示而建议的限制。
NOTE: As stated in [RFC5322], there is NO restriction on the number of lines into which a header field may be split, and hence there is NO restriction on the total length of a header field (in particular it may, by suitable folding, be made to exceed the 998-octet restriction pertaining to a single header field line).
注：如[RFC5322]中所述，标题字段可以拆分成的行数没有限制，因此标题字段的总长度没有限制（特别是，通过适当的折叠，可以使标题字段超过与单个标题字段行相关的998八位字节限制）。
o The character set for header fields is US-ASCII. Where the use of non-ASCII characters is required, they MUST be encoded using the MIME mechanisms defined in [RFC2047] and [RFC2231].
o 标题字段的字符集为US-ASCII。如果需要使用非ASCII字符，则必须使用[RFC2047]和[RFC2231]中定义的MIME机制对其进行编码。
User agents MUST meet the definition of MIME conformance in [RFC2049] and MUST also support [RFC2231]. This level of MIME conformance provides support for internationalization and multimedia in message bodies [RFC2045], [RFC2046], and [RFC2231], and support for internationalization of header fields [RFC2047] and [RFC2231]. Note that [Errata] currently exist for [RFC2045], [RFC2046], [RFC2047] and [RFC2231].
用户代理必须满足[RFC2049]中MIME一致性的定义，并且还必须支持[RFC2231]。此MIME一致性级别支持消息体[RFC2045]、[RFC2046]和[RFC2231]中的国际化和多媒体，并支持头字段[RFC2047]和[RFC2231]的国际化。请注意，[RFC2045]、[RFC2046]、[RFC2047]和[RFC2231]目前存在[Errata]。
For the purposes of Section 5 of [RFC2047], all header fields defined in Section 3 of this standard are to be considered as "extension message header fields", permitting the use of [RFC2047] encodings within any <unstructured> header field, or within any <comment> or <phrase> permitted within any structured header field.
就[RFC2047]第5节而言，本标准第3节中定义的所有标题字段均被视为“扩展消息标题字段”，允许在任何<unstructured>标题字段内，或在任何结构化标题字段内允许的任何<comment>或<phrase>内使用[RFC2047]编码。
User agents MAY accept and generate other MIME extension header fields, and in particular SHOULD accept Content-Disposition [RFC2183] and Content-Language [RFC3282].
用户代理可以接受并生成其他MIME扩展头字段，尤其应该接受内容处置[RFC2183]和内容语言[RFC3282]。
The following news header fields extend those defined in Section 3.6 of [RFC5322]:
以下新闻标题字段扩展了[RFC5322]第3.6节中定义的字段：
fields =/ *( approved /
archive /
control /
distribution /
expires /
followup-to /
injection-date /
injection-info /
lines /
newsgroups /
organization /
path /
summary /
supersedes /
user-agent /
xref )
fields =/ *( approved /
archive /
control /
distribution /
expires /
followup-to /
injection-date /
injection-info /
lines /
newsgroups /
organization /
path /
summary /
supersedes /
user-agent /
xref )
Each of these header fields MUST NOT occur more than once in a news article.
每个标题字段在新闻文章中不得出现多次。
The following header fields defined in this document do not allow <comment>s (i.e., they use FWS rather than CFWS).
本文档中定义的以下标题字段不允许<comment>s（即，它们使用FWS而不是CFW）。
Control Distribution Followup-To Lines Newsgroups Path Supersedes Xref
控件分发后续行新闻组路径替代外部参照
This also applies to the following header field defined in [RFC5322]:
这也适用于[RFC5322]中定义的以下标题字段：
Message-ID
消息ID
Most of these header fields are mainly of interest to news servers, and news servers often need to process these fields very rapidly. Thus, some header fields prohibit <comment>s.
这些标题字段中的大多数主要是新闻服务器感兴趣的，新闻服务器通常需要非常快速地处理这些字段。因此，一些标题字段禁止<comment>s。
Each Netnews article conformant with this specification MUST have exactly one of each of the following header fields: Date, From, Message-ID, Newsgroups, Path, and Subject.
符合此规范的每个Netnews文章必须具有以下每个标题字段中的一个：日期、发件人、消息ID、新闻组、路径和主题。
The Date header field is the same as that specified in Sections 3.3 and 3.6.1 of [RFC5322], with the added restrictions detailed above in Section 2.2. However, the use of "GMT" as a time zone (part of <obs-zone>), although deprecated, is widespread in Netnews articles today. Therefore, agents MUST accept <date-time> constructs that use the "GMT" zone.
日期标题字段与[RFC5322]第3.3节和第3.6.1节中规定的字段相同，但增加了上述第2.2节中详述的限制。然而，使用“GMT”作为时区（属于<obs zone>的一部分）虽然已被弃用，但在今天的Netnews文章中却很普遍。因此，代理必须接受使用“GMT”区域的<date-time>构造。
orig-date = "Date:" SP date-time CRLF
orig date=“日期：”SP日期时间CRLF
NOTE: This specification does not change [RFC5322], which says that agents MUST NOT generate <date-time> constructs that include any zone names defined by <obs-zone>.
注意：此规范没有更改[RFC5322]，即代理不能生成包含由<obs zone>定义的任何区域名称的<date time>构造。
Software that accepts dates with unknown timezones SHOULD treat such timezones as equivalent to "-0000" when comparing dates, as specified in Section 4.3 of [RFC5322].
按照[RFC5322]第4.3节的规定，在比较日期时，接受未知时区日期的软件应将此类时区视为等同于“-0000”。
Also note that these requirements apply wherever <date-time> is used, including Injection-Date and Expires (Sections 3.2.7 and 3.2.5, respectively).
还应注意，这些要求适用于使用<日期-时间>的任何地方，包括注射日期和有效期（分别为第3.2.7节和第3.2.5节）。
The From header field is the same as that specified in Section 3.6.2 of [RFC5322], with the added restrictions detailed above in Section 2.2.
From标头字段与[RFC5322]第3.6.2节中规定的字段相同，但增加了上述第2.2节中详述的限制。
from = "From:" SP mailbox-list CRLF
from=“from:”SP邮箱列表CRLF
The Message-ID header field contains a unique message identifier. Netnews is more dependent on message identifier uniqueness and fast comparison than Email is, and some news software and standards [RFC3977] might have trouble with the full range of possible <msg-id>s permitted by [RFC5322]. This section therefore restricts the syntax of <msg-id> as compared to Section 3.6.4 of [RFC5322]. The global uniqueness requirement for <msg-id> in [RFC5322] is to be understood as applying across all protocols using such message identifiers, and across both Email and Netnews in particular.
消息ID标头字段包含唯一的消息标识符。与电子邮件相比，Netnews更依赖于消息标识符的唯一性和快速比较，一些新闻软件和标准[RFC3977]可能在[RFC5322]允许的所有可能的<msg id>方面存在问题。因此，与[RFC5322]第3.6.4节相比，本节限制了<msg id>的语法。[RFC5322]中<msg id>的全局唯一性要求应理解为适用于使用此类消息标识符的所有协议，尤其适用于电子邮件和网络新闻。
message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF
message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF
msg-id = "<" msg-id-core ">"
; maximum length is 250 octets
msg-id = "<" msg-id-core ">"
; maximum length is 250 octets
msg-id-core = id-left "@" id-right
msg id core=id left“@”id right
id-left = dot-atom-text
id-left = dot-atom-text
id-right = dot-atom-text / no-fold-literal
id-right = dot-atom-text / no-fold-literal
no-fold-literal = "[" *mdtext "]"
无折叠文字=“[”*mdtext”]”
mdtext = %d33-61 / ; The rest of the US-ASCII
%d63-90 / ; characters not including
%d94-126 ; ">", "[", "]", or "\"
mdtext = %d33-61 / ; The rest of the US-ASCII
%d63-90 / ; characters not including
%d94-126 ; ">", "[", "]", or "\"
The <msg-id> MUST NOT be more than 250 octets in length.
<msg id>的长度不得超过250个八位字节。
NOTE: The length restriction ensures that systems that accept message identifiers as a parameter when referencing an article (e.g., [RFC3977]) can rely on a bounded length.
注意：长度限制确保在引用项目（例如，[RFC3977]）时接受消息标识符作为参数的系统可以依赖有界长度。
Observe that <msg-id> includes the < and >.
注意<msg id>包括<and>。
Observe also that in contrast to the corresponding header field in [RFC5322]:
还应注意，与[RFC5322]中相应的标题字段相反：
o The syntax does not allow comments within the Message-ID header field.
o 该语法不允许在消息ID标头字段中添加注释。
o There is no possibility for ">" or WSP to occur inside a <msg-id>.
o <msg id>中不可能出现“>”或WSP。
o Even though commonly derived from <domain>s, <id-rights>s are case-sensitive (and thus, once created, are not to be altered during subsequent transmission or copying)
o 即使通常从<domain>s派生，<id rights>s也是区分大小写的（因此，一旦创建，在后续传输或复制过程中不会更改）
This is to simplify processing by news servers and to ensure interoperability with existing implementations and compliance with [RFC3977]. A simple comparison of octets will always suffice to determine the identity of two <msg-id>s.
这是为了简化新闻服务器的处理，并确保与现有实现的互操作性以及对[RFC3977]的遵从性。一个简单的八位字节比较总是足以确定两个<msg id>s的身份。
Also note that this updated ABNF applies wherever <msg-id> is used, including the References header field discussed in Section 3.2.10 and the Supersedes header field discussed in Section 3.2.12.
还请注意，此更新的ABNF适用于使用<msg id>的任何地方，包括第3.2.10节中讨论的引用标题字段和第3.2.12节中讨论的取代标题字段。
Some software will try to match the <id-right> of a <msg-id> in a case-insensitive fashion; some will match it in a case-sensitive fashion. Implementations MUST NOT generate a Message-ID where the only difference from another Message-ID is the case of characters in the <id-right> part.
某些软件将尝试以不区分大小写的方式匹配<msg id>的<id right>；有些人会以区分大小写的方式匹配它。如果与另一个消息ID的唯一区别是<ID right>部分中的字符大小写，则实现不能生成消息ID。
When generating a <msg-id>, implementations SHOULD use a domain name as the <id-right>.
生成<msg id>时，实现应使用域名作为<id right>。
NOTE: Section 3.6.4 of [RFC5322] recommends that the <id-right> should be a domain name or a domain literal. Domain literals are troublesome since many IP addresses are not globally unique; domain names are more likely to generate unique Message-IDs.
注：[RFC5322]第3.6.4节建议<id right>应为域名或域文字。域文字很麻烦，因为许多IP地址不是全局唯一的；域名更有可能生成唯一的消息ID。
The Newsgroups header field specifies the newsgroup(s) to which the article is posted.
新闻组标题字段指定文章发布到的新闻组。
newsgroups = "Newsgroups:" SP newsgroup-list CRLF
新闻组=“新闻组：”SP新闻组列表CRLF
newsgroup-list = *WSP newsgroup-name
*( [FWS] "," [FWS] newsgroup-name ) *WSP
newsgroup-list = *WSP newsgroup-name
*( [FWS] "," [FWS] newsgroup-name ) *WSP
newsgroup-name = component *( "." component )
新闻组名称=组件*（“”组件）
component = 1*component-char
component = 1*component-char
component-char = ALPHA / DIGIT / "+" / "-" / "_"
component-char = ALPHA / DIGIT / "+" / "-" / "_"
Not all servers support optional FWS in the list of newsgroups. In particular, folding the Newsgroups header field over several lines has been shown to harm propagation significantly. Optional FWS in the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
并非所有服务器都支持新闻组列表中的可选FW。特别是，将新闻组标题字段折叠在几行上会严重损害传播。不应生成<新闻组列表>中的可选FW，但必须接受。
A <component> SHOULD NOT consist solely of digits and SHOULD NOT contain uppercase letters. Such <component>s MAY be used only to refer to existing groups that do not conform to this naming scheme, but MUST NOT be used otherwise.
<component>不应仅由数字组成，也不应包含大写字母。此类<component>s只能用于引用不符合此命名方案的现有组，但不得用于其他情况。
NOTE: All-digit <component>s conflict with one widely used storage scheme for articles. Mixed-case groups cause confusion between systems with case-sensitive matching and systems with case-insensitive matching of <newsgroup-name>s.
注：所有数字<component>s与一种广泛使用的物品存储方案冲突。混合大小写组会导致区分大小写匹配的系统与区分大小写匹配为<newsgroup name>s的系统之间的混淆。
<component>s beginning with underline ("_") are reserved for use by future versions of this standard and SHOULD NOT be generated by user agents (whether in header fields or in newgroup control messages as defined by [RFC5537]). However, such names MUST be accepted by news servers.
<component>s以下划线（“389;”）开头，保留供本标准的未来版本使用，不应由用户代理生成（无论是在标题字段中还是在[RFC5537]定义的新组控制消息中）。但是，新闻服务器必须接受此类名称。
<component>s beginning with "+" and "-" are reserved for private use and SHOULD NOT be generated by user agents (whether in header fields or in newgroup control messages [RFC5537]) without a private prior agreement to do so. However, such names MUST be accepted by news servers.
以“+”和“-”开头的<component>s保留供私人使用，未经私人事先同意，用户代理（无论是在标头字段中还是在新组控制消息[RFC5537]中）都不应生成。但是，新闻服务器必须接受此类名称。
The following <newsgroup-name>s are reserved and MUST NOT be used as the name of a newsgroup:
以下<新闻组名称>是保留的，不能用作新闻组的名称：
o Groups whose first (or only) <component> is "example"
o 第一个（或唯一一个）<component>为“示例”的组
o The group "poster"
o “海报”组
The following <newsgroup-name>s have been used for specific purposes in various implementations and protocols and therefore MUST NOT be used for the names of normal newsgroups. They MAY be used for their specific purpose or by local agreement.
以下<newsgroup name>在各种实现和协议中用于特定目的，因此不能用于普通新闻组的名称。它们可用于其特定目的或通过当地协议使用。
o Groups whose first (or only) component is "to"
o 第一个（或唯一一个）组件为“to”的组
o Groups whose first (or only) component is "control"
o 第一个（或唯一一个）组件为“control”的组
o Groups that contain (or consist only of) the component "all"
o 包含（或仅包含）组件“全部”的组
o Groups that contain (or consist only of) the component "ctl"
o 包含（或仅包含）组件“ctl”的组
o The group "junk"
o “垃圾”组
NOTE: "example.*" is reserved for examples in this and other standards; "poster" has a special meaning in the Followup-To header field; "to.*" is reserved for certain point-to-point communications in conjunction with the "ihave" control message as defined in [RFC5537]; "control.*" and "junk" have special meanings in some news servers; "all" is used as a wildcard in some implementations; and "ctl" was formerly used to indicate a <control-command> within the Newsgroups header field.
注：“示例。*”保留用于本标准和其他标准中的示例；“海报”在标题后续字段中具有特殊含义；“to.*”与[RFC5537]中定义的“ihave”控制消息一起保留用于某些点对点通信；“控制。*”和“垃圾”在某些新闻服务器中有特殊含义；“all”在某些实现中用作通配符；“ctl”以前用于表示新闻组标题字段中的<control command>。
The Path header field indicates the route taken by an article since its injection into the Netnews system. Each agent that processes an article is required to prepend at least one <path-identity> to this header field body. This is primarily so that news servers are able to avoid sending articles to sites already known to have them, in particular the site they came from. Additionally, it permits gathering statistics and tracing the route articles take in moving over the network.
Path header字段表示文章自注入Netnews系统以来所采用的路由。处理项目的每个代理都需要至少向该标题字段正文添加一个<path identity>。这主要是为了使新闻服务器能够避免将文章发送到已知有文章的站点，特别是它们来自的站点。此外，它还允许收集统计数据并跟踪物品在网络上移动的路线。
path = "Path:" SP *WSP path-list tail-entry *WSP CRLF
path = "Path:" SP *WSP path-list tail-entry *WSP CRLF
path-list = *( path-identity [FWS] [path-diagnostic] "!" )
path-list = *( path-identity [FWS] [path-diagnostic] "!" )
path-diagnostic = diag-match / diag-other / diag-deprecated
path-diagnostic = diag-match / diag-other / diag-deprecated
diag-match = "!" ; another "!"
diag-match = "!" ; another "!"
diag-other = "!." diag-keyword [ "." diag-identity ] [FWS]
diag-other=“！”diag关键字[““diag-identity][FWS]
diag-deprecated = "!" IPv4address [FWS]
diag已弃用=“！”IPv4address[FWS]
diag-keyword = 1*ALPHA ; see [RFC5537]
diag-keyword = 1*ALPHA ; see [RFC5537]
diag-identity = path-identity / IPv4address / IPv6address
diag-identity = path-identity / IPv4address / IPv6address
tail-entry = path-nodot ; may be the string "not-for-mail"
尾部入口=路径节点；可能是字符串“不用于邮件”
path-identity = ( 1*( label "." ) toplabel ) / path-nodot
path-identity = ( 1*( label "." ) toplabel ) / path-nodot
path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
label = alphanum [ *( alphanum / "-" ) alphanum ]
label = alphanum [ *( alphanum / "-" ) alphanum ]
toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) /
( label *( "-" ) ALPHA [ *( "-" ) label ] ) /
( label 1*( "-" ) label )
toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) /
( label *( "-" ) ALPHA [ *( "-" ) label ] ) /
( label 1*( "-" ) label )
alphanum = ALPHA / DIGIT ; compare [RFC3696]
alphanum = ALPHA / DIGIT ; compare [RFC3696]
A <path-identity> is a name identifying a site. It takes the form of a domain name having two or more components separated by dots, or a single name with no dots (<path-nodot>).
<path identity>是标识站点的名称。它采用的形式是域名有两个或多个由点分隔的组件，或者一个没有点的名称（<path nodot>）。
Each <path-identity> in the <path-list> (which does not include the <tail-entry>) indicates, from right to left, the successive agents through which the article has passed. The use of the <diag-match>, which appears as "!!", indicates that the agent to its left verified the identity of the agent to its right before accepting the article (whereas the <path-delimiter> "!" implies no such claim).
<path list>中的每个<path identity>（不包括<tail entry>）从右到左指示文章经过的连续代理。使用显示为“！！”的<diag match>，表示其左侧的代理在接受文章之前验证了其右侧的代理的身份（而<path delimiter>“！”表示没有此类声明）。
NOTE: Historically, the <tail-entry> indicated the name of the sender. If not used for this purpose, the string "not-for-mail" is often used instead (since at one time the whole path could be used as a mail address for the sender).
注意：历史上，<tail entry>表示发送者的名称。如果不用于此目的，则通常使用字符串“not for mail”（不用于邮件）（因为整个路径一度可以用作发件人的邮件地址）。
NOTE: Although case-insensitive, it is intended that the <diag-keyword>s should be in uppercase, to distinguish them from the <path-identity>s, which are traditionally in lowercase.
注意：尽管不区分大小写，但是<diag关键字>s应该是大写的，以区别于<path identity>s，后者传统上是小写的。
A <path-diagnostic> is an item inserted into the Path header field for purposes other than to indicate the name of a site. The use of these is described in [RFC5537].
<path diagnostic>是插入到路径标题字段中的一个项目，用于指示站点名称以外的目的。[RFC5537]中描述了它们的使用。
NOTE: One usage of a <path-diagnostic> is to record an IP address. The fact that <IPv6address>es are allowed means that the colon (:) is permitted; note that this may cause interoperability problems at older sites that regard ":" as a <path-delimiter> and have neighbors whose names have 4 or fewer characters, and where all the characters are valid HEX digits.
注意：<path diagnostic>的一种用法是记录IP地址。允许使用<IPv6address>es这一事实意味着允许使用冒号（：）；请注意，这可能会导致旧站点出现互操作性问题，这些站点将“：”视为<path delimiter>，并且其邻居的名称包含4个或更少的字符，并且所有字符都是有效的十六进制数字。
NOTE: Although <IPv4address>es have occasionally been used in the past (usually with a diagnostic intent), their continued use is deprecated (though it is still acceptable in the form of the <diag-deprecated>).
注意：尽管过去偶尔会使用<IPv4address>es（通常是出于诊断目的），但不推荐继续使用它们（尽管以<diag deprecated>的形式仍然可以接受）。
The Subject header field is the same as that specified in Section 3.6.5 of [RFC5322], with the added restrictions detailed above in Section 2.2. Further discussion of the content of the Subject header field appears in [RFC5537] and [USEAGE].
主题标题字段与[RFC5322]第3.6.5节中规定的字段相同，但增加了上述第2.2节中详述的限制。关于主题标题字段内容的进一步讨论见[RFC5537]和[USEAGE]。
subject = "Subject:" SP unstructured CRLF
subject=“subject:“SP非结构化CRLF”
None of the header fields appearing in this section are required to appear in every article, but some of them may be required in certain types of articles. Further discussion of these requirements appears in [RFC5537] and [USEAGE].
本节中出现的标题字段均不要求出现在每篇文章中，但某些类型的文章可能需要其中一些字段。关于这些要求的进一步讨论见[RFC5537]和[USEAGE]。
The header fields Comments, Keywords, Reply-To, and Sender are used in Netnews articles in the same circumstances and with the same meanings as those specified in [RFC5322], with the added restrictions detailed above in Section 2.2. Multiple occurrences of the Keywords header field are not permitted.
标题字段“评论”、“关键字”、“回复”和“发件人”在Netnews文章中使用的情况和含义与[RFC5322]中规定的相同，但增加了上述第2.2节中详述的限制。“关键字标题”字段不允许多次出现。
comments = "Comments:" SP unstructured CRLF
comments=“comments:”SP非结构化CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF
reply-to = "Reply-To:" SP address-list CRLF
reply to=“reply to:”SP地址列表CRLF
sender = "Sender:" SP mailbox CRLF
发件人=“发件人：”SP邮箱CRLF
The MIME header fields MIME-Version, Content-Type, Content-Transfer-Encoding, Content-Disposition, and Content-Language are used in Netnews articles in the same circumstances and with the same meanings as those specified in [RFC2045], [RFC2183], and [RFC3282], with the added restrictions detailed above in Section 2.2.
MIME标题字段MIME版本、内容类型、内容传输编码、内容处置和内容语言在Netnews文章中使用的情况和含义与[RFC2045]、[RFC2183]和[RFC3282]中规定的相同，并在上文第2.2节中详细说明了附加限制。
All remaining news header fields are described below.
所有剩余的新闻标题字段如下所述。
The Approved header field indicates the mailing addresses (and possibly the full names) of the persons or entities approving the article for posting. Its principal uses are in moderated articles and in group control messages; see [RFC5537].
Approved header字段表示批准发布文章的个人或实体的邮寄地址（可能还有全名）。它的主要用途是在有版主的文章和群组控制信息中；参见[RFC5537]。
approved = "Approved:" SP mailbox-list CRLF
approved=“approved:”SP邮箱列表CRLF
The Archive header field provides an indication of the poster's intent regarding preservation of the article in publicly accessible long-term or permanent storage.
Archive header（存档标题）字段表示海报将文章保存在可公开访问的长期或永久存储中的意图。
archive = "Archive:" SP [CFWS] ("no" / "yes")
*( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF
archive = "Archive:" SP [CFWS] ("no" / "yes")
*( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF
archive-param = parameter
archive-param = parameter
The presence of an Archive header field in an article with a field body of "no" indicates that the poster does not permit redistribution from publicly accessible long-term or permanent archives. A field body of "yes" indicates that the poster permits such redistribution.
在字段主体为“否”的文章中存在存档标题字段表示海报不允许从公开访问的长期或永久存档重新分发。字段主体为“是”表示海报允许此类再分配。
No <parameter>s are currently defined; if present, they can be ignored. Further discussion of the use of the Archive header field appears in [USEAGE].
当前未定义<parameter>s；如果存在，则可以忽略它们。关于存档标题字段使用的进一步讨论见[USEAGE]。
The Control header field marks the article as a control message and specifies the desired actions (in addition to the usual actions of storing and/or relaying the article).
控制标题字段将项目标记为控制消息，并指定所需的操作（除了存储和/或中继项目的常规操作之外）。
control = "Control:" SP *WSP control-command *WSP CRLF
control = "Control:" SP *WSP control-command *WSP CRLF
control-command = verb *( 1*WSP argument )
control-command = verb *( 1*WSP argument )
verb = token
verb = token
argument = 1*( %x21-7E )
argument = 1*( %x21-7E )
The verb indicates what action should be taken, and the argument(s) (if any) supply details. In some cases, the <body> (as defined in [RFC5322]) of the article may also contain details. The legal verbs and respective arguments are discussed in the companion document, [RFC5537].
动词表示应该采取什么行动，参数（如果有）提供详细信息。在某些情况下，文章的<body>（定义见[RFC5322]）也可能包含详细信息。相关文件[RFC5537]中讨论了法律动词和相应的参数。
An article with a Control header field MUST NOT also have a Supersedes header field.
具有控件标题字段的项目不得同时具有取代标题字段。
The Distribution header field specifies geographic or organizational limits on an article's propagation.
Distribution header字段指定文章传播的地理或组织限制。
distribution = "Distribution:" SP dist-list CRLF
distribution=“distribution:“SP dist list CRLF”
dist-list = *WSP dist-name
*( [FWS] "," [FWS] dist-name ) *WSP
dist-list = *WSP dist-name
*( [FWS] "," [FWS] dist-name ) *WSP
dist-name = ALPHA / DIGIT
*( ALPHA / DIGIT / "+" / "-" / "_" )
dist-name = ALPHA / DIGIT
*( ALPHA / DIGIT / "+" / "-" / "_" )
The <dist-name>s "world" and "local" are reserved. "world" indicates unlimited distribution and SHOULD NOT be used explicitly, since it is the default when the Distribution header field is absent entirely. "local" is reserved for indicating distribution only to the local site, as defined by local software configuration.
<dist name>s的“世界”和“本地”是保留的。“world”表示无限制的分发，不应明确使用，因为它是完全不存在分发标头字段时的默认值。“本地”仅用于指示本地站点的分发，如本地软件配置所定义。
"All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain at least three characters, except when they are two-letter country codes drawn from [ISO3166-1]. <dist-name>s are case-insensitive (i.e., "US", "Us", "uS", and "us" all specify the same distribution).
“All”不能用作<dist name><dist name>s应至少包含三个字符，除非它们是从[ISO3166-1]中提取的两个字母的国家/地区代码<dist name>s不区分大小写（即，“US”、“US”、“US”和“US”都指定相同的分布）。
Optional FWS in the <dist-list> SHOULD NOT be generated, but MUST be accepted.
不应生成<dist list>中的可选FW，但必须接受。
The Expires header field specifies a date and time when the poster deems the article to be no longer relevant and could usefully be removed ("expired").
Expires标题字段指定海报认为文章不再相关并且可以有效删除（“过期”）的日期和时间。
NOTE: This header field is useful when the poster desires an unusually long or an unusually short expiry time.
注意：当海报要求超长或超短的到期时间时，此标题字段非常有用。
expires = "Expires:" SP date-time CRLF
expires=“expires:”SP日期时间CRLF
See the remarks under Section 3.1.1 regarding the syntax of <date-time> and the requirements and recommendations to which it is subject.
参见第3.1.1节中关于<日期-时间>语法的备注以及它所遵循的要求和建议。
NOTE: The Expires header field is also sometimes used in Email with a similar meaning; see [RFC2156].
注意：Expires标头字段有时也用于具有类似含义的电子邮件中；见[RFC2156]。
The Followup-To header field specifies to which newsgroup(s) the poster has requested that followups are to be posted. The Followup-To header field SHOULD NOT appear in a message, unless its content is different from the content of the Newsgroups header field.
Followup To header字段指定海报请求将后续内容发布到的新闻组。除非消息的内容与新闻组标题字段的内容不同，否则标题字段的后续内容不应出现在消息中。
followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) CRLF
followup to=“followup to:”SP（新闻组列表/海报文本）CRLF
poster-text = *WSP %d112.111.115.116.101.114 *WSP
; "poster" in lowercase
poster-text = *WSP %d112.111.115.116.101.114 *WSP
; "poster" in lowercase
The syntax is the same as that of the Newsgroups (Section 3.1.4) header field, with the exception that the keyword "poster" requests that followups should be emailed directly to the article's poster (using the addresses contained in the Reply-To header field if one exists, otherwise using the addresses contained in the From header field) rather than posted to any newsgroups. Agents MUST generate the keyword "poster" in lowercase, but MAY choose to recognize case-insensitive forms such as "Poster".
该语法与新闻组（第3.1.4节）标题字段的语法相同，但关键字“poster”要求将后续内容直接通过电子邮件发送到文章的海报（如果存在，使用回复标题字段中包含的地址，否则使用发件人标题字段中包含的地址）而不是发布到任何新闻组。代理必须以小写形式生成关键字“poster”，但可以选择识别不区分大小写的表单，如“poster”。
As in the Newsgroups (Section 3.1.4) header field, optional FWS in the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
与新闻组（第3.1.4节）标题字段一样，<newsgroup list>中的可选FW不应生成，但必须接受。
The Injection-Date header field contains the date and time that the article was injected into the network. Its purpose is to enable news servers, when checking for "stale" articles, to use a <date-time> that was added by a news server at injection time rather than one added by the user agent at message composition time.
注入日期标题字段包含文章注入网络的日期和时间。它的目的是使新闻服务器在检查“过时”文章时能够使用由新闻服务器在注入时添加的<date time>，而不是由用户代理在消息合成时添加的<date time>。
This header field MUST be inserted whenever an article is injected. However, software that predates this standard does not use this header, and therefore agents MUST accept articles without the Injection-Date header field.
每当插入项目时，必须插入此标题字段。但是，早于此标准的软件不使用此标题，因此代理必须接受没有注入日期标题字段的文章。
injection-date = "Injection-Date:" SP date-time CRLF
注入日期=“注入日期：”SP日期时间CRLF
See the remarks under Section 3.1.1 regarding the syntax of <date-time> and the requirements and recommendations to which it is subject.
参见第3.1.1节中关于<日期-时间>语法的备注以及它所遵循的要求和建议。
NOTE: Since clocks on various agents are not necessarily synchronized, the <date-time> in this header field might not be a later value than that in the Date header field. Agents MUST NOT alter a pre-existing Date header field when adding an Injection-Date header field.
注意：由于不同代理上的时钟不一定同步，因此此标头字段中的<日期时间>值可能不会晚于日期标头字段中的值。添加注入日期标头字段时，代理不得更改预先存在的日期标头字段。
This header field is intended to replace the currently used but undocumented "NNTP-Posting-Date" header field, whose use is now deprecated.
此标题字段旨在替换当前使用但未记录的“NNTP过账日期”标题字段，该字段现在已不再使用。
The Injection-Info header field contains information provided by the injecting news server as to how an article entered the Netnews system; it assists in tracing the article's true origin. It can also specify one or more addresses where complaints concerning the poster of the article may be sent.
注入信息标题字段包含注入新闻服务器提供的关于文章如何进入Netnews系统的信息；它有助于追踪文章的真实来源。它还可以指定一个或多个地址，用于发送有关文章海报的投诉。
injection-info = "Injection-Info:" SP [CFWS] path-identity
[CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF
injection-info = "Injection-Info:" SP [CFWS] path-identity
[CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF
NOTE: The syntax of <parameter> (Section 5.1 of [RFC2045], as amended by [RFC2231]), taken in conjunction with the folding rules of [RFC0822] (note: not [RFC2822] or [RFC5322]), effectively allows [CFWS] to occur on either side of the "=" inside a <parameter>.
注：结合[RFC0822]（注：非[RFC2822]或[RFC5322]）的折叠规则，<parameter>（经[RFC2231]修订的[RFC2045]第5.1节）的语法有效地允许[CFWS]出现在<parameter>内“=”的任一侧。
The following table gives the <attribute> and the format of the <value> for each <parameter> defined for use with this header field. At most, one occurrence of each such <parameter> is allowed.
下表给出了定义用于此标题字段的每个<parameter>的<attribute>和<value>格式。每个<parameter>最多允许出现一次。
<attribute> format of <value>
-------------------- -----------------
"posting-host" a <host-value>
"posting-account" any <value>
"logging-data" any <value>
"mail-complaints-to" an <address-list>
<attribute> format of <value>
-------------------- -----------------
"posting-host" a <host-value>
"posting-account" any <value>
"logging-data" any <value>
"mail-complaints-to" an <address-list>
where
哪里
host-value = dot-atom-text / IPv4address / IPv6address /
(dot-atom-text ":" ( IPv4address / IPv6address ))
host-value = dot-atom-text / IPv4address / IPv6address /
(dot-atom-text ":" ( IPv4address / IPv6address ))
NOTE: Since any such <host-value> or <address-list> also has to be a syntactically correct <value>, it will usually be necessary to encapsulate it as a <quoted-string>, for example:
注意：由于任何此类<host value>或<address list>也必须是语法正确的<value>，因此通常需要将其封装为<quoted string>，例如：
posting-host = "posting.example.com:192.0.2.1"
posting host=“posting.example.com:192.0.2.1”
Other <attribute>s SHOULD NOT be used unless defined in extensions to this standard. If non-standards-based <attribute>s are used, they MUST begin with an "x-".
除非在本标准的扩展部分中定义，否则不应使用其他<attribute>s。如果使用基于非标准的<attribute>s，则它们必须以“x-”开头。
Although comments and folding of whitespace are permitted throughout the Injection-Info header field, folding SHOULD NOT be used within any <parameter>. Folding SHOULD only occur before or after the ";" separating <parameter>s, and comments SHOULD only be used following the last <parameter>.
尽管在整个Injection Info header字段中允许注释和空白折叠，但在任何<parameter>中都不应使用折叠。折叠只能发生在“；”分隔<parameter>之前或之后，注释只能在最后一个<parameter>之后使用。
NOTE: Some of this information has previously been sent in non-standardized header fields such as NNTP-Posting-Host, X-Trace, X-Complaints-To, and others. Once a news server generates an Injection-Info header field, it should have no need to send these non-standard header fields.
注意：其中一些信息以前是在非标准化的标题字段中发送的，如NNTP POST Host、X-Trace、X-To等。一旦新闻服务器生成注入信息头字段，它就不需要发送这些非标准头字段。
The "posting-host" <parameter> specifies the Fully Qualified Domain Name (FQDN) and/or IP address (IPv4address or IPv6address) of the host from which the news server received the article.
“发布主机”<parameter>指定新闻服务器接收文章的主机的完全限定域名（FQDN）和/或IP地址（IPv4address或IPv6address）。
NOTE: If the "posting-host" <parameter> fails to deterministically identify the host (e.g., dynamic IP address allocation), the "posting-account" or "logging-data" <parameter> may provide additional information about the true origin of the article.
注意：如果“过帐主机”<parameter>无法确定主机（例如，动态IP地址分配），“过帐帐户”或“日志数据”<parameter>可能会提供有关物品真实来源的附加信息。
The "posting-account" <parameter> identifies the source from which that news server received the article, in a notation that can be interpreted by the news server administrator. This notation can include any information the administrator deems pertinent. In order to limit the exposure of personal data, it SHOULD be given in a form that cannot be interpreted by other sites. However, to make it useful for rate limiting and abuse detection, two messages posted from the same source SHOULD have the same value of "posting-account", and two messages from different sources SHOULD have differing values of "posting-account". The exact definition of "source" is left to the discretion of the news server administrator.
“posting account”<parameter>标识新闻服务器接收文章的来源，其符号可由新闻服务器管理员解释。此符号可以包括管理员认为相关的任何信息。为了限制个人数据的暴露，应以其他网站无法解释的形式提供。然而，为了使其对速率限制和滥用检测有用，来自同一来源的两封邮件应具有相同的“发布帐户”值，而来自不同来源的两封邮件应具有不同的“发布帐户”值。“来源”的确切定义由新闻服务器管理员自行决定。
The "logging-data" <parameter> contains information (typically a session number or other non-persistent means of identifying a posting account) that will enable the true origin of the article to be determined by reference to logging information kept by the news server.
“logging data”<parameter>包含的信息（通常是会话号或其他非持久性的标识发布帐户的方法），可通过参考新闻服务器保存的日志信息来确定文章的真实来源。
The "mail-complaints-to" <parameter> specifies one or more mailboxes for sending complaints concerning the behavior of the poster of the article.
“mail complaints to”<parameter>指定一个或多个邮箱，用于发送有关文章海报行为的投诉。
It is a matter of local policy which of the above <parameter>s to include. Some pieces of information have privacy implications; this is discussed in [USEAGE].
包括上述<parameter>s中的哪一项是当地政策的问题。某些信息涉及隐私；这在[使用]中讨论。
The Organization header field is a short phrase identifying the poster's organization.
“组织标题”字段是标识海报组织的简短短语。
organization = "Organization:" SP unstructured CRLF
organization=“organization:”SP非结构化CRLF
NOTE: There is no "s" in Organization.
注意：组织中没有“s”。
The References header field is the same as that specified in Section 3.6.4 of [RFC5322], with the added restrictions detailed above in Section 2.2 and those listed below:
参考标题字段与[RFC5322]第3.6.4节中规定的字段相同，增加的限制在上文第2.2节中详细说明，并在下面列出：
o The updated <msg-id> construct defined in Section 3.1.3 MUST be used.
o 必须使用第3.1.3节中定义的更新的<msg id>构造。
o Message identifiers MUST be separated with CFWS.
o 消息标识符必须用CFW分隔。
o Comments in CFWS between message identifiers can cause interoperability problems, so comments SHOULD NOT be generated but MUST be accepted.
o 消息标识符之间的CFWS中的注释可能会导致互操作性问题，因此不应生成注释，但必须接受注释。
references = "References:" SP [CFWS] msg-id *(CFWS msg-id) [CFWS] CRLF
references=“references:”SP[CFWS]msg id*（CFWS-msg id）[CFWS]CRLF
The Summary header field is a short phrase summarizing the article's content.
摘要标题字段是总结文章内容的简短短语。
summary = "Summary:" SP unstructured CRLF
summary=“summary:”SP非结构化CRLF
The Supersedes header field contains a message identifier specifying an article to be superseded upon the arrival of this one. An article containing a Supersedes header field is equivalent to a "cancel" [RFC5537] control message for the specified article, followed immediately by the new article without the Supersedes header field.
“取代标题”字段包含一个消息标识符，该标识符指定了到达时要取代的项目。包含取代标题字段的项目相当于指定项目的“取消”[RFC5537]控制消息，紧接着是不带取代标题字段的新项目。
supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF
supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF
NOTE: There is no "c" in Supersedes.
注：替换项中没有“c”。
NOTE: The Supersedes header field defined here has no connection with the Supersedes header field that sometimes appears in Email messages converted from X.400 according to [RFC2156]; in particular, the syntax here permits only one <msg-id> in contrast to the multiple <msg-id>s in that Email version.
注意：此处定义的取代标题字段与根据[RFC2156]从X.400转换而来的电子邮件中有时出现的取代标题字段没有联系；特别是，这里的语法只允许一个<msg id>，而不是该电子邮件版本中的多个<msg id>。
The User-Agent header field contains information about the user agent (typically a newsreader) generating the article, for statistical purposes and tracing of standards violations to specific software in need of correction. It is intended that this header field be suitable for use in Email.
用户代理标题字段包含有关生成文章的用户代理（通常是新闻阅读器）的信息，用于统计目的，并将违反标准的情况跟踪到需要更正的特定软件。此标题字段适合在电子邮件中使用。
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
product = [CFWS] token [ [CFWS] "/" product-version ]
product = [CFWS] token [ [CFWS] "/" product-version ]
product-version = [CFWS] token
product-version = [CFWS] token
This header field MAY contain multiple <product> tokens identifying the user agent and any subproducts that form a significant part of it, listed in order of their significance for identifying the application.
此标题字段可能包含多个标识用户代理和构成其重要部分的任何子产品的<product>标记，按其标识应用程序的重要性顺序列出。
NOTE: Some of this information has previously been sent in non-standardized header fields such as X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent generates a User-Agent header field, it should have no need to send these non-standard header fields.
注意：其中一些信息以前是在非标准的标题字段中发送的，如X-Newsreader、X-Mailer、X-Posting-Agent、X-Http-User-Agent等。一旦用户代理生成用户代理头字段，它就不需要发送这些非标准头字段。
NOTE: [RFC2616] describes a similar facility for the HTTP protocol. The Netnews article format differs in that "{" and "}" are allowed in tokens (<product> and <product-version>) and comments are permitted wherever white space is allowed.
注：[RFC2616]描述了HTTP协议的类似功能。Netnews文章格式的不同之处在于，标记（<product>和<product version>）中允许使用“{”和“}”，并且在允许空白的地方允许使用注释。
The Xref header field indicates where an article was filed by the last news server to process it. User agents often use the information in the Xref header field to avoid multiple processing of crossposted articles.
Xref header字段表示最后一个处理文章的新闻服务器将文章归档的位置。用户代理经常使用外部参照标题字段中的信息来避免对交叉发布的文章进行多次处理。
xref = "Xref:" SP *WSP server-name
1*( FWS location ) *WSP CRLF
xref = "Xref:" SP *WSP server-name
1*( FWS location ) *WSP CRLF
server-name = path-identity
server-name = path-identity
location = newsgroup-name ":" article-locator
位置=新闻组名称“：“文章定位器”
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; US-ASCII printable characters
; except '(' and ';'
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; US-ASCII printable characters
; except '(' and ';'
The <server-name> is included so that software can determine which news server generated the header field. The locations specify where the article is filed -- i.e., under which newsgroups (which may differ from those in the Newsgroups header field), and where under those newsgroups. The exact form of an <article-locator> is implementation-specific.
包含<server name>，以便软件可以确定哪个新闻服务器生成了标题字段。位置指定文章的归档位置——即，在哪个新闻组下（可能不同于新闻组标题字段中的新闻组），以及在这些新闻组下的位置。<article locator>的确切形式是特定于实现的。
NOTE: The traditional form of an <article-locator> (as required by [RFC3977]) is a decimal number, with articles in each newsgroup numbered consecutively starting from 1.
注意：<article locator>（根据[RFC3977]的要求）的传统形式是十进制数字，每个新闻组中的文章从1开始连续编号。
The header fields Date-Received, Posting-Version, and Relay-Version defined in [RFC0850], as well as Also-Control, Article-Names, Article-Updates, and See-Also defined in [Son-of-1036] are declared obsolete. See the cited specification documents for further information on their original use.
[RFC0850]中定义的标题字段Date Received、Posting Version和Relay Version以及[Son-of-1036]中定义的Control、Article Name、Article Updates和See均被宣布为已过时。有关其原始用途的更多信息，请参阅引用的规范文件。
These header fields MUST NOT be generated and SHOULD be ignored.
不得生成这些标题字段，应忽略这些字段。
The Lines header field indicates the number of lines in the <body> (as defined in [RFC5322]) of the article.
行标题字段表示文章的<body>（定义见[RFC5322]）中的行数。
lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF
lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF
The line count is the number of CRLF separators in the <body>.
行计数是<body>中CRLF分隔符的数量。
Historically, this header field was used by the NNTP [RFC3977] overview facility, but its use for this purpose is now deprecated. As a result, this header field is to be regarded as obsolescent, and it is likely to be removed entirely in a future version of this standard. All agents SHOULD ignore it and SHOULD NOT generate it.
历史上，NNTP[RFC3977]概览工具曾使用此标题字段，但现在不推荐使用此字段。因此，此标题字段将被视为已过时，并且可能在本标准的未来版本中被完全删除。所有代理都应该忽略它，而不应该生成它。
Internationalization of Netnews article header fields and bodies is provided using the MIME mechanisms discussed in Section 2.3. Note that the generation of internationalized <newsgroup-name>s for use in header fields is not addressed in this document.
Netnews文章标题字段和正文的国际化是使用第2.3节中讨论的MIME机制提供的。请注意，本文档中未涉及在标题字段中使用的国际化<新闻组名称>的生成。
The Netnews article format specified in this document does not provide any security services, such as confidentiality, authentication of sender, or non-repudiation. Instead, such services need to be layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME (Pretty Good Privacy / MIME) [RFC3156], or below, using secure versions of news transport protocols. Additionally, several currently non-standardized protocols such as [PGPVERIFY] may be standardized in the near future.
本文档中指定的Netnews文章格式不提供任何安全服务，例如机密性、发件人身份验证或不可否认性。相反，这类服务需要使用S/MIME[RFC3851]或PGP/MIME（相当好的隐私/MIME）[RFC3156]等协议，或者使用安全版本的新闻传输协议，在上面或下面进行分层。此外，一些目前未标准化的协议，如[PGPVERIFY]可能在不久的将来标准化。
Message identifiers (Section 3.1.3) in Netnews articles are required to be unique; articles may be refused (in server-to-server transfer) if the identifier has already been seen. If a malicious agent can predict the identifier of an article, it can preempt the article by posting its own article (possibly to a quite different group) with
Netnews文章中的消息标识符（第3.1.3节）要求是唯一的；如果已看到标识符，则可能会拒绝项目（在服务器到服务器传输中）。如果恶意代理可以预测文章的标识符，那么它可以通过使用
the same message identifier, thereby preventing the target article from propagating. Therefore, agents that generate message identifiers for Netnews articles SHOULD ensure that they are unpredictable.
相同的消息标识符，从而防止目标项目传播。因此，为Netnews文章生成消息标识符的代理应该确保它们是不可预测的。
MIME security considerations are discussed in [RFC2046]. Note that the full range of encodings allowed for parameters in [RFC2046] and [RFC2231] permits constructs that simple parsers may fail to parse correctly; examples of hard-to-parse constructs are:
[RFC2046]中讨论了MIME安全注意事项。注意，[RFC2046]和[RFC2231]中的参数所允许的全部编码允许简单解析器可能无法正确解析的构造；难以解析的构造示例包括：
Content-Type: multipart/mixed
(; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
Content-Type: multipart/mixed
(; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
Content-Type: multipart/digest;
boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
Content-Type: multipart/digest;
boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
Such deficiencies in parsing may be used as part of an attack.
解析中的此类缺陷可能被用作攻击的一部分。
Further security considerations are discussed in [RFC5537].
[RFC5537]中讨论了进一步的安全注意事项。
IANA has registered the following header fields in the Permanent Message Header Field Repository, in accordance with the procedures set out in [RFC3864].
IANA已根据[RFC3864]中规定的程序，在永久消息标题字段存储库中注册了以下标题字段。
Header field name: Also-Control
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.15)
Header field name: Also-Control
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.15)
Header field name: Approved
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.1)
Header field name: Approved
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.1)
Header field name: Archive
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.2)
Header field name: Archive
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.2)
Header field name: Article-Names
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.17)
Header field name: Article-Names
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.17)
Header field name: Article-Updates
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.18)
Header field name: Article-Updates
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.18)
Header field name: Comments Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2), [RFC5322] (Section 3.6.5)
标题字段名称：注释适用协议：网络新闻状态：标准作者/变更控制者：IETF规范文件：本文件（第3.2节），[RFC5322]（第3.6.5节）
Header field name: Control
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.3)
Header field name: Control
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.3)
Header field name: Date Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.1), [RFC5322] (Section 3.6.1)
标题字段名称：日期适用协议：网络新闻状态：标准作者/变更控制者：IETF规范文件：本文件（第3.1.1节），[RFC5322]（第3.6.1节）
Header field name: Date-Received
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.2.4)
Header field name: Date-Received
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.2.4)
Header field name: Distribution
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.4)
Header field name: Distribution
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.4)
Header field name: Expires
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.5)
Header field name: Expires
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.5)
Header field name: Followup-To
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.6)
Header field name: Followup-To
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.6)
Header field name: From Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.2), [RFC5322] (Section 3.6.2)
标题字段名称：来自适用协议：网络新闻状态：标准作者/变更控制者：IETF规范文件：本文件（第3.1.2节），[RFC5322]（第3.6.2节）
Header field name: Injection-Date
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.7)
Header field name: Injection-Date
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.7)
Header field name: Injection-Info
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.8)
Header field name: Injection-Info
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.8)
Header field name: Keywords Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2), [RFC5322] (Section 3.6.5)
标题字段名称：关键词适用协议：网络新闻状态：标准作者/变更控制者：IETF规范文件：本文件（第3.2节），[RFC5322]（第3.6.5节）
Header field name: Lines
Applicable protocol: netnews
Status: deprecated
Author/change controller: IETF
Specification document(s): This document (Section 3.3.1)
Related information: [RFC3977] (Section 8.1)
Header field name: Lines
Applicable protocol: netnews
Status: deprecated
Author/change controller: IETF
Specification document(s): This document (Section 3.3.1)
Related information: [RFC3977] (Section 8.1)
Header field name: Message-ID
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.3)
Related information: [RFC5322] (Section 3.6.4)
Header field name: Message-ID
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.3)
Related information: [RFC5322] (Section 3.6.4)
Header field name: Newsgroups
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.4)
Header field name: Newsgroups
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.4)
Header field name: NNTP-Posting-Date
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): none
Header field name: NNTP-Posting-Date
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): none
Header field name: NNTP-Posting-Host
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC2980] (Section 3.4.1)
Header field name: NNTP-Posting-Host
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC2980] (Section 3.4.1)
Header field name: Organization
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.9)
Header field name: Organization
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.9)
Header field name: Path
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.5)
Header field name: Path
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.5)
Header field name: Posting-Version
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.1.2)
Header field name: Posting-Version
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.1.2)
Header field name: References Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.10), [RFC5322] (Section 3.6.4)
标题字段名称：参考适用协议：网络新闻状态：标准作者/变更控制者：IETF规范文件：本文件（第3.2.10节），[RFC5322]（第3.6.4节）
Header field name: Relay-Version
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.1.1)
Header field name: Relay-Version
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.1.1)
Header field name: Reply-To Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2), [RFC5322] (Section 3.6.2)
标题字段名称：对适用协议的回复：网络新闻状态：标准作者/变更控制者：IETF规范文件：本文件（第3.2节），[RFC5322]（第3.6.2节）
Header field name: See-Also
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.16)
Header field name: See-Also
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.16)
Header field name: Sender Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2), [RFC5322] (Section 3.6.2)
标题字段名称：发送方适用协议：网络新闻状态：标准作者/变更控制者：IETF规范文件：本文件（第3.2节），[RFC5322]（第3.6.2节）
Header field name: Subject Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.6), [RFC5322] (Section 3.6.5)
标题字段名称：主题适用协议：网络新闻状态：标准作者/变更控制者：IETF规范文件：本文件（第3.1.6节），[RFC5322]（第3.6.5节）
Header field name: Summary
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.11)
Header field name: Summary
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.11)
Header field name: Supersedes
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.12)
Header field name: Supersedes
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.12)
Header field name: User-Agent
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.13)
Related information: [RFC2616] (Section 14.43)
Header field name: User-Agent
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.13)
Related information: [RFC2616] (Section 14.43)
Header field name: Xref
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.14)
Header field name: Xref
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.14)
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2049]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，“在Internet消息中传递表示信息：内容处置头字段”，RFC 2183，1997年8月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[RFC3282]Alvestrand，H.，“内容语言标题”，RFC 3282，2002年5月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and Protocols", RFC 5537, November 2009.
[RFC5537]Allbery，R.，Ed.和C.Lindsey，“网络新闻体系结构和协议”，RFC5372009年11月。
[Errata] "RFC Editor Errata", <http://www.rfc-editor.org/errata.php>.
[勘误表]“RFC编辑器勘误表”<http://www.rfc-editor.org/errata.php>.
[ISO3166-1] International Organization for Standardization, "ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", 1997.
[ISO3166-1]国际标准化组织，“ISO 3166-1:1997.国家及其分支机构名称表示代码——第1部分：国家代码”，1997年。
[PGPVERIFY] Lawrence, D., "Authentication of Usenet Group Changes (pgpverify)", June 1999, <ftp://ftp.isc.org/pub/pgpcontrol/README.html>.
[PGPVERIFY]Lawrence，D.，“Usenet组变更认证（PGPVERIFY）”，1999年6月<ftp://ftp.isc.org/pub/pgpcontrol/README.html>.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC0822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC0850] Horton, M., "Standard for interchange of USENET messages", RFC 850, June 1983.
[RFC0850]霍顿，M.，“USENET消息交换标准”，RFC 850，1983年6月。
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
[RFC1036]霍顿，M.和R.亚当斯，“USENET消息交换标准”，RFC1036，1987年12月。
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[RFC2156]Kille，S.，“混音器（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，1998年1月。
[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.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[RFC2980]Barber，S.，“通用NNTP扩展”，RFC 29802000年10月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156]Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004.
[RFC3696]Klensin，J.，“名称检查和转换的应用技术”，RFC 36962004年2月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[RFC3977]Feather，C.，“网络新闻传输协议（NNTP）”，RFC3977，2006年10月。
[Son-of-1036] Spencer, H., "Son of 1036: News Article Format and Transmission", Work in Progress, May 2009.
[1036之子]斯宾塞，H.，“1036之子：新闻文章格式和传播”，正在进行的工作，2009年5月。
[USEAGE] Lindsey, C., "Usenet Best Practice", Work in Progress, March 2005.
[USEAGE]Lindsey，C.，“Usenet最佳实践”，正在进行的工作，2005年3月。
As this document is the result of an eight-year effort, the number of people that have contributed to its content are too numerous to mention individually. Many thanks go out to all past and present members of the USEFOR Working Group of the Internet Engineering Task Force (IETF) and its accompanying mailing list.
由于本文件是八年努力的结果，对其内容作出贡献的人数太多，无法单独提及。非常感谢互联网工程任务组（IETF）USEFOR工作组的所有过去和现在的成员及其附带的邮件列表。
This appendix contains a list of changes that have been made in the Netnews article format from earlier standards, specifically [RFC1036].
本附录包含Netnews文章格式与早期标准（特别是[RFC1036]）相比所做更改的列表。
o The [RFC5322] conventions for parenthesis-enclosed <comment>s in header fields are supported in all newly defined header fields and in header fields inherited from [RFC5322]. They are, however, still disallowed for performance and/or compatibility reasons in the Control, Distribution, Followup-To, Lines, Message-ID, Newsgroups, Path, Supersedes, and Xref header fields.
o 在所有新定义的标题字段和从[RFC5322]继承的标题字段中，都支持标题字段中括号括起的[RFC5322]约定。但是，出于性能和/或兼容性原因，在控件、分发、后续操作、行、消息ID、新闻组、路径、替代和外部参照标头字段中仍然不允许使用它们。
o Multiple addresses are allowed in the From header field.
o “发件人标头”字段中允许有多个地址。
o [FWS] is permitted in Newsgroups header fields.
o 允许在新闻组标题字段中使用[FWS]。
o An enhanced syntax for the Path header field enables the injection point of, and the route taken by, an article to be determined with more precision.
o Path header字段的增强语法可以更精确地确定文章的注入点和路径。
o Only one (1) message identifier is allowed in the Supersedes header field.
o “取代”标头字段中只允许有一（1）个消息标识符。
o MIME is recognized as an integral part of Netnews.
o MIME被认为是网络新闻不可或缺的一部分。
o There is a new Injection-Date header field to make the rejection of stale articles more precise and to minimize spurious rejections.
o 有一个新的注入日期标题字段，可以更精确地拒绝过期物品，并最大限度地减少虚假拒绝。
o There are several new optional header fields defined, notably Archive, Injection-Info, and User-Agent, leading to increased functionality.
o 定义了几个新的可选标题字段，特别是归档、注入信息和用户代理，从而增加了功能。
o Certain header fields, notably Lines, have been deprecated or made obsolete (Section 3.3).
o 某些标题字段（尤其是行）已被弃用或作废（第3.3节）。
o The convention to interpret subjects starting with the word "cmsg" as a control message was removed.
o 删除了将以“cmsg”一词开头的受试者解释为控制信息的惯例。
o There are numerous other small changes, clarifications, and enhancements.
o 还有许多其他的小改动、澄清和增强。
This appendix lists the differences between the syntax allowed by the Netnews article format (this document) as compared to the Internet Message Format, as specified in [RFC5322].
本附录列出了Netnews文章格式（本文档）所允许的语法与[RFC5322]中规定的互联网消息格式之间的差异。
The Netnews article format is a strict subset of the Internet Message Format; all Netnews articles conform to the syntax of [RFC5322].
网络新闻文章格式是互联网消息格式的严格子集；所有Netnews文章都符合[RFC5322]的语法。
The following restrictions are important:
以下限制很重要：
o A SP (space) is REQUIRED after the colon (':') following a header field name.
o 标题字段名称后面的冒号（“：”）后面需要一个SP（空格）。
o A slightly restricted syntax of <msg-id> (to be used by the Message-ID, References, and Supersedes header fields) is defined.
o 定义了稍微受限的<msg id>（由消息id、引用和取代头字段使用）语法。
o The length of a <msg-id> MUST NOT exceed 250 octets.
o <msg id>的长度不得超过250个八位字节。
o Comments are not allowed in the Message-ID header field.
o 消息ID标头字段中不允许有注释。
o The CFWS between <msg-id>s in the References header field is not optional.
o 引用标头字段中<msg id>s之间的CFWS不是可选的。
o It is legal for a parser to reject obsolete syntax, except that:
o 解析器拒绝过时语法是合法的，但以下情况除外：
* The <obs-phrase> construct MUST be accepted.
* 必须接受<obs短语>构造。
* The obsolete <zone> "GMT" MUST be accepted within a <date-time>.
* 必须在<date time>内接受过时的<zone>“GMT”。
o Every line of a header field body (including the first and any that are subsequently folded) MUST contain at least one non-whitespace character. This means that an empty header field body is illegal.
o 标题字段正文的每一行（包括第一行和随后折叠的任何行）必须至少包含一个非空白字符。这意味着空标题字段正文是非法的。
Authors' Addresses
作者地址
Kenneth Murchison (editor) Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 U.S.A.
肯尼斯·默奇森（编辑）美国宾夕法尼亚州匹兹堡福布斯大道5000号卡内基梅隆大学塞尔特大厅285号，邮编15213。
Phone: +1 412 268 2638
EMail: murch@andrew.cmu.edu
Phone: +1 412 268 2638
EMail: murch@andrew.cmu.edu
Charles H. Lindsey University of Manchester 5 Clerewood Avenue Heald Green Cheadle Cheshire SK8 3JU U.K.
查尔斯·H·林赛曼彻斯特大学5 Cree伍伍德大道综绿奇德尔柴郡SK8 3JU英国
Phone: +44 161 436 6131
EMail: chl@clerew.man.ac.uk
Phone: +44 161 436 6131
EMail: chl@clerew.man.ac.uk
Dan Kohn Healing Thresholds 211 N End Ave Apt 22E New York, NY 10282 U.S.A.
Dan Kohn美国纽约州纽约市南端大道211号22 E室邮编10282。
Phone: +1 415 233 1000
EMail: dan@dankohn.com
Phone: +1 415 233 1000
EMail: dan@dankohn.com