[要約] RFC 5536はNetnews記事のフォーマットに関する仕様であり、要約と目的は以下の通りです： 1. Netnews記事の構造と要素を定義する。 2. 記事のヘッダー、本文、署名などの要素を明確にする。 3. Netnewsクライアントやサーバーの開発者に対して、統一された記事フォーマットを提供する。
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
NetNewsの記事形式
Abstract
概要
This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents.
このドキュメントは、インターネットメッセージ形式（RFC 5322）と多目的インターネットメールエクステンション（MIME）（RFC 2045）のコンテキストでNetNewsの記事の構文を指定します。このドキュメントは、RFC 1036を廃止し、現在の慣行を反映し、他のドキュメントで指定された増分変更を組み込むための更新された仕様を提供します。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
「NetNews」は、ニュース「記事」（その形式は電子メールメッセージのサブセットである）を生成、保存、および取得するためのプロトコルのセットであり、潜在的に広く配布される読者の間でそれらを交換するためのプロトコルです。「ニュースグループ」を中心に編成されており、各読者が彼が参加している各ニュースグループに投稿されたすべての記事を見ることができると期待しています。これらのプロトコルは、最も一般的に洪水アルゴリズムを使用しており、参加サーバーのネットワーク全体にコピーを伝播します。通常、サーバーごとに1つのコピーのみが保存され、各サーバーにより、そのサーバーにアクセスできる読者が利用できるようにします。
This document specifies the syntax of Netnews articles in the context of the Internet Message Format [RFC5322] and Multipurpose Internet Mail Extensions (MIME) [RFC2045]. This document obsoletes [RFC1036], updating the syntax of Netnews articles to reflect current practice and incorporating changes and clarifications specified in other documents such as [Son-of-1036].
このドキュメントは、インターネットメッセージ形式[RFC5322]と多目的インターネットメールエクステンション（MIME）[RFC2045]のコンテキストでNetNewsの記事の構文を指定します。このドキュメントは廃止され[RFC1036]、NetNewsの記事の構文を更新して、現在の慣行を反映し、[son-of-1036]などの他の文書に指定された変更と明確化を組み込みます。
This is the first in a set of documents that obsolete [RFC1036]. This document focuses on the syntax and semantics of Netnews articles. [RFC5537] is also a Standards Track document and describes the protocol issues of Netnews articles, independent of transport protocols such as the Network News Transfer Protocol (NNTP) [RFC3977]. [USEAGE], "Usenet Best Practice", describes implementation recommendations to improve interoperability and usability.
これは、廃止された一連のドキュメントの最初のものです[RFC1036]。このドキュメントは、NetNewsの記事の構文とセマンティクスに焦点を当てています。[RFC5537]は標準の追跡文書でもあり、ネットワークニュース転送プロトコル（NNTP）[RFC3977]などの輸送プロトコルとは無関係に、NetNewsの記事のプロトコルの問題を説明しています。[useage]、「usenetベストプラクティス」は、相互運用性と使いやすさを改善するための実装の推奨事項について説明しています。
This specification is intended as a definition of what article content format is to be passed between systems. Although many news systems locally store articles in this format (which eliminates the need for translation between formats), local storage is outside of the scope of this standard.
この仕様は、システム間で渡される記事のコンテンツ形式の定義として意図されています。多くのニュースシステムは、この形式で記事をローカルに保存しますが（フォーマット間の翻訳の必要性を排除します）、ローカルストレージはこの標準の範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Header fields defined in this specification use the Augmented Backus-Naur Form (ABNF) notation (including the Core Rules) specified in [RFC5234] as well as many constructs defined in [RFC5322], [RFC2045] as updated by [RFC2231], and [RFC3986]. Specifically:
この仕様で定義されたヘッダーフィールドは、[RFC5234]で指定された拡張バックスノーフォーム（ABNF）表記（コアルールを含む）と[RFC5322]、[RFC2045]で定義された多くのコンストラクトを使用し、[RFC2231]、および[RFC2231]、および[RFC2045]、および[RFC2045]、および[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>
FWS = <see RFC 5322 Section 3.2.2>
comment = <see RFC 5322 Section 3.2.2>
CFWS = <see RFC 5322 Section 3.2.2>
atext = <see RFC 5322 Section 3.2.3>
dot-atom-text = <see RFC 5322 Section 3.2.3>
phrase = <see RFC 5322 Section 3.2.5>
date-time = <see RFC 5322 Section 3.3>
mailbox = <see RFC 5322 Section 3.4>
mailbox-list = <see RFC 5322 Section 3.4>
address-list = <see RFC 5322 Section 3.4>
body = <see RFC 5322 Section 3.5>
fields = <see RFC 5322 Section 3.6>
IPv6address = <see RFC 3986 Section 3.2.2>
IPv4address = <see RFC 3986 Section 3.2.2>
ALPHA = <see RFC 5234 Appendix B.1>
CRLF = <see RFC 5234 Appendix B.1>
DIGIT = <see RFC 5234 Appendix B.1>
DQUOTE = <see RFC 5234 Appendix B.1>
SP = <see RFC 5234 Appendix B.1>
VCHAR = <see RFC 5234 Appendix B.1>
Additionally, Section 3.1.3 specifies a stricter definition of <msg-id> than the syntax in Section 3.6.4 of [RFC5322].
さらに、セクション3.1.3は、[RFC5322]のセクション3.6.4の構文よりも<MSG-ID>のより厳格な定義を指定します。
An "article" is the unit of Netnews, analogous to an [RFC5322] "message". A "proto-article" is one that has not yet been injected into the news system. In contrast to an article, a proto-article may lack some mandatory header fields.
「記事」は、[RFC5322]「メッセージ」に類似したNetNewsの単位です。「プロトアーティクル」とは、ニュースシステムにまだ注入されていないものです。記事とは対照的に、プロトアーティクルにはいくつかの必須のヘッダーフィールドがない場合があります。
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.
「NewsGroup」は名前を持つフォーラムであり、特定のトピックに関する記事を目的としています。記事は、単一のニュースグループまたはいくつかのニュースグループに「投稿」されます。記事が複数のニュースグループに投稿されると、「クロスポスト」と言われています。これは、いくつかの記事の一部、1つのニュースグループの一部と同じテキストを投稿することとは異なることに注意してください。
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.
「読者」とは、NetNewsの記事を読んでいる人またはソフトウェアです。
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.
「ユーザーエージェント」は、ポスターがニュースサーバーにProto-Articlesを提出したり、ニュースサーバーから記事を取得したり、読者に提示したり、読者が記事やフォローアップを作成するのを支援するのに役立つソフトウェアです。
The generic term "agent" is used when describing requirements that apply to both user agents and news servers.
一般的な用語「エージェント」は、ユーザーエージェントとニュースサーバーの両方に適用される要件を記述するときに使用されます。
An agent is said to "generate" a construct if it did not exist before the agent created it. Examples are when a user agent creates a message from text and addressing information supplied by a user, or when a news server creates an "Injection-Info" header field for a newly posted message.
エージェントは、エージェントが作成する前に存在しなかった場合、コンストラクトを「生成」すると言われています。例は、ユーザーエージェントがテキストからメッセージを作成し、ユーザーが提供する情報をアドレス指定するとき、またはニュースサーバーが新しく投稿されたメッセージの「インジェクションインフォ」ヘッダーフィールドを作成するときです。
An agent is said to "accept" a construct if some other entity generates it and passes it to the agent in question, and the agent processes it without treating it as a format or protocol error.
エージェントは、他のエンティティがそれを生成し、問題のエージェントに渡す場合、コンストラクトを「受け入れる」と言われ、エージェントはそれをフォーマットまたはプロトコルエラーとして扱うことなく処理します。
This document uses a cite-by-reference methodology, rather than repeating the contents of other standards, which could otherwise result in subtle differences and interoperability challenges. Although this document is as a result rather short, it requires complete understanding and implementation of the normative references to be compliant.
このドキュメントでは、他の標準の内容を繰り返すのではなく、引用ごとの方法論を使用します。そうでなければ、微妙な違いや相互運用性の課題をもたらす可能性があります。このドキュメントは結果としてかなり短いですが、規範的参照の完全な理解と実装が準拠する必要があります。
Section 2 defines the format of Netnews articles. Section 3 details the header fields necessary to make an article suitable for the Netnews environment.
セクション2では、NetNewsの記事の形式を定義します。セクション3では、NetNews環境に適した記事を作成するために必要なヘッダーフィールドについて詳しく説明しています。
An article is said to be conformant to this specification if it conforms to the format specified in Section 3 of [RFC5322] and to the additional requirements of this specification.
記事は、[RFC5322]のセクション3で指定された形式と、この仕様の追加要件に準拠している場合、この仕様に適合していると言われています。
An article that uses the obsolete syntax specified in Section 4 of [RFC5322] is NOT conformant to this specification, except for the following two cases:
[RFC5322]のセクション4で指定された時代遅れの構文を使用する記事は、次の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-phrase> construct（引用符を使用せずに「John Q. public」などのフレーズの使用を使用している場合に適合しますが、[RFC5322]のセクション4.1を参照）が、エージェントはそのような構文の生成を生成してはなりません。
o Articles are conformant if they use the "GMT" <zone>, as specified in Section 3.1.1.
o セクション3.1.1で指定されているように、記事は「GMT」<Zone>を使用する場合に適合します。
This document, and specifications that build upon it, specify how to handle conformant articles. Handling of non-conformant articles is outside the scope of this specification.
このドキュメントとそれに基づいて構築される仕様は、コンフォーマント記事の処理方法を指定します。不適合物品の取り扱いは、この仕様の範囲外です。
Agents conforming to this specification MUST generate only conformant articles.
この仕様に準拠しているエージェントは、コンフォーマント記事のみを生成する必要があります。
The text below uses ABNF to specify restrictions on the syntax specified in [RFC5322]; this grammar is intended to be more restrictive than the [RFC5322] grammar. Articles must conform to the ABNF 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]で指定された構文の制限を指定します。この文法は、[RFC5322]文法よりも制限的であることを目的としています。記事は、[RFC5322]で指定されているABNFに準拠する必要があります。また、ここで指定された制限、テキストとして表現されるものとABNFとして表されるものの両方に適合する必要があります。
NOTE: Other specifications use the term "header" as a synonym for what [RFC5322] calls "header field". This document follows the terminology in Section 2 of [RFC5322] in using the terms "line", "header field", "header field name", "header field body", and "folding", based on a belief that consistent terminology among specifications that depend on each other makes the specifications easier to use in the long run.
注：他の仕様は、[RFC5322]が「ヘッダーフィールド」と呼ぶものの同義語として「ヘッダー」という用語を使用します。このドキュメントは、[RFC5322]のセクション2の用語に従って、「線」、「ヘッダーフィールド」、「ヘッダーフィールド名」、「ヘッダーフィールドボディ」、「折り畳み」という用語を使用します。互いに依存する仕様により、仕様は長期的に使用しやすくなります。
All header fields in a Netnews article are compliant with [RFC5322]; this specification, however, is less permissive in what can be generated and accepted by agents. The syntax allowed for Netnews article headers is a strict subset of the Internet Message Format headers, making all headers compliant with this specification inherently compliant with [RFC5322]. Note however that the converse is not guaranteed to be true in all cases.
NetNewsの記事のすべてのヘッダーフィールドは、[RFC5322]に準拠しています。ただし、この仕様は、エージェントが生成および受け入れることができるものでは寛容ではありません。NetNewsの記事ヘッダーに許可されている構文は、インターネットメッセージ形式のヘッダーの厳格なサブセットであり、この仕様に本質的に[RFC5322]に準拠しているすべてのヘッダーが準拠しています。ただし、逆はすべての場合に当てはまることが保証されていないことに注意してください。
General rules that apply to all header fields (even those documented in [RFC5322] and [RFC2045]) are listed below, and those that apply to specific header fields are described in the relevant sections of this document.
すべてのヘッダーフィールドに適用される一般的なルール（[RFC5322]および[RFC2045]に文書化されたものでも）を以下にリストし、特定のヘッダーフィールドに適用されるルールについては、このドキュメントの関連セクションで説明します。
o All agents MUST generate header fields so that at least one space immediately follows the ':' separating the header field name and the header field body (for compatibility with deployed software, including NNTP [RFC3977] servers). News agents MAY accept header fields that do not contain the required space.
o すべてのエージェントは、ヘッダーフィールドを生成する必要があります。これにより、少なくとも1つのスペースが '：'： 'ヘッダーフィールド名とヘッダーフィールドボディを分離する必要があります（NNTP [RFC3977]サーバーを含む展開ソフトウェアとの互換性）。ニュースエージェントは、必要なスペースを含まないヘッダーフィールドを受け入れる場合があります。
o Every line of a header field body (including the first and any that are subsequently folded) MUST contain at least one non-whitespace character.
o ヘッダーフィールドボディのすべてのライン（最初のものを含むもの、およびその後折り畳まれたもの）には、少なくとも1つの非白文字文字が含まれている必要があります。
NOTE: This means that no header field body defined by or referenced by this document can be empty. As a result, rather than using the <unstructured> syntax from Section 3.2.5 of [RFC5322], this document uses a stricter definition:
注：これは、このドキュメントによって定義されている、または参照されるヘッダーフィールド本体が空になる可能性がないことを意味します。その結果、[RFC5322]のセクション3.2.5の<非構造化>構文を使用するのではなく、このドキュメントはより厳しい定義を使用します。
unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSP
NOTE: The [RFC5322] specification sometimes uses [FWS] at the beginning or end of ABNF describing header field content. This specification uses *WSP in such cases, also in cases where this specification redefines constructs from [RFC5322]. This is 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.
注：[RFC5322]仕様は、ヘッダーフィールドコンテンツを説明するABNFの開始または終了時に[FWS]を使用する場合があります。この仕様では、この仕様が[RFC5322]から構成要素を再定義する場合にも、 *WSPを使用します。これは、ここで説明する制限と一貫性があるために行われますが、このドキュメントでABNFが定義されている場所だけでなく、すべてのヘッダーフィールドに制限が適用されます。
o Compliant software MUST NOT generate (but MAY accept) header field lines of more than 998 octets. This is the only limit on the length of a header field line prescribed by this standard. However, specific rules to the contrary may apply in particular cases (for example, according to [RFC2047], lines of a header field containing encoded words are limited to 76 octets). [USEAGE] includes suggested limits for convenience of display by user agents.
o 準拠したソフトウェアは、998を超えるオクテットのヘッダーフィールドラインを生成（ただし受け入れる可能性があります）であってはなりません。これは、この標準で規定されているヘッダーフィールドラインの長さの唯一の制限です。ただし、反対の特定のルールは、特定の場合に適用される場合があります（たとえば、[RFC2047]によると、エンコードされた単語を含むヘッダーフィールドの線は76オクテットに制限されています）。[使用]は、ユーザーエージェントによるディスプレイの利便性のための提案された制限が含まれています。
NOTE: As stated in [RFC5322], there is NO restriction on the number of lines into which a header field may be split, and hence there is NO restriction on the total length of a header field (in particular it may, by suitable folding, be made to exceed the 998-octet restriction pertaining to a single header field line).
注：[RFC5322]に記載されているように、ヘッダーフィールドが分割される可能性のある線の数に制限はないため、ヘッダーフィールドの全長に制限はありません（特に、適切な折り畳みによって、、単一のヘッダーフィールドラインに関連する998-OCTET制限を超えるようにします）。
o The character set for header fields is US-ASCII. Where the use of non-ASCII characters is required, they MUST be encoded using the MIME mechanisms defined in [RFC2047] and [RFC2231].
o ヘッダーフィールドのキャラクターセットはUS-ASCIIです。非ASCII文字の使用が必要な場合、[RFC2047]および[RFC2231]で定義されたMIMEメカニズムを使用してエンコードする必要があります。
User agents MUST meet the definition of MIME conformance in [RFC2049] and MUST also support [RFC2231]. This level of MIME conformance provides support for internationalization and multimedia in message bodies [RFC2045], [RFC2046], and [RFC2231], and support for internationalization of header fields [RFC2047] and [RFC2231]. Note that [Errata] currently exist for [RFC2045], [RFC2046], [RFC2047] and [RFC2231].
ユーザーエージェントは、[RFC2049]のMIME適合性の定義を満たす必要があり、[RFC2231]もサポートする必要があります。このレベルのMIME適合性は、メッセージボディ[RFC2045]、[RFC2046]、および[RFC2231]の国際化とマルチメディアのサポートを提供し、ヘッダーフィールド[RFC2047]および[RFC2231]の国際化のサポートを提供します。[RFC2045]、[RFC2046]、[RFC2047]、[RFC2231]には現在[errata]が存在することに注意してください。
For the purposes of Section 5 of [RFC2047], all header fields defined in Section 3 of this standard are to be considered as "extension message header fields", permitting the use of [RFC2047] encodings within any <unstructured> header field, or within any <comment> or <phrase> permitted within any structured header field.
[RFC2047]のセクション5の目的のために、この標準のセクション3で定義されているすべてのヘッダーフィールドは、「拡張メッセージヘッダーフィールド」と見なされ、[RFC2047]エンコーディングが任意の<非構造化>ヘッダーフィールド、または使用を許可します。構造化されたヘッダーフィールド内で許可されている<コメント>または<フレーズ>内で。
User agents MAY accept and generate other MIME extension header fields, and in particular SHOULD accept Content-Disposition [RFC2183] and Content-Language [RFC3282].
ユーザーエージェントは、他のMIMEエクステンションヘッダーフィールドを受け入れて生成する場合があり、特にコンテンツ拡張[RFC2183]およびコンテンツ言語[RFC3282]を受け入れる必要があります。
The following news header fields extend those defined in Section 3.6
of [RFC5322]:
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.
これらのヘッダーフィールドのそれぞれは、ニュース記事で1回以上発生してはなりません。
The following header fields defined in this document do not allow <comment>s (i.e., they use FWS rather than CFWS).
このドキュメントで定義されている次のヘッダーフィールドは、<コメント>を許可しません（つまり、CFWではなくFWSを使用します）。
Control Distribution Followup-To Lines Newsgroups Path Supersedes Xref
コントロールディストリビューションフォローアップトゥラインニュースグループパスはXrefに取って代わります
This also applies to the following header field defined in [RFC5322]:
これは、[RFC5322]で定義されている次のヘッダーフィールドにも適用されます。
Message-ID
メッセージ-ID
Most of these header fields are mainly of interest to news servers, and news servers often need to process these fields very rapidly. Thus, some header fields prohibit <comment>s.
これらのヘッダーフィールドのほとんどは主にニュースサーバーにとって興味深いものであり、ニュースサーバーはしばしばこれらのフィールドを非常に迅速に処理する必要があります。したがって、一部のヘッダーフィールドは<comment>を禁止しています。
Each Netnews article conformant with this specification MUST have exactly one of each of the following header fields: Date, From, Message-ID, Newsgroups, Path, and Subject.
この仕様に準拠した各NetNewsの記事には、次のヘッダーフィールドのそれぞれの1つが必要です。
The Date header field is the same as that specified in Sections 3.3 and 3.6.1 of [RFC5322], with the added restrictions detailed above in Section 2.2. However, the use of "GMT" as a time zone (part of <obs-zone>), although deprecated, is widespread in Netnews articles today. Therefore, agents MUST accept <date-time> constructs that use the "GMT" zone.
日付ヘッダーフィールドは、[RFC5322]のセクション3.3および3.6.1で指定されているものと同じであり、上記のセクション2.2で詳細な制限が追加されています。ただし、タイムゾーンとしての「GMT」の使用（<Abs-Zone>の一部）は、非推奨ですが、今日のNetNewsの記事で広まっています。したがって、エージェントは「GMT」ゾーンを使用する<date-Time>コンストラクトを受け入れる必要があります。
orig-date = "Date:" SP date-time CRLF
Orig-date = "date：" sp date-time crlf
NOTE: This specification does not change [RFC5322], which says that agents MUST NOT generate <date-time> constructs that include any zone names defined by <obs-zone>.
注：この仕様は[RFC5322]を変更せず、エージェントは<date-zone>で定義されたゾーン名を含む<date-time>コンストラクトを生成してはならないと述べています。
Software that accepts dates with unknown timezones SHOULD treat such timezones as equivalent to "-0000" when comparing dates, as specified in Section 4.3 of [RFC5322].
未知のタイムゾーンを使用して日付を受け入れるソフトウェアは、[RFC5322]のセクション4.3で指定されているように、日付を比較するときに「-0000」に相当するようなタイムゾーンを扱う必要があります。
Also note that these requirements apply wherever <date-time> is used, including Injection-Date and Expires (Sections 3.2.7 and 3.2.5, respectively).
また、これらの要件は、注射日と有効期限を含む<date-Time>を使用する場所に適用されることに注意してください（それぞれセクション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 Headerフィールドは、[RFC5322]のセクション3.6.2で指定されているものと同じであり、上記のセクション2.2で追加された制限が追加されています。
from = "From:" SP mailbox-list CRLF
from = "from：" sp mailbox-list 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.
Message-IDヘッダーフィールドには、一意のメッセージ識別子が含まれています。NetNewsは、メッセージ識別子の一意性と電子メールよりも高速な比較に依存しており、一部のニュースソフトウェアと標準[RFC3977]は、[RFC5322]で許可される可能性のある<MSG-ID>の全範囲に問題がある可能性があります。したがって、このセクションでは、[RFC5322]のセクション3.6.4と比較して、<MSG-ID>の構文を制限します。[RFC5322]の<MSG-ID>のグローバルな一意性要件は、そのようなメッセージ識別子を使用してすべてのプロトコルに適用されると理解されるべきです。
message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF
msg-id = "<" msg-id-core ">"
; maximum length is 250 octets
msg-id-core = id-left "@" id-right
msg-id-core = is-left "@" and-right
id-left = dot-atom-text
id-right = dot-atom-text / no-fold-literal
no-fold-literal = "[" *mdtext "]"
no-fold-literal = "[" *mdtext "]"
mdtext = %d33-61 / ; The rest of the US-ASCII
%d63-90 / ; characters not including
%d94-126 ; ">", "[", "]", or "\"
The <msg-id> MUST NOT be more than 250 octets in length.
<msg-id>は、長さが250オクターを超えてはなりません。
NOTE: The length restriction ensures that systems that accept message identifiers as a parameter when referencing an article (e.g., [RFC3977]) can rely on a bounded length.
注：長さの制限により、記事を参照するときにメッセージ識別子をパラメーターとして受け入れるシステム（[RFC3977]など）が境界の長さに依存できるようになります。
Observe that <msg-id> includes the < and >.
<sg-id>には<and>が含まれていることを観察します。
Observe also that in contrast to the corresponding header field in [RFC5322]:
また、[RFC5322]の対応するヘッダーフィールドとは対照的にも観察してください。
o The syntax does not allow comments within the Message-ID header field.
o 構文では、メッセージIDヘッダーフィールド内のコメントは許可されていません。
o There is no possibility for ">" or WSP to occur inside a <msg-id>.
o 「>」またはwspが<msg-id>内で発生する可能性はありません。
o Even though commonly derived from <domain>s, <id-rights>s are case-sensitive (and thus, once created, are not to be altered during subsequent transmission or copying)
o <domain> sから一般的に導出されているにもかかわらず、<id-rights> sはケースに敏感です（したがって、作成されると、後続の送信またはコピー中に変更されることはありません）
This is to simplify processing by news servers and to ensure interoperability with existing implementations and compliance with [RFC3977]. A simple comparison of octets will always suffice to determine the identity of two <msg-id>s.
これは、ニュースサーバーによる処理を簡素化し、既存の実装との相互運用性と[RFC3977]のコンプライアンスを確保するためです。オクテットの単純な比較では、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は、セクション3.2.10で説明されている参照ヘッダーフィールドやセクション3.2.12で説明したスーパーデスヘッダーフィールドを含め、<MSG-ID>を使用する場所に適用されることに注意してください。
Some software will try to match the <id-right> of a <msg-id> in a case-insensitive fashion; some will match it in a case-sensitive fashion. Implementations MUST NOT generate a Message-ID where the only difference from another Message-ID is the case of characters in the <id-right> part.
一部のソフトウェアは、<MSG-ID>の<ID-right>をケースに依存しない方法で一致させようとします。いくつかは、ケースに敏感な方法でそれを一致させます。実装は、別のメッセージIDとの唯一の違いが<id-right>パーツの文字の場合であるメッセージを生成してはなりません。
When generating a <msg-id>, implementations SHOULD use a domain name as the <id-right>.
<msg-id>を生成する場合、実装は<id-right>としてドメイン名を使用する必要があります。
NOTE: Section 3.6.4 of [RFC5322] recommends that the <id-right> should be a domain name or a domain literal. Domain literals are troublesome since many IP addresses are not globally unique; domain names are more likely to generate unique Message-IDs.
注：[RFC5322]のセクション3.6.4は、<id-right>がドメイン名またはドメインリテラルであることを推奨しています。多くのIPアドレスはグローバルに一意ではないため、ドメインリテラルは面倒です。ドメイン名は、一意のメッセージIDを生成する可能性が高くなります。
The Newsgroups header field specifies the newsgroup(s) to which the article is posted.
NewsGroups Headerフィールドは、記事が投稿されるニュースグループを指定します。
newsgroups = "Newsgroups:" SP newsgroup-list CRLF
NewsGroups = "NewsGroups：" SP NewsGroup-List CRLF
newsgroup-list = *WSP newsgroup-name
*( [FWS] "," [FWS] newsgroup-name ) *WSP
newsgroup-name = component *( "." component )
newsgroup-name = component *（ "。"コンポーネント）
component = 1*component-char
component-char = ALPHA / DIGIT / "+" / "-" / "_"
Not all servers support optional FWS in the list of newsgroups. In particular, folding the Newsgroups header field over several lines has been shown to harm propagation significantly. Optional FWS in the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
すべてのサーバーがニュースグループのリストでオプションのFWをサポートするわけではありません。特に、ニュースグループヘッダーフィールドをいくつかの行に折り畳むことは、伝播を大幅に害することが示されています。<newsgroup-list>のオプションの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.
<コンポーネント>は数字のみで構成されておらず、大文字を含めてはなりません。このような<コンポーネント>は、この命名スキームに準拠していないが、それ以外の場合は使用してはならない既存のグループを参照するためにのみ使用できます。
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つのストレージスキームと矛盾するAll-Digit <Component>。混合ケースグループは、ケースに敏感なマッチングを備えたシステム間の混乱と、<newsgroup-name> sのケース非感受性マッチングを備えたシステム間で混乱を引き起こします。
<component>s beginning with underline ("_") are reserved for use by future versions of this standard and SHOULD NOT be generated by user agents (whether in header fields or in newgroup control messages as defined by [RFC5537]). However, such names MUST be accepted by news servers.
<component> s underline（ "_"）は、この標準の将来のバージョンで使用するために予約されており、ユーザーエージェントによって生成されるべきではありません（[RFC5537]で定義されているヘッダーフィールドまたは新しいグループ制御メッセージで）。ただし、そのような名前はニュースサーバーで受け入れられる必要があります。
<component>s beginning with "+" and "-" are reserved for private use and SHOULD NOT be generated by user agents (whether in header fields or in newgroup control messages [RFC5537]) without a private prior agreement to do so. However, such names MUST be accepted by news servers.
<component> s "" and " - "は個人用に予約されており、ユーザーエージェント（ヘッダーフィールドであろうと新しいグループ制御メッセージ[RFC5537]）が生成するべきではありません。ただし、そのような名前はニュースサーバーで受け入れられる必要があります。
The following <newsgroup-name>s are reserved and MUST NOT be used as the name of a newsgroup:
次の<NewsGroup-Name>は予約されており、ニュースグループの名前として使用してはなりません。
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.
以下の<NewsGroup-Name>は、さまざまな実装やプロトコルで特定の目的に使用されているため、通常のニュースグループの名前に使用してはなりません。それらは、特定の目的または現地の合意に使用される場合があります。
o Groups whose first (or only) component is "to"
o 最初の（または唯一の）コンポーネントが「to」であるグループのグループ
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.
注：「例。*」は、この標準およびその他の標準の例のために予約されています。「ポスター」は、フォローアップツーヘッダーフィールドに特別な意味があります。「to。*」は、[rfc5537]で定義されている「ihave」制御メッセージと組み合わせて、特定のポイントツーポイント通信のために予約されています。「コントロール。*」と「ジャンク」は、一部のニュースサーバーで特別な意味を持っています。「すべて」は、いくつかの実装でワイルドカードとして使用されます。「CTL」は、以前はNewsGroupsヘッダーフィールド内でA <Control-Command>を示すために使用されていました。
The Path header field indicates the route taken by an article since its injection into the Netnews system. Each agent that processes an article is required to prepend at least one <path-identity> to this header field body. This is primarily so that news servers are able to avoid sending articles to sites already known to have them, in particular the site they came from. Additionally, it permits gathering statistics and tracing the route articles take in moving over the network.
パスヘッダーフィールドは、NetNewsシステムへの注入以来、記事で撮影されたルートを示します。記事を処理する各エージェントは、このヘッダーフィールドボディに少なくとも1つの<パスアイデンティティ>を準備する必要があります。これは主に、ニュースサーバーが記事を持っていることが既に知られているサイト、特に彼らが来たサイトに記事を送信することを避けることができるようにするためです。さらに、統計を収集し、ネットワーク上を移動する際にルートの記事を追跡することができます。
path = "Path:" SP *WSP path-list tail-entry *WSP CRLF
path-list = *( path-identity [FWS] [path-diagnostic] "!" )
path-diagnostic = diag-match / diag-other / diag-deprecated
diag-match = "!" ; another "!"
diag-other = "!." diag-keyword [ "." diag-identity ] [FWS]
diag-other = "！。"diag-keyword ["。"diag-identity] [fws]
diag-deprecated = "!" IPv4address [FWS]
diag-deprecated = "！"IPv4Address [FWS]
diag-keyword = 1*ALPHA ; see [RFC5537]
diag-identity = path-identity / IPv4address / IPv6address
tail-entry = path-nodot ; may be the string "not-for-mail"
テールエントリー=パスノドット;文字列「Not-for-mail」かもしれません
path-identity = ( 1*( label "." ) toplabel ) / path-nodot
path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
label = alphanum [ *( alphanum / "-" ) alphanum ]
toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) /
( label *( "-" ) ALPHA [ *( "-" ) label ] ) /
( label 1*( "-" ) label )
alphanum = ALPHA / DIGIT ; compare [RFC3696]
A <path-identity> is a name identifying a site. It takes the form of a domain name having two or more components separated by dots, or a single name with no dots (<path-nodot>).
a <Path-Identity>は、サイトを識別する名前です。ドットで2つ以上のコンポーネントが分離されているドット、またはドットのない単一の名前（<sath-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).
<sath-list>（<tail-entry>を含まない）の各<パスアイデンティティ>は、右から左へ、記事が通過した連続したエージェントを示します。「!!」として表示される<diag-match>の使用は、左のエージェントが記事を受け入れる前にエージェントの身元をその直接に検証したことを示しています（<sath-delimiter> "！"は意味します。そのような主張はありません）。
NOTE: Historically, the <tail-entry> indicated the name of the sender. If not used for this purpose, the string "not-for-mail" is often used instead (since at one time the whole path could be used as a mail address for the sender).
注：歴史的に、<Tail-Entry>は送信者の名前を示しました。この目的に使用されない場合、文字列「Not-for-mail」が代わりに使用されることがよくあります（一度にパス全体を送信者のメールアドレスとして使用できるため）。
NOTE: Although case-insensitive, it is intended that the <diag-keyword>s should be in uppercase, to distinguish them from the <path-identity>s, which are traditionally in lowercase.
注：症例感受性ですが、伝統的に小文字にある<パスアイデンティティ> sと区別するために、<diag-keyword> 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].
A <Path-Dianostic>は、サイトの名前を示す以外の目的でパスヘッダーフィールドに挿入されたアイテムです。これらの使用は[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.
注：A <path-diagnostic>の使用法は、IPアドレスを記録することです。<ipv6address> esが許可されているという事実は、コロン（:)が許可されていることを意味します。これは、「：」と見なす古いサイトで相互運用性の問題を引き起こす可能性があることに注意してください。「Path-delimiter>と、名前が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 deprecated>の形ではまだ受け入れられます）。
The Subject header field is the same as that specified in Section 3.6.5 of [RFC5322], with the added restrictions detailed above in Section 2.2. Further discussion of the content of the Subject header field appears in [RFC5537] and [USEAGE].
サブジェクトヘッダーフィールドは、[RFC5322]のセクション3.6.5で指定されているものと同じであり、上記のセクション2.2で追加された制限が追加されています。被験者ヘッダーフィールドの内容のさらなる議論は、[RFC5537]および[使用]に表示されます。
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]および[使用]に表示されます。
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.
ヘッダーフィールドのコメント、キーワード、返信、および送信者は、[RFC5322]で指定されたものと同じ状況で、同じ意味でNetNewsの記事で使用され、セクション2.2で上記の追加の制限があります。キーワードヘッダーフィールドの複数の発生は許可されていません。
comments = "Comments:" SP unstructured CRLF
コメント= "コメント：" SP非構造化CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF
reply-to = "Reply-To:" SP address-list CRLF
sender = "Sender:" SP mailbox CRLF
sender = "sender：" sp mailbox crlf
The MIME header fields MIME-Version, Content-Type, Content-Transfer-Encoding, Content-Disposition, and Content-Language are used in Netnews articles in the same circumstances and with the same meanings as those specified in [RFC2045], [RFC2183], and [RFC3282], with the added restrictions detailed above in Section 2.2.
MIMEヘッダーフィールドMIMEバージョン、コンテンツタイプ、コンテンツトランスファーエンコード、コンテンツディスポジション、およびコンテンツ言語は、[RFC2045]、[RFC2183で指定されたものと同じ状況で、同じ意味で使用されます。]、および[RFC3282]、上記のセクション2.2で詳細な制限が追加されています。
All remaining news header fields are described below.
残りのニュースヘッダーフィールドはすべて以下に説明します。
The Approved header field indicates the mailing addresses (and possibly the full names) of the persons or entities approving the article for posting. Its principal uses are in moderated articles and in group control messages; see [RFC5537].
承認されたヘッダーフィールドは、投稿のために記事を承認した人物または団体の郵送アドレス（および場合によってはフルネーム）を示します。その主要な用途は、緩和された記事とグループ制御メッセージにあります。[RFC5537]を参照してください。
approved = "Approved:" SP mailbox-list CRLF
承認= "承認：" SP Mailbox-List 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
archive-param = parameter
The presence of an Archive header field in an article with a field body of "no" indicates that the poster does not permit redistribution from publicly accessible long-term or permanent archives. A field body of "yes" indicates that the poster permits such redistribution.
「NO」のフィールドボディを含む記事にアーカイブヘッダーフィールドが存在することは、ポスターが公的にアクセス可能な長期または永続的なアーカイブからの再分配を許可していないことを示しています。「はい」のフィールドボディは、ポスターがそのような再分配を許可していることを示しています。
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].
現在、<パラメーター>は定義されています。存在する場合、それらは無視できます。アーカイブヘッダーフィールドの使用に関するさらなる議論は、[使用]に表示されます。
The Control header field marks the article as a control message and specifies the desired actions (in addition to the usual actions of storing and/or relaying the article).
コントロールヘッダーフィールドは、記事をコントロールメッセージとしてマークし、目的のアクションを指定します（記事を保存および/または中継する通常のアクションに加えて）。
control = "Control:" SP *WSP control-command *WSP CRLF
control-command = verb *( 1*WSP argument )
verb = token
argument = 1*( %x21-7E )
The verb indicates what action should be taken, and the argument(s) (if any) supply details. In some cases, the <body> (as defined in [RFC5322]) of the article may also contain details. The legal verbs and respective arguments are discussed in the companion document, [RFC5537].
動詞は、どのアクションを実行すべきかを示し、議論（もしあれば）は詳細を提供します。場合によっては、記事の<body>（[rfc5322]で定義されている）にも詳細が含まれている場合があります。法的動詞とそれぞれの議論は、コンパニオン文書[RFC5537]で議論されています。
An article with a Control header field MUST NOT also have a Supersedes header field.
コントロールヘッダーフィールドを備えた記事には、SuperSedesヘッダーフィールドも必要です。
The Distribution header field specifies geographic or organizational limits on an article's propagation.
分布ヘッダーフィールドは、記事の伝播に関する地理的または組織的な制限を指定します。
distribution = "Distribution:" SP dist-list CRLF
Distribution = "Distribution：" sp distlist crlf
dist-list = *WSP dist-name
*( [FWS] "," [FWS] dist-name ) *WSP
dist-name = ALPHA / DIGIT
*( ALPHA / DIGIT / "+" / "-" / "_" )
The <dist-name>s "world" and "local" are reserved. "world" indicates unlimited distribution and SHOULD NOT be used explicitly, since it is the default when the Distribution header field is absent entirely. "local" is reserved for indicating distribution only to the local site, as defined by local software configuration.
<dist-name> sの「世界」と「ローカル」は予約されています。「World」は無制限の分布を示しており、配布ヘッダーフィールドが完全に欠如している場合にデフォルトであるため、明示的に使用すべきではありません。「ローカル」は、ローカルソフトウェア構成によって定義されているように、ローカルサイトへのみ配信を示すために予約されています。
"All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain at least three characters, except when they are two-letter country codes drawn from [ISO3166-1]. <dist-name>s are case-insensitive (i.e., "US", "Us", "uS", and "us" all specify the same distribution).
「すべて」を<dist-name>として使用してはなりません。<dist-name> sには、[ISO3166-1]から描かれた2文字の国コードである場合を除き、少なくとも3つの文字を含める必要があります。<dist-name> sはケース非感受性（つまり、「us」、「us」、「us」、および「us」がすべて同じ分布を指定します）です。
Optional FWS in the <dist-list> SHOULD NOT be generated, but MUST be accepted.
<distlist>のオプションのFWSは生成されるべきではありませんが、受け入れられる必要があります。
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
期限切れ= "expires：" SP Date-Time 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.
<date-time>の構文に関するセクション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.
フォローアップツーヘッダーフィールドは、ポスターがフォローアップを掲載することを要求したニュースグループを指定します。コンテンツがNewsGroupsヘッダーフィールドのコンテンツとは異なる場合を除き、フォローアップツーヘッダーフィールドはメッセージに表示されないはずです。
followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) CRLF
followup-to = "followup-to：" sp（newsgroup-list /ポスターテキスト）crlf
poster-text = *WSP %d112.111.115.116.101.114 *WSP
; "poster" in lowercase
The syntax is the same as that of the Newsgroups (Section 3.1.4) header field, with the exception that the keyword "poster" requests that followups should be emailed directly to the article's poster (using the addresses contained in the Reply-To header field if one exists, otherwise using the addresses contained in the From header field) rather than posted to any newsgroups. Agents MUST generate the keyword "poster" in lowercase, but MAY choose to recognize case-insensitive forms such as "Poster".
構文は、ニュースグループ（セクション3.1.4）ヘッダーフィールドのそれと同じですが、キーワード「ポスター」がフォローアップを記事のポスターに直接電子メールで送信することを要求することを除いて（Reply-to Headerに含まれるアドレスを使用してフィールドが存在する場合、それ以外の場合は、任意のニュースグループに投稿するのではなく、Headerフィールドに含まれるアドレスを使用します。エージェントは、小文字でキーワード「ポスター」を生成する必要がありますが、「ポスター」などのケースに依存しないフォームを認識することを選択できます。
As in the Newsgroups (Section 3.1.4) header field, optional FWS in the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
NewsGroups（セクション3.1.4）ヘッダーフィールドと同様に、<newsGroup-List>のオプションの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-Time>を使用することです。
This header field MUST be inserted whenever an article is injected. However, software that predates this standard does not use this header, and therefore agents MUST accept articles without the Injection-Date header field.
このヘッダーフィールドは、記事が挿入されるたびに挿入する必要があります。ただし、この標準よりも前のソフトウェアはこのヘッダーを使用していないため、エージェントは注入日付ヘッダーフィールドなしで記事を受け入れる必要があります。
injection-date = "Injection-Date:" SP date-time CRLF
Injection-date = "Injection-date：" SP Date-Time 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.
<date-time>の構文に関するセクション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-time>は、日付ヘッダーフィールドの<date-time>よりも後の値ではない場合があります。インジェクションデートヘッダーフィールドを追加するとき、エージェントは既存の日付ヘッダーフィールドを変更してはなりません。
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ヘッダーフィールドには、記事がNetNewsシステムにどのように入力されたかについて、注入ニュースサーバーが提供する情報が含まれています。記事の真の起源を追跡するのに役立ちます。また、記事のポスターに関する苦情が送信される可能性のある1つ以上のアドレスを指定することもできます。
injection-info = "Injection-Info:" SP [CFWS] path-identity
[CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF
NOTE: The syntax of <parameter> (Section 5.1 of [RFC2045], as amended by [RFC2231]), taken in conjunction with the folding rules of [RFC0822] (note: not [RFC2822] or [RFC5322]), effectively allows [CFWS] to occur on either side of the "=" inside a <parameter>.
注：[RFC0822]の折り畳みルールと併せて採取された<パラメーター>（[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.
次の表は、このヘッダーフィールドで使用するために定義された各<パラメーター>の<属性>と<value>の形式を示します。せいぜい、そのような各<パラメーター>の1つの発生が許可されます。
<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 ))
NOTE: Since any such <host-value> or <address-list> also has to be a syntactically correct <value>, it will usually be necessary to encapsulate it as a <quoted-string>, for example:
注：そのような<HOST-VALUE>または<draddSlist>も構文的に正しい<value>である必要があるため、通常、<引用符で描かれた>としてカプセル化する必要があります。
posting-host = "posting.example.com:192.0.2.1"
posting-host = "posting.example.com:192.0.2.1"
Other <attribute>s SHOULD NOT be used unless defined in extensions to this standard. If non-standards-based <attribute>s are used, they MUST begin with an "x-".
この標準の拡張機能で定義されない限り、他の<属性>は使用しないでください。非標準ベースの<属性> 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>.
噴射内のヘッダーフィールド全体で、ホワイトスパースのコメントと折りたたみは許可されていますが、折りたたみは<パラメーター>内で使用しないでください。折り畳みは、「;」の前または後にのみ発生する必要があります。<パラメーター>を分離します。コメントは、最後の<パラメーター>に続いてのみ使用する必要があります。
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-Trace、X-Compraints-toなどの非標準化されたヘッダーフィールドで送信されています。ニュースサーバーがインジェクション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.
注：「Posting-Host」<Parameter>がホストを決定的に識別できない場合（たとえば、動的IPアドレスの割り当て）、「Posting-Account」または「Logging-Data」<Parameter>は、真の起源に関する追加情報を提供する場合があります。記事の。
The "posting-account" <parameter> identifies the source from which that news server received the article, in a notation that can be interpreted by the news server administrator. This notation can include any information the administrator deems pertinent. In order to limit the exposure of personal data, it SHOULD be given in a form that cannot be interpreted by other sites. However, to make it useful for rate limiting and abuse detection, two messages posted from the same source SHOULD have the same value of "posting-account", and two messages from different sources SHOULD have differing values of "posting-account". The exact definition of "source" is left to the discretion of the news server administrator.
「Posting-Account」<Parameter>は、ニュースサーバーが記事を受け取ったソースを、ニュースサーバー管理者が解釈できる表記で識別します。この表記法には、管理者が適切とみなす情報を含めることができます。個人データの露出を制限するために、他のサイトでは解釈できない形式で指定する必要があります。ただし、レートの制限と乱用の検出に役立つようにするには、同じソースから投稿された2つのメッセージが同じ値「投稿アカウント」を持つ必要があり、異なるソースからの2つのメッセージには「Posting-Account」の値が異なるはずです。「ソース」の正確な定義は、ニュースサーバー管理者の裁量に任されています。
The "logging-data" <parameter> contains information (typically a session number or other non-persistent means of identifying a posting account) that will enable the true origin of the article to be determined by reference to logging information kept by the news server.
「Logging-data」<parameter>には、記事の真の起源がニュースサーバーが保持しているロギング情報を参照して決定できるようにする情報（通常、セッション番号またはその他の非特性手段）が含まれています。。
The "mail-complaints-to" <parameter> specifies one or more mailboxes for sending complaints concerning the behavior of the poster of the article.
「Mail-Compraints-to」<Parameter>は、記事のポスターの動作に関する苦情を送信するために、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].
これは、上記の<パラメーター>を含めることがローカルポリシーの問題です。いくつかの情報にはプライバシーへの影響があります。これは[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:
参考文献ヘッダーフィールドは、[RFC5322]のセクション3.6.4で指定されているものと同じであり、上記のセクション2.2および以下にリストされている制限が追加されています。
o The updated <msg-id> construct defined in Section 3.1.3 MUST be used.
o セクション3.1.3で定義された更新された<MSG-ID>コンストラクトを使用する必要があります。
o Message identifiers MUST be separated with CFWS.
o メッセージ識別子はCFWSで分離する必要があります。
o Comments in CFWS between message identifiers can cause interoperability problems, so comments SHOULD NOT be generated but MUST be accepted.
o メッセージ識別子間のCFWのコメントは、相互運用性の問題を引き起こす可能性があるため、コメントを生成すべきではありませんが、受け入れられる必要があります。
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
summary = "summary：" SP非構造化CRLF
The Supersedes header field contains a message identifier specifying an article to be superseded upon the arrival of this one. An article containing a Supersedes header field is equivalent to a "cancel" [RFC5537] control message for the specified article, followed immediately by the new article without the Supersedes header field.
SuperSedesヘッダーフィールドには、この1つの到着時に記事を指定するメッセージ識別子が含まれています。SuperSedesヘッダーフィールドを含む記事は、指定された記事の「キャンセル」[RFC5537]制御メッセージに相当し、その後、スーパーデスヘッダーフィールドのない新しい記事がすぐに続きます。
supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF
NOTE: There is no "c" in Supersedes.
注：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.
注：ここで定義されているSuperSedesヘッダーフィールドは、[RFC2156]に従ってX.400から変換された電子メールメッセージに表示される場合があるSuperSedesヘッダーフィールドとの関係がありません。特に、ここの構文では、そのメールバージョンの複数の<MSG-ID>とは対照的に、1つの<MSG-ID>のみを許可します。
The User-Agent header field contains information about the user agent (typically a newsreader) generating the article, for statistical purposes and tracing of standards violations to specific software in need of correction. It is intended that this header field be suitable for use in Email.
ユーザーエージェントヘッダーフィールドには、修正が必要な特定のソフトウェアに対する統計的目的と標準違反のトレースのために、記事を生成するユーザーエージェント（通常はニュースリーダー）に関する情報が含まれています。このヘッダーフィールドは、電子メールでの使用に適していることを意図しています。
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
product = [CFWS] token [ [CFWS] "/" product-version ]
product-version = [CFWS] token
This header field MAY contain multiple <product> tokens identifying
the user agent and any subproducts that form a significant part of
it, listed in order of their significance for identifying the
application.
NOTE: Some of this information has previously been sent in non-standardized header fields such as X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent generates a User-Agent header field, it should have no need to send these non-standard header fields.
注：この情報の一部は、以前にX-NewsReader、X-Mailer、X-Posting-Agent、X-HTTP-User-Agentなどの非標準化されたヘッダーフィールドで送信されています。ユーザーエージェントがユーザーエージェントヘッダーフィールドを生成したら、これらの非標準ヘッダーフィールドを送信する必要はありません。
NOTE: [RFC2616] describes a similar facility for the HTTP protocol. The Netnews article format differs in that "{" and "}" are allowed in tokens (<product> and <product-version>) and comments are permitted wherever white space is allowed.
注：[RFC2616]は、HTTPプロトコルの同様の施設について説明しています。netnewsの記事形式は、「{"と"}」がトークン（<product> and <product-version>）で許可されているという点で異なり、ホワイトスペースが許可されている場合はコメントが許可されています。
The Xref header field indicates where an article was filed by the last news server to process it. User agents often use the information in the Xref header field to avoid multiple processing of crossposted articles.
XREFヘッダーフィールドは、最後のニュースサーバーによって記事がどこに提出されたかを示し、それを処理します。ユーザーエージェントは、多くの場合、XREFヘッダーフィールドの情報を使用して、クロス投稿記事の複数の処理を避けます。
xref = "Xref:" SP *WSP server-name
1*( FWS location ) *WSP CRLF
server-name = path-identity
location = newsgroup-name ":" article-locator
場所= newsgroup-name "：" article-locator
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; US-ASCII printable characters
; except '(' and ';'
The <server-name> is included so that software can determine which news server generated the header field. The locations specify where the article is filed -- i.e., under which newsgroups (which may differ from those in the Newsgroups header field), and where under those newsgroups. The exact form of an <article-locator> is implementation-specific.
ソフトウェアがヘッダーフィールドを生成するニュースサーバーを決定できるように、<server-name>が含まれています。場所は、記事が提出される場所、つまりニュースグループ（ニュースグループのヘッダーフィールドのものとは異なる場合がある）、およびそれらのニュースグループの下の場所を指定します。<article-locator>の正確な形式は実装固有です。
NOTE: The traditional form of an <article-locator> (as required by [RFC3977]) is a decimal number, with articles in each newsgroup numbered consecutively starting from 1.
注：<article-locator>の従来の形式（[rfc3977]で要求される）は10進数であり、各ニュースグループの記事は1から連続して連続して始まります。
The header fields Date-Received, Posting-Version, and Relay-Version defined in [RFC0850], as well as Also-Control, Article-Names, Article-Updates, and See-Also defined in [Son-of-1036] are declared obsolete. See the cited specification documents for further information on their original use.
[RFC0850]で定義されているヘッダーフィールドは、[RFC0850]で定義されているリレーバージョン、ならびに[1036-of-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.
ラインヘッダーフィールドは、記事の<body>（[rfc5322]で定義されている）の線の数を示します。
lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF
The line count is the number of CRLF separators in the <body>.
ラインカウントは、<body>のCRLFセパレーターの数です。
Historically, this header field was used by the NNTP [RFC3977] overview facility, but its use for this purpose is now deprecated. As a result, this header field is to be regarded as obsolescent, and it is likely to be removed entirely in a future version of this standard. All agents SHOULD ignore it and SHOULD NOT generate it.
歴史的に、このヘッダーフィールドはNNTP [RFC3977]の概要施設で使用されていましたが、この目的での使用は現在廃止されています。その結果、このヘッダーフィールドは時代遅れと見なされるはずであり、この標準の将来のバージョンで完全に削除される可能性があります。すべてのエージェントはそれを無視する必要があり、それを生成しないでください。
Internationalization of Netnews article header fields and bodies is provided using the MIME mechanisms discussed in Section 2.3. Note that the generation of internationalized <newsgroup-name>s for use in header fields is not addressed in this document.
NetNewsの記事ヘッダーフィールドとボディの国際化は、セクション2.3で説明したMIMEメカニズムを使用して提供されます。このドキュメントでは、ヘッダーフィールドで使用するためのInternationalized <newsgroup-name> sの生成が扱われていないことに注意してください。
The Netnews article format specified in this document does not provide any security services, such as confidentiality, authentication of sender, or non-repudiation. Instead, such services need to be layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME (Pretty Good Privacy / MIME) [RFC3156], or below, using secure versions of news transport protocols. Additionally, several currently non-standardized protocols such as [PGPVERIFY] may be standardized in the near future.
このドキュメントで指定されたNetNewsの記事形式は、機密性、送信者の認証、非控除などのセキュリティサービスを提供しません。代わりに、S/MIME [RFC3851]またはPGP/MIME（Pretty Good Privacy/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.
NetNewsの記事のメッセージ識別子（セクション3.1.3）は一意である必要があります。識別子がすでに見られている場合、記事は（サーバーからサーバーへの転送で）拒否される場合があります。悪意のあるエージェントが記事の識別子を予測できる場合、同じメッセージ識別子を使用して独自の記事（おそらくまったく異なるグループに）を投稿することにより、記事を先制することができ、それによりターゲットの記事が伝播するのを防ぎます。したがって、NetNewsの記事のメッセージ識別子を生成するエージェントは、それらが予測不可能であることを保証する必要があります。
MIME security considerations are discussed in [RFC2046]. Note that the full range of encodings allowed for parameters in [RFC2046] and [RFC2231] permits constructs that simple parsers may fail to parse correctly; examples of hard-to-parse constructs are:
MIMEセキュリティの考慮事項は[RFC2046]で説明されています。[RFC2046]および[RFC2231]でパラメーターを許可するすべてのエンコーディングにより、単純なパーサーが正しく解析できない可能性があることを構築することを許可することに注意してください。パースが困難な構造の例は次のとおりです。
Content-Type: multipart/mixed
(; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
Content-Type: multipart/digest;
boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
Such deficiencies in parsing may be used as part of an attack.
このような解析の欠陥は、攻撃の一部として使用できます。
Further security considerations are discussed in [RFC5537].
さらなるセキュリティ上の考慮事項については、[RFC5537]で説明します。
IANA has registered the following header fields in the Permanent Message Header Field Repository, in accordance with the procedures set out in [RFC3864].
IANAは、[RFC3864]に定められた手順に従って、永続的なメッセージヘッダーフィールドリポジトリに次のヘッダーフィールドを登録しています。
Header field name: Also-Control Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [Son-of-1036] (Section 6.15)
ヘッダーフィールド名：また、コントロール該当するプロトコル：NetNewsステータス：廃止された著者/変更コントローラー：IETF仕様文書：[son-of-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)
ヘッダーフィールド名：承認済み該当するプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.2.1）
Header field name: Archive
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.2)
Header field name: Article-Names
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.17)
Header field name: Article-Updates Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [Son-of-1036] (Section 6.18)
ヘッダーフィールド名：記事 - アップデート該当するプロトコル：NetNewsステータス：廃止された著者/変更コントローラー：IETF仕様文書：[son-of-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)
ヘッダーフィールド名：コメント該当するプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.2）、[RFC5322]（セクション3.6.5）
Header field name: Control Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.3)
ヘッダーフィールド名：コントロール適用プロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション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)
ヘッダーフィールド名：日付該当するプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.1.1）、[RFC5322]（セクション3.6.1）
Header field name: Date-Received Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [RFC0850] (Section 2.2.4)
ヘッダーフィールド名：日付測定該当するプロトコル：NetNewsステータス：廃止された著者/変更コントローラー：IETF仕様文書：[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)
Header field name: Expires
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.5)
Header field name: Followup-To Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.6)
ヘッダーフィールド名：フォローアップ対応プロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション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)
ヘッダーフィールド名：該当するプロトコルから：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.1.2）、[RFC5322]（セクション3.6.2）
Header field name: Injection-Date Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.7)
ヘッダーフィールド名：インジェクションデート適用可能なプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション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)
ヘッダーフィールド名：インジェクションINFO該当するプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション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)
ヘッダーフィールド名：キーワード適用可能なプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.2）、[RFC5322]（セクション3.6.5）
Header field name: Lines
Applicable protocol: netnews
Status: deprecated
Author/change controller: IETF
Specification document(s): This document (Section 3.3.1)
Related information: [RFC3977] (Section 8.1)
Header field name: Message-ID
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.3)
Related information: [RFC5322] (Section 3.6.4)
Header field name: Newsgroups Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.4)
ヘッダーフィールド名：NewsGroups適用可能なプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.1.4）
Header field name: NNTP-Posting-Date Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): none
ヘッダーフィールド名：NNTP-POSTING-DATE適用プロトコル：NetNewsステータス：廃止された著者/変更コントローラー：IETF仕様文書：なし：なし
Header field name: NNTP-Posting-Host Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [RFC2980] (Section 3.4.1)
ヘッダーフィールド名：NNTP-POSTING-HOST適用プロトコル：NetNewsステータス：廃止された著者/変更コントローラー：IETF仕様文書：[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)
ヘッダーフィールド名：組織適用プロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション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)
ヘッダーフィールド名：PATH適用プロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.1.5）
Header field name: Posting-Version
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.1.2)
Header field name: References
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.10),
[RFC5322] (Section 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)
ヘッダーフィールド名：リレーバージョン適用プロトコル：NetNewsステータス：廃止された著者/変更コントローラー：IETF仕様文書：[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)
ヘッダーフィールド名：応答対該当するプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.2）、[RFC5322]（セクション3.6.2）
Header field name: See-Also Applicable protocol: netnews Status: obsoleted Author/change controller: IETF Specification document(s): [Son-of-1036] (Section 6.16)
ヘッダーフィールド名：SEE-適用可能なプロトコル：NetNewsステータス：廃止された著者/変更コントローラー：IETF仕様文書：[son-of-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)
ヘッダーフィールド名：送信者適用可能なプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.2）、[RFC5322]（セクション3.6.2）
Header field name: Subject Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.1.6), [RFC5322] (Section 3.6.5)
ヘッダーフィールド名：件名適用可能なプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.1.6）、[RFC5322]（セクション3.6.5）
Header field name: Summary
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.11)
Header field name: Supersedes
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.12)
Header field name: User-Agent Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document (Section 3.2.13) Related information: [RFC2616] (Section 14.43)
ヘッダーフィールド名：ユーザーエージェント該当するプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション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)
ヘッダーフィールド名：XREF適用可能なプロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3.2.14）
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（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] Freed、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージでのプレゼンテーション情報の通信：コンテンツ - 分散ヘッダーフィールド」、RFC 2183、1997年8月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張：文字セット、言語、および継続」、RFC 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] 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の増強」、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and Protocols", RFC 5537, November 2009.
[RFC5537] Allbery、R.、ed。C. Lindsey、「Netnews Architecture and Protocols」、RFC 5537、2009年11月。
[Errata] "RFC Editor Errata", <http://www.rfc-editor.org/errata.php>.
[errata] "RFCエディターERRATA"、<http://www.rfc-editor.org/errata.php>。
[ISO3166-1] International Organization for Standardization, "ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", 1997.
[ISO3166-1]国際標準化機関、「ISO 3166-1：1997。国の名前とその細分化の表現のためのコード - パート1：国コード」、1997。
[PGPVERIFY] Lawrence, D., "Authentication of Usenet Group Changes (pgpverify)", June 1999, <ftp://ftp.isc.org/pub/pgpcontrol/README.html>.
[Pgpverify] Lawrence、D。、「Usenet Group Changes（PGPVerify）の認証」、1999年6月、<ftp://ftp.isc.org/pub/pgpcontrol/readme.html>。
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC0822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[RFC0850] Horton, M., "Standard for interchange of USENET messages", RFC 850, June 1983.
[RFC0850] Horton、M。、「Usenetメッセージの交換の標準」、RFC 850、1983年6月。
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
[RFC1036] Horton、M。およびR. Adams、「Usenetメッセージの交換の標準」、RFC 1036、1987年12月。
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[RFC2156] Kille、S。、「Mixer（Mime Internet X.400 Enhanced Relay）：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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[RFC2980] BARBER、S。、「一般的なNNTP拡張機能」、RFC 2980、2000年10月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「OpenPGPを使用したMime Security」、RFC 3156、2001年8月。
[RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004.
[RFC3696]クレンシン、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。、「Secure/Multipurpose Internet Mail Extensions（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.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、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.
[使用] Lindsey、C。、「Usenet Best Practice」、2005年3月、進行中の作業。
As this document is the result of an eight-year effort, the number of people that have contributed to its content are too numerous to mention individually. Many thanks go out to all past and present members of the USEFOR Working Group of the Internet Engineering Task Force (IETF) and its accompanying mailing list.
このドキュメントは8年間の努力の結果であるため、その内容に貢献した人の数は多すぎて個別に言及することができません。インターネットエンジニアリングタスクフォース（IETF）とその付随するメーリングリストのワーキンググループの過去と現在のすべてのメンバーに感謝します。
This appendix contains a list of changes that have been made in the Netnews article format from earlier standards, specifically [RFC1036].
この付録には、以前の標準、特に[RFC1036]からNetNewsの記事形式で行われた変更のリストが含まれています。
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]から継承されたヘッダーフィールドでサポートされています。しかし、彼らは、制御、配布、フォローアップ、ライン、メッセージ、ニュースグループ、パス、SuperSedes、およびXREFヘッダーフィールドのパフォーマンスおよび/または互換性の理由でまだ許可されていません。
o Multiple addresses are allowed in the From header field.
o From Headerフィールドでは、複数のアドレスが許可されています。
o [FWS] is permitted in Newsgroups header fields.
o [FWS]は、NewsGroups Headerフィールドで許可されています。
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 SuperSedesヘッダーフィールドでは、1つのメッセージ識別子のみが許可されています。
o MIME is recognized as an integral part of Netnews.
o MIMEは、NetNewsの不可欠な部分として認識されています。
o There is a new Injection-Date header field to make the rejection of stale articles more precise and to minimize spurious rejections.
o 古い記事の拒絶をより正確にし、偽の拒絶を最小限に抑えるための新しい注入日付ヘッダーフィールドがあります。
o There are several new optional header fields defined, notably Archive, Injection-Info, and User-Agent, leading to increased functionality.
o 定義されたいくつかの新しいオプションのヘッダーフィールド、特にアーカイブ、インジェクションINFO、およびユーザーエージェントがあり、機能の向上につながります。
o Certain header fields, notably Lines, have been deprecated or made obsolete (Section 3.3).
o 特定のヘッダーフィールド、特にラインは、廃止または時代遅れになっています（セクション3.3）。
o The convention to interpret subjects starting with the word "cmsg" as a control message was removed.
o 「cmsg」という言葉から始まる被験者をコントロールメッセージとして解釈するための条約が削除されました。
o There are numerous other small changes, clarifications, and enhancements.
o 他にも多くの小さな変化、説明、強化があります。
This appendix lists the differences between the syntax allowed by the Netnews article format (this document) as compared to the Internet Message Format, as specified in [RFC5322].
この付録には、[RFC5322]で指定されているように、インターネットメッセージ形式と比較して、NetNewsの記事形式（このドキュメント）で許可された構文の違いをリストしています。
The Netnews article format is a strict subset of the Internet Message Format; all Netnews articles conform to the syntax of [RFC5322].
NetNewsの記事形式は、インターネットメッセージ形式の厳格なサブセットです。すべてのNetNewsの記事は、[RFC5322]の構文に準拠しています。
The following restrictions are important:
次の制限が重要です。
o A SP (space) is REQUIRED after the colon (':') following a header field name.
o ヘッダーフィールド名に続いて、コロン（ '：'）の後にSP（スペース）が必要です。
o A slightly restricted syntax of <msg-id> (to be used by the Message-ID, References, and Supersedes header fields) is defined.
o <MSG-ID>のわずかに制限された構文（メッセージID、参照、およびSuperSedesヘッダーフィールドで使用される）が定義されています。
o The length of a <msg-id> MUST NOT exceed 250 octets.
o a <sg-id>の長さは250オクテットを超えてはなりません。
o Comments are not allowed in the Message-ID header field.
o メッセージ-IDヘッダーフィールドではコメントは許可されていません。
o The CFWS between <msg-id>s in the References header field is not optional.
o 参照ヘッダーフィールドの<sg-id> s間のCFWはオプションではありません。
o It is legal for a parser to reject obsolete syntax, except that:
o パーサーが時代遅れの構文を拒否することは合法ですが、それを除いて：
* The <obs-phrase> construct MUST be accepted.
* <obs-phrase>コンストラクトを受け入れる必要があります。
* The obsolete <zone> "GMT" MUST be accepted within a <date-time>.
* 時代遅れの<Zone>「GMT」は<dateTime>内で受け入れなければなりません。
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 ヘッダーフィールドボディのすべてのライン（最初のものを含むもの、およびその後折り畳まれたもの）には、少なくとも1つの非白文字文字が含まれている必要があります。これは、空のヘッダーフィールドボディが違法であることを意味します。
Authors' Addresses
著者のアドレス
Kenneth Murchison (editor) Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 U.S.A.
ケネスマーチソン（編集者）カーネギーメロン大学5000フォーブスアベニューサイエートホール285ピッツバーグ、ペンシルベニア州15213 U.S.A.
Phone: +1 412 268 2638
EMail: murch@andrew.cmu.edu
Charles H. Lindsey University of Manchester 5 Clerewood Avenue Heald Green Cheadle Cheshire SK8 3JU U.K.
チャールズ・H・リンジー大学マンチェスター大学クレアウッド・アベニューヒールドグリーンチードルチェシャーSK8 3JU英国
Phone: +44 161 436 6131
EMail: chl@clerew.man.ac.uk
Dan Kohn Healing Thresholds 211 N End Ave Apt 22E New York, NY 10282 U.S.A.
Dan Kohn Healing Thresholds 211 N End Ave Apt 22e New York、NY 10282 U.S.A.
Phone: +1 415 233 1000
EMail: dan@dankohn.com