Network Working Group
Request for Comments: 2822
Obsoletes: 822
Obsoleted by: 5322
Updated by: 5335, 5336
Category: Standards Track

P. Resnick, Editor
QUALCOMM Incorporated
April 2001

Internet Message Format
インターネットメッセージの形式

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) The Internet Society (2001). All Rights Reserved.

Abstract
 要約

This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.

「Eメール」メッセージの枠組の中でコンピュータユーザの間に送信されるテキストメッセージのために、この標準は全規則を指定します。この標準は、現在の実行を反映するためにそれを最新のものとし、他のRFCの中で指定された漸増的変化を含んでいて、コメント(RFC)822(「ARPAインターネットテキストメッセージの書式のための標準」)のための要求の中で指定された一方に取って代ります。

Table of Contents
 目次

1. 導入
 1.1. 目的
 1.2. 記号法規約
  1.2.1. 要件記法
  1.2.2. 構文上の表記方法
 1.3. 文書の成り立ち
2. メッセージの語彙の分析
 2.1. 一般的な記述
  2.1.1. 行の長さの制限
 2.2. ヘッダフィールド
  2.2.1. 構造化されないヘッダフィールドボディ
  2.2.2. 構造化されたヘッダフィールドボディ
  2.2.3. 長いヘッダーフィールド
 2.3. ボディ
3. 構文
 3.1. 導入
 3.2. 構文トークン
  3.2.1. 基本的なトークン
  3.2.2. 引用された文字
  3.2.3. foldingしたホワイトスペースとコメント
  3.2.4. 基本文字列
  3.2.5. 引用された文字列
  3.2.6. 雑多なトークン
 3.3. 日時の詳細
 3.4. アドレスの規定
  3.4.1. addr-specの規定
 3.5. 総合的なメッセージの構文
 3.6. フィールドの定義
  3.6.1. もともとの日時のフィールド
  3.6.2. 差出人のフィールド
  3.6.3. 宛先フィールド
  3.6.4. 同一性に関するフィールド
  3.6.5. 情報フィールド
  3.6.6. 再送フィールド
  3.6.7. トレースフィールド
  3.6.8. オプションのフィールド
4. 廃れた構文
 4.1. 種々雑多な廃れたトークン
 4.2. 廃れたfoldingのホワイトスペース
 4.3. 廃れた日時
 4.4. 廃れたアドレス
 4.5. 廃れたヘッダフィールド
  4.5.1. 廃れた創作年月日
  4.5.2. 廃れた創始者分野
  4.5.3. 廃れたアドレス・フィールド
  4.5.4. 廃れた同定(identification)フィールド
  4.5.5. 廃れた情報フィールド
  4.5.6. 廃れた再送フィールド
  4.5.7. 廃れたトレースフィールド
  4.5.8. 廃れた任意フィールド
5. セキュリティに関する考察
6. 図書目録
7. 奥付
8. 承認
Appendix A. メッセージの例
 A.1. アドレス書きの例
  A.1.1. ある人から別の人への、単純なアドレス書きのメッセージ
  A.1.2. 異なる種類のメールボックス
  A.1.3. グループアドレス
 A.2. 返信メッセージ
 A.3. 再送メッセージ
 A.4. トレースフィールドつきメッセージ
 A.5. ホワイトスペース、コメント、その他変なもの
 A.6. 廃れたフォーム
  A.6.1. 廃れたアドレス書き
  A.6.2. 廃れた日時
  A.6.3. 廃れたホワイトスペースとコメント
Appendix B. 古い標準からの変更点
Appendix C. 通知
完全な著作権声明
承認

1. Introduction
 導入

1.1. Scope
 目的

This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages" [RFC822], updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs [STD3].

「Eメール」メッセージの枠組の中でコンピュータユーザの間に送信されるテキストメッセージのために、この標準は全規則を指定します。この標準は、現在の実行を反映するためにそれを最新のものとし、他のRFC[STD3]中で指定された漸増的変化を含んでいて、コメント(RFC)822(「ARPAインターネットテキストメッセージの書式のための標準」[RFC822])のための要求の中で指定された一方に取って代ります。

This standard specifies a syntax only for text messages. In particular, it makes no provision for the transmission of images, audio, or other sorts of structured data in electronic mail messages. There are several extensions published, such as the MIME document series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the transmission of such data through electronic mail, either by extending the syntax provided here or by structuring such messages to conform to this syntax. Those mechanisms are outside of the scope of this standard.

この標準はテキストメッセージのためにだけ全規則を指定します。特に、それはEメールのメッセージの中でイメージ、オーディオ、または他の種類の構造化データの伝送への用意を全然しません。 ここに提供された全規則を拡張すること、またはこの全規則に対応するというそのようなメッセージを構造化することによって、MIME文書シリーズ[RFC 2045RFC 2046、RFC 2049]〈Eメールを通じてそのようなデータの送信するための過程を記述してあります〉など出版されたいくつかの拡張があります。それらの過程はこの標準の範囲の外にあります。

In the context of electronic mail, messages are viewed as having an envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. (See [RFC2821] for a discussion of the envelope.) The contents comprise the object to be delivered to the recipient. This standard applies only to the format and some of the semantics of message contents. It contains no specification of the information in the envelope.

Eメールに関する文脈の中で、メッセージは、封筒と内容を持つこととして見られます。封筒は、送信と配達を遂行するために必要などのような情報でも含んでいます。(封筒の議論のために[RFC2821]を見てください。)内容は、受領者に配達されるオブジェクトから成っています。この標準は書式とメッセージ内容の意味論のいくらかにだけあてはまります。それは封筒の中に情報の仕様を全然含んでいません。

However, some message systems may use information from the contents to create the envelope. It is intended that this standard facilitate the acquisition of such information by programs.

しかし、いくつかのメッセージシステムは、封筒を作成するために内容からの情報を使うかもしれません。この標準がプログラムによるそのような情報の獲得を容易にすることは意図されています。

This specification is intended as a definition of what message content format is to be passed between systems. Though some message systems locally store messages in this format (which eliminates the need for translation between formats) and others use formats that differ from the one specified in this standard, local storage is outside of the scope of this standard.

この仕様は、メッセージ内容フォーマットが、システムの間で通過されることになっているものの定義として意図されています。このフォーマット(フォーマットの間で翻訳が不要になります)中で、いくつかのメッセージシステムがローカルにメッセージを記憶し、他が、この標準の中で指定された一方と異なるフォーマットを使うけれども、ローカル記憶域はこの標準の範囲の外にあります。

Note: This standard is not intended to dictate the internal formats used by sites, the specific message system features that they are expected to support, or any of the characteristics of user interface programs that create or read messages. In addition, this standard does not specify an encoding of the characters for either transport or storage; that is, it does not specify the number of bits used or how those bits are specifically transferred over the wire or stored on disk.

メモ: この標準は、サイト、それらが、サポートすることを期待されている特定のメッセージシステム特徴、またはメッセージを作成するか、読んだユーザインタフェースプログラムの特徴のどれでもによって使われた内部形式を命じることを意図していません。さらに、この標準はトランスポートまたは記憶装置のどちらかのためにキャラクタのエンコーディングを指定しません; すなわちそれは、使われたビット数またはどうそれらのビットがワイヤの上で特に転送されるか、ディスクに記憶されるかを指定しません。

1.2. Notational conventions
 記号法規約

1.2.1. Requirements notation
 要件記法

This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119].

この文書は時々、大文字の中で出現する項を使います。項「MUST」、「SHOULD」、「RECOMMENDED」、「MUST NOT」、「SHOULD NOT」、および「MAY」が大文字で書かれるような時に、それらは、この仕様の特定の必要条件を示すために使われています。これらの項の意味の議論は[RFC2119]にあります。

1.2.2. Syntactic notation
 構文上の表記方法

This standard uses the Augmented Backus-Naur Form (ABNF) notation specified in [RFC2234] for the formal definitions of the syntax of messages. Characters will be specified either by a decimal value (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by a case-insensitive literal value enclosed in quotation marks (e.g., "A" for either uppercase or lowercase A). See [RFC2234] for the full description of the notation.

この標準はメッセージの全規則の形式定義のために[RFC2234]において指定された増大したバッカス・ナウア形式(ABNF)表記法を使います。キャラクタは10進値(例えば大文字のAのための値%のd65と小文字のAのための%のd97)によってまたは引用符(例えば大文字または小文字のどちらかのAのための「A」)で囲まれている大文字小文字を区別しない値によって指定されるでしょう。表記法の完全な説明のために[RFC2234]を見てください。

1.3. Structure of this document
 文書の成り立ち

This document is divided into several sections.

この文書はいくつかのセクションに分かれています。

This section, section 1, is a short introduction to the document.

このセクション、セクション1は文書への短い導入です。

Section 2 lays out the general description of a message and its constituent parts. This is an overview to help the reader understand some of the general principles used in the later portions of this document. Any examples in this section MUST NOT be taken as specification of the formal syntax of any part of a message.

セクション2はメッセージとその成分の概要を広げます。これは、リーダがこの文書の後の方の部分において使われた一般原則のいくつかを理解するのを手助けする概要です。このセクションの中のどのような例もメッセージのどのような部分の形式的なシンタックスの仕様としてもとられてはなりません。

Section 3 specifies formal ABNF rules for the structure of each part of a message (the syntax) and describes the relationship between those parts and their meaning in the context of a message (the semantics). That is, it describes the actual rules for the structure of each part of a message (the syntax) as well as a description of the parts and instructions on how they ought to be interpreted (the semantics). This includes analysis of the syntax and semantics of subparts of messages that have specific structure. The syntax included in section 3 represents messages as they MUST be created. There are also notes in section 3 to indicate if any of the options specified in the syntax SHOULD be used over any of the others.

セクション3はメッセージ(シンタックス)の各部分の構造のために形式的なABNF規則を指定し、メッセージ(意味論)のコンテキストの中のそれらの部分とそれらの意味の間の関係を説明します。どのようにそれらが解釈される(意味論)べきであるかについての部分と指示の説明だけでなくメッセージ(シンタックス)の各部分の構造に、すなわちそれは実際の規則を記述します。これは、特定の構造を持っているメッセージの下位区分の構文と意味の分析を含みます。それらが作成されなければならない時に、セクション3に含められているシンタックスはメッセージを表しています。シンタックスの中で指定されたオプションのいくつかがその他のいくらかの上で使われるべきであるかどうかを示すセクション3中に、また、注があります。

Both sections 2 and 3 describe messages that are legal to generate for purposes of this standard.

この標準の目的のために生成するように、両方のセクション2と3は、正当なメッセージを説明します。

Section 4 of this document specifies an "obsolete" syntax. There are references in section 3 to these obsolete syntactic elements. The rules of the obsolete syntax are elements that have appeared in earlier revisions of this standard or have previously been widely used in Internet messages. As such, these elements MUST be interpreted by parsers of messages in order to be conformant to this standard. However, since items in this syntax have been determined to be non-interoperable or to cause significant problems for recipients of messages, they MUST NOT be generated by creators of conformant messages.

この文書のセクション4は「廃れた」シンタックスを指定します。これらの廃れた構文要素にセクション3中にリファレンスがあります。廃れたシンタックスの規則は、この標準のより早いリビジョンの中で出現したか、以前にインターネットメッセージの中で広く使われているエレメントです。そのようなものとして、これらのエレメントは、conformantであるためのメッセージのパーザによってこの標準に解釈されなければなりません。しかし、このシンタックスの中のアイテムが、相互運用可能でなく、メッセージの受領者のために有意な問題を起こすと決定されていたので、それらはconformantメッセージの創造者によって生成されてはなりません。

Section 5 details security considerations to take into account when implementing this standard.

セクション5はこの規格を実装するとき考慮に入れるセキュリティ問題を詳しく述べます。

Section 6 is a bibliography of references in this document.

セクション6はこの文書の中で参考文献目録です。

Section 7 contains the editor's address.

セクション7では著者の連絡先の記述があります。

Section 8 contains acknowledgements.

セクション8は謝辞です。

Appendix A lists examples of different sorts of messages. These examples are not exhaustive of the types of messages that appear on the Internet, but give a broad overview of certain syntactic forms.

付録Aはメッセージの違う種類の例をリストにします。これらの例は、インターネットに出るメッセージのタイプで徹底的ではないけれども、一定の統語的な形式の広い概要を与えます。

Appendix B lists the differences between this standard and earlier standards for Internet messages.

付録Bはインターネットメッセージのためにこの標準とより早い標準の違いをリストにします。

Appendix C has copyright and intellectual property notices.

付録Cは著作権と知的所有権の通知を持っています。

2. Lexical Analysis of Messages
 メッセージの語彙の分析

2.1. General Description
 一般的な記述

At the most basic level, a message is a series of characters. A message that is conformant with this standard is comprised of characters with values in the range 1 through 127 and interpreted as US-ASCII characters [ASCII]. For brevity, this document sometimes refers to this range of characters as simply "US-ASCII characters".

最も基本のレベルで、メッセージは一連のキャラクタです。この標準を持つconformantであるメッセージは1から127まで範囲の値によってキャラクタから成っていて、米国ASCII文字[ASCII]として解釈されます。簡潔さのために、この文書は時々キャラクタのこの範囲を単に「US-ASCII文字」と称します。

Note: This standard specifies that messages are made up of characters in the US-ASCII range of 1 through 127. There are other documents, specifically the MIME document series [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049], that extend this standard to allow for values outside of that range. Discussion of those mechanisms is not within the scope of this standard.

注意: この標準は、メッセージが1から127のUS-ASCII範囲のキャラクタからなると指定します。他の文書、特に MIME文書シリーズ[RFC2045RFC2046RFC2047、RFC2048、RFC2049] があり、それは、その範囲の外で値を考慮するために、この標準を拡張します。それらの過程の議論はこの標準の範囲の中にありません。

Messages are divided into lines of characters. A line is a series of characters that is delimited with the two characters carriage-return and line-feed; that is, the carriage return (CR) character (ASCII value 13) followed immediately by the line feed (LF) character (ASCII value 10). (The carriage-return/line-feed pair is usually written in this document as "CRLF".)

メッセージは文字の行に分割されます。行は、2文字のキャリッジリターンとラインフィードによって区切られる一連の文字です。すなわちラインフィード(LF)性格(ASCII値10)の後すぐ続いているキャリジリターン(CR)キャラクタ(ASCII値13)。(キャリッジリターン/ラインフィードのペアは「CRLF」としてこの文書では書かれています。)

A message consists of header fields (collectively called "the header of the message") followed, optionally, by a body. The header is a sequence of lines of characters with special syntax as defined in this standard. The body is simply a sequence of characters that follows the header and is separated from the header by an empty line (i.e., a line with nothing preceding the CRLF).

メッセージは、オプションで本文が後に続くヘッダーフィールド(「メッセージのヘッダー」と集合的に呼ばれます)から成ります。この標準の中で定義されるように、ヘッダーは特殊な構文を持つ一連の文字列です。 本文は、ヘッダーに続いていて、空の行(すなわちCRLFしかない行)によってヘッダーから分離される単なる文字列です。

2.1.1. Line Length Limits
 行の長さの制限

There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

この規格が文字の数に並んでいる置く2つの限界があります。 文字列は998未満の文字でなければならず、CRLFを除いて78文字であるべきです。

The 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations which (in compliance with the transport requirements of [RFC2821]) do not accept messages containing more than 1000 character including the CR and LF per line, it is important for implementations not to create such messages.

998文字の限界は、単に、1行が998文字より多くを処理することができないインターネットメッセージフォーマットのメッセージを送り、受け取るか、記憶する多くの実装の中の制限によります。 実装を受けるのは、丈夫さ目的のために並んで任意に多くのキャラクタを扱うために順調でしょう。しかし、([RFC2821]のトランスポート必要条件に従って)、1行あたりCRとLFを含む1000文字より多くを含んでいるメッセージを受信しない多くの実装があり、実装としてそのようなメッセージを作成しないことは重要です。

The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC2821] if they actually cause information to be lost). Again, even though this limitation is put on messages, it is encumbant upon implementations which display messages to handle an arbitrarily large number of characters in a line (certainly at least up to the 998 character limit) for the sake of robustness.

よりひかえめな78文字の勧告は、切り捨てるか、そのような実装が、この仕様(そして、それらが実際情報に、なくされさせるならば[RFC2821]のそれ)の意思へ適合させていないという事実にもかかわらず悲惨にも1行あたり78文字より多くの表示を包むかもしれないこれらのメッセージを表示するユーザインタフェースの多くの実装を適応させることです。 再び、この制限がメッセージに加えられても、それは、頑強性のための行(確かに少なくとも最高998文字までの限界)中で多くの文字を処理するメッセージを表示する実装の重荷です。

2.2. Header Fields
 ヘッダフィールド

Header fields are lines composed of a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon. A field body may be composed of any US-ASCII characters, except for CR and LF. However, a field body may contain CRLF when used in header "folding" and "unfolding" as described in section 2.2.3. All field bodies MUST conform to the syntax described in sections 3 and 4 of this standard.

ヘッダーフィールドはフィールド名から構成されていて、コロン(":")が後に続き、フィールドボディが後に続き、CRLFによって終了させられたラインです。フィールド名は、印刷可能US-ASCII文字(すなわち、包含的に、33から126の間に値を持っているキャラクタ)からコロンを除いて構成されていなければなりません。フィールドボディはCRとLFを除いてどのようなUS-ASCII文字からでも構成されているかもしれません。しかし、ヘッダー「折りたため」中で使われて、セクション2.2.3中で説明されるように「広がる」時に、フィールドボディはCRLFを含むかもしれません。すべてのフィールドボディはこの標準のセクション3と4中で説明されたシンタックスに対応しなければなりません。

2.2.1. Unstructured Header Field Bodies
 構造化されないヘッダフィールドボディ

Some field bodies in this standard are defined simply as "unstructured" (which is specified below as any US-ASCII characters, except for CR and LF) with no further restrictions. These are referred to as unstructured field bodies. Semantically, unstructured field bodies are simply to be treated as a single line of characters with no further processing (except for header "folding" and "unfolding" as described in section 2.2.3).

この標準の中のいくつかのフィールドボディは、単に、「不統一です」(CRとLFを除いてどのようなUS-ASCII文字としてでも下で指定されます)とさらなる制限なしで定義されます。これらは不統一のフィールドボディと称されます。意味で、不統一のフィールドボディは、単に、さらなる処理(ヘッダー「unfolding」とセクション2.2.3中で説明されるような「folding」を除いた)なしでキャラクタの1本のラインとみなされることになっています。

2.2.2. Structured Header Field Bodies
 構造化されたヘッダフィールドボディ

Some field bodies in this standard have specific syntactical structure more restrictive than the unstructured field bodies described above. These are referred to as "structured" field bodies. Structured field bodies are sequences of specific lexical tokens as described in sections 3 and 4 of this standard. Many of these tokens are allowed (according to their syntax) to be introduced or end with comments (as described in section 3.2.3) as well as the space (SP, ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters (together known as the white space characters, WSP), and those WSP characters are subject to header "folding" and "unfolding" as described in section 2.2.3. Semantic analysis of structured field bodies is given along with their syntax.

この標準の中のいくつかのフィールドボディは上で説明された不統一のフィールドボディより制限的な特定の構文上の構造を持っています。 これらは、「構造化されます」フィールドボディと称されます。この標準のセクション3と4中で説明されるように、構造化フィールドボディは特定の字句のシーケンスです。これらのトークンの多くは、導入されるか、スペース(SP、ASCIIの値32)と水平タブ(HTAB、ASCIIの値9)キャラクタ(空白類キャラクタ、WSPとして一緒に知られています)だけでなくコメント(セクション3.2.3中で説明されるような)によって終わることを許されて(それらのシンタックスによると)、それらのWSPキャラクタはヘッダー「折りたため」に主体で、セクション2.2.3中で説明されるように「展開しています」。構造化フィールドボディの意味解析はそれらのシンタックスとともに与えられます。

2.2.3. Long Header Fields
 長いヘッダーフィールド

Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called "folding". The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field:

各ヘッダーフィールドは論理的にフィールド名、コロン、およびフィールドボディから成っているキャラクタの1本のラインです。しかしと1ラインあたり998/78文字の制限を扱うために、便利さのために、ヘッダーフィールドのフィールドのく体部は多数種目表現に分割されることができます; これは「folding」と呼ばれます。一般規則は、たとえ、どこで、この標準が折りたためる空白類(単にWSPキャラクタでない)を考慮しても、CRLFがどのようなWSPの前ででも挿入されるかもしれないことです。例えばヘッダーフィールド:

Subject: This is a test

can be represented as:

次として表現することができます:

Subject: This
 is a test

Note: Though structured field bodies are defined in such a way that folding can take place between many of the lexical tokens (and even within some of the lexical tokens), folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere.

注意: 構造化フィールドボディが、折りたためが字句(そして字句のいくつかの中)さえの多くの間で起こることができるそのような方法で定義されるけれども、折りたためることは、より高レベル統語的な破壊でCRLFを置くことに制限されるべきです。例えば、フィールドボディがカンマで分離された値と定義されるならば、それが他の場所で許されても、フィールドが折りたたまれることができた他の場所についての好みにおいて構造化されたアイテムを区切っているカンマの後で、折りたためが起こることは勧められます。

The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation.

ヘッダーフィールドのこの折りたたまれた複数回線表現からそのシングルライン表現に動くプロセスは「unfolding」と呼ばれます。 広がることは、直ちにWSPが続いているどのようなCRLFでも単に削除することによって遂行されます。フィールドが統語的にさらにその表明された形式において扱われるべきである各ヘッダーと意味論的な評価。

2.3. Body
 ボディ

The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows:

メッセージのボディはUS-ASCII文字の単なる行です。ボディの上のただ2つの制限は次の通りです:

Note: As was stated earlier, there are other standards documents, specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049] that extend this standard to allow for different sorts of message bodies. Again, these mechanisms are beyond the scope of this document.

注意: これ以前に記述しましたが、他の標準文書がある時に、特にMIMEは、本文の違う種類を考慮するために、[RFC2045RFC2046、RFC2048、RFC2049]それがこの標準を拡張します。また、これらの実装はこの文書の範囲を越えています。

3. Syntax
 構文

3.1. Introduction
 導入

The syntax as given in this section defines the legal syntax of Internet messages. Messages that are conformant to this standard MUST conform to the syntax in this section. If there are options in this section where one option SHOULD be generated, that is indicated either in the prose or in a comment next to the syntax.

このセクションの中で与えられるようなシンタックスはインターネットメッセージの正当なシンタックスを定義します。この標準へ準拠したメッセージはこのセクションの中の全規則に対応しなければなりません。1つのオプションが生成されるべきであるこのセクションの中に、オプションがあるならば、それは文章中か構文の横のコメントで示されます。

For the defined expressions, a short description of the syntax and use is given, followed by the syntax in ABNF, followed by a semantic analysis. Primitive tokens that are used but otherwise unspecified come from [RFC2234].

定義された式のために、ABNFにおける全規則が続いていて、意味解析が続いていて、全規則と使用の短い説明は与えられます。使われるけれどもさもなければ、不特定の基本のトークンは[RFC2234]から来ます。

In some of the definitions, there will be nonterminals whose names start with "obs-". These "obs-" elements refer to tokens defined in the obsolete syntax in section 4. In all cases, these productions are to be ignored for the purposes of generating legal Internet messages and MUST NOT be used as part of such a message. However, when interpreting messages, these tokens MUST be honored as part of the legal syntax. In this sense, section 3 defines a grammar for generation of messages, with "obs-" elements that are to be ignored, while section 4 adds grammar for interpretation of messages.

定義のいくつかにおいて、名前が「obs-」によって起動する非端末があるでしょう。これらの「obs-」エレメントはセクション4中の廃れた全規則の中で定義されたトークンを参照します。すべての場合に、これらの製品は、正当なインターネットメッセージを生成する目的のために無視されることになっていて、そのようなメッセージの一部として使われてはなりません。しかし、メッセージを解釈する時に、これらのトークンは正当な全規則の一部として尊重されていなければなりません。この感覚において、無視されることになっている「obs-」エレメントによって、セクション3はメッセージの世代のために文法を定義する一方、セクション4はメッセージの翻訳のために文法を追加します。

3.2. Lexical Tokens
 構文トークン

The following rules are used to define an underlying lexical analyzer, which feeds tokens to the higher-level parsers. This section defines the tokens used in structured header field bodies.

以下の規則は、潜在的な語い解析器を定義するために使われます(それはトークンをより高レベルパーザに入れます)。このセクションは構造化されたヘッダーフィールドボディの中で使われたトークンを定義します。

Note: Readers of this standard need to pay special attention to how these lexical tokens are used in both the lower-level and higher-level syntax later in the document. Particularly, the white space tokens and the comment tokens defined in section 3.2.3 get used in the lower-level tokens defined here, and those lower-level tokens are in turn used as parts of the higher-level tokens defined later. Therefore, the white space and comments may be allowed in the higher-level tokens even though they may not explicitly appear in a particular definition.

注意: この標準の読者は、どうこれらの字句が文書の中で後でより低いレベルとより高レベル全規則の両方において使われるかに特殊な注意を払う必要があります。特に、空白類トークンとセクション3.2.3中で定義されたコメントトークンはここで定義されたより低いレベルのトークンの中で使われて、それらのより低いレベルのトークンは後で定義されたより高レベルトークンの一部として次々使われます。従って、それらが特定の定義の中で明示的に出現してはならなくても、空白類とコメントはより高レベルトークンの中で許されるかもしれません。

3.2.1. Primitive Tokens
 基本的なトークン

The following are primitive tokens referred to elsewhere in this standard, but not otherwise defined in [RFC2234]. Some of them will not appear anywhere else in the syntax, but they are convenient to refer to in other parts of this document.

以下は、この標準の中で他の場所で参照されたけれども[RFC2234]において定義されて、その他の点で差し向けられなかった基本のトークンです。彼らの何人かが全規則の中で他のどこでも出現しないであろうけれども、この文書の他の部分のに差し向けるために、彼らは便利です。

Note: The "specials" below are just such an example. Though the specials token does not appear anywhere else in this standard, it is useful for implementers who use tools that lexically analyze messages. Each of the characters in specials can be used to indicate a tokenization point in lexical analysis.

注意: 下の「specials」はただそのような例です。スペシャルトークンがこの標準の中で他のどこでも出現しないけれども、それは、語彙的に、メッセージを分析するツールを使う実装者に有益です。スペシャルの中のキャラクタのそれぞれは、字句解析の中でトークン化するポイントを示すために使われることができます。

NO-WS-CTL       =       %d1-8 /         ; US-ASCII control characters
                        %d11 /          ;  that do not include the
                        %d12 /          ;  carriage return, line feed,
                        %d14-31 /       ;  and white space characters
                        %d127
    ; CR、LF、および空白類キャラクタを含まないUS-ASCII制御文字


text            =       %d1-9 /         ; Characters excluding CR and LF
                        %d11 /          ; CR,LF以外の文字
                        %d12 /
                        %d14-127 /
                        obs-text

specials        =       "(" / ")" /     ; Special characters used in
                        "<" / ">" /     ;  other parts of the syntax
                        "[" / "]" /     ; この構文の別の箇所で使われる特殊文字
                        ":" / ";" /
                        "@" / "\" /
                        "," / "." /
                        DQUOTE

No special semantics are attached to these tokens. They are simply single characters.

どの特殊な意味論もこれらのトークンに付属しません。彼らは単独の文字です。

3.2.2. Quoted characters
 引用された文字

Some characters are reserved for special interpretation, such as delimiting lexical tokens. To permit use of these characters as uninterpreted data, a quoting mechanism is provided.

いくつかの文字は、字句を区切るなどの特殊な翻訳のために蓄えられます。解釈されていないデータとしてこれらのキャラクタの使用を許すために、引用メカニズムは提供されます。

quoted-pair     =       ("\" text) / obs-qp

Where any quoted-pair appears, it is to be interpreted as the text character alone. That is to say, the "\" character that appears as part of a quoted-pair is semantically "invisible".

どのような引用されたペアでも出現する所で、それは、一人でテキストキャラクタとして解釈されることになっています。すなわち、引用されたペアの一部として表れる「\」キャラクタの意味は「見えない」です。

Note: The "\" character may appear in a message where it is not part of a quoted-pair. A "\" character that does not appear in a quoted-pair is not semantically invisible. The only places in this standard where quoted-pair currently appears are ccontent, qcontent, dcontent, no-fold-quote, and no-fold-literal.

注意: それが引用されたペアの一部ではない所で、「\」キャラクタはメッセージの中で表れることができます。引用されたペアにおいて表れない「\」キャラクタは意味で見えなくありません。引用されるペアが現在出現するこの標準の中の唯一の場所はccontent、qcontent、dcontent、無折りたたみ引用符、および無折りたたみリテラルです。

3.2.3. Folding white space and comments
 foldingしたホワイトスペースとコメント

White space characters, including white space used in folding (described in section 2.2.3), may appear between many elements in header field bodies. Also, strings of characters that are treated as comments may be included in structured field bodies as characters enclosed in parentheses. The following defines the folding white space (FWS) and comment constructs.

folding(セクション2.2.3中で説明されます)において使われた空白類を含む空白類キャラクタはヘッダーフィールドボディの中の多くのエレメントの間で表れることができます。また、コメントとして扱われるキャラクタのストリングは括弧の中で取り囲まれているキャラクタとして構造化フィールドボディに含められているかもしれません。以下は折りたためる空白類(FWS)とコメントのコンストラクトを定義します。

Strings of characters enclosed in parentheses are considered comments so long as they do not appear within a "quoted-string", as defined in section 3.2.5. Comments may nest.

括弧の中で取り囲まれているキャラクタのストリングは、セクション3.2.5中で定義されるように、それらが「引用符で囲まれたストリング」中で出現しない限りコメントと考えられます。コメントは入れ子にするかもしれません。

There are several places in this standard where comments and FWS may be freely inserted. To accommodate that syntax, an additional token for "CFWS" is defined for places where comments and/or FWS can occur. However, where CFWS occurs in this standard, it MUST NOT be inserted in such a way that any line of a folded header field is made up entirely of WSP characters and nothing else.

コメントとFWSが自由に挿入されるかもしれない所に、この標準の中にいくつかの場所があります。その全規則を適応させるために、「CFWS」のための追加のトークンは、コメント、および/またはFWSが起こることができる場所のために定義されます。しかし、CFWSがこの標準に存在している所で、それは、折りたたまれたヘッダーフィールドのどのようなラインも完全にWSPキャラクタ、それだけからなるそのような方法で挿入されてはなりません。

FWS             =       ([*WSP CRLF] 1*WSP) /   ; Folding white space
                        obs-FWS                 ; folding空白類

ctext           =       NO-WS-CTL /     ; Non white space controls
                                        ; 空白類以外の制御文字

                        %d33-39 /       ; The rest of the US-ASCII
                        %d42-91 /       ;  characters not including "(",
                        %d93-126        ;  ")", or "\"
                                        ; 「(」「)」「\」以外のUS-ASCII文字

ccontent        =       ctext / quoted-pair / comment

comment         =       "(" *([FWS] ccontent) [FWS] ")"

CFWS            =       *([FWS] comment) (([FWS] comment) / FWS)

Throughout this standard, where FWS (the folding white space token) appears, it indicates a place where header folding, as discussed in section 2.2.3, may take place. Wherever header folding appears in a message (that is, a header field body containing a CRLF followed by any WSP), header unfolding (removal of the CRLF) is performed before any further lexical analysis is performed on that header field according to this standard. That is to say, any CRLF that appears in FWS is semantically "invisible."

この標準(そこで、FWS(折りたためる空白類トークン)は出現します)にわたって、それは、セクション2.2.3中で議論されるように折りたためているヘッダーが起こるかもしれない場所を示します。たとえ、どこで、メッセージ(すなわちどのようなWSPでも後に続くCRLFを含んでいるヘッダーフィールドボディ)中でヘッダー折りたためが出現しても、さらなる字句解析がこの標準に従ってそのヘッダーフィールドで実行される前に、ヘッダー広がり(CRLFの除去)は実行されます。すなわち、FWSに出るどのようなCRLFでも意味で「見えない」です。

A comment is normally used in a structured field body to provide some human readable informational text. Since a comment is allowed to contain FWS, folding is permitted within the comment. Also note that since quoted-pair is allowed in a comment, the parentheses and backslash characters may appear in a comment so long as they appear as a quoted-pair. Semantically, the enclosing parentheses are not part of the comment; the comment is what is contained between the two parentheses. As stated earlier, the "\" in any quoted-pair and the CRLF in any FWS that appears within the comment are semantically "invisible" and therefore not part of the comment either.

コメントは、ある人の読取り可能の情報のテキストを提供するために構造化フィールドボディの中で正常に使われます。コメントが、FWSを含むことを許されるので、折りたためることはコメントの中で許されます。また、引用されるペアがコメントの中で許されるので、括弧とバックスラッシュキャラクタが、コメントの中で、それらが引用されたペアとして出現するのと同じくらい長いようであるかもしれないことに注意してください。意味で、取り囲んでいる括弧はコメントの一部ではありません; コメントは、2つの括弧の間に含まれているものです。より早く述べられるように、どのような引用されたペアにおけるでも「\」とコメントの中で出現するすべてのFWSにおけるCRLFは意味で「見えない」とコメントの部分でないことです。

Runs of FWS, comment or CFWS that occur between lexical tokens in a structured field header are semantically interpreted as a single space character.

構造化フィールドヘッダーの中の字句の間で起こるFWS、コメント、またはCFWSの実行は1つの空白文字という意味で解釈されます。