Internet Engineering Task Force (IETF) F. Ellermann
Request for Comments: 5538 xyzzy
Category: Standards Track April 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Ellermann
Request for Comments: 5538 xyzzy
Category: Standards Track April 2010
ISSN: 2070-1721
The 'news' and 'nntp' URI Schemes
“news”和“nntp”URI方案
Abstract
摘要
This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track.
此备忘录指定了最初在RFC 1738中定义的“新闻”和“nntp”统一资源标识符（URI）方案。本文件的目的是使RFC 1738过时，同时将有关这些方案的信息保持在标准轨道上。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/5538.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/5538.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 Simplified 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
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人可能没有授予IETF信托允许的权利
modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling 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标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. 'nntp' URIs . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. 'news' URIs . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Query Parts, Fragments, and Normalization . . . . . . . . 5
3. Syntax of 'nntp' URIs . . . . . . . . . . . . . . . . . . . . 5
4. Syntax of 'news' URIs . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
6. Internationalization Considerations . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. 'snews' URIs . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. 'news-message-ID' Access Type . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 13
Appendix B. Detailed Example . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. 'nntp' URIs . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. 'news' URIs . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Query Parts, Fragments, and Normalization . . . . . . . . 5
3. Syntax of 'nntp' URIs . . . . . . . . . . . . . . . . . . . . 5
4. Syntax of 'news' URIs . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
6. Internationalization Considerations . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. 'snews' URIs . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. 'news-message-ID' Access Type . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 13
Appendix B. Detailed Example . . . . . . . . . . . . . . . . . . 13
The first definition for many URI schemes appears in [RFC1738]. This memo extracts the 'news' and 'nntp' URI schemes from it to allow that material to remain on the Standards Track if [RFC1738] is moved to "historic" status. It belongs to a series of similar documents like [RFC4156], [RFC4157], [RFC4248], and [RFC4266], which are discussed on the <mailto:uri@w3.org> list.
许多URI方案的第一个定义出现在[RFC1738]中。此备忘录从中提取“新闻”和“nntp”URI方案，以便在[RFC1738]被移至“历史”状态时，允许该材料保留在标准轨道上。它属于一系列类似文件，如[RFC4156]、[RFC4157]、[RFC4248]和[RFC4266]，这些文件在<mailto:uri@w3.org>名单。
The definitions for the 'news' and 'nntp' URI schemes given here are updates from [RFC1738] based on modern usage of these schemes. This memo intentionally limits its description of the 'news' URI scheme to essential features supposed to work with "any browser" and Network News Transfer Protocol (NNTP) server.
这里给出的“news”和“nntp”URI模式的定义是[RFC1738]基于这些模式的现代用法的更新。本备忘录有意将其对“新闻”URI方案的描述限制为与“任何浏览器”和网络新闻传输协议（NNTP）服务器配合使用的基本功能。
[RFC3986] specifies how to define schemes for URIs; it also explains the term "Uniform Resource Locator" (URL). The Network News Transfer Protocol (NNTP) is specified in [RFC3977]. The Netnews Article Format is defined in [RFC5536].
[RFC3986]指定如何为URI定义方案；它还解释了术语“统一资源定位器”（URL）。[RFC3977]中规定了网络新闻传输协议（NNTP）。Netnews文章格式在[RFC5536]中定义。
The key word "MUST" in this memo is to be interpreted as described in [RFC2119]. UTF-8 is specified in [RFC3629]. The syntax uses the ABNF defined in [RFC5234].
本备忘录中的关键词“必须”应按照[RFC2119]中的说明进行解释。[RFC3629]中规定了UTF-8。该语法使用[RFC5234]中定义的ABNF。
The 'news' and 'nntp' URI schemes identify resources on an NNTP server, individual articles, individual newsgroups, or sets of newsgroups.
“news”和“nntp”URI模式标识nntp服务器上的资源、单个文章、单个新闻组或一组新闻组。
User agents like Web browsers supporting these schemes use the NNTP protocol to access the corresponding resources. The details of how they do this, e.g., employing a separate or integrated newsreader, depend on the implementation. The default <port> associated with NNTP in [RFC3977] is 119.
支持这些方案的Web浏览器等用户代理使用NNTP协议访问相应的资源。他们如何做到这一点的细节，例如，使用单独或集成的新闻阅读器，取决于实现。[RFC3977]中与NNTP关联的默认<port>为119。
The 'nntp' URI scheme identifies articles in a newsgroup on a specific NNTP server. In [RFC3986] terminology, this means that 'nntp' URIs have a non-empty <authority> component; there is no default <host> as for the 'file' or 'news' URI schemes.
“nntp”URI方案标识特定nntp服务器上新闻组中的文章。在[RFC3986]术语中，这意味着“nntp”URI具有非空的<authority>组件；对于“文件”或“新闻”URI方案，没有默认的<host>。
Netnews is typically distributed among several news servers, using the same newsgroup names but local article numbers. An article available as number 10 in group "example" on server "news.example.com" has most likely a different number on any other
Netnews通常分布在多个新闻服务器之间，使用相同的新闻组名称，但使用本地文章编号。在“news.example.com”服务器上的“example”组中，一篇文章的编号为10，很可能在任何其他网站上都有不同的编号
server where the same article is still available. Users allowed to read and post articles on "their" server may not be allowed to access articles on an "arbitrary" server specified in an 'nntp' URI.
相同文章仍然可用的服务器。允许在“他们的”服务器上阅读和发布文章的用户可能无法访问“nntp”URI中指定的“任意”服务器上的文章。
For these reasons, the use of the 'nntp' URI scheme is limited, and it is less widely supported by user agents than the similar 'news' URI scheme.
由于这些原因，“nntp”URI方案的使用受到限制，并且与类似的“news”URI方案相比，用户代理对它的支持不那么广泛。
The 'news' URI scheme identifies articles by their worldwide unique "Message-ID", independent of the server and the newsgroup. Newsreaders support access to articles by their "Message-ID", without the overhead of a URI scheme. In simple cases, they do this directly as an NNTP client of a default or currently used server as configured by the user. More general user agents use the 'news' URI scheme to distinguish "Message-IDs" from similar constructs such as other URI schemes in contexts such as a plain text message body.
“news”URI方案通过其全球唯一的“messageid”来识别文章，独立于服务器和新闻组。新闻阅读器支持通过其“消息ID”访问文章，而无需URI方案的开销。在简单的情况下，它们直接作为用户配置的默认服务器或当前使用的服务器的NNTP客户端执行此操作。更一般的用户代理使用“新闻”URI方案来区分“消息ID”与类似的构造，例如在纯文本消息正文等上下文中的其他URI方案。
The 'news' URI scheme also allows the identification of newsgroups or sets of newsgroups independent of a specific server. For Netnews, a group "example" has the same name on any server carrying this group, exotic cases involving gateways notwithstanding. To distinguish "Message-IDs" and newsgroup names, the 'news' URI scheme relies on the "@" between local part (left-hand side) and domain part (right-hand side) of "Message-IDs".
“新闻”URI方案还允许独立于特定服务器识别新闻组或新闻组集。对于Netnews，组“示例”在承载该组的任何服务器上都具有相同的名称，尽管存在涉及网关的特殊情况。为了区分“消息ID”和新闻组名称，“新闻”URI方案依赖于“消息ID”的本地部分（左侧）和域部分（右侧）之间的“@”。
[RFC1738] offered only one wildcard for sets of newsgroups in 'news' URIs, a "*" used to refer to "all available newsgroups". In common practice, this was extended to varying degrees by different user agents. An NNTP extension known as <wildmat>, specified in [RFC2980] and now part of the base NNTP specification, allows pattern matching in the style of the [POSIX] "find" command. For the purpose of this memo, this means that some additional special characters have to be allowed in 'news' URIs, some of them percent-encoded as required by the overall [RFC3986] URI syntax. User agents and NNTP servers not yet compliant with [RFC3977] do not implement all parts of this new feature.
[RFC1738]仅为“新闻”URI中的新闻组集提供了一个通配符，一个“*”用于表示“所有可用新闻组”。在通常的实践中，不同的用户代理在不同程度上扩展了这一功能。[RFC2980]中指定的名为<wildmat>的NNTP扩展，现在是基本NNTP规范的一部分，允许以[POSIX]“find”命令的样式进行模式匹配。就本备忘录而言，这意味着在“新闻”URI中必须允许一些额外的特殊字符，其中一些字符按照[RFC3986]URI语法的要求进行百分比编码。尚未与[RFC3977]兼容的用户代理和NNTP服务器未实现此新功能的所有部分。
Another commonly supported addition to the [RFC1738] syntax is the optional specification of a server at the beginning of 'news' URIs. This optional <authority> component follows the overall [RFC3986] syntax, preceded by a double slash "//" and terminated by the next slash "/", question mark "?", number sign "#", or the end of the URI.
[RFC1738]语法的另一个普遍支持的补充是在“news”URI开头的可选服务器规范。此可选的<authority>组件遵循整个[RFC3986]语法，前面是双斜杠“/”，以下一个斜杠“/”、问号“？”、数字符号“#”或URI结尾。
Fragments introduced by a number sign "#" are specified in [RFC3986]; the semantics is independent of the URI scheme, and the resolution depends on the media type.
[RFC3986]中指定了由数字符号“#”引入的片段；语义独立于URI方案，解析取决于媒体类型。
This memo doesn't specify a query part introduced by a question mark "?" for the 'news' and 'nntp' URI schemes, but some implementations are known to use query parts instead of fragments internally to address parts of a composite media type [RFC2046] in Multipurpose Internet Mail Extensions (MIME).
此备忘录没有为“news”和“nntp”URI方案指定问号“？”引入的查询部分，但已知一些实现在内部使用查询部分而不是片段来寻址多用途Internet邮件扩展（MIME）中复合媒体类型[RFC2046]的部分。
There are no special "." or ".." path segments in 'news' and 'nntp' URLs. Please note that "." and ".." are not valid <newsgroup-name>s.
“新闻”和“nntp”URL中没有特殊的“.”或“.”路径段。请注意，“.”和“.”无效。
URI producers have to percent-encode some characters as specified below (Section 4); otherwise, they MUST treat a "Message-ID" without angle brackets for 'news' URLs as is, i.e., case-sensitive.
URI生产者必须按照以下规定对某些字符进行百分比编码（第4节）；否则，他们必须按原样对待“新闻”URL的“消息ID”（不带尖括号），即区分大小写。
An 'nntp' URI identifies an article by its number in a given newsgroup on a specified server, or it identifies the newsgroup without article number.
“nntp”URI通过指定服务器上给定新闻组中的文章编号来标识文章，或者标识没有文章编号的新闻组。
nntpURL = "nntp:" server "/" group [ "/" article-number ]
server = "//" authority ; see RFC 3986
group = 1*( group-char / pct-encoded )
article-number = 1*16DIGIT ; see RFC 3977
group-char = ALPHA / DIGIT / "-" / "+" / "_" / "."
nntpURL = "nntp:" server "/" group [ "/" article-number ]
server = "//" authority ; see RFC 3986
group = 1*( group-char / pct-encoded )
article-number = 1*16DIGIT ; see RFC 3977
group-char = ALPHA / DIGIT / "-" / "+" / "_" / "."
In the form with an <article-number>, the URL corresponds roughly to the content of an <xref> header field as specified in [RFC5536], replacing its more general <article-locator> by the <article-number> used with the NNTP.
在带有<article number>的表单中，URL大致对应于[RFC5536]中指定的<xref>标题字段的内容，将其更通用的<article locator>替换为与NNTP一起使用的<article number>。
A <newsgroup-name> as specified in [RFC5536] consists of dot-separated components. Each component contains one or more letters, digits, "-" (hyphen-minus), "+", or "_" (underscore). These characters can be directly used in a segment of a path in an [RFC3986] URI; no percent-encoding is necessary. Example:
[RFC5536]中指定的<newsgroup name>由点分隔的组件组成。每个组件包含一个或多个字母、数字、“-”（连字符减号）、“+”或“”（下划线）。这些字符可以直接用于[RFC3986]URI中的路径段；不需要百分比编码。例子：
nntp://news.server.example/example.group.this/12345
nntp://news.server.example/example.group.this/12345
A <wildmat-exact> newsgroup name as specified in [RFC3977] allows (in
theory) any <UTF8-non-ascii> (see Section 6) and most printable
US-ASCII characters, excluding "!", "*", ",", "?", "[", "\", and "]".
However, [RFC5536] does not (yet) permit characters outside of
A <wildmat-exact> newsgroup name as specified in [RFC3977] allows (in
theory) any <UTF8-non-ascii> (see Section 6) and most printable
US-ASCII characters, excluding "!", "*", ",", "?", "[", "\", and "]".
However, [RFC5536] does not (yet) permit characters outside of
<group-char> and so, to keep the syntax simple, the additional characters are here covered by <pct-encoded> as defined in [RFC3986], since most of them have to be percent-encoded anyway (with a few exceptions, such as ":", ";", and "~"). Example:
<group char>因此，为了保持语法简单，此处的附加字符由[RFC3986]中定义的<pct encoded>涵盖，因为它们中的大多数都必须进行百分比编码（除了少数例外，如“：”、“；”和“~”）。例子：
nntp://wild.server.example/example.group.n%2Fa/12345
nntp://wild.server.example/example.group.n%2Fa/12345
In the form without <article-number>, the URL identifies a single group on the specified server. This is also possible with an equivalent 'news' URL, and the latter is better supported by user agents. Example:
在不带<article number>的表单中，URL标识指定服务器上的单个组。这也可以通过一个等效的“新闻”URL实现，用户代理更好地支持后者。例子：
nntp://news.server.example/example.group.this
news://news.server.example/example.group.this
nntp://news.server.example/example.group.this
news://news.server.example/example.group.this
A 'news' URI identifies an article by its unique "Message-ID", or it identifies a set of newsgroups. Additionally, it can specify a server; when the server is not specified, a configured default server for Netnews access is used.
“新闻”URI通过其唯一的“消息ID”标识文章，或者标识一组新闻组。此外，它还可以指定服务器；未指定服务器时，将使用为Netnews访问配置的默认服务器。
newsURL = "news:" [ server "/" ] ( article / newsgroups )
article = msg-id-core ; see RFC 5536
newsURL = "news:" [ server "/" ] ( article / newsgroups )
article = msg-id-core ; see RFC 5536
The form identifying an <article> is the <msg-id-core> from
[RFC5536]; it is a "Message-ID" without angle brackets. According to
[RFC3986], characters that are in <gen-delims> (a subset of
<reserved>), together with the character "%", MUST be percent-encoded
(though it is not wrong to encode others). Specifically, the
characters allowed in <msg-id-core> that must be encoded are
The form identifying an <article> is the <msg-id-core> from
[RFC5536]; it is a "Message-ID" without angle brackets. According to
[RFC3986], characters that are in <gen-delims> (a subset of
<reserved>), together with the character "%", MUST be percent-encoded
(though it is not wrong to encode others). Specifically, the
characters allowed in <msg-id-core> that must be encoded are
"/" "?" "#" "[" "]" and "%"
“/”“？”“#”“[”“]”和“%”
Note that an agent which seeks to interpret a 'news' URI needs to decode all percent-encoded characters before passing it on to an NNTP server to be acted upon.
请注意，试图解释“新闻”URI的代理需要先解码所有百分比编码字符，然后再将其传递给NNTP服务器进行操作。
Please note that "%3E" (">") is not allowed; <msg-id-core> is
otherwise identical to
Please note that "%3E" (">") is not allowed; <msg-id-core> is
otherwise identical to
id-left "@" id-right
id左“@”id右
as defined in [RFC5322].
如[RFC5322]中所定义。
The form identifying <newsgroups> corresponds to the [RFC3977] <wildmat-pattern>, a newsgroup name with wildcards "*" and "?". Any "?" has to be percent-encoded as "%3F" in this part of a URI.
标识<newsgroups>的表单对应于[RFC3977]<wildmat pattern>，这是一个带有通配符“*”和“？”的新闻组名称。在URI的这一部分中，任何“？”都必须百分比编码为“%3F”。
Examples (the first two are equivalent):
示例（前两个等效）：
news://news.server.example/*
news://news.server.example/
news://wild.server.example/example.group.th%3Fse
news:example.group.*
news:example.group.this
news://news.server.example/*
news://news.server.example/
news://wild.server.example/example.group.th%3Fse
news:example.group.*
news:example.group.this
Without wildcards, this form of the URL identifies a single group if it is not empty. User agents would typically try to present an overview of the articles available in this group, likely somehow limiting this overview to the newest unread articles up to a configured maximum.
如果不使用通配符，这种形式的URL将标识单个组（如果该组不是空的）。用户代理通常会尝试呈现此组中可用文章的概述，可能会以某种方式将此概述限制为最新的未读文章，最多可配置一个上限。
With wildcards, user agents could try to list matching group names on the specified or default server. Some user agents support only a specific <group> without wildcards, or an optional single "*".
使用通配符，用户代理可以尝试在指定或默认服务器上列出匹配的组名。某些用户代理只支持不带通配符的特定<group>，或可选的单个“*”。
As noted above (Section 2.2), the presence of an "@" in a 'news' URI disambiguates <article> and <newsgroups> for URI consumers. The new <message-id> construct specified in [RFC3977] does not require an "@". Since [RFC0822], the "Message-ID" syntax has been closely related to the syntax of mail addresses with an "@" separating left-hand side (local part of addresses, unique part of message identifiers) and right-hand side (domain part), and this memo sticks to the known [RFC1738] practice.
如上所述（第2.2节），“新闻”URI中的“@”消除了URI消费者对<article>和<newsgroups>的歧义。[RFC3977]中指定的新<message id>构造不需要“@”。自[RFC0822]以来，“邮件ID”语法一直与邮件地址的语法密切相关，左侧（地址的本地部分、邮件标识符的唯一部分）和右侧（域部分）用“@”分隔，本备忘录遵循已知的[RFC1738]实践。
Henry Spencer was the driving force to adopt MIME in Netnews; he registered the MIME 'message/external-body' access type 'news-message-ID', discussed below (Section 8.2), in 1993 as recalled in "Son-of-1036" [RFC1849].
亨利·斯宾塞（Henry Spencer）是网络新闻中采用哑剧的驱动力；他于1993年注册了MIME“消息/外部主体”访问类型“新闻消息ID”，如下所述（第8.2节），如“Son-of-1036”[RFC1849]所述。
"The 'news' URL scheme" [GILMAN], by Alfred S. Gilman (March 1998), introduced additions to the original [RFC1738] 'news' URI scheme. Some of these ideas are now widely supported and reflected by the revised 'news' URI scheme specified here.
阿尔弗雷德·吉尔曼（Alfred S.GILMAN）（1998年3月）的“新闻”URL方案[GILMAN]对原始[RFC1738]“新闻”URI方案进行了补充。其中一些想法现在得到了广泛支持，并在此处指定的修订版“news”URI方案中得到了反映。
Thanks to Alfred Hoenes, Charles Lindsey, Clive Feather, Chris Newman, Ken Murchinson, Kjetil T. Homme, Lars Magne Ingebrigtsen, Martin Duerst, Matt Seitz, Nicolas Krebs, Paul Hoffman, Pasi Eronen, Roy T. Fielding, Russ Allbery, Stephane Bortzmeyer, and Tom Petch for their feedback, contributions, or encouragement.
感谢阿尔弗雷德·霍恩斯、查尔斯·林赛、克莱夫·费瑟、克里斯·纽曼、肯·默金森、克杰蒂尔·霍姆、拉尔斯·马格纳·英格布里格森、马丁·杜尔斯、马特·塞茨、尼古拉斯·克雷布斯、保罗·霍夫曼、帕西·埃隆、罗伊·T·菲尔丁、罗斯·奥尔贝里、斯蒂芬·博茨梅尔和汤姆·佩奇的反馈、贡献或鼓励。
Bill Fenner's _xml2rfc validator_ and _ABNF checker_ were a great help in the creation of (not only) this memo. The same goes for various great _IETF tools_ written by Henrik Levkowetz.
Bill Fenner的_xml2rfc验证器u和_abnfchecker u在创建（不仅仅是）此备忘录方面提供了巨大帮助。Henrik Levkowetz编写的各种伟大的IETF工具也是如此。
The URI schemes were updated to support percent-encoded UTF-8 characters in NNTP newsgroup names as specified in [RFC3977] and [RFC3987].
已更新URI方案，以支持[RFC3977]和[RFC3987]中指定的NNTP新闻组名称中的百分比编码UTF-8字符。
The Netnews Article Format in [RFC5536] does not yet allow UTF-8 in <newsgroup-name>s; therefore, well-known Unicode and UTF-8 security considerations are not listed below. For an overview, see [UTR36] and [RFC3629].
[RFC5536]中的Netnews文章格式尚不允许在<newsgroup name>s中使用UTF-8；因此，下面没有列出众所周知的Unicode和UTF-8安全注意事项。有关概述，请参阅[UTR36]和[RFC3629]。
The work on Email Address Internationalization (EAI), started in [RFC4952], is not expected to change the syntax of a "Message-ID".
始于[RFC4952]的电子邮件地址国际化（EAI）工作预计不会改变“消息ID”的语法。
There are many security considerations for URI schemes discussed in [RFC3986]. The NNTP protocol may use passwords in the clear for authentication or offer no privacy, both of which are considered extremely unsafe in current practice. Alternatives and further security considerations with respect to the NNTP are discussed in [RFC4642] and [RFC4643].
[RFC3986]中讨论了URI方案的许多安全注意事项。NNTP协议可以使用明文密码进行身份验证，或者不提供隐私，这两种情况在当前实践中都被认为是极不安全的。[RFC4642]和[RFC4643]中讨论了与NNTP相关的备选方案和进一步的安全注意事项。
The syntax for the 'news' and 'nntp' URI schemes contains the general <authority> construct with an optional <userinfo> defined in [RFC3986]. As noted in [RFC3986], the "user:password" form of a <userinfo> is deprecated.
“news”和“nntp”URI方案的语法包含通用的<authority>构造，并在[RFC3986]中定义了可选的<userinfo>。如[RFC3986]所述，<userinfo>的“用户：密码”形式已被弃用。
Articles on NNTP servers typically expire after some time. After that time, corresponding 'news' and 'nntp' URLs may not work anymore depending on the server. While a "Message-ID" is supposed to be worldwide unique forever, the NNTP protocol does not guarantee this. Under various conditions depending on the servers, the same "Message-ID" could be used for different articles, and attackers could try to distribute malicious content for known 'news' or 'nntp' URLs.
NNTP服务器上的文章通常在一段时间后过期。此后，根据服务器的不同，相应的“news”和“nntp”URL可能不再工作。虽然“消息ID”应该永远是全球唯一的，但NNTP协议并不保证这一点。根据服务器的不同情况，相同的“消息ID”可用于不同的文章，攻击者可尝试为已知的“新闻”或“nntp”URL分发恶意内容。
If a URI does not match the generic syntax in [RFC3986], it is invalid, and broken URIs can cause havoc. Compare [RFC5064] for similar security considerations.
如果URI与[RFC3986]中的通用语法不匹配，则该URI无效，并且损坏的URI可能会造成严重破坏。比较[RFC5064]以了解类似的安全注意事项。
The IANA registry of URI schemes has been updated to point to this memo instead of [RFC1738] for the 'news' and 'nntp' URI schemes.
已更新IANA URI方案注册表，以指向此备忘录，而不是“新闻”和“nntp”URI方案的[RFC1738]。
This section contains the [RFC4395] template for the registration of the historical 'snews' scheme specified in [GILMAN].
本节包含[RFC4395]模板，用于注册[GILMAN]中指定的历史“snews”方案。
URI scheme name: snews
URI方案名称：snews
Status: historical
现状：历史
URI scheme syntax: Same as for 'news' (Section 4)
URI方案语法：与“新闻”相同（第4节）
URI scheme semantics: Syntactically equivalent to 'news', but using NNTP over SSL/TLS (SSL/TLS with security layer is negotiated immediately after establishing the TCP connection) with a default port of 563, registered as "nntps"
URI方案语义：语法上等同于“news”，但在SSL/TLS上使用NNTP（在建立TCP连接后立即协商具有安全层的SSL/TLS），默认端口为563，注册为“nntps”
Encoding considerations: Same as for 'news' (Section 6)
编码注意事项：与“新闻”相同（第6节）
Applications/protocols that use this URI scheme name: For some user agents, 'snews' URLs trigger the use of "nntps" instead of NNTP for their access on Netnews
使用此URI方案名称的应用程序/协议：对于某些用户代理，“snews”URL触发使用“nntps”而不是NNTP来访问Netnews
Interoperability considerations: This URI scheme was not widely deployed; its further use is deprecated in favor of ordinary 'news' URLs in conjunction with NNTP servers supporting [RFC4642]
互操作性考虑：此URI方案未广泛部署；它的进一步使用已被弃用，取而代之的是普通的“新闻”URL以及支持[RFC4642]的NNTP服务器
Security considerations: See [RFC4642]; the use of a dedicated port for secure variants of a protocol was discouraged in [RFC2595]
安全注意事项：参见[RFC4642]；[RFC2595]中不鼓励将专用端口用于协议的安全变体
Contact: <mailto:uri@w3.org> (URI mailing list)
Contact: <mailto:uri@w3.org> (URI mailing list)
Change controller: IETF
更改控制器：IETF
References: RFC 5538, [RFC4642], [GILMAN]
参考文献：RFC5538、[RFC4642]、[GILMAN]
The MIME 'news-message-ID' access type was erroneously listed as a subtype. IANA has removed 'news-message-ID' from the application subtype registry, and has added it to the access types registry defined in [RFC4289].
MIME“news message ID”访问类型被错误地列为子类型。IANA已从应用程序子类型注册表中删除“新闻消息ID”，并将其添加到[RFC4289]中定义的访问类型注册表中。
[RFC4289] requires an RFC (preferably on the Standards Track) for the access types registry. To provide a definition meeting this requirement, the following paragraph is reproduced verbatim from [RFC1849]:
[RFC4289]需要访问类型注册表的RFC（最好在标准轨道上）。为提供符合此要求的定义，以下段落逐字复制自[RFC1849]：
NOTE: In the specific case where it is desired to essentially make another article PART of the current one, e.g., for annotation of the other article, MIME's "message/external-body" convention can be used to do so without actual inclusion. "news-message-ID" was registered as a standard external-body access method, with a mandatory NAME parameter giving the message ID and an optional SITE parameter suggesting an NNTP site that might have the article available (if it is not available locally), by IANA 22 June 1993.
注意：在需要基本上使另一篇文章成为当前文章的一部分的特定情况下，例如，对于另一篇文章的注释，可以使用MIME的“消息/外部主体”约定来实现，而无需实际包含。“新闻消息ID”作为一种标准的外部机构访问方法进行了注册，IANA于1993年6月22日通过一个强制性名称参数提供消息ID，并通过一个可选站点参数建议一个NNTP站点，该站点可能有该文章（如果在本地不可用）。
Please note that 'news' URLs offer a very similar and (today) more common way to access articles by their Message-ID; compare [RFC2017].
请注意，“新闻”URL提供了一种非常相似且（今天）更常见的通过消息ID访问文章的方式；比较[RFC2017]。
[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月。
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[RFC3977]Feather，C.，“网络新闻传输协议（NNTP）”，RFC3977，2006年10月。
[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月。
[RFC5536] Murchison, K., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, November 2009.
[RFC5536]Murchison，K.，Lindsey，C.，和D.Kohn，“网络新闻文章格式”，RFC5362009年11月。
[GILMAN] Gilman, A., "The 'news' URL scheme", Work in Progress, March 1998.
[GILMAN]GILMAN，A.，“新闻”URL方案，正在进行的工作，1998年3月。
[POSIX] Institute of Electrical and Electronics Engineers, "The Open Group Base Specifications Issue 6", IEEE Standard 1003.1, 2004 edition.
[POSIX]电气和电子工程师协会，“开放组基础规范第6期”，IEEE标准1003.12004年版。
[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月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]Berners Lee，T.，Masinter，L.，和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC1849] Spencer, H., ""Son of 1036": News Article Format and Transmission", RFC 1849, March 2010.
[RFC1849]斯宾塞，H.，“1036之子：新闻文章格式和传输”，RFC18492010年3月。
[RFC2017] Freed, N. and K. Moore, "Definition of the URL MIME External-Body Access-Type", RFC 2017, October 1996.
[RFC2017]Freed，N.和K.Moore，“URL MIME外部实体访问类型的定义”，RFC 2017，1996年10月。
[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月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595]Newman，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC2595，1999年6月。
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[RFC2980]Barber，S.，“通用NNTP扩展”，RFC 29802000年10月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC4156] Hoffman, P., "The wais URI Scheme", RFC 4156, August 2005.
[RFC4156]Hoffman，P.，“wais URI方案”，RFC 4156，2005年8月。
[RFC4157] Hoffman, P., "The prospero URI Scheme", RFC 4157, August 2005.
[RFC4157]Hoffman，P.，“普洛斯彼罗URI方案”，RFC 4157，2005年8月。
[RFC4248] Hoffman, P., "The telnet URI Scheme", RFC 4248, October 2005.
[RFC4248]Hoffman，P.，“telnet URI方案”，RFC 4248，2005年10月。
[RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266, November 2005.
[RFC4266]Hoffman，P.，“地鼠URI方案”，RFC 4266，2005年11月。
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
[RFC4289]Freed，N.和J.Klensin，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 4289，2005年12月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, October 2006.
[RFC4642]Murchison，K.，Vinocur，J.，和C.Newman，“将传输层安全（TLS）与网络新闻传输协议（NNTP）结合使用”，RFC 4642，2006年10月。
[RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer Protocol (NNTP) Extension for Authentication", RFC 4643, October 2006.
[RFC4643]Vinocur，J.和K.Murchison，“用于认证的网络新闻传输协议（NNTP）扩展”，RFC 46432006年10月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC 49522007年7月。
[RFC5064] Duerst, M., "The Archived-At Message Header Field", RFC 5064, December 2007.
[RFC5064]Duerst，M.“在消息头字段存档”，RFC 5064，2007年12月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[UTR36] Davis, M. and M. Suignard, "Unicode Security Considerations", Unicode Technical Reports #36, August 2006.
[UTR36]Davis，M.和M.Suignard，“Unicode安全注意事项”，Unicode技术报告#36，2006年8月。
In addition to the syntax given above, this appendix also lists the sources of terms used in comments and the prose:
除上述语法外，本附录还列出了评论和散文中使用的术语来源：
nntpURL = "nntp:" server "/" group [ "/" article-number ]
server = "//" authority ; see RFC 3986
group = 1*( group-char / pct-encoded )
article-number = 1*16DIGIT ; see RFC 3977
group-char = ALPHA / DIGIT / "-" / "+" / "_" / "."
nntpURL = "nntp:" server "/" group [ "/" article-number ]
server = "//" authority ; see RFC 3986
group = 1*( group-char / pct-encoded )
article-number = 1*16DIGIT ; see RFC 3977
group-char = ALPHA / DIGIT / "-" / "+" / "_" / "."
newsURL = "news:" [ server "/" ] ( article / newsgroups )
article = msg-id-core ; see RFC 5536
newsgroups = *( group-char / pct-encoded / "*" )
newsURL = "news:" [ server "/" ] ( article / newsgroups )
article = msg-id-core ; see RFC 5536
newsgroups = *( group-char / pct-encoded / "*" )
authority = <see RFC 3986 Section 3.2>
host = <see RFC 3986 Section 3.2.2>
pct-encoded = <see RFC 3986 Section 2.1>
port = <see RFC 3986 Section 3.2.3>
gen-delims = <see RFC 3986 Section 2.2>
msg-id-core = <see RFC 5536 Section 3.1.3>
reserved = <see RFC 5536 Section 2.2>
userinfo = <see RFC 3986 Section 3.2.1>
authority = <see RFC 3986 Section 3.2>
host = <see RFC 3986 Section 3.2.2>
pct-encoded = <see RFC 3986 Section 2.1>
port = <see RFC 3986 Section 3.2.3>
gen-delims = <see RFC 3986 Section 2.2>
msg-id-core = <see RFC 5536 Section 3.1.3>
reserved = <see RFC 5536 Section 2.2>
userinfo = <see RFC 3986 Section 3.2.1>
message-id = <see RFC 3977 Section 9.8>
UTF8-non-ascii = <see RFC 3977 Section 9.8>
wildmat = <see RFC 3977 Section 4.1>
wildmat-exact = <see RFC 3977 Section 4.1>
wildmat-pattern = <see RFC 3977 Section 4.1>
message-id = <see RFC 3977 Section 9.8>
UTF8-non-ascii = <see RFC 3977 Section 9.8>
wildmat = <see RFC 3977 Section 4.1>
wildmat-exact = <see RFC 3977 Section 4.1>
wildmat-pattern = <see RFC 3977 Section 4.1>
ALPHA = <see RFC 5234 Appendix B.1>
DIGIT = <see RFC 5234 Appendix B.1>
ALPHA = <see RFC 5234 Appendix B.1>
DIGIT = <see RFC 5234 Appendix B.1>
article-locator = <see RFC 5536 Section 3.2.14>
newsgroup-name = <see RFC 5536 Section 3.1.4>
xref = <see RFC 5536 Section 3.2.14>
article-locator = <see RFC 5536 Section 3.2.14>
newsgroup-name = <see RFC 5536 Section 3.1.4>
xref = <see RFC 5536 Section 3.2.14>
Here is an example of a mail to the <mailto:tools.discuss@ietf.org> list with "Message-ID" <p0624081dc30b8699bf9b@[10.20.30.108]>.
下面是一个发送到<mailto:tools的邮件示例。discuss@ietf.org>带有“消息ID”的列表<p0624081dc30b8699bf9b@[10.20.30.108]>。
<http://dir.gmane.org/gmane.ietf.tools> is one of the various list archives; it converts mail into Netnews articles. The header of this article contains the following fields (among others):
<http://dir.gmane.org/gmane.ietf.tools>是各类清单档案之一；它将邮件转换为Netnews文章。本文的标题包含以下字段（以及其他字段）：
Message-ID: <p0624081dc30b8699bf9b@[10.20.30.108]>
Xref: news.gmane.org gmane.ietf.tools:742
Archived-At: <http://permalink.gmane.org/gmane.ietf.tools/742>
Message-ID: <p0624081dc30b8699bf9b@[10.20.30.108]>
Xref: news.gmane.org gmane.ietf.tools:742
Archived-At: <http://permalink.gmane.org/gmane.ietf.tools/742>
The "Xref" roughly indicates the 742nd article in newsgroup <news://news.gmane.org/gmane.ietf.tools> on this server. An 'nntp' URL might be <nntp://news.gmane.org/gmane.ietf.tools/742>. For details about the "Archived-At" URL, see [RFC5064].
“Xref”大致表示新闻组中的第742篇文章<news://news.gmane.org/gmane.ietf.tools>在这个服务器上。“nntp”URL可能是<nntp://news.gmane.org/gmane.ietf.tools/742>. 有关“存档地址”URL的详细信息，请参阅[RFC5064]。
The list software and list subscribers reading the list elsewhere can't predict a server-specific article number 742 in this archive. If they know this server, they can however guess the corresponding <news://news.gmane.org/p0624081dc30b8699bf9b@%5B10.20.30.108%5D> URL.
在别处阅读列表的列表软件和列表订阅者无法预测此存档中特定于服务器的文章编号742。如果他们知道这个服务器，他们可以猜测相应的<news://news.gmane.org/p0624081dc30b8699bf9b@%5B10.20.30.108%5D>URL。
In theory, the list software could use the guessed 'news' URL in an "Archived-At" header field, but if a list tries this, it would likely use <http://mid.gmane.org/p0624081dc30b8699bf9b@%5B10.20.30.108%5D>.
理论上，列表软件可以在“归档地址”标题字段中使用猜测的“新闻”URL，但如果列表尝试此操作，它可能会使用<http://mid.gmane.org/p0624081dc30b8699bf9b@%5B10.20.30.108%5D>。
Using domain literals in a "Message-ID" could cause collisions. A collision might force the mail2news gateway in this example to invent a new "Message-ID", and an attempt to guess the future URL on this server would then fail.
在“消息ID”中使用域文字可能会导致冲突。冲突可能会迫使本例中的mail2news网关发明一个新的“消息ID”，然后尝试猜测此服务器上的未来URL将失败。
Author's Address
作者地址
Frank Ellermann xyzzy Hamburg, Germany
Frank Ellermann xyzzy汉堡，德国
EMail: hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com
URI: http://purl.net/xyzzy/
EMail: hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com
URI: http://purl.net/xyzzy/