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（Multipurpose Internet Mail Extensions）（RFC 2045）の文脈におけるネットニュース記事の構文を指定します。この文書は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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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 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トラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、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
"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（Multipurpose Internet Mail Extensions）[RFC2045]の文脈におけるネットニュース記事の構文を指定します。この文書では、現在のやり方や、[息子-の-1036]など、他の文書で指定された組み込むの変更と明確化を反映するために、ネットニュース記事の構文を更新し、[RFC1036]を廃止します。
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]のセットの最初のです。この文書では、ネットニュース記事の構文と意味論に焦点を当てています。 [RFC5537]も標準化過程の文書であり、そのようなネットワークニュース転送プロトコル（NNTP）[RFC3977]などのトランスポートプロトコルとは無関係に、ネットニュース記事のプロトコルの問題について説明します。 [USEAGE]、「ユーズネットベストプラクティス」は、相互運用性と使いやすさを向上させるために、実装の推奨事項について説明します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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:
本明細書で定義されたヘッダフィールドは、[RFC2231]によって更新されるよう、[RFC5234]で指定されただけでなく、[RFC5322]で定義された多くの構築、[RFC2045]（コアルールを含む）増補バッカス - ナウアフォーム（ABNF）表記を使用し、そして[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>
トークン= <RFC 2045のセクション5.1を参照してください>値= <参照RFC 2045のセクション5.1>パラメータ=属性= <RFC 2231のセクション7を参照してください> <RFC 2231のセクション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 = <RFC 5322のセクション3.2.2を参照してください>コメント= <参照RFC 5322のセクション3.2.2> CFWS = <RFC 5322のセクション3.2.2を参照してください> atext = =ドット原子テキスト<RFC 5322のセクション3.2.3を参照してください>フレーズ= <参照RFC 5322のセクション3.2.5>日時= <RFC 5322のセクション3.3を参照してください>メールボックス= RFC 5322のセクション3.4を参照してください。<=メールボックスリスト<RFC 5322のセクション3.4参照>を<RFC 5322 3.2.3項参照> >アドレスリスト= <RFC 5322のセクション3.4>ボディは= <RFC 5322のセクション3.5>フィールド=を見る<RFC 5322のセクション3.6を参照してください>
IPv6address = <see RFC 3986 Section 3.2.2> IPv4address = <see RFC 3986 Section 3.2.2>
IPv6address = IPv4Addressを= <RFC 3986のセクション3.2.2を参照してください> <RFC 3986のセクション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 = CRLF = <参照RFC 5234の付録B.1> DIGIT = <RFC 5234付録B.1を参照してください> DQUOTE = <参照RFC 5234付録B.1> SP = <RFC 5234を参照してください。<RFC 5234の付録B.1参照>は、付録B.1> VCHAR = <RFC 5234付録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 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.
「メッセージ識別子」（3.1.3項）は、通常、「ニュース・サーバ」で、それを掲示したり、その失敗をユーザエージェントによって提供され、記事の一意の識別子です。それは今までどこにも掲載、他のすべての記事から記事を区別します。彼らは関係なく、身体またはヘッダフィールドの違いの同じ物品であるかのように同じメッセージ識別子を有する物品が処理されます。
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).
「フォロー」は、以前の記事、その「前駆体」の内容に対する応答を含む物品です。すべてのフォローアップは、その前駆体を識別する「参照」ヘッダフィールドを含む（しかし、非フォロー記事も参照フィールドをヘッダ使用してもよいことに留意されたいです）。
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節では、ネットニュース記事のフォーマットを定義します。第3節では、ネットニュース環境に適した製品を作るために必要なヘッダフィールドの詳細を示します。
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で指定された時代遅れの構文を使用して記事には次の2つの場合を除き、この仕様に準拠されていません。
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-フレーズ>構築物（引用符を使用せずに、「ジョンQ公開」のようなフレーズの使用、[RFC5322]のセクション4.1を参照）を使用する場合の記事は準拠しているが、薬剤は、このような構文の生産を生成してはなりません。
o Articles are conformant if they use the "GMT" <zone>, as specified in Section 3.1.1.
彼らは「GMT」<ゾーン>を使用している場合は、セクション3.1.1に指定されているOの記事は、準拠しています。
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
下のテキストは、[RFC5322]で指定された構文上の制限を指定するには、ABNFを使用しています。この文法は[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.
ABNF [RFC5322]で指定され、またここで指定した制約は、両方のテキストとして表現されるものと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.
ネットニュース記事のすべてのヘッダ・フィールドは、[RFC5322]に準拠しています。本明細書では、しかし、エージェントによって生成され、受け入れられるものではあまり寛容です。ネットニュースの記事ヘッダに許さ構文は、[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.
「：」ヘッダフィールド名およびヘッダフィールド本体分離（NNTPなど展開ソフトウェアとの互換性のために、[RFC3977]サーバ）少なくとも1つのスペースがすぐに追従するようにOすべてのエージェントは、ヘッダフィールドを生成しなければなりません。ニュース剤には、必要なスペースが含まれていないヘッダフィールドを受け入れることができます。
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:
unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSP
構造化されていない= * WSP VCHAR *（[ISI] 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
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個のオクテットに限定されます）。 【USEAGE】ユーザエージェントによる表示の便宜のために提案さの制限を含みます。
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).
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適合のこのレベルは、ヘッダーフィールド[RFC2047]及び[RFC2231]の国際化のための国際マルチメディアメッセージ本文に[RFC2045]、[RFC2046]及び[RFC2231]、およびサポートのためのサポートを提供します。 [正誤表]現在[RFC2047]及び[RFC2231]、[RFC2045]のために[RFC2046]を存在することに留意されたいです。
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.
この規格のセクション3で定義された全てのヘッダフィールドは「拡張メッセージヘッダフィールド」として考えられるべきである[RFC2047]、任意の<構造化されていない>ヘッダフィールド内に[RFC2047]エンコードの使用を可能にする、または第5の目的のために任意の<コメント>または<句>内の任意の構造化ヘッダフィールド内許可。
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]とContent-言語[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 )
フィールド= / *（承認/アーカイブ/管理/配信/有効期限が切れる/フォロー-へ/射出日付/射出情報/ライン/ニュースグループ/組織/パス/要約/が取って代わる/ユーザーエージェント/外部参照）
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).
この文書で定義された次のヘッダフィールド（すなわち、それらはFWSなくCFWSを使用）<コメント> Sを許可しません。
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.
これらのヘッダフィールドのほとんどは、主にニュースサーバへの関心のある、とのニュースサーバーは、多くの場合、非常に急速にこれらのフィールドを処理する必要があります。このように、いくつかのヘッダフィールドは、<コメント> 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.
この仕様に準拠し、各ネットニュースの記事は、厳密に1つの次のヘッダーフィールドのそれぞれのを持っている必要があります。日付、メッセージ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.
日付ヘッダーフィールドは、セクション2.2で上記に詳述追加制限が、セクション3.3と[RFC5322]の3.6.1に指定されたものと同じです。しかし、タイムゾーン（<OBS-ゾーン>の一部）として、「GMT」の使用は、非推奨ものの、ネットニュースの記事で、今日広く普及しています。そのため、エージェントは、「GMT」ゾーンを使用し、<日時>構文を受け入れなければなりません。
orig-date = "Date:" SP date-time CRLF
ORIG-日付= "日：" 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>.
注：この仕様は、エージェントが、<OBS-ゾーン>で定義された任意のゾーン名を含む<日時>の構造を生成してはならないことを言っている、[RFC5322]を変更しません。
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ヘッダフィールドは、セクション2.2で上記に詳述追加の制限が、[RFC5322]のセクション3.6.2で指定されたものと同じです。
from = "From:" SP mailbox-list CRLF
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ヘッダフィールドは、一意のメッセージ識別子を含みます。ネットニュースは、メッセージ識別子の一意性の詳細に依存しており、電子メールよりも高速な比較があり、そしていくつかのニュースのソフトウェアや規格[RFC3977]は、<MSG-ID>は、[RFC5322]で許可されてsの可能性の全範囲に問題がある可能性があります。このセクションでは、したがって、[RFC5322]のセクション3.6.4に比べて<MSG-ID>の構文を制限します。 [RFC5322]で<MSG-ID>のグローバル一意性の要件は、そのようなメッセージ識別子を使用して、すべてのプロトコルを横切って適用されると理解されるべきであり、そして両方の電子メールを横切って、特にネットニュース。
message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF
メッセージID = "メッセージID：" SP * WSP MSG-ID * WSP CRLF
msg-id = "<" msg-id-core ">" ; maximum length is 250 octets
MSG-ID = "<" MSG-ID-コア ">"。最大長は250オクテットであります
msg-id-core = id-left "@" id-right
MSG-ID-コア= ID-左ID-右の "@"
id-left = dot-atom-text
ID-左=ドット原子テキスト
id-right = dot-atom-text / no-fold-literal
ID-右=ドット原子テキスト/ノー倍リテラル
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 /。 US-ASCIIの残り％のd63-90 /; ％のd94-126を含まない文字。 ">"、 "["、 "]"、または "\"
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>は、<と>含む観察。
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一般に<ドメイン> S、<ID権> 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]の遵守との相互運用性を確保することです。オクテットの単純な比較は常に2つの<MSG-ID>の同一性を決定するために十分であろう。
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.
一部のソフトウェアは、大文字と小文字を区別しないやり方で、<ID-右> <MSG-ID>の一致するようにしようとします。一部では、大文字と小文字は区別の方法でそれと一致します。実装は、別のメッセージIDとの唯一の違いは、<ID右>部分における文字の場合であるメッセージIDを生成してはいけません。
When generating a <msg-id>, implementations SHOULD use a domain name as the <id-right>.
<MSG-ID>を生成する際に、実装は、<ID右>のようにドメイン名を使用すべきです。
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-右>である必要があり、ドメイン名またはドメインリテラルをお勧めします。ドメインリテラルは、多くの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
ニュースグループリスト= * WSPのニュースグループ名*（[FWS] "" [FWS]ニュースグループ名）* WSP
newsgroup-name = component *( "." component )
ニュースグループ名=成分*（「」のコンポーネント）
component = 1*component-char
成分= 1 *コンポーネントチャー
component-char = ALPHA / DIGIT / "+" / "-" / "_"
部品チャー= 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.
いないすべてのサーバーは、ニュースグループのリストに指定されているオプションFWSをサポートしています。具体的には、複数行にわたってニュースグループヘッダフィールドを折り畳む大幅伝播に悪影響を与えることが示されています。オプションFWSは<ニュースグループ・リスト>で生成されるべきではなく、受け入れなければなりません。
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.
<コンポーネント>は、単に数字で構成すべきではなく、大文字を含めることはできません。このような<コンポーネント> 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.
注：すべての桁の記事のための1つの広く使われているストレージ方式に<コンポーネント>の葛藤。混在ケース・グループは、<ニュースグループ名>の大文字と小文字を区別しないマッチングで大文字と小文字が区別マッチングとシステムとのシステム間で混乱を引き起こします。
<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.
<成分>は、（「_」）下線で始まるSはこの規格の将来のバージョンで使用するために予約されており、（[RFC5537]で定義されるようにヘッダーフィールドまたはnewgroup制御メッセージでも）ユーザエージェントによって生成されるべきではありません。しかし、そのような名前は、ニュースサーバで受け入れなければなりません。
<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.
<成分>「+」で、最初Sは「 - 」私的使用のために予約されており、そうするプライベート事前の合意なしにユーザエージェント（[RFC5537]ヘッダーフィールドまたはnewgroup制御メッセージであれ）によって生成されるべきではありません。しかし、そのような名前は、ニュースサーバで受け入れなければなりません。
The following <newsgroup-name>s are reserved and MUST NOT be used as the name of a newsgroup:
次の<ニュースグループ名> sが予約されており、ニュースグループの名前として使用してはいけません。
o Groups whose first (or only) <component> is "example"
Oグループその最初の（または唯一の）<成分>は「例」であります
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.
次の<ニュースグループ名> sが様々な実装とプロトコルに特定の目的のために使用されているので、通常のニュースグループの名前に使用してはいけません。彼らは、特定の目的のために、またはローカルの合意によって使用されるかもしれません。
o Groups whose first (or only) component is "to"
Oその最初の（または唯一の）コンポーネントグループは「」であります
o Groups whose first (or only) component is "control"
Oグループその最初の（または唯一の）コンポーネントが「コントロール」であります
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.
注：「例*」これと他の規格の例のために予約されています。 「ポスターは」で特別な意味フォロー-にフィールドをヘッダーを持っています。 「*する」[RFC5537]で定義されるように「IHAVE」制御メッセージに関連して特定のポイント・ツー・ポイント通信のために予約されています。 「コントロール*」と「ジャンク」は、いくつかのニュースサーバで特別な意味を持っています。 「全て」いくつかの実装形態では、ワイルドカードとして使用されます。そして「CTL」は、以前ニュースグループヘッダフィールド内の<制御コマンド>を示すために使用されました。
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ヘッダフィールドは、ネットニュースシステムへのその注射ため記事によって取られる経路を示しています。物品を処理する各エージェントは、このヘッダフィールド本体に少なくとも一つの<パスアイデンティティ>を前に付加する必要があります。ニュースサーバは特に、すでにそれらを持っていることが知られているサイトに記事を送信して、彼らがどこから来たのサイトを避けることができますように、これは主です。さらに、それは統計収集と記事がネットワーク上を移動中に取るルートを追跡が可能になります。
path = "Path:" SP *WSP path-list tail-entry *WSP CRLF
パス=「パス：」SP *のWSPパスリストの末尾のエントリ* WSP CRLF
path-list = *( path-identity [FWS] [path-diagnostic] "!" )
パスリスト= *（パス・アイデンティティ[FWS] [パス診断] "！"）
path-diagnostic = diag-match / diag-other / diag-deprecated
パス診断= DIAGマッチ/ダイアグその他/ダイアグ非推奨
diag-match = "!" ; another "!"
DIAG-一致= "！" ;別の「！」
diag-other = "!." diag-keyword [ "." diag-identity ] [FWS]
クリアotier = "！"。クリアkeivord [ ""クリアアイデンティティ] [FOS]
diag-deprecated = "!" IPv4address [FWS]
クリアdeprekated = "！" YPv4address [FOS]
diag-keyword = 1*ALPHA ; see [RFC5537]
DIAG-キーワード= 1 * ALPHA。 [RFC5537]を参照してください
diag-identity = path-identity / IPv4address / IPv6address
DIAG-アイデンティティ=パス-アイデンティティ/ IPv4Addressを/ IPv6address
tail-entry = path-nodot ; may be the string "not-for-mail"
テールエントリー=パスnodot。文字列かもしれない「 - のためのメール」
path-identity = ( 1*( label "." ) toplabel ) / path-nodot
パス・アイデンティティ=（1 *（ラベル ""）toplabel）/パスnodot
path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
経路nodot = 1 *（alphanum / " - " / "_"）。レガシー名
label = alphanum [ *( alphanum / "-" ) alphanum ]
ラベル= alphanum [*（alphanum / " - "）alphanum]
toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) / ( label *( "-" ) ALPHA [ *( "-" ) label ] ) / ( label 1*( "-" ) label )
toplabel =（[ラベル*（ " - "）] ALPHA *（ " - "）ラベル）/（ラベル*（ " - "）ALPHA [*（ " - "）ラベル]）/（ラベル1 *（ " - " ）ラベル）
alphanum = ALPHA / DIGIT ; compare [RFC3696]
alphanum = ALPHA / DIGIT。 [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>).
<パスアイデンティティ>は、サイトを特定する名前です。これは、ドットで区切られた2つの以上の成分を有する、ドメイン名の形態、あるいは全くドット（<パス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).
各<パス同一性> <パスリスト>（<テールエントリ>を含まない）で、右から左に、物品が通過した連続的な薬剤を示します。 「!!」と表示されます。<DIAG-試合>の使用は、その左にあるエージェントが、<パス区切り文字>のに対し、物品（受け入れる前に、その右にあるエージェントの身元を確認していることを示し、「！」を意味しますそのような請求がありません）。
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).
注：歴史的に、<尾-entry>は、送信者の名前を示しました。この目的のために使用されていない場合は（一度に全体のパスは送信者のメールアドレスとして使用できるので）、「ない-用メール」の文字列は、多くの場合、代わりに使用されます。
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 <パスアイデンティティ> 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].
<パス診断は>サイトの名前を示す以外の目的のためにパスヘッダフィールドに挿入された項目です。これらの使用は、[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.
注：<パス診断>の一つの使用は、IPアドレスを記録することです。 <IPv6address> ESが許可されているという事実は、コロン（:)許可されていることを意味します。 「：」<パス区切り文字>などと名前が4文字以下を持っている、そしてすべての文字が有効な16進数字です隣人を持っている、これはその点、古いサイトで相互運用性の問題を引き起こす可能性があることに注意。
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-非推奨>の形で、まだ許容ですが）、その継続的な使用が推奨されていません。
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].
件名ヘッダフィールドは、セクション2.2で上記に詳述追加の制限が、[RFC5322]のセクション3.6.5で指定されたものと同じです。件名ヘッダフィールドの内容のさらなる議論は、[RFC5537]に表示され、[USEAGE]。
subject = "Subject:" SP unstructured CRLF
件名= "件名：" 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.
ヘッダフィールドのコメント、キーワード、返信し、送信者は、同じ状況でネットニュースの記事に、セクション2.2で上記に詳述添加制限が[RFC5322]で指定されたものと同じ意味で使用されています。キーワードヘッダフィールドの複数の発生は許されません。
comments = "Comments:" SP unstructured CRLF
コメント= "コメント：" SP非構造化CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF reply-to = "Reply-To:" SP address-list CRLF
キーワード=「キーワード：」SPフレーズ*（「」フレーズ）CRLFの返信先= 『返信先：』 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ヘッダはRFC2183 [MIME-バージョン、コンテンツタイプ、コンテンツ転送エンコード、コンテンツの廃棄、およびContent-言語が同じ状況下で及び[RFC2045]で指定されたものと同じ意味を有するネットニュース記事で使用されるフィールド]、および[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].
承認されたヘッダフィールドには、投稿のための記事を承認する個人または団体の（おそらくとフルネーム）メーリングアドレスを示しています。その主な用途はモデレートの記事で、グループ制御メッセージです。 [RFC5537]を参照してください。
approved = "Approved:" SP mailbox-list CRLF
承認=「承認：」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 = "Archive:" SP [CFWS] ("no" / "yes") *( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF
アーカイブ= "アーカイブ：" SP [CFWS]（ "なし" / "はい"）*（[CFWS] ";" [CFWS]アーカイブのparam）[CFWS] CRLF
archive-param = parameter
アーカイブ-PARAM =パラメータ
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].
いいえ<パラメータ> 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 = "Control:" SP *WSP control-command *WSP CRLF
コントロール= "コントロール：" SP *のWSP制御コマンド* WSP CRLF
control-command = verb *( 1*WSP argument )
制御コマンド=動詞*（1 * WSP引数）
verb = token
動詞=トークン
argument = 1*( %x21-7E )
引数= 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.
Controlヘッダフィールドとの記事も取って代わるヘッダフィールドを持ってはいけません。
The Distribution header field specifies geographic or organizational limits on an article's propagation.
ディストリビューションヘッダフィールドは記事の伝播の地理的または組織的制限を指定します。
distribution = "Distribution:" SP dist-list CRLF
分布= "配布：" SPのdist-リストCRLF
dist-list = *WSP dist-name *( [FWS] "," [FWS] dist-name ) *WSP
DISTリスト= DIST * WSP名*（[ISI] "" [ISI] DIST名）* WSP
dist-name = ALPHA / DIGIT *( ALPHA / DIGIT / "+" / "-" / "_" )
dist-名= 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-名>の「世界」と「ローカル」が予約されています。 「世界は」無制限の分布を示し、分配ヘッダフィールドが完全に欠けているとき、それはデフォルトなので、明示的に使用されるべきではありません。ローカルソフトウェア構成によって定義されるような「ローカル」は、唯一のローカルサイトへの分布を示すために予約されています。
"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).
「すべて」<のdist-名>として使用してはいけません。 <のdist-name>のsが、彼らは[ISO3166-1]から引き出された2文字の国コードのときを除いて、3文字以上を含むべきです。 <のdist-name>はsが大文字と小文字を区別しない（すなわち、 "米国"、 "会社"、 "US"、および "私たち" はすべて同じ分布を指定します）。
Optional FWS in the <dist-list> SHOULD NOT be generated, but MUST be accepted.
オプションFWSは、<のdist-list>の中で生成されるべきではなく、受け入れなければなりません。
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").
有効期限ヘッダーフィールドは、ポスターがもはや適切でないために記事をと考えると、有効（「期限切れ」）除去することができ、日付と時刻を指定します。
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
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].
注：ザ・ヘッダフィールドはまた時々同様の意味を持つ電子メールで使用される有効期限。 [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 = "Followup-To:" SP ( newsgroup-list / poster-text ) CRLF
フォロー-へ= "フォロー-へ：" SP（ニュースグループリスト/ポスター - テキスト）CRLF
poster-text = *WSP %d112.111.115.116.101.114 *WSP ; "poster" in lowercase
ポスター - テキスト=％のd112.111.115.116.101.114 * * WSP WSP。小文字で「ポスター」
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項）ヘッダフィールドのものと同じです1フィールドは、そうでなければ、任意のニュースグループへの投稿ではなく、Fromヘッダフィールドに含まれるアドレス）を使用して、存在する場合。エージェントは小文字でキーワード「ポスター」を生成しなければならないが、そのような「ポスター」など、大文字と小文字を区別しないフォームを認識することを選択するかもしれません。
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）ヘッダフィールドのように、任意FWSは<ニュースグループリスト>で生成されるべきではなく、受け入れなければなりません。
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ヘッダーフィールドは記事がネットワークに注入された日付と時刻が含まれています。その目的は、噴射時間ではなく、メッセージ作成時にユーザエージェントによって追加1でニュースサーバーによって追加された<日時>を使用して、「古い」の記事をチェックするときに、ニュース・サーバを有効にすることです。
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.
物品が注入されるたびに、このヘッダフィールドが挿入されなければなりません。しかし、この標準に先行ソフトウェアは、このヘッダーを使用していないので、薬剤は、射出-Dateヘッダフィールドのない記事を受け入れなければなりません。
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.
注：種々の薬剤のクロックは必ずしも同期していないので、<日時>このヘッダフィールドには、日付ヘッダーフィールドよりも後の値ではないかもしれません。インジェクション-Dateヘッダフィールドを追加する際にエージェントは、既存のDateヘッダフィールドを変更してはなりません。
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.
インジェクション-Infoヘッダーフィールドは、記事がネットニュースのシステムに入る方法として注入するニュース・サーバによって提供された情報が含まれています。それは記事の本当の起源を追跡するのを助けます。また、物品のポスターに関する苦情を送信することができる1つ以上のアドレスを指定することができます。
injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF
射出情報= "インジェクション・情報：" SP [CFWS]パス・アイデンティティ[CFWS] *（ ";" [CFWS]パラメータ）[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]の折りたたみ規則と併せて<パラメータ>（[RFC2231]によって修正され、[RFC2045]のセクション5.1）の構文、（注：いない[RFC2822]または[RFC5322]）を、効果的に可能にします[CFWS]「=」<パラメータ>内部の両側に発生します。
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.
次の表は、このヘッダーフィールドで使用するために定義された各<パラメータ>のための<属性>と<値>の形式を与えます。せいぜい、それぞれのそのような<パラメータ>のいずれかの発生が許可されます。
<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 ))
ホスト値=ドット原子テキスト/ IPv4Addressを/ IPv6address /（ドット原子テキスト "："（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:
注：このような<ホスト値>または<アドレス・リストは>また、構文的に正しい<値>である必要がありますので、それは通常、例えば、<引用符で囲まれた文字列>としてそれをカプセル化する必要があります。
posting-host = "posting.example.com:192.0.2.1"
投稿-ホスト= "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-".
定義されない限り、他の<属性> Sは、この規格の拡張機能では使用しないでください。非標準ベースの<属性> 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>.
コメントと空白文字の折り畳みを注入-Infoヘッダーフィールド全体で許可されていますが、折り畳みがどの<パラメータ>内で使用されるべきではありません。折りたたみだけ前または後に行うべきです「;」 <パラメータ>の分離、およびコメントは、最後の<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-ポスティング - ホスト、X-トレース、X-苦情-に、などのような非標準ヘッダフィールドに送られました。ニュースサーバを射出Infoヘッダーフィールドを生成したら、それはこれらの非標準ヘッダフィールドを送信する必要はないはずです。
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.
「ポスト・ホスト」<パラメータ>は、完全修飾ドメイン名（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.
注：「ポスト・ホスト」<パラメータ>は確定的にホスト（例えば、動的なIPアドレスの割り当て）、「ポスト・アカウント」または「ログ・データ」を識別するために失敗した場合<パラメータ>は真の起源についての追加情報を提供することができます記事の。
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.
「ポスト・アカウント」<パラメータ>はそのニュースサーバーは、ニュース・サーバの管理者が解釈できる表記で、記事を受け、そこからソースを識別する。この表記は、管理者が適切と考える任意の情報を含めることができます。個人情報の露出を制限するためには、他のサイトが解釈することができない形で与えられるべきです。しかし、レート制限や虐待の検出のために、それは有用なものにするために、同じソースからの投稿の2つのメッセージが、「ポスト・アカウント」の同じ値を持つべきであり、異なるソースからの2つのメッセージが、「ポスト・アカウント」の異なる値を持つべきです。 「ソース」の正確な定義は、ニュース・サーバの管理者の裁量に任されています。
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.
「ログデータ」<パラメータ>はニュースサーバによって保持される情報をログを参照して決定されるべき物品の真の起源を可能にする情報（一般セッション番号または投稿アカウントを識別する他の非永続的手段）が含まれてい。
The "mail-complaints-to" <parameter> specifies one or more mailboxes for sending complaints concerning the behavior of the poster of the article.
「メールの苦情-に」<パラメータ>は、物品のポスターの振る舞いに関する苦情を送信するための1つまたは複数のメールボックスを指定します。
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].
これは、含まれるようにsを超える<パラメータ>のローカルポリシーの問題です。情報のいくつかの作品は、プライバシーの意味を持っています。これは、[USEAGE]で議論されています。
The Organization header field is a short phrase identifying the poster's organization.
組織のヘッダフィールドは、ポスターの組織を特定する短いフレーズです。
organization = "Organization:" SP unstructured CRLF
組織= "組織：" 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:
参照フィールドは、セクション2.2で上記に詳述追加制限が、[RFC5322]のセクション3.6.4で指定されたものと同じであり、それらを以下に示す：ヘッダ
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メッセージ識別子はCFWSで分離しなければなりません。
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
参考文献= "参照：" 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
要約= "要約：" 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
取って代わる= "取って代わる：" SP * WSP MSG-ID * CRLF WSP
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 = "User-Agent:" SP 1*product [CFWS] CRLF
ユーザーエージェント= "ユーザーエージェント：" SP 1 *製品[CFWS] CRLF
product = [CFWS] token [ [CFWS] "/" product-version ]
生成物= [CFWS]トークン[CFWS] "/" 製品バージョン]
product-version = [CFWS] token
製品バージョン= [CFWS]トークン
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.
このヘッダーフィールドは、複数の<製品>を含むかもしれユーザエージェントとアプリケーションを識別するためのそれらの重要性の順に列挙されたそれの重要な部分を形成する任意のサブプロダクトを識別するトークン。
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-ニュースキャスター、X-Mailerの、X-ポスティングエージェント、X-HTTP-のUser-Agent、および他のような非標準ヘッダフィールドに送られました。ユーザーエージェントは、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プロトコルのための同様の機能を説明します。ネットニュースの記事の形式は、「{」および「}」トークンで許可さが異なる（<製品>と<製品バージョン>）ホワイトスペースが許可されている場所とコメントが許可されています。
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 = "Xref:" SP *WSP server-name 1*( FWS location ) *WSP CRLF
外部参照= "外部参照：" SP * WSPサーバ名1 *（FWSの場所）* WSP CRLF
server-name = path-identity
サーバ名=パスアイデンティティ
location = newsgroup-name ":" article-locator
場所=ニュースグループ名「：」記事ロケータ
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) ; US-ASCII printable characters ; except '(' and ';'
物品ロケータ= 1 *（％x21-27 /％x29-3A /％X3C-7E）。 US-ASCII印刷可能な文字。 「（」を除くと「;」
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.
そのソフトウェアは、ヘッダフィールドを生成したニュースサーバーを判別できるようにし、<サーバ名>が含まれています。ここで、これらのニュースグループの下のニュースグループは、（ニュースグループヘッダフィールドと異なる可能性がある）、すなわち、その下で、及び - 位置は、物品が提出されている場所を指定します。 <物品ロケータ>の正確な形式は、実装固有です。
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.
注：<物品ロケータ>の伝統的な形態は、（[RFC3977]によって必要とされる）1から始まる通し番号各ニュースグループの資料で、10進数です。
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]と同様に、また、コントロール、記事名、記事、アップデートで定義されたリレー・バージョン、および参照-また、[息子-の-1036]で定義されています時代遅れと宣言。元の使用の詳細については、引用した仕様書を参照してください。
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.
行は、フィールドは、物品の（[RFC5322]で定義されるように）<BODY>の行数を示すヘッダ。
lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF
ライン= "行：" WSP * SP * 1 * DIGIT CRLF WSP
The line count is the number of CRLF separators in the <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.
ネットニュース記事のヘッダフィールドと本体の国際化は、セクション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.
この文書で指定されたネットニュースの記事・フォーマットは、機密性、送信者の認証、または否認防止など任意のセキュリティサービスを、提供していません。代わりに、このようなサービスは、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 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.
ネットニュースの記事でメッセージ識別子（3.1.3）は一意であることが要求されています。識別子がすでに見てきた場合には、記事（サーバー間の転送で）拒否されることがあります。悪意のある剤が物品の識別子を予測することができれば、それによって伝播対象物品を防止する、同じメッセージ識別子（おそらくは全く異なるグループに）それ自身の記事を投稿することによって、物品を先取りすることができます。そのため、ネットニュースの記事のためのメッセージ識別子を生成する物質は、彼らが予測不可能であることを確認する必要があります。
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:
MIMEセキュリティの考慮事項は、[RFC2046]で議論されています。 [RFC2046]のパラメータと[RFC2231]を許可するための許可エンコーディングの完全な範囲は、単純なパーサーを正しく構文解析に失敗することが構築ことに留意されたいです。ハード・ツー・パース構築物の例は以下のとおりです。
Content-Type: multipart/mixed (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
コンテンツタイプ：混合/マルチパート（;境界= FOO; XYZ = "）;境界* = '' 次％の20part（"）
Content-Type: multipart/digest; boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
コンテンツタイプ：マルチパート/ダイジェスト。境界（ない=私）=（ "はい;-)シンプル（FOO;バー"）; 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)
ヘッダフィールド名：また、コントロール適用可能プロトコル：廃止作者/変化コントローラ：ステータスをネットニュースIETF仕様書（S）：[息子の-1036]（セクション6.15）
Header field name: Approved Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.1)
ヘッダフィールド名：承認適用プロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：この文書（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)
ヘッダフィールド名：アーカイブ該当するプロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：この文書（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)
ヘッダフィールド名：記事-名前適用プロトコルは：廃止著者/変更コントローラ：ステータスをネットニュースIETF仕様書（S）：[息子-の-1036]（セクション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)
ヘッダフィールド名：記事-アップデート適用プロトコルは：廃止著者/変更コントローラ：ステータスをネットニュースIETF仕様書（S）：[息子-の-1036]（セクション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仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：該当プロトコルを制御：ネットニュースステータス：標準著者/変更コントローラ：IETF仕様書（S）：この文書（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仕様書（S）：この文書（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)
ヘッダフィールド名：日付-受信適用プロトコルは：廃止著者/変更コントローラ：ステータスをネットニュースIETF仕様書（S）：[RFC0850]（セクション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)
ヘッダフィールド名：配布適用プロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：該当プロトコルを有効期限：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：フォロー-に適用されるプロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：この文書（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仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：インジェクション-日適用プロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：インジェクション・インフォメーション適用プロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：このドキュメント（セクション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仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：行適用プロトコル：非推奨作者/変化コントローラ：ステータスをネットニュースIETF仕様書（S）：この文書（3.3.1）関連情報：[RFC3977]（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)
ヘッダフィールド名：メッセージID適用プロトコール：標準作者/変化コントローラ：IETF仕様書（S）：この文書（3.1.3）関連情報：[RFC5322]（セクション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)
ヘッダフィールド名：ニュースグループ適用プロトコル：ネットニュースステータス：標準著者/変更コントローラ：IETF仕様書（S）：この文書（3.1.4）
Header field name: NNTP-Posting-Date Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): none
ヘッダフィールド名：NNTP-ポスティング-日適用プロトコル：ネットニュースステータス：廃止著者/変更コントローラ：IETF仕様書（S）：なし
Header field name: NNTP-Posting-Host Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [RFC2980] (Section 3.4.1)
ヘッダフィールド名：NNTP-ポスティング - ホスト適用プロトコルは：廃止著者/変更コントローラ：ステータスをネットニュースIETF仕様書（S）：[RFC2980]（セクション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)
ヘッダフィールド名：組織適合プロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：パス適用プロトコール：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：この文書（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)
ヘッダフィールド名：投稿-バージョン適用プロトコル：廃止著者/変更コントローラ：ステータスネットニュースIETF仕様書（S）：[RFC0850]（セクション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仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：リレー版適用プロトコルは：廃止作者/変化コントローラ：ステータスをネットニュースIETF仕様書（S）：[RFC0850]（セクション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仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：参照してください-も適用プロトコルは：廃止著者/変更コントローラ：ステータスをネットニュースIETF仕様書（S）：[息子-の-1036]（セクション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仕様書（S）：このドキュメント（セクション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仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：概要該当プロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：該当プロトコルに取って代わる：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：このドキュメント（セクション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)
ヘッダフィールド名：のUser-Agent適用プロトコル：ネットニュースステータス：標準著者/変更コントローラ：IETF仕様書（S）：このドキュメント（セクション3.2.13）関連情報：[RFC2616]（セクション14.43）
Header field name: Xref Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.14)
ヘッダフィールド名：外部参照適用プロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（S）：このドキュメント（セクション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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ドルナー、S.、およびK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、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]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年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]バーナーズ - リー、T.、フィールディング、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]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and Protocols", RFC 5537, November 2009.
[RFC5537] Allbery、R.、エド。そして、C.リンジー、 "ネットニュースのアーキテクチャとプロトコル"、RFC 5537、2009年11月。
[Errata] "RFC Editor Errata", <http://www.rfc-editor.org/errata.php>.
[正誤表] "RFC Editorの正誤表"、<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]ローレンス、D.、<ftp://ftp.isc.org/pub/pgpcontrol/README.html>、1999年6月、 "ユーズネットグループの変更（pgpverify）の認証"。
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC0822]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[RFC0850] Horton, M., "Standard for interchange of USENET messages", RFC 850, June 1983.
"USENETメッセージの交換のための標準的な" [RFC0850]ホートン、M.、RFC 850、1983年6月。
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
、RFC 1036、1987年12月 "USENETメッセージの交換のための標準的な" [RFC1036]ホートン、M.およびR.アダムス。
[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.、 "MIXER（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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[RFC2980]バーバー、S.、 "共通NNTP拡張機能"、RFC 2980、2000年10月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156]エルキンズ、M.、デルTorto、D.、Levien、R.、およびT.レスラー、 "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 3696、2004年2月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、ノッティンガム、M.、およびJ.モーグル、BCP 90、RFC 3864、2004年9月 "メッセージヘッダフィールドの登録手順"。
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[RFC3977]フェザー、C.、 "ネットワークニュース転送プロトコル（NNTP）"、RFC 3977、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]リンジー、C.、 "Usenetのベストプラクティス"、進歩、2005年3月に作業。
Appendix A. Acknowledgments
付録A.謝辞
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.
このドキュメントは、8年間の努力の結果であるとして、そのコンテンツに貢献した人の数は、個別に枚挙にいとまがないです。多くのおかげでは、IETF（Internet Engineering Task Force）とそれに付随するメーリングリストのUSEFORワーキンググループの過去と現在のメンバーに出かけます。
Appendix B. Differences from and Its Derivatives
付録Bとの違いとその誘導体
This appendix contains a list of changes that have been made in the Netnews article format from earlier standards, specifically [RFC1036].
この付録では、以前の標準からネットニュースの記事形式で行われた変更は、具体的に[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]から継承されました。彼らは、しかし、依然として制御、配布、フォロー-TO、ライン、メッセージID、ニュースグループ、パス、優先し、および外部参照ヘッダフィールドにおける性能および/または互換性の理由で禁止されています。
o Multiple addresses are allowed in the From header field.
O複数のアドレスは、Fromヘッダフィールドで許可されています。
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パスヘッダフィールドの拡張構文は、注入点を可能にし、物品、によって撮影されたルートは、より精度で決定します。
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古い記事の拒絶がより正確にすると偽の拒否を最小限にするために、新しいインジェクション-Dateヘッダフィールドがあります。
o There are several new optional header fields defined, notably Archive, Injection-Info, and User-Agent, leading to increased functionality.
O定義されたいくつかの新しいオプションのヘッダーフィールド、特にアーカイブ、射出情報、およびUser-Agentは、機能性の向上につながる、があります。
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他の多数の小さな変更、明確化、および機能拡張があります。
Appendix C. Differences from
から付録C.違い
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].
この付録では、[RFC5322]で指定されるように、インターネットメッセージ形式に比べて、ネットニュースの記事・フォーマット（本書）で許可された構文の違いを示しています。
The Netnews article format is a strict subset of the Internet Message Format; all Netnews articles conform to the syntax of [RFC5322].
ネットニュースの記事のフォーマットは、インターネットメッセージ形式の厳密なサブセットです。すべてのネットニュースの記事は[RFC5322]の構文に準拠しています。
The following restrictions are important:
以下の制限が重要です。
o A SP (space) is REQUIRED after the colon (':') following a header field name.
ヘッダフィールド名以下：SP（空間）O（「」）コロンの後に必要とされます。
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.
<MSG-ID>の長oを250個のオクテットを超えてはなりません。
o Comments are not allowed in the Message-ID header field.
Oコメントは、Message-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>.
*廃止された<ゾーン>「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フォーブス・アベニューCyertホール285ピッツバーグ、PA 15213 U.S.A.
Phone: +1 412 268 2638 EMail: murch@andrew.cmu.edu
電話：+1 412 268 2638 Eメール：murch@andrew.cmu.edu
Charles H. Lindsey University of Manchester 5 Clerewood Avenue Heald Green Cheadle Cheshire SK8 3JU U.K.
マンチェスター5 ClerewoodアベニューヒールドグリーンチードルチェシャーSK8 3JU U.K.のチャールズ・H・リンジー大学
Phone: +44 161 436 6131 EMail: chl@clerew.man.ac.uk
電話：+44 161 436 6131 Eメール：chl@clerew.man.ac.uk
Dan Kohn Healing Thresholds 211 N End Ave Apt 22E New York, NY 10282 U.S.A.
ダンコーンヒーリングしきい値211 Nエンドアベニューアプト22Eニューヨーク、NY 10282 U.S.A.
Phone: +1 415 233 1000 EMail: dan@dankohn.com
電話：+1 415 233 1000 Eメール：dan@dankohn.com