RFC822 日本語訳
0822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. D.Crocker. August 1982. (Format: TXT=106299 bytes) (Obsoletes RFC0733) (Obsoleted by RFC2822) (Updated by RFC1123, RFC2156, RFC1327, RFC1138, RFC1148) (Also STD0011) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
RFC # 822
RFC#822
Obsoletes: RFC #733 (NIC #41952)
時代遅れにします: RFC#733(NIC#41952)
STANDARD FOR THE FORMAT OF
形式における標準
ARPA INTERNET TEXT MESSAGES
アルパインターネットテキスト・メッセージ
August 13, 1982
1982年8月13日
Revised by
復習されます。
David H. Crocker
デヴィッド・H.クロッカー
Dept. of Electrical Engineering
University of Delaware, Newark, DE 19711
Network: DCrocker @ UDel-Relay
電気工学デラウエア大学の部、ニューアーク、DE 19711は以下をネットワークでつなぎます。 DCrocker@UDel-リレー
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
TABLE OF CONTENTS
目次
PREFACE .................................................... ii
PREFACE… ii
1. INTRODUCTION ........................................... 1
1. 序論… 1
1.1. Scope ............................................ 1
1.2. Communication Framework .......................... 2
1.1. 範囲… 1 1.2. コミュニケーションフレームワーク… 2
2. NOTATIONAL CONVENTIONS ................................. 3
2. 記号法のコンベンション… 3
3. LEXICAL ANALYSIS OF MESSAGES ........................... 5
3. メッセージの字句解析… 5
3.1. General Description .............................. 5
3.2. Header Field Definitions ......................... 9
3.3. Lexical Tokens ................................... 10
3.4. Clarifications ................................... 11
3.1. 一般記述… 5 3.2. ヘッダーフィールド定義… 9 3.3. 字句… 10 3.4. 明確化… 11
4. MESSAGE SPECIFICATION .................................. 17
4. メッセージ仕様… 17
4.1. Syntax ........................................... 17
4.2. Forwarding ....................................... 19
4.3. Trace Fields ..................................... 20
4.4. Originator Fields ................................ 21
4.5. Receiver Fields .................................. 23
4.6. Reference Fields ................................. 23
4.7. Other Fields ..................................... 24
4.1. 構文… 17 4.2. 転送します。 19 4.3. 野原をたどってください… 20 4.4. 創始者分野… 21 4.5. 受信機分野… 23 4.6. 参照分野… 23 4.7. 他の分野… 24
5. DATE AND TIME SPECIFICATION ............................ 26
5. 日時の仕様… 26
5.1. Syntax ........................................... 26
5.2. Semantics ........................................ 26
5.1. 構文… 26 5.2. 意味論… 26
6. ADDRESS SPECIFICATION .................................. 27
6. 仕様を扱ってください… 27
6.1. Syntax ........................................... 27
6.2. Semantics ........................................ 27
6.3. Reserved Address ................................. 33
6.1. 構文… 27 6.2. 意味論… 27 6.3. アドレスを予約します… 33
7. BIBLIOGRAPHY ........................................... 34
7. 図書目録… 34
APPENDIX
付録
A. EXAMPLES ............................................... 36
B. SIMPLE FIELD PARSING ................................... 40
C. DIFFERENCES FROM RFC #733 .............................. 41
D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44
A.の例… 36 B.の簡単な分野構文解析… 40 RFC#733からのC.差… 41 構文のD.アルファベット順のリストは統治されます… 44
August 13, 1982 - i - RFC #822
1982年8月13日--i--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
PREFACE
序文
By 1977, the Arpanet employed several informal standards for
the text messages (mail) sent among its host computers. It was
felt necessary to codify these practices and provide for those
features that seemed imminent. The result of that effort was
Request for Comments (RFC) #733, "Standard for the Format of ARPA
Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
The specification attempted to avoid major changes in existing
software, while permitting several new features.
1977年までには、Arpanetはホストコンピュータの中で送られたテキスト・メッセージ(メール)のいくつかの非公式の規格を使いました。 これらの習慣を成文化して、差し迫っているように見えたそれらの特徴に備えるのは必要であると感じられました。 その取り組みの結果はComments(RFC)#733のためのRequestでした、「アーパネットテキストメッセージの形式において標準です」、クロッカー、Vittal、Pogran、およびヘンダーソンで。 仕様は、いくつかの新機能を可能にしている間、既存のソフトウェアにおける大きな変化を避けるのを試みました。
This document revises the specifications in RFC #733, in
order to serve the needs of the larger and more complex ARPA
Internet. Some of RFC #733's features failed to gain adequate
acceptance. In order to simplify the standard and the software
that follows it, these features have been removed. A different
addressing scheme is used, to handle the case of inter-network
mail; and the concept of re-transmission has been introduced.
このドキュメントはRFC#733で仕様を改訂します、より大きくて、より複雑なARPAインターネットの必要性に役立つように。 RFC#733の特徴のいくつかが適切な承認を獲得しませんでした。 それに続く規格とソフトウェアを簡素化するために、これらの特徴を取り除いてあります。 異なったアドレシング体系はインターネットワークメールに関するケースを扱うのに使用されます。 そして、再トランスミッションの概念は紹介されました。
This specification is intended for use in the ARPA Internet.
However, an attempt has been made to free it of any dependence on
that environment, so that it can be applied to other network text
message systems.
この仕様はARPAインターネットでの使用のために意図します。 しかしながら、その環境へのどんな依存についてもそれを解放するのを試みをしました、他のネットワークテキストメッセージシステムにそれを適用できるように。
The specification of RFC #733 took place over the course of
one year, using the ARPANET mail environment, itself, to provide
an on-going forum for discussing the capabilities to be included.
More than twenty individuals, from across the country, partici-
pated in the original discussion. The development of this
revised specification has, similarly, utilized network mail-based
group discussion. Both specification efforts greatly benefited
from the comments and ideas of the participants.
1年のコース、アルパネットメール環境を使用する上でRFC#733の仕様は、含まれるべき能力について議論するのに継続しているフォーラムを提供するためにそれ自体で行われました。 20以上、国中からのオリジナルの議論における個人partici- pated。 この訂正明細書の開発は同様にネットワークのメールベースの集団討議を利用しました。 両方の仕様取り組みは大いに関係者のコメントと考えの利益を得ました。
The syntax of the standard, in RFC #733, was originally
specified in the Backus-Naur Form (BNF) meta-language. Ken L.
Harrenstien, of SRI International, was responsible for re-coding
the BNF into an augmented BNF that makes the representation
smaller and easier to understand.
RFC#733では、規格の構文は元々、BN記法(BNF)メタ言語で指定されました。 SRIインターナショナルのケンL.Harrenstienは、より小さくて、表現をより簡単にさせる増大しているBNFへのBNFを再コード化するのに理解している責任がありました。
August 13, 1982 - ii - RFC #822
1982年8月13日--ii--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
1. INTRODUCTION
1. 序論
1.1. SCOPE
1.1. 範囲
This standard specifies a syntax for text messages that are
sent among computer users, within the framework of "electronic
mail". The standard supersedes the one specified in ARPANET
Request for Comments #733, "Standard for the Format of ARPA Net-
work Text Messages".
この規格は「電子メール」のフレームワークの中でコンピュータユーザの中で送られるテキスト・メッセージに構文を指定します。 規格はアルパネットRequestでComments#733に指定されたものに取って代わります、「ARPAネット仕事Text MessagesのFormatにおいて、標準です」。
In this context, messages are viewed as having an envelope
and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. The contents
compose the object to be delivered to the recipient. This stan-
dard applies only to the format and some of the semantics of mes-
sage contents. It contains no specification of the information
in the envelope.
このような関係においては、メッセージは封筒とコンテンツを持っていると見なされます。 封筒はトランスミッションと配送を実行するのに必要であるどんな情報も含んでいます。 内容は受取人に提供されるオブジェクトを構成します。 このstan- dardは形式とmesの賢人のコンテンツの意味論のいくつかだけに適用されます。 それは封筒に情報の仕様を全く含んでいません。
However, some message systems may use information from the
contents to create the envelope. It is intended that this stan-
dard facilitate the acquisition of such information by programs.
しかしながら、いくつかのメッセージシステムが、封筒を作成するのにコンテンツからの情報を使用するかもしれません。 このstan- dardがプログラムによるそのような情報の獲得を容易にすることを意図します。
Some message systems may store messages in formats that
differ from the one specified in this standard. This specifica-
tion is intended strictly as a definition of what message content
format is to be passed BETWEEN hosts.
いくつかのメッセージシステムがこの規格で指定されたものと異なっている形式におけるメッセージを保存するかもしれません。 このspecifica- tionは、どんなメッセージ内容形式の定義がBETWEENホストに渡されることであるかので、厳密に意図します。
Note: This standard is NOT intended to dictate the internal for-
mats used by sites, the specific message system features
that they are expected to support, or any of the charac-
teristics of user interface programs that create or read
messages.
以下に注意してください。 この規格が内部を書き取ることを意図しない、-、メッセージを作成するか、または読むユーザーインタフェースプログラムのcharac- teristicsのサイトによって使用されるマット、それらがサポートすると予想される特定のメッセージシステム機能、またはいずれも。
A distinction should be made between what the specification
REQUIRES and what it ALLOWS. Messages can be made complex and
rich with formally-structured components of information or can be
kept small and simple, with a minimum of such information. Also,
the standard simplifies the interpretation of differing visual
formats in messages; only the visual aspect of a message is
affected and not the interpretation of information within it.
Implementors may choose to retain such visual distinctions.
そして、ことの間で区別をするべきである、仕様REQUIRES、何、それ、ALLOWS。 メッセージを情報の正式に構造化された成分に複雑で豊かに作ることができるか、または小さく簡単に保つことができます、最小そのような情報で。 また、規格はメッセージにおける、異なった視覚形式の解釈を簡素化します。 メッセージの視覚局面だけが影響を受けますが、それの中の情報の解釈は影響を受けません。 作成者は、そのような視覚区別を保有するのを選ぶかもしれません。
The formal definition is divided into four levels. The bot-
tom level describes the meta-notation used in this document. The
second level describes basic lexical analyzers that feed tokens
to higher-level parsers. Next is an overall specification for
messages; it permits distinguishing individual fields. Finally,
there is definition of the contents of several structured fields.
公式の定義は4つのレベルに分割されます。 ウマバエの幼虫雄ネコレベルは本書では使用されるメタ記法を説明します。 第2レベルは、よりハイレベルのパーサにトークンを提供する基本的な語彙分析器について説明します。 次に、メッセージのための総合的な仕様があります。 それは、個々の分野を区別することを許可します。 最終的に、いくつかの構造化された分野のコンテンツの定義があります。
August 13, 1982 - 1 - RFC #822
1982年8月13日--1--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
1.2. COMMUNICATION FRAMEWORK
1.2. コミュニケーションフレームワーク
Messages consist of lines of text. No special provisions
are made for encoding drawings, facsimile, speech, or structured
text. No significant consideration has been given to questions
of data compression or to transmission and storage efficiency,
and the standard tends to be free with the number of bits con-
sumed. For example, field names are specified as free text,
rather than special terse codes.
メッセージはテキストの系列から成ります。 特別条項は、全く図面、ファクシミリ、スピーチ、または構造化されたテキストをコード化するために作られていません。 データ圧縮の質問、または、トランスミッションと充てん率に対してどんな重要な考慮も払っていません、そして、規格はビットまやかしの数がsumedされている状態で自由である傾向があります。 例えば、フィールド名は特別な簡潔なコードよりむしろ無料のテキストとして指定されます。
A general "memo" framework is used. That is, a message con-
sists of some information in a rigid format, followed by the main
part of the message, with a format that is not specified in this
document. The syntax of several fields of the rigidly-formated
("headers") section is defined in this specification; some of
these fields must be included in all messages.
一般的な「メモ」フレームワークは使用されています。 すなわち、本書では指定されない形式があるメッセージの主部があとに続いた堅い形式の何らかの情報のメッセージまやかしsists。 厳格にformatedされた(「ヘッダー」)セクションのいくつかの分野の構文はこの仕様に基づき定義されます。 すべてのメッセージにこれらの分野のいくつかを含まなければなりません。
The syntax that distinguishes between header fields is
specified separately from the internal syntax for particular
fields. This separation is intended to allow simple parsers to
operate on the general structure of messages, without concern for
the detailed structure of individual header fields. Appendix B
is provided to facilitate construction of these parsers.
ヘッダーフィールドを見分ける構文は別々に内部の構文から特定の分野に指定されます。 この分離が、簡単なパーサがメッセージの一般構造体を作動させるのを許容することを意図します、個々のヘッダーフィールドの詳細な構造に関する心配なしで。 これらのパーサの工事を容易にするために付録Bを提供します。
In addition to the fields specified in this document, it is
expected that other fields will gain common use. As necessary,
the specifications for these "extension-fields" will be published
through the same mechanism used to publish this document. Users
may also wish to extend the set of fields that they use
privately. Such "user-defined fields" are permitted.
本書では指定された分野に加えて、他の分野が一般の使用を獲得すると予想されます。 必要に応じて、これらの「拡大分野」のための仕様はこのドキュメントを発表するのに使用される同じメカニズムを通して発表されるでしょう。 また、ユーザはそれらが個人的に使用する分野のセットを広げたがっているかもしれません。 そのような「ユーザによって定義された分野」は受入れられます。
The framework severely constrains document tone and appear-
ance and is primarily useful for most intra-organization communi-
cations and well-structured inter-organization communication.
It also can be used for some types of inter-process communica-
tion, such as simple file transfer and remote job entry. A more
robust framework might allow for multi-font, multi-color, multi-
dimension encoding of information. A less robust one, as is
present in most single-machine message systems, would more
severely constrain the ability to add fields and the decision to
include specific fields. In contrast with paper-based communica-
tion, it is interesting to note that the RECEIVER of a message
can exercise an extraordinary amount of control over the
message's appearance. The amount of actual control available to
message receivers is contingent upon the capabilities of their
individual message systems.
フレームワークは、厳しくドキュメントトーンを抑制して、anceに見えて、主として最もイントラ組織communi陽イオンの、そして、よく構造化された相互組織コミュニケーションの役に立ちます。 また、相互プロセスcommunica- tionの何人かのタイプにそれを使用できます、簡単なファイル転送やリモートジョブエントリのように。 より強健なフレームワークはマルチフォント、情報のマルチ色の、そして、マルチ寸法のコード化を考慮するかもしれません。 ほとんどの単一マシンメッセージシステムでのプレゼントのように、それほど強健でない人は、より厳しく、分野を加える能力と特定の分野を含んでいるという決定を抑制するでしょう。 紙のベースのcommunica- tionと比べて、メッセージのRECEIVERが並はずれた量のコントロールをメッセージの外観に及ぼすことができることに注意するのはおもしろいです。 メッセージ受信機に利用可能な実際のコントロールの量がそれらの個々のメッセージシステムの能力次第であります。
August 13, 1982 - 2 - RFC #822
1982年8月13日--2--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
2. NOTATIONAL CONVENTIONS
2. 記号法のコンベンション
This specification uses an augmented Backus-Naur Form (BNF)
notation. The differences from standard BNF involve naming rules
and indicating repetition and "local" alternatives.
この仕様は増大しているBN記法(BNF)記法を使用します。 標準のBNFからの違いは、規則を命名して、反復と「地方」の代替手段を示すことを伴います。
2.1. RULE NAMING
2.1. 規則命名
Angle brackets ("<", ">") are not used, in general. The
name of a rule is simply the name itself, rather than "<name>".
Quotation-marks enclose literal text (which may be upper and/or
lower case). Certain basic rules are in uppercase, such as
SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in
rule definitions, and in the rest of this document, whenever
their presence will facilitate discerning the use of rule names.
一般に、角ブラケット("<"、">")は使用されません。 規則の名前は単に「<名前>」よりむしろ名前自体です。 引用符は文字通りのテキスト(上側の、そして/または、低いケースであるかもしれない)を同封します。 SPACE、TAB、CRLF、DIGIT、アルファーなどの大文字には、ある基本的なルールがあります。 角ブラケットは規則定義、およびこのドキュメントの残りに使用されます、それらの存在が、規則名の使用について明察するのを容易にするときはいつも。
2.2. RULE1 / RULE2: ALTERNATIVES
2.2. RULE1 / RULE2: 代替手段
Elements separated by slash ("/") are alternatives. There-
fore "foo / bar" will accept foo or bar.
スラッシュ(「/」)によって切り離された要素は代替手段です。 そこでは、前面の「foo/バー」がfooかバーを受け入れるでしょう。
2.3. (RULE1 RULE2): LOCAL ALTERNATIVES
2.3. (RULE1 RULE2): ローカルの代替手段
Elements enclosed in parentheses are treated as a single
element. Thus, "(elem (foo / bar) elem)" allows the token
sequences "elem foo elem" and "elem bar elem".
括弧に同封された要素はただ一つの要素として扱われます。 したがって、「(elem(foo/バー)elem)」はトークン系列"elem foo elem"と「elemバーelem」を許容します。
2.4. *RULE: REPETITION
2.4. *以下を統治してください。 反復
The character "*" preceding an element indicates repetition.
The full form is:
要素に先行するキャラクタ「*」は反復を示します。 完全形は以下の通りです。
<l>*<m>element
<l>*<m>要素
indicating at least <l> and at most <m> occurrences of element.
Default values are 0 and infinity so that "*(element)" allows any
number, including zero; "1*element" requires at least one; and
"1*2element" allows one or two.
少なくとも<l>とほとんどの<mでは、要素の>発生を示します。 「デフォルト値が0であり、無限がそう、それ、」 *、(要素) 」 ゼロを含むどんな数も許容します。 「1*要素」は少なくとも1を必要とします。 そして、「1*2element」は1か2を許容します。
2.5. [RULE]: OPTIONAL
2.5. [規則]: 任意
Square brackets enclose optional elements; "[foo bar]" is
equivalent to "*1(foo bar)".
角括弧は随意的な要素を同封します。 「「[fooバー]」は」 *1(fooバー)に同等です。」
2.6. NRULE: SPECIFIC REPETITION
2.6. NRULE: 特定の反復
"<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit
number, and 3ALPHA is a string of three alphabetic characters.
「<n>(要素)」は「<n>*<n>(要素)」に同等です。 すなわち、まさに(要素)の<n>発生。 したがって、2DIGITは2桁数です、そして、3ALPHAは一連の3つの英字です。
August 13, 1982 - 3 - RFC #822
1982年8月13日--3--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
2.7. #RULE: LISTS
2.7. #以下を統治してください。 リスト
A construct "#" is defined, similar to "*", as follows:
構造物「#」は、以下の通り「*」と定義されていて、同様です:
<l>#<m>element
<l>#<m>要素
indicating at least <l> and at most <m> elements, each separated
by one or more commas (","). This makes the usual form of lists
very easy; a rule such as '(element *("," element))' can be shown
as "1#element". Wherever this construct is used, null elements
are allowed, but do not contribute to the count of elements
present. That is, "(element),,(element)" is permitted, but
counts as only two elements. Therefore, where at least one ele-
ment is required, at least one non-null element must be present.
Default values are 0 and infinity so that "#(element)" allows any
number, including zero; "1#element" requires at least one; and
"1#2element" allows one or two.
少なくとも<l>と高々<m>を示して、要素でありそれぞれが1つ以上のコンマで分離した、(「」、) これで、普通の形式のリストは非常に簡単になります。 aが統治する、'、(要素*、(「」、要素) '「1#要素」として示すことができます。 この構造物が中古であって、どこでも、ヌルであるところでは、要素が許容されていますが、要素の現在のカウントに貢献しないでください。 すなわち、「(要素)、(要素) 」 受入れられますが、2つの要素だけにみなします。 したがって、少なくとも1ele- mentが必要であるところでは、少なくとも1つの非ヌル要素が存在していなければなりません。 「デフォルト値が0であり、無限がそう、それ、」 #、(要素) 」 ゼロを含むどんな数も許容します。 「1#要素」は少なくとも1を必要とします。 そして、「1#2element」は1か2を許容します。
2.8. ; COMMENTS
2.8. ; コメント
A semi-colon, set off some distance to the right of rule
text, starts a comment that continues to the end of line. This
is a simple way of including useful notes in parallel with the
specifications.
規則テキストの右への何らかの距離に引きたったセミコロンは行末に続くコメントを始めます。 これは仕様と平行して役に立つ注意を含む簡単な方法です。
August 13, 1982 - 4 - RFC #822
1982年8月13日--4--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
3. LEXICAL ANALYSIS OF MESSAGES
3. メッセージの字句解析
3.1. GENERAL DESCRIPTION
3.1. 概説
A message consists of header fields and, optionally, a body.
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).
メッセージはヘッダーフィールドと任意にボディーから成ります。 ボディーは単にASCII charac- tersを含む系列の系列です。 空行(すなわち、何もCRLFに先行していない系列)によってそれはヘッダーと切り離されます。
3.1.1. LONG HEADER FIELDS
3.1.1. 長いヘッダーフィールド
Each header field can be viewed as a single, logical line of
ASCII characters, comprising a field-name and a field-body.
For convenience, the field-body portion of this conceptual
entity can be split into a multiple-line representation; this
is called "folding". The general rule is that wherever there
may be linear-white-space (NOT simply LWSP-chars), a CRLF
immediately followed by AT LEAST one LWSP-char may instead be
inserted. Thus, the single line
シングル、ASCII文字の論理行、フィールド名を包括して、および分野本体として各ヘッダーフィールドを見なすことができます。 便利において、この概念的な実体の分野本体部分を複数の線表現に分けることができます。 これは「折りたたみである」と呼ばれます。 直線的な余白(単にLWSP-雑用でない)があるかもしれません、とCRLFがすぐにどこで1つがLWSP炭にするAT LEASTで続いたとしても代わりに挿入されるかもしれない一般的な規則があります。 その結果、単線
To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
To: 「ジョーとJ.ハーヴェイ」<ddd@Org>、JJV@BBN
can be represented as:
以下として表すことができます。
To: "Joe & J. Harvey" <ddd @ Org>,
JJV@BBN
To: 「ジョーとJ.ハーヴェイ」<ddd@Org>、 JJV@BBN
and
そして
To: "Joe & J. Harvey"
<ddd@ Org>, JJV
@BBN
To: 「ジョーとJ.ハーヴェイ」<ddd@Org>、JJV@BBN
and
そして
To: "Joe &
J. Harvey" <ddd @ Org>, JJV @ BBN
To: 「ジョーとJ.ハーヴェイ」<ddd@Org>、JJV@BBN
The process of moving from this folded multiple-line
representation of a header field to its single line represen-
tation is called "unfolding". Unfolding is accomplished by
regarding CRLF immediately followed by a LWSP-char as
equivalent to the LWSP-char.
ヘッダーフィールドのこの折り重ねられた複数の線表現から単線represen- tationまで動く過程は「開き」と呼ばれます。 開きは、LWSP-炭に同じくらい同等なLWSP-炭がすぐにあとに続いたCRLFを見なすことによって、実行されます。
Note: While the standard permits folding wherever linear-
white-space is permitted, it is recommended that struc-
tured fields, such as those containing addresses, limit
folding to higher-level syntactic breaks. For address
fields, it is recommended that such folding occur
以下に注意してください。 規格は、どこでも、直線的な余白が受入れられるところに折り重なることを許可しますが、アドレスを含むものなどのstruc- tured分野が折り重なりをよりハイレベルの構文の中断に制限するのは、お勧めです。 アドレス・フィールドにおいて、そのような折り重なりが起こるのは、お勧めです。
August 13, 1982 - 5 - RFC #822
1982年8月13日--5--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
between addresses, after the separating comma.
分離コンマの後のアドレスの間で。
3.1.2. STRUCTURE OF HEADER FIELDS
3.1.2. ヘッダーフィールドの構造
Once a field has been unfolded, it may be viewed as being com-
posed of a field-name followed by a colon (":"), followed by a
field-body, and terminated by a carriage-return/line-feed.
The field-name must be composed of printable ASCII characters
(i.e., characters that have values between 33. and 126.,
decimal, except colon). The field-body may be composed of any
ASCII characters, except CR or LF. (While CR and/or LF may be
present in the actual text, they are removed by the action of
unfolding the field.)
分野がいったん繰り広げられると、それがコロンがあとに続いたフィールド名についてポーズをとられたcomであるとして見なされるかもしれない、(「:」、)、分野本体であとに続かれて、a復帰/改行で終えられます。 印刷可能なASCII文字(すなわち、コロンを除いて、33と126.、小数の間に値を持っているキャラクタ)でフィールド名を構成しなければなりません。 分野本体はCRかLF以外のどんなASCII文字でも構成されるかもしれません。 (CR、そして/または、LFが実際のテキストに存在しているかもしれない間、分野を繰り広げる動作でそれらを取り除きます。)
Certain field-bodies of headers may be interpreted according
to an internal syntax that some systems may wish to parse.
These fields are called "structured fields". Examples
include fields containing dates and addresses. Other fields,
such as "Subject" and "Comments", are regarded simply as
strings of text.
いくつかのシステムが分析したがっているかもしれない内部の構文によると、ヘッダーのある分野ボディーは解釈されるかもしれません。 これらの分野は「構造化された分野」と呼ばれます。 例は日付とアドレスを含む分野を含んでいます。 「対象」や「コメント」などの他の分野は単にテキストのストリングと見なされます。
Note: Any field which has a field-body that is defined as
other than simply <text> is to be treated as a struc-
tured field.
以下に注意してください。 単に<テキスト>のように定義される分野本体を持っているどんな分野もstruc- tured分野として扱われることです。
Field-names, unstructured field bodies and structured
field bodies each are scanned by their own, independent
"lexical" analyzers.
フィールド名、不統一な分野本体、およびそれぞれ構造化された分野本体はそれら自身のによってスキャンされて、独立者は「語彙」の分析器です。
3.1.3. UNSTRUCTURED FIELD BODIES
3.1.3. 不統一な分野本体
For some fields, such as "Subject" and "Comments", no struc-
turing is assumed, and they are treated simply as <text>s, as
in the message body. Rules of folding apply to these fields,
so that such field bodies which occupy several lines must
therefore have the second and successive lines indented by at
least one LWSP-char.
「対象」や「コメント」などのいくつかの分野において、struc- turingは全く想定されません、そして、それらは単に<テキスト>sとして扱われます、メッセージ本体のように。 折り重なりの規則はこれらの分野に適用されます、したがって、いくつかの線を占領するそのような分野本体が2番目を持たなければならなくて、少なくとも1時までにギザギザを付けられた連続した線がLWSP焦げるように。
3.1.4. STRUCTURED FIELD BODIES
3.1.4. 構造化された分野本体
To aid in the creation and reading of structured fields, the
free insertion of linear-white-space (which permits folding
by inclusion of CRLFs) is allowed between lexical tokens.
Rather than obscuring the syntax specifications for these
structured fields with explicit syntax for this linear-white-
space, the existence of another "lexical" analyzer is assumed.
This analyzer does not apply for unstructured field bodies
that are simply strings of text, as described above. The
analyzer provides an interpretation of the unfolded text
構造化された分野の創造と読書で支援するために、直線的な余白(CRLFsの包含で折り重なることを許可する)の無料の挿入は字句の間に許容されています。 明白な構文でこれらの構造化された分野のための構文仕様をこの直線的に白いスペースにあいまいにするよりむしろ、別の「語彙」の分析器の存在は想定されます。 この分析器は上で説明されるように単にテキストのストリングである不統一な分野本体に申し込みません。 分析器は繰り広げられたテキストの解釈を提供します。
August 13, 1982 - 6 - RFC #822
1982年8月13日--6--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
composing the body of the field as a sequence of lexical sym-
bols.
語彙sym- bolsの系列として分野のボディーを構成します。
These symbols are:
これらのシンボルは以下の通りです。
- individual special characters
- quoted-strings
- domain-literals
- comments
- atoms
- 個々の特殊文字--引用文字列--ドメイン誤字誤植--コメント--原子
The first four of these symbols are self-delimiting. Atoms
are not; they are delimited by the self-delimiting symbols and
by linear-white-space. For the purposes of regenerating
sequences of atoms and quoted-strings, exactly one SPACE is
assumed to exist, and should be used, between them. (Also, in
the "Clarifications" section on "White Space", below, note the
rules about treatment of multiple contiguous LWSP-chars.)
これらの4つの最初のシンボルは自己区切りです。 原子はそうではありません。 それらは自己を区切るシンボルと直線的な余白によって区切られます。 原子と引用文字列の系列を作り直す目的のために、ちょうど1SPACEが存在すると思われて、使用されるべきです、それらの間で。 (また、「余白」の「明確化」セクションで、以下では、複数の隣接のLWSP-雑用の処理に関する規則に注意してください。)
So, for example, the folded body of an address field
そう、例えば、アドレス・フィールドの折り重ねられたボディー
":sysmail"@ Some-Group. Some-Org,
Muhammed.(I am the greatest) Ali @(the)Vegas.WBA
「: sysmail」@、-いくつか、分類してください。 いくつか、-、Org、マホメット(私は最も偉大です)アリ@(the)Vegas.WBA
August 13, 1982 - 7 - RFC #822
1982年8月13日--7--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
is analyzed into the following lexical symbols and types:
以下の語彙シンボルとタイプに分析されます:
:sysmail quoted string
@ special
Some-Group atom
. special
Some-Org atom
, special
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ atom
(the) comment
Vegas atom
. special
WBA atom
:sysmailの引用文字列の@の特別なSome-グループ原子特別なマホメット原子特別な(私は最も偉大である)コメントのアリ原子@原子(the)コメントヴェガス原子特別なSome-Org原子、特別なWBA原子
The canonical representations for the data in these addresses
are the following strings:
これらのアドレスのデータの正準な表現は以下のストリングです:
":sysmail"@Some-Group.Some-Org
「: sysmail」@Some-Group.Some-Org
and
そして
Muhammed.Ali@Vegas.WBA
Muhammed.Ali@Vegas.WBA
Note: For purposes of display, and when passing such struc-
tured information to other systems, such as mail proto-
col services, there must be NO linear-white-space
between <word>s that are separated by period (".") or
at-sign ("@") and exactly one SPACE between all other
<word>s. Also, headers should be in a folded form.
以下に注意してください。 表示の目的と他のシステム、メールprotoなどのあん部サービスにそのようなstruc- tured情報を通過して、いつ、直線的に切り離された<単語>sの間の白いスペースの期間が全くあるはずがないか、(「」、)、サインの("@")とまさに他のすべての<の間のあるスペースが>sを言い表します。 また、ヘッダーが折り重ねられたフォームにあるべきです。
August 13, 1982 - 8 - RFC #822
1982年8月13日--8--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
3.2. HEADER FIELD DEFINITIONS
3.2. ヘッダーフィールド定義
These rules show a field meta-syntax, without regard for the
particular type or internal syntax. Their purpose is to permit
detection of fields; also, they present to higher-level parsers
an image of each field as fitting on one line.
これらの規則は特定のタイプか内部の構文への尊敬なしで分野メタ構文を示しています。 それらの目的は分野の検出を可能にすることです。 また、彼らは1つの線に合うとしてそれぞれの分野のイメージをよりハイレベルのパーサに提示します。
field = field-name ":" [ field-body ] CRLF
「分野=フィールド名」:、」 [分野本体] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
「」 : CTLsを除いたどんなCHAR、SPACE、および">"というフィールド名=1*<。
field-body = field-body-contents
[CRLF LWSP-char field-body]
分野本体=分野ボディーコンテンツ[CRLF LWSP-炭の分野本体]
field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>
分野ボディーコンテンツは分野本体を作るASCII文字の<と等しいです、原子、引用文字列、および特別番組象徴の組み合わせ、またはテキスト>から成るのから以下のセクションで定義して、成るとして
August 13, 1982 - 9 - RFC #822
1982年8月13日--9--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
3.3. LEXICAL TOKENS
3.3. 字句
The following rules are used to define an underlying lexical
analyzer, which feeds tokens to higher level parsers. See the
ANSI references, in the Bibliography.
以下の規則は、基本的な語彙分析器を定義するのに使用されます。(分析器は、より高い平らなパーサに象徴を提供します)。 BibliographyのANSI参照を見てください。
; ( Octal, Decimal.)
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 42, 34.)
CRLF = CR LF
; (8進、小数。) CHARが<と等しい、どんなASCII文字>も。 ( 0-177, 0.-127.) アルファーが<と等しい、どんなASCII英字>も。 (101-132, 65.- 90.) ; (141-172, 97.-122.) DIGITが<と等しい、どんなASCII10進数字>も。 ( 60- 71, 48.- 57.) CTLはどんなASCIIも制御する<と等しいです。 ( 0- 37, 0.- 31.) キャラクタとDEL>。 ( 177, 127.) CRは<ASCII CR、復帰>と等しいです。 ( 15, 13.) LFは<ASCII LF、ラインフィード>と等しいです。 ( 12, 10.) SPACEは<ASCII SP、スペース>と等しいです。 ( 40, 32.) HTABは<ASCII HT、水平タブ>と等しいです。 ( 11, 9.) <「>=<ASCII引用符>」。 ( 42, 34.) CRLFはCR LFと等しいです。
LWSP-char = SPACE / HTAB ; semantics = SPACE
LWSP-炭はスペース/HTABと等しいです。 意味論はSPACEと等しいです。
linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
; CRLF => folding
直線的な余白=1*([CRLF]LWSP-炭)。 意味論はSPACEと等しいです。 CRLFは>の折り重なりと等しいです。
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
特別番組は「(「/」)」/"<"/">"/"@"と等しいです。 「引用されたコネが/であったに違いないなら」」 /、」、;、」 / ":" /「\」/<">"。 「使用/に結ぶ」、」 / "[" / "]" ; 単語の中で。
delimiters = specials / linear-white-space / comment
デリミタは直線的な特別番組/余白/コメントと等しいです。
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
テキストは<とどんなCHARで、包含むき出しでも等しいです。 =しかし、>原子、特別番組、CR、およびむき出しのLF、NOT。 コメントとCRLF>を含んでいます。 引用文字列はそうです。 認識されません。
atom = 1*<any CHAR except specials, SPACE and CTLs>
原子=1*<は特別番組、SPACE、およびCTLs>以外のあらゆるCHARです。
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
引用文字列=<、「>*(引用されたqtext/組の)<">" または、通常のqtext、。 雑用を引用しました。
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
qtextが<と等しい、<を除いたどんなCHAR、も「>、」、。 =>は折り重ねられた「\」と、CRと、直線的な余白>を含むことであるかもしれません。
domain-literal = "[" *(dtext / quoted-pair) "]"
「[「*(引用されたdtext/組の)」]」というドメイン文字通りの=
August 13, 1982 - 10 - RFC #822
1982年8月13日--10--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
dtextは<のどんなCHAR「[「;= >が折り重ねられるかもしれない 」]」という除外、「\」、およびCR、そして、も含んでいる直線的な余白>と等しいです。
comment = "(" *(ctext / quoted-pair / comment) ")"
「(「*(引用されたctext/組の/コメント)」)」というコメント=
ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>
ctextは<のどんなCHAR「(「;= >が折り重ねられるかもしれない 」)」という除外、「\」、およびCR、そして、も含んでいる直線的な余白>と等しいです。
quoted-pair = "\" CHAR ; may quote any char
引用された組は「\」炭と等しいです。 どんな炭も引用するかもしれません。
phrase = 1*word ; Sequence of words
=1*単語を言葉で表してください。 単語の続き
word = atom / quoted-string
単語=原子/引用文字列
3.4. CLARIFICATIONS
3.4. 明確化
3.4.1. QUOTING
3.4.1. 引用
Some characters are reserved for special interpretation, such
as delimiting lexical tokens. To permit use of these charac-
ters as uninterpreted data, a quoting mechanism is provided.
To quote a character, precede it with a backslash ("\").
字句を区切ることなどの特別な解釈のために予約されるキャラクタもあります。 非解釈されたデータとしてのcharac- ters、引用メカニズムをこれらの使用に可能にするのを提供します。 キャラクタを引用するには、バックスラッシュ(「\」)でそれに先行してください。
This mechanism is not fully general. Characters may be quoted
only within a subset of the lexical constructs. In particu-
lar, quoting is limited to use within:
このメカニズムは完全に一般的であるというわけではありません。 キャラクターは語彙構造物の部分集合だけの中で引用されるかもしれません。 particu- larでは、引用は以下の中で使用に制限されます。
- quoted-string
- domain-literal
- comment
- 引用文字列(ドメイン文字通りである)はコメントします。
Within these constructs, quoting is REQUIRED for CR and "\"
and for the character(s) that delimit the token (e.g., "(" and
")" for a comment). However, quoting is PERMITTED for any
character.
そして、引用がCRと「\」と象徴を区切るキャラクタのためのこれらの構造物の中では、REQUIREDである、(例えば、「(「」、)、」、コメント) しかしながら、引用はどんなキャラクタのためのPERMITTEDです。
Note: In particular, quoting is NOT permitted within atoms.
For example when the local-part of an addr-spec must
contain a special character, a quoted string must be
used. Therefore, a specification such as:
以下に注意してください。 特に、引用は原子の中で受入れられません。例えば、addr-仕様の地方の部分が特殊文字を含まなければならないとき、引用文字列を使用しなければなりません。 したがって、以下などの仕様
Full\ Name@Domain
完全な\ Name@Domain
is not legal and must be specified as:
法的でなく、指定しなければなりません:
"Full Name"@Domain
「フルネーム」@Domain
August 13, 1982 - 11 - RFC #822
1982年8月13日--11--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
3.4.2. WHITE SPACE
3.4.2. 余白
Note: In structured field bodies, multiple linear space ASCII
characters (namely HTABs and SPACEs) are treated as
single spaces and may freely surround any symbol. In
all header fields, the only place in which at least one
LWSP-char is REQUIRED is at the beginning of continua-
tion lines in a folded field.
以下に注意してください。 構造化された分野本体では、複数の直線的な宇宙ASCIIキャラクタ(すなわち、HTABsとSPACEs)が、シングルスペースとして扱われて、自由にどんなシンボルも囲むかもしれません。 すべてのヘッダーフィールドでは、連続tionの始めに、LWSP-炭が少なくともどれのREQUIREDであるかがある唯一の場所が折り重ねられた分野に立ち並んでいます。
When passing text to processes that do not interpret text
according to this standard (e.g., mail protocol servers), then
NO linear-white-space characters should occur between a period
(".") or at-sign ("@") and a <word>. Exactly ONE SPACE should
be used in place of arbitrary linear-white-space and comment
sequences.
間にテキストを通過するとき、これに従って標準(例えば、メールプロトコルサーバ)と、次に、直線的な空白類文字でテキストの機械言語に翻訳処理をしない過程に期間が起こっているべきである、(「」、)、サインの("@")と<は>を言い表します。 ちょうどONE SPACEは任意の直線的な余白とコメント系列に代わって使用されるべきです。
Note: Within systems conforming to this standard, wherever a
member of the list of delimiters is allowed, LWSP-chars
may also occur before and/or after it.
以下に注意してください。 また、デリミタのリストのメンバーがどこに許容されていてもこの規格に一致しているシステムの中では、LWSP-雑用はそれの前それの後に起こるかもしれません。
Writers of mail-sending (i.e., header-generating) programs
should realize that there is no network-wide definition of the
effect of ASCII HT (horizontal-tab) characters on the appear-
ance of text at another network host; therefore, the use of
tabs in message headers, though permitted, is discouraged.
メールを送る(すなわち、ヘッダー発生)プログラムの作家が、ASCII HT(水平タブ)キャラクタの効果のどんなネットワーク全体の進行中の定義もないとわかるべきである、別のネットワークホストのテキストのanceに見える、。 したがって、受入れられますが、メッセージヘッダーにおけるタブの使用はお勧めできないです。
3.4.3. COMMENTS
3.4.3. コメント
A comment is a set of ASCII characters, which is enclosed in
matching parentheses and which is not within a quoted-string
The comment construct permits message originators to add text
which will be useful for human readers, but which will be
ignored by the formal semantics. Comments should be retained
while the message is subject to interpretation according to
this standard. However, comments must NOT be included in
other cases, such as during protocol exchanges with mail
servers.
コメントはASCII文字のセットです。(そのセットは、合っている括弧に同封されて、引用文字列に中コメント構造物が人間の読者の役に立ちますが、正式な意味論によって無視されるテキストを加えることをメッセージ創始者に許可するありません)。 この規格に従ってメッセージは解釈を受けることがある間、コメントが保有されるべきです。 しかしながら、メールサーバによるプロトコル交換などの他のケースにコメントを含んではいけません。
Comments nest, so that if an unquoted left parenthesis occurs
in a comment string, there must also be a matching right
parenthesis. When a comment acts as the delimiter between a
sequence of two lexical symbols, such as two atoms, it is lex-
ically equivalent with a single SPACE, for the purposes of
regenerating the sequence, such as when passing the sequence
onto a mail protocol server. Comments are detected as such
only within field-bodies of structured fields.
また、引用を終わっている左括弧がコメントストリングに起こるなら、合っている右括弧があるに違いないように、巣について論評します。 2つの原子などの2つの語彙記号の系列の間のデリミタとしてのコメント条例であるときに、それは独身のSPACEによってicallyに同等な法です、系列を作り直す目的のために、メールプロトコルサーバに系列を通過して. コメントが構造化された分野の分野本体だけの中にそういうものとして検出される時のように。
If a comment is to be "folded" onto multiple lines, then the
syntax for folding must be adhered to. (See the "Lexical
コメントが複数の線ににされる」「折り重ねことであるなら、折り重ねのための構文を固く守らなければなりません。 (「語彙」を見てください。
August 13, 1982 - 12 - RFC #822
1982年8月13日--12--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
Analysis of Messages" section on "Folding Long Header Fields"
above, and the section on "Case Independence" below.) Note
that the official semantics therefore do not "see" any
unquoted CRLFs that are in comments, although particular pars-
ing programs may wish to note their presence. For these pro-
grams, it would be reasonable to interpret a "CRLF LWSP-char"
as being a CRLF that is part of the comment; i.e., the CRLF is
kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a
backslash followed by a CR followed by a LF) still must be
followed by at least one LWSP-char.
上の「折りたたみの長いヘッダーフィールド」の「Messagesの分析」セクション、および以下の「ケース独立」のセクション。) したがって、公式の意味論が「見てください」でないのにいずれもするというメモはコメント中であることのCRLFsに引用を終わらせました、特定のパーingプログラムがそれらの存在に注意したがっているかもしれませんが。 これらの親グラムに、コメントの一部であるCRLFであるとして「CRLF LWSP-炭」を解釈するのは妥当でしょう。 すなわち、CRLFは保たれます、そして、LWSP-炭は捨てられます。 少なくとも1つはまだ、LWSP焦げた状態で引用されたCRLFs(すなわち、LFによって続かれたCRによって従われたバックスラッシュ)のあとに続かなければなりません。
3.4.4. DELIMITING AND QUOTING CHARACTERS
3.4.4. キャラクタを区切って、引用します。
The quote character (backslash) and characters that delimit
syntactic units are not, generally, to be taken as data that
are part of the delimited or quoted unit(s). In particular,
the quotation-marks that define a quoted-string, the
parentheses that define a comment and the backslash that
quotes a following character are NOT part of the quoted-
string, comment or quoted character. A quotation-mark that is
to be part of a quoted-string, a parenthesis that is to be
part of a comment and a backslash that is to be part of either
must each be preceded by the quote-character backslash ("\").
Note that the syntax allows any character to be quoted within
a quoted-string or comment; however only certain characters
MUST be quoted to be included as data. These characters are
the ones that are not part of the alternate text group (i.e.,
ctext or qtext).
一般に、区切られたか引用されたユニットの一部であるデータとして取るために、引用文字(バックスラッシュ)と構文のユニットを区切るキャラクタはありません。 引用文字列を定義する引用符、コメントを定義する括弧、および次のキャラクタを引用するバックスラッシュは特に、引用されたストリング、コメントまたは引用されたキャラクタの一部ではありません。 引用文字バックスラッシュ(「\」)はそれぞれ、引用文字列の一部であることになっている引用符、コメントの一部であることになっている挿入句、およびどちらかの一部であることになっているバックスラッシュに先行しなければなりません。 構文が、どんなキャラクタも引用文字列かコメントの中で引用されるのを許容することに注意してください。 しかしながら、データとして含まれるように確信しているキャラクタだけを引用しなければなりません。 これらのキャラクタは交互のテキストグループ(すなわち、ctextかqtext)の一部でないものです。
The one exception to this rule is that a single SPACE is
assumed to exist between contiguous words in a phrase, and
this interpretation is independent of the actual number of
LWSP-chars that the creator places between the words. To
include more than one SPACE, the creator must make the LWSP-
chars be part of a quoted-string.
この規則への1つの例外は独身のSPACEが隣接の単語の間にひと口に言えば存在すると思われるということです、そして、この解釈は創造者が単語の間に置くLWSP-雑用の実数から独立しています。 1SPACEを含むように、創造者は、LWSP雑用が引用文字列の一部であることを作らなければなりません。
Quotation marks that delimit a quoted string and backslashes
that quote the following character should NOT accompany the
quoted-string when the string is passed to processes that do
not interpret data according to this specification (e.g., mail
protocol servers).
ストリングがこの仕様(例えば、メールプロトコルサーバ)通りにデータの機械言語に翻訳処理をしない過程に渡されるとき、引用文字列を区切る引用符と以下のキャラクタを引用するバックスラッシュは引用文字列に伴うべきではありません。
3.4.5. QUOTED-STRINGS
3.4.5. 引用文字列
Where permitted (i.e., in words in structured fields) quoted-
strings are treated as a single symbol. That is, a quoted-
string is equivalent to an atom, syntactically. If a quoted-
string is to be "folded" onto multiple lines, then the syntax
for folding must be adhered to. (See the "Lexical Analysis of
受入れられる(すなわち、構造化された分野の単語による)ところでは、引用されたストリングがただ一つのシンボルとして扱われます。 すなわち、引用されたストリングはシンタクス上原子に同等です。 引用されたストリングが複数の線ににされる」「折り重ねことであるなら、折り重ねのための構文を固く守らなければなりません。 (見る、「字句解析、」
August 13, 1982 - 13 - RFC #822
1982年8月13日--13--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
Messages" section on "Folding Long Header Fields" above, and
the section on "Case Independence" below.) Therefore, the
official semantics do not "see" any bare CRLFs that are in
quoted-strings; however particular parsing programs may wish
to note their presence. For such programs, it would be rea-
sonable to interpret a "CRLF LWSP-char" as being a CRLF which
is part of the quoted-string; i.e., the CRLF is kept and the
LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol-
lowed by a CR followed by a LF) are also subject to rules of
folding, but the presence of the quoting character (backslash)
explicitly indicates that the CRLF is data to the quoted
string. Stripping off the first following LWSP-char is also
appropriate when parsing quoted CRLFs.
上の「折りたたみの長いヘッダーフィールド」の「メッセージ」セクション、および以下の「ケース独立」のセクション。) したがって、公式の意味論は引用文字列にあるいくつかのむき出しのCRLFsを「見ません」。 しかしながら、特定の構文解析プログラムはそれらの存在に注意したがっているかもしれません。 そのようなプログラムのために、それはそうするでしょう。引用文字列の一部であるCRLFであるとして「CRLF LWSP-炭」を解釈するrea- sonableになってください。 すなわち、CRLFは保たれます、そして、LWSP-炭は捨てられます。 また、引用されたCRLFs(すなわち、CRによるfol- lowedがLFを続けたバックスラッシュ)も折り重なりの規則を受けることがありますが、引用しているキャラクタ(バックスラッシュ)の存在は、CRLFが引用文字列へのデータであることを明らかに示します。 また、構文解析がCRLFsを引用したとき、最初の次のLWSP-炭を全部はぎ取るのも適切です。
3.4.6. BRACKETING CHARACTERS
3.4.6. 大括弧のキャラクタ
There is one type of bracket which must occur in matched pairs
and may have pairs nested within each other:
互角のペアで起こらなければならなくて、互いの中で組を入れ子にするかもしれない1つのタイプのブラケットがあります:
o Parentheses ("(" and ")") are used to indicate com-
ments.
o そして、括弧、(「(「」、)、」、)、com- mentsを示すために、使用されます。
There are three types of brackets which must occur in matched
pairs, and which may NOT be nested:
互角のペアで起こらなければならなくて、入れ子にされないかもしれない3つのタイプの括弧があります:
o Colon/semi-colon (":" and ";") are used in address
specifications to indicate that the included list of
addresses are to be treated as a group.
o そして、「コロン/セミコロン、(「:」、」、;、」、)、示すグループとして扱われるために含まれている住所録があるアドレス指定では、使用されます。
o Angle brackets ("<" and ">") are generally used to
indicate the presence of a one machine-usable refer-
ence (e.g., delimiting mailboxes), possibly including
source-routing to the machine.
o 一般に、角ブラケット("<"と">")はマシン使用可能なものの存在がenceを参照するのを示すのに使用されます(例えば、メールボックスを区切ります)、ことによるとマシンにソースで掘るのを含んでいて。
o Square brackets ("[" and "]") are used to indicate the
presence of a domain-literal, which the appropriate
name-domain is to use directly, bypassing normal
name-resolution mechanisms.
o そして、角括弧、(「[「」、]、」、)、使用されている、ドメイン文字通りでaの存在を示してください、適切な名前ドメインが直接使用することになっているもの、正常な名前解決メカニズムを迂回させて。
3.4.7. CASE INDEPENDENCE
3.4.7. ケース独立
Except as noted, alphabetic strings may be represented in any
combination of upper and lower case. The only syntactic units
注意されるのを除いて、欧字列は大文字と小文字のどんな組み合わせでも表されるかもしれません。 唯一の構文のユニット
August 13, 1982 - 14 - RFC #822
1982年8月13日--14--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
which requires preservation of case information are:
どれがケース情報の保存を必要とするかによるである:
- text
- qtext
- dtext
- ctext
- quoted-pair
- local-part, except "Postmaster"
- テキスト--qtext--dtext--「郵便局長」を除いた、地方の部分のctext(引用された組)
When matching any other syntactic unit, case is to be ignored.
For example, the field-names "From", "FROM", "from", and even
"FroM" are semantically equal and should all be treated ident-
ically.
いかなる他の構文のユニットも合わせるとき、ケースは無視されることです。 例えば、フィールド名の“From"、“FROM"、“from"、および“FroM"さえ意味的に等しく、すべて、扱われたident- icallyであるべきです。
When generating these units, any mix of upper and lower case
alphabetic characters may be used. The case shown in this
specification is suggested for message-creating processes.
これらのユニットを発生させるとき、大文字と小文字英字のどんなミックスも使用されるかもしれません。 この仕様で見せられたケースはメッセージ作成過程のために示されます。
Note: The reserved local-part address unit, "Postmaster", is
an exception. When the value "Postmaster" is being
interpreted, it must be accepted in any mixture of
case, including "POSTMASTER", and "postmaster".
以下に注意してください。 「郵便局長」という予約された地方の部分アドレスユニットは例外です。 値の「郵便局長」を解釈しているとき、「郵便局長」、および「郵便局長」を含むケースのどんな混合物の中にもそれを受け入れなければなりません。
3.4.8. FOLDING LONG HEADER FIELDS
3.4.8. 折りたたみの長いヘッダーフィールド
Each header field may be represented on exactly one line con-
sisting of the name of the field and its body, and terminated
by a CRLF; this is what the parser sees. For readability, the
field-body portion of long header fields may be "folded" onto
multiple lines of the actual field. "Long" is commonly inter-
preted to mean greater than 65 or 72 characters. The former
length serves as a limit, when the message is to be viewed on
most simple terminals which use simple display software; how-
ever, the limit is not imposed by this standard.
各ヘッダーフィールドは、分野とそのボディーの名前をsistingしながらまさに1つの線まやかしの上に表されて、CRLFによって終えられるかもしれません。 これはパーサが見るものです。 読み易さにおいて、長いヘッダーフィールドの分野本体部分は実際の分野の複数の線に「折り重ねられるかもしれません」。 「長い」であることは、65か72よりすばらしいことを意味するために相互一般的にpretedされたキャラクタです。 前の長さは限界として機能します、メッセージが簡単な表示ソフトウェアを使用するほとんどの簡単な端末で見られることであるときに。 どのように、-、かつて、限界はこの規格によって課されないか。
Note: Some display software often can selectively fold lines,
to suit the display terminal. In such cases, sender-
provided folding can interfere with the display
software.
以下に注意してください。 何らかの表示ソフトウェアが、ディスプレー装置に合うようにしばしば選択的に線を折り重ねることができます。 そのような場合、送付者の提供された折り重なりは表示ソフトウェアを妨げることができます。
3.4.9. BACKSPACE CHARACTERS
3.4.9. 後退文字
ASCII BS characters (Backspace, decimal 8) may be included in
texts and quoted-strings to effect overstriking. However, any
use of backspaces which effects an overstrike to the left of
the beginning of the text or quoted-string is prohibited.
ASCII BSキャラクタ、(バックスペースキーを押して印字位置を一字分戻ってください、そして、10進8は)テキストと引用文字列で効果「過剰-打撃」に含められてもよいです。 しかしながら、いずれも使用する、バックスペースキー、どれが重ね打ちにテキストか引用文字列の始まりの左まで作用するかは禁止されています。
August 13, 1982 - 15 - RFC #822
1982年8月13日--15--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS
3.4.10. ネットワーク特有の変化
During transmission through heterogeneous networks, it may be
necessary to force data to conform to a network's local con-
ventions. For example, it may be required that a CR be fol-
lowed either by LF, making a CRLF, or by <null>, if the CR is
to stand alone). Such transformations are reversed, when the
message exits that network.
異機種ネットワークを通したトランスミッションの間、データをネットワークの地方のまやかしventionsに従わせるのが必要であるかもしれません。 例えば、CRがCRLFを作るLFか<のヌル>によるfol- lowedであることが必要であるかもしれません、CRが単独で立つつもりであるなら) メッセージがそのネットワークを出るとき、そのような変化は逆にされます。
When crossing network boundaries, the message should be
treated as passing through two modules. It will enter the
first module containing whatever network-specific transforma-
tions that were necessary to permit migration through the
"current" network. It then passes through the modules:
ネットワーク限界に交差するとき、メッセージは2つのモジュールを通り抜けるとして扱われるべきです。 それはどんな「現在」のネットワークを通した移動を可能にするのに必要であったネットワーク特有のtransforma- tionsも含む最初のモジュールに入るでしょう。 次に、それはモジュールを通り抜けます:
o Transformation Reversal
o 変化反転
The "current" network's idiosyncracies are removed and
the message is returned to the canonical form speci-
fied in this standard.
「現在、」 ネットワークの特異性を移して、この規格で標準形speci- fiedにメッセージを返します。
o Transformation
o 変化
The "next" network's local idiosyncracies are imposed
on the message.
「次」のネットワークの地方の特異性はメッセージに課されます。
------------------
From ==> | Remove Net-A |
Net-A | idiosyncracies |
------------------
||
\/
Conformance
with standard
||
\/
------------------
| Impose Net-B | ==> To
| idiosyncracies | Net-B
------------------
------------------ =>から| ネットのAを取り除いてください。| ネットのA| 特異性| ------------------ || 規格がある\/順応|| \/ ------------------ | ネットのBを課してください。| ==>。| 特異性| ネットのB------------------
August 13, 1982 - 16 - RFC #822
1982年8月13日--16--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
4. MESSAGE SPECIFICATION
4. メッセージ仕様
4.1. SYNTAX
4.1. 構文
Note: Due to an artifact of the notational conventions, the syn-
tax indicates that, when present, some fields, must be in
a particular order. Header fields are NOT required to
occur in any particular order, except that the message
body must occur AFTER the headers. It is recommended
that, if present, headers be sent in the order "Return-
Path", "Received", "Date", "From", "Subject", "Sender",
"To", "cc", etc.
以下に注意してください。 記号法のコンベンションの人工物のため、syn税はそれを示します、プレゼント(いくつかの分野)が特定のオーダーにあるに違いないとき。 ヘッダーフィールドは起こるのが必要でないことで、メッセージ本体が起こらなければならないのを除いて、どんな事項でも、ヘッダーのAFTERが注文しているということです。 「リターン経路」は、「デートしてください」と「受けました」、“From"、「受けることがある」という注文、「送付者」、“To"、「cc」などでヘッダーを存在しているなら送るのはお勧めです。
This specification permits multiple occurrences of most
fields. Except as noted, their interpretation is not
specified here, and their use is discouraged.
この仕様はほとんどの分野の複数の発生を可能にします。 注意される以外に、彼らの解釈はここで指定されません、そして、彼らの使用はお勧めできないです。
The following syntax for the bodies of various fields should
be thought of as describing each field body as a single long
string (or line). The "Lexical Analysis of Message" section on
"Long Header Fields", above, indicates how such long strings can
be represented on more than one line in the actual transmitted
message.
多岐のボディーのための以下の構文はそれぞれの分野本体をただ一つのロング・ストリングとして記述すると考えられるべきです(立ち並んでください)。 「長いヘッダーフィールド」の「メッセージの字句解析」セクションは上で実際の伝えられたメッセージの1つ以上の線の上にどうそのようなロング・ストリングを表すことができるかを示します。
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
メッセージ=は*(CRLF*テキスト)をさばきます。 後のすべて。 最初の空行。 メッセージ本体です。
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
分野=日付。 創造時間、ソース。 イドと1つ1の*目的地を書いてください。 アドレスは*任意の分野を必要としました。 他のもの、任意
source = [ trace ] ; net traversals
originator ; original mail
[ resent ] ; forwarded
ソースは[跡]と等しいです。 ネットの縦断創始者。 オリジナルのメール[憤慨します]。 転送されます。
trace = return ; path to sender
1*received ; receipt tags
跡はリターンと等しいです。 送付者1*への経路は受信されました。 領収書タグ
return = "Return-path" ":" route-addr ; return address
「リターンは「リターンパス」と等しい」:、」 ルート-addr。 返送先
received = "Received" ":" ; one per relay
["from" domain] ; sending host
["by" domain] ; receiving host
["via" atom] ; physical path
*("with" atom) ; link/mail protocol
["id" msg-id] ; receiver msg id
["for" addr-spec] ; initial form
「容認された=は「受信」だった」:、」 ; リレー[“from"ドメイン]あたり1つ。 送付ホスト[“by"ドメイン]。 受信ホスト[原子「を通した」の]。 物理的な経路*(“with"原子)。 リンク/メールプロトコル[「イド」msg-イド]。 受信機msgイド[“for" addr-仕様]。 初期のフォーム
August 13, 1982 - 17 - RFC #822
1982年8月13日--17--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
";" date-time ; time received
";" 日付-時間。 受付時刻
originator = authentic ; authenticated addr
[ "Reply-To" ":" 1#address] )
創始者=正統。 「addr[」 : 」 1#アドレスに「答える」)を認証します。
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
; or not sender
「正統の=“From"」:、」 メールボックス。 「作者/を選抜してください、(「送付者、」 」 : 」 メールボックス;、実際のsubmittor “From"、」 : 」 1#メールボックス、)、。 複数の作者。 または、送付者でない
resent = resent-authentic
[ "Resent-Reply-To" ":" 1#address] )
「=に憤慨してください、憤慨、-、正統である、[「回答に憤慨する、」 」 : 」 1#アドレス、)
resent-authentic =
= "Resent-From" ":" mailbox
/ ( "Resent-Sender" ":" mailbox
"Resent-From" ":" 1#mailbox )
「憤慨、-、正統である、=が等しい、「憤慨、-、」、」、:、」 メールボックス/「(「送付者に憤慨する、」 」 : 」 メールボックス、「憤慨、-、」 」 : 」 1#メールボックス、)
dates = orig-date ; Original
[ resent-date ] ; Forwarded
orig日付=日付。 オリジナル[日付に憤慨している]。 転送されます。
orig-date = "Date" ":" date-time
「orig「日付」と=の日付を入れてください」:、」 日付-時間
resent-date = "Resent-Date" ":" date-time
「日付に憤慨する、= 「-再送して、デートしてください」、」、:、」 日付-時間
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
「目的地=“To"」:、」 1#アドレス。 「予備選挙/、「憤慨、-、」、」、:、」 「1#アドレス/「cc」」:、」 1#アドレス。 「2番目/、「ccに憤慨する、」、」、:、」 「1#アドレス/"bcc"」:、」 #アドレス。 「盲目の炭素/「-bccに再送」であっていた」:、」 #アドレス
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
「任意の分野の=/「Message ID」」:、」 「msgイド/、「Message IDに憤慨してください」、」、:、」 「msgイド/、「に対して」、」、:、」 *(msg句/イド) 「/「参照」」:、」 *(msg句/イド) 「/「キーワード」」:、」 #「句/「対象」」:、」 *「テキスト/「コメント」」:、」 *「テキスト/「コード化」にされる」:、」 拡大1#2word/分野。 定義された/ユーザ定義された分野になるように。 先取りされるかもしれません。
msg-id = "<" addr-spec ">" ; Unique message id
msg-イドは">"という"<"addr-仕様と等しいです。 ユニークなメッセージイド
August 13, 1982 - 18 - RFC #822
1982年8月13日--18--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
Anyがさばくドキュメントで定義される拡大分野=<は正式な拡大としてこの仕様に発行されました。 なにもひもで始まる名前を持たない、「X">"
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
ユーザの定義された分野はAnyがさばくこの仕様に基づき定義されないか、または拡大としてこの仕様に発行されていない<と等しいです。 そのような分野への名前は、ユニークでなければならなく、発行された拡大>によって先取りされるかもしれません。
4.2. FORWARDING
4.2. 推進
Some systems permit mail recipients to forward a message,
retaining the original headers, by adding some new fields. This
standard supports such a service, through the "Resent-" prefix to
field names.
いくつかのシステムが、いくつかの新しい分野を加えることによってオリジナルのヘッダーを保有して、メール受取人がメッセージを転送するのを可能にします。 この規格は「再送された」という接頭語を通したそのようなサービスをフィールド名に支持します。
Whenever the string "Resent-" begins a field name, the field
has the same semantics as a field whose name does not have the
prefix. However, the message is assumed to have been forwarded
by an original recipient who attached the "Resent-" field. This
new field is treated as being more recent than the equivalent,
original field. For example, the "Resent-From", indicates the
person that forwarded the message, whereas the "From" field indi-
cates the original author.
「再送された」ストリングがフィールド名を始めるときはいつも、分野には名前に接頭語がない分野と同じ意味論があります。 しかしながら、メッセージは「再送された」という分野を付けたオリジナルの受取人によって進められたと思われます。 この新しい分野は同等で、元の分野より最近として扱われます。 例えば、「憤慨、-、」、“From"がindiにオリジナルが書く美味をさばきますが、メッセージを転送した人を示します。
Use of such precedence information depends upon partici-
pants' communication needs. For example, this standard does not
dictate when a "Resent-From:" address should receive replies, in
lieu of sending them to the "From:" address.
そのような先行情報の使用は喘ぎのコミュニケーションが必要とするparticiによります。 aであるときに、例えば、この規格が決めない、「From:に憤慨する、」 「From:」にそれらを送ることの代わりにアドレスは回答を受け取るべきです。 アドレス。
Note: In general, the "Resent-" fields should be treated as con-
taining a set of information that is independent of the
set of original fields. Information for one set should
not automatically be taken from the other. The interpre-
tation of multiple "Resent-" fields, of the same type, is
undefined.
以下に注意してください。 一般に、「再送された」という分野は、1セットの元の分野のセットから独立している情報をtainingしながら、まやかしとして扱われるべきです。 もう片方から個人的には設定された情報を自動的に取るべきではありません。 「再送された」という複数の分野、同じタイプのinterpre- tationは未定義です。
In the remainder of this specification, occurrence of legal
"Resent-" fields are treated identically with the occurrence of
中に、この仕様の残り、「再送された」という法的な分野の発生は同様に発生と共に扱われます。
August 13, 1982 - 19 - RFC #822
1982年8月13日--19--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
fields whose names do not contain this prefix.
名前がこの接頭語を含まない分野。
4.3. TRACE FIELDS
4.3. 跡の分野
Trace information is used to provide an audit trail of mes-
sage handling. In addition, it indicates a route back to the
sender of the message.
トレース情報は、mesの賢人の取り扱いの監査証跡を提供するのに使用されます。 さらに、それはルートをメッセージ送信者に示して戻します。
The list of known "via" and "with" values are registered
with the Network Information Center, SRI International, Menlo
Park, California.
知られることのリスト、「」 “with"を通して、値はNetworkインフォメーション・センター、SRIインターナショナル、メンローパーク、カリフォルニアに示されます。
4.3.1. RETURN-PATH
4.3.1. リターンパス
This field is added by the final transport system that
delivers the message to its recipient. The field is intended
to contain definitive information about the address and route
back to the message's originator.
この分野はメッセージを受取人に送る最終的な輸送システムによって加えられます。 分野がアドレスとルートの決定的な情報をメッセージの創始者に含んで戻すことを意図します。
Note: The "Reply-To" field is added by the originator and
serves to direct replies, whereas the "Return-Path"
field is used to identify a path back to the origina-
tor.
以下に注意してください。 」 分野に答えてください。「創始者によって言い足されて、「リターンパス」分野はorigina- torに経路を特定して戻すのに使用されますが、回答を指示するのに勤めます。
While the syntax indicates that a route specification is
optional, every attempt should be made to provide that infor-
mation in this field.
構文が、ルート仕様が任意であることを示している間、そのinfor- mationをこの分野に提供するように最善の努力をするべきです。
4.3.2. RECEIVED
4.3.2. 受信します。
A copy of this field is added by each transport service that
relays the message. The information in the field can be quite
useful for tracing transport problems.
この分野のコピーはメッセージをリレーする各輸送サービスで加えられます。 その分野の情報はかなり追跡輸送問題の役に立つ場合があります。
The names of the sending and receiving hosts and time-of-
receipt may be specified. The "via" parameter may be used, to
indicate what physical mechanism the message was sent over,
such as Arpanet or Phonenet, and the "with" parameter may be
used to indicate the mail-, or connection-, level protocol
that was used, such as the SMTP mail protocol, or X.25 tran-
sport protocol.
名前、-ホストと時間を送って、得て、領収書では、指定されるかもしれなくなってください。 パラメタ「を通して」では、メッセージがどんな物理的なメカニズムに送られたかを示すのに使用されるかもしれません、ArpanetやPhonenetのように、そして、“with"パラメタは、メール、または接続がSMTPメールプロトコルなどのように使用されたプロトコルかX.25 tranスポーツプロトコルを平らにするのを示すのに使用されるかもしれません。
Note: Several "with" parameters may be included, to fully
specify the set of protocols that were used.
以下に注意してください。 いくつかの“with"パラメタが、使用されたプロトコルのセットを完全に指定するために含まれるかもしれません。
Some transport services queue mail; the internal message iden-
tifier that is assigned to the message may be noted, using the
"id" parameter. When the sending host uses a destination
address specification that the receiving host reinterprets, by
いくつかの輸送サービスがメールを列に並ばせます。 「イド」パラメタを使用して、メッセージに割り当てられる社内通信文iden- tifierは注意されるかもしれません。 送付ホストが受信ホストが解釈し直す目的地アドレス指定を使用する場合
August 13, 1982 - 20 - RFC #822
1982年8月13日--20--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
expansion or transformation, the receiving host may wish to
record the original specification, using the "for" parameter.
For example, when a copy of mail is sent to the member of a
distribution list, this parameter may be used to record the
original address that was used to specify the list.
“for"パラメタを使用して、拡大か変化、受信ホストが正式仕様書を記録したがっているかもしれません。 メールのコピーを発送先リストのメンバーに送るとき、例えば、リストを指定するのに使用されたオリジナルのアドレスを記録するのにこのパラメタを使用するかもしれません。
4.4. ORIGINATOR FIELDS
4.4. 創始者分野
The standard allows only a subset of the combinations possi-
ble with the From, Sender, Reply-To, Resent-From, Resent-Sender,
and Resent-Reply-To fields. The limitation is intentional.
そして、規格はFromと共に組み合わせpossi- bleの部分集合だけを許容します、Sender、Reply、-、Resent、-、Resent-送付者、Resentが答える、分野。 制限は意図的です。
4.4.1. FROM / RESENT-FROM
4.4.1. /、憤慨、-
This field contains the identity of the person(s) who wished
this message to be sent. The message-creation process should
default this field to be a single, authenticated machine
address, indicating the AGENT (person, system or process)
entering the message. If this is not done, the "Sender" field
MUST be present. If the "From" field IS defaulted this way,
the "Sender" field is optional and is redundant with the
"From" field. In all cases, addresses in the "From" field
must be machine-usable (addr-specs) and may not contain named
lists (groups).
この分野はこの送られるべきメッセージを願っていた人のアイデンティティを含んでいます。 メッセージ創造の過程はデフォルトとするべきです。メッセージを入力しながらエージェント(人、システムまたは過程)を示す単一の、そして、認証された機械語アドレスであるこの分野。 これが完了していないなら、「送付者」分野は存在していなければなりません。 “From"分野がそうである、デフォルト、このように、「送付者」分野は、任意であり、“From"分野で余分です。 すべての場合では、“From"分野のアドレスは、マシン使用可能でなければならなく(addr-仕様)、命名されたリスト(グループ)を含まないかもしれません。
4.4.2. SENDER / RESENT-SENDER
4.4.2. 送付者に送付者/憤慨します。
This field contains the authenticated identity of the AGENT
(person, system or process) that sends the message. It is
intended for use when the sender is not the author of the mes-
sage, or to indicate who among a group of authors actually
sent the message. If the contents of the "Sender" field would
be completely redundant with the "From" field, then the
"Sender" field need not be present and its use is discouraged
(though still legal). In particular, the "Sender" field MUST
be present if it is NOT the same as the "From" Field.
この分野はメッセージを送るエージェント(人、システムまたは過程)の認証されたアイデンティティを含んでいます。 送付者がmes賢人の作者でないことの使用かだれが実際に作者のグループにメッセージを送ったかを示すのが意図しています。 「送付者」分野のコンテンツが“From"分野で完全に余分であるなら、「送付者」分野は存在している必要はありません、そして、使用はお勧めできないです(まだ法的ですが)。 それが“From" Fieldと同じでないなら、「送付者」分野は特に、存在していなければなりません。
The Sender mailbox specification includes a word sequence
which must correspond to a specific agent (i.e., a human user
or a computer program) rather than a standard address. This
indicates the expectation that the field will identify the
single AGENT (person, system, or process) responsible for
sending the mail and not simply include the name of a mailbox
from which the mail was sent. For example in the case of a
shared login name, the name, by itself, would not be adequate.
The local-part address unit, which refers to this agent, is
expected to be a computer system term, and not (for example) a
generalized person reference which can be used outside the
network text message context.
Senderメールボックス仕様は標準のアドレスよりむしろ特定のエージェント(すなわち、人間のユーザかコンピュータ・プログラム)に文通されなければならない単語系列を含んでいます。 これは、分野がメールを送りながら責任がある独身のエージェント(人、システム、または過程)を特定する期待を示して、メールが送られたメールボックスの名前を絶対に含んでいません。 例えば、共有されたログイン名の場合では、名前はそれ自体で適切でないでしょう。 地方の部分アドレスユニット(このエージェントについて言及する)は(例えば、)一般化された人の参照ではなく、ネットワークテキストメッセージの文脈の外に使用できるコンピュータ・システム用語であると予想されます。
August 13, 1982 - 21 - RFC #822
1982年8月13日--21--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
Since the critical function served by the "Sender" field is
identification of the agent responsible for sending mail and
since computer programs cannot be held accountable for their
behavior, it is strongly recommended that when a computer pro-
gram generates a message, the HUMAN who is responsible for
that program be referenced as part of the "Sender" field mail-
box specification.
「送付者」分野によって役立たれる批判的機能が送付メールに責任があるエージェントの識別であり、彼らの振舞いについて責任があるようにコンピュータ・プログラムは保持できないので、コンピュータ親グラムがメッセージ(「送付者」分野メール箱の仕様の離れているとき参照をつけられて、そのプログラムに責任があるHUMAN)を発生させるとき、それは強くそれに推薦されます。
4.4.3. REPLY-TO / RESENT-REPLY-TO
4.4.3. /に答えてください、回答に憤慨します。
This field provides a general mechanism for indicating any
mailbox(es) to which responses are to be sent. Three typical
uses for this feature can be distinguished. In the first
case, the author(s) may not have regular machine-based mail-
boxes and therefore wish(es) to indicate an alternate machine
address. In the second case, an author may wish additional
persons to be made aware of, or responsible for, replies. A
somewhat different use may be of some help to "text message
teleconferencing" groups equipped with automatic distribution
services: include the address of that service in the "Reply-
To" field of all messages submitted to the teleconference;
then participants can "reply" to conference submissions to
guarantee the correct distribution of any submission of their
own.
この分野は送られる応答がことであるどんなメールボックス(es)も示すのに一般的機構を提供します。 この特徴への3つの典型的な用途を区別できます。 前者の場合、作者は、レギュラーのマシンベースのメール箱を持って、したがって、(es)に交互の機械語アドレスを示して欲しくないかもしれません。 作者は、2番目の場合で返答するのを追加人々を意識する、または責任があるようにしたがっているかもしれません。 いくらか異なった使用は自動配布サービスを備えていた「テキストメッセージ電子会議」グループへの何らかの助けのものであるかもしれません: 中でそのサービスのアドレスを含めてください、「」 電子会議に提出されたすべてのメッセージの分野に関して、返答してください。 そして、関係者は、それら自身のどんな服従の正しい分配も保証するために会議差出に「返答できます」。
Note: The "Return-Path" field is added by the mail transport
service, at the time of final deliver. It is intended
to identify a path back to the orginator of the mes-
sage. The "Reply-To" field is added by the message
originator and is intended to direct replies.
以下に注意してください。 メール輸送サービスで加えられて、最終的時点で、配送してください。「リターンパス」分野はmes賢人のorginatorに経路を特定して戻すのが意図しているということです。 」 分野に答えてください。「メッセージ創始者によって加えられて、回答は指示するつもりです。
4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO
4.4.4. 自動使用、送付者/が答える/
For systems which automatically generate address lists for
replies to messages, the following recommendations are made:
回答のための住所録をメッセージに自動的に発生させるシステムにおいて、以下の推薦状をします:
o The "Sender" field mailbox should be sent notices of
any problems in transport or delivery of the original
messages. If there is no "Sender" field, then the
"From" field mailbox should be used.
o 輸送における、どんな問題の通知かオリジナルのメッセージの配送も「送付者」分野メールボックスに送るべきです。 「送付者」分野が全くなければ、“From"分野メールボックスは使用されるべきです。
o The "Sender" field mailbox should NEVER be used
automatically, in a recipient's reply message.
o 「送付者」分野メールボックスは受取人の応答メッセージで決して自動的に使用されるべきではありません。
o If the "Reply-To" field exists, then the reply should
go to the addresses indicated in that field and not to
the address(es) indicated in the "From" field.
o 「答え、」 分野は存在していて、次に、回答は“From"分野で示されたアドレス(es)ではなく、その分野で示されたアドレスに行くべきです。
August 13, 1982 - 22 - RFC #822
1982年8月13日--22--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
o If there is a "From" field, but no "Reply-To" field,
the reply should be sent to the address(es) indicated
in the "From" field.
o “From"分野がありますが、いいえが分野に「答える」なら、“From"分野で示されたアドレス(es)に回答を送るべきです。
Sometimes, a recipient may actually wish to communicate with
the person that initiated the message transfer. In such
cases, it is reasonable to use the "Sender" address.
時々、受取人は実際にメッセージ転送を起こした人とコミュニケートしたがっているかもしれません。 そのような場合、「送付者」というアドレスを使用するのは妥当です。
This recommendation is intended only for automated use of
originator-fields and is not intended to suggest that replies
may not also be sent to other recipients of messages. It is
up to the respective mail-handling programs to decide what
additional facilities will be provided.
この推薦は、創始者分野の自動化された使用のためだけに意図して、また、回答がメッセージの他の受取人に送られないかもしれないのを示すことを意図しません。 どんな追加の便宜供与が提供されるかを決めるのは、それぞれのメール取り扱いプログラム次第です。
Examples are provided in Appendix A.
例をAppendix Aに提供します。
4.5. RECEIVER FIELDS
4.5. あて先欄
4.5.1. TO / RESENT-TO
4.5.1. /、憤慨、-
This field contains the identity of the primary recipients of
the message.
この分野はメッセージの第一の受取人のアイデンティティを含んでいます。
4.5.2. CC / RESENT-CC
4.5.2. CCにCC/憤慨します。
This field contains the identity of the secondary (informa-
tional) recipients of the message.
この分野はメッセージの二次(informa- tional)受取人のアイデンティティを含んでいます。
4.5.3. BCC / RESENT-BCC
4.5.3. BCCにBCC/憤慨します。
This field contains the identity of additional recipients of
the message. The contents of this field are not included in
copies of the message sent to the primary and secondary reci-
pients. Some systems may choose to include the text of the
"Bcc" field only in the author(s)'s copy, while others may
also include it in the text sent to all those indicated in the
"Bcc" list.
この分野はメッセージの追加受取人のアイデンティティを含んでいます。 この分野の内容は第一の、そして、二次のreci- pientsに送られたメッセージのコピーに含まれていません。 いくつかのシステムが、作者のコピーだけの"Bcc"分野のテキストを含んでいるのを選ぶかもしれません、また、他のものは"Bcc"リストで示されたすべてのものに送られたテキストでそれを入れるかもしれませんが。
4.6. REFERENCE FIELDS
4.6. 参照分野
4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID
4.6.1. MESSAGE IDにMESSAGE ID/憤慨しています。
This field contains a unique identifier (the local-part
address unit) which refers to THIS version of THIS message.
The uniqueness of the message identifier is guaranteed by the
host which generates it. This identifier is intended to be
machine readable and not necessarily meaningful to humans. A
message identifier pertains to exactly one instantiation of a
particular message; subsequent revisions to the message should
この分野はTHISメッセージのTHISバージョンを示すユニークな識別子(地方の部分アドレスユニット)を含んでいます。 メッセージ識別子のユニークさはどれがそれを発生させるかがホストによって保証されます。 この識別子は読み込み可能で人間には、必ず重要であるというわけではないマシンであることを意図します。 メッセージ識別子はまさに特定のメッセージの1つの具体化に関係します。 メッセージへのその後の改正はそうするべきです。
August 13, 1982 - 23 - RFC #822
1982年8月13日--23--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
each receive new message identifiers.
それぞれが新しいメッセージ識別子を受け取ります。
4.6.2. IN-REPLY-TO
4.6.2. in reply to
The contents of this field identify previous correspon-
dence which this message answers. Note that if message iden-
tifiers are used in this field, they must use the msg-id
specification format.
この分野の内容はこのメッセージが答える前のcorrespon- denceを特定します。 メッセージiden- tifiersがこの分野で使用されるなら、彼らがmsg-イド仕様形式を使用しなければならないことに注意してください。
4.6.3. REFERENCES
4.6.3. 参照
The contents of this field identify other correspondence
which this message references. Note that if message identif-
iers are used, they must use the msg-id specification format.
この分野の内容はこのメッセージが参照をつける他の通信を特定します。 メッセージidentif- iersが使用されているなら、彼らがmsg-イド仕様形式を使用しなければならないことに注意してください。
4.6.4. KEYWORDS
4.6.4. キーワード
This field contains keywords or phrases, separated by
commas.
この分野はコンマによって切り離されたキーワードか句を含んでいます。
4.7. OTHER FIELDS
4.7. 他の分野
4.7.1. SUBJECT
4.7.1. 対象
This is intended to provide a summary, or indicate the
nature, of the message.
これは、概要を提供するか、またはメッセージの本質を示すことを意図します。
4.7.2. COMMENTS
4.7.2. コメント
Permits adding text comments onto the message without
disturbing the contents of the message's body.
メッセージのボディーのコンテンツを擾乱しないでテキストコメントをメッセージに追加する許可証。
4.7.3. ENCRYPTED
4.7.3. コード化されます。
Sometimes, data encryption is used to increase the
privacy of message contents. If the body of a message has
been encrypted, to keep its contents private, the "Encrypted"
field can be used to note the fact and to indicate the nature
of the encryption. The first <word> parameter indicates the
software used to encrypt the body, and the second, optional
<word> is intended to aid the recipient in selecting the
proper decryption key. This code word may be viewed as an
index to a table of keys held by the recipient.
時々、データ暗号化は、メッセージ内容のプライバシーを増加させるのに使用されます。 メッセージのボディーがコンテンツを個人的に保つためにコード化されたなら、事実に注意して、暗号化の本質を示すのに「コード化された」分野を使用できます。 最初の<単語>パラメタは、ソフトウェアが以前はよくボディー、および2番目をコード化していたのを示します、>が適切な復号化キーを選択する際に受取人を支援することを意図するという任意の<単語。 キーのテーブルへのインデックスが受取人を固守したので、この婉曲的表現は見られるかもしれません。
Note: Unfortunately, headers must contain envelope, as well
as contents, information. Consequently, it is neces-
sary that they remain unencrypted, so that mail tran-
sport services may access them. Since names,
addresses, and "Subject" field contents may contain
以下に注意してください。 残念ながら、ヘッダーは封筒、およびコンテンツ、情報を含まなければなりません。 その結果、彼らがメールtranスポーツサービスがそれらにアクセスできるように非コード化されたままで残っているのは、neces- saryです。 名前、アドレス、およびコンテンツが含むかもしれない「受けることがある」分野以来
August 13, 1982 - 24 - RFC #822
1982年8月13日--24--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
sensitive information, this requirement limits total
message privacy.
機密情報、限界がメッセージプライバシーを合計するというこの要件。
Names of encryption software are registered with the Net-
work Information Center, SRI International, Menlo Park, Cali-
fornia.
暗号化ソフトウェアの名前はネット仕事インフォメーション・センター、SRIインターナショナル、メンローパーク、カリforniaに登録されます。
4.7.4. EXTENSION-FIELD
4.7.4. 拡大分野
A limited number of common fields have been defined in
this document. As network mail requirements dictate, addi-
tional fields may be standardized. To provide user-defined
fields with a measure of safety, in name selection, such
extension-fields will never have names that begin with the
string "X-".
限られた数の共同耕地が本書では定義されました。 ネットワークメール要件が決めるように、addi- tional分野は標準化されるかもしれません。 名前選択における、安全の基準をユーザによって定義された分野に提供するために、そのような拡大分野には、ひも「X」で始まる名前が決してないでしょう。
Names of Extension-fields are registered with the Network
Information Center, SRI International, Menlo Park, California.
Extension-分野の名前はNetworkインフォメーション・センター、SRIインターナショナル、メンローパーク、カリフォルニアに登録されます。
4.7.5. USER-DEFINED-FIELD
4.7.5. ユーザの定義された分野
Individual users of network mail are free to define and
use additional header fields. Such fields must have names
which are not already used in the current specification or in
any definitions of extension-fields, and the overall syntax of
these user-defined-fields must conform to this specification's
rules for delimiting and folding fields. Due to the
extension-field publishing process, the name of a user-
defined-field may be pre-empted
追加ヘッダーフィールドを定義して、ネットワークメールの個々のユーザは自由に使用できます。 そのような分野には、現在の仕様か拡大分野のどんな定義にも既に使用されない名前がなければなりません、そして、これらのユーザの定義された分野の総合的な構文が分野を区切って、折り重ねるためのこの仕様の規則に従わなければなりません。 拡大分野出版の過程のため、ユーザの定義された分野の名前は先取りされるかもしれません。
Note: The prefatory string "X-" will never be used in the
names of Extension-fields. This provides user-defined
fields with a protected set of names.
以下に注意してください。 序文のストリング「X」は拡大分野の名前に決して使用されないでしょう。 これは保護されたセットの名前をユーザによって定義された分野に提供します。
August 13, 1982 - 25 - RFC #822
1982年8月13日--25--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
5. DATE AND TIME SPECIFICATION
5. 日時の仕様
5.1. SYNTAX
5.1. 構文
date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz
「日付-時間が等しい、[日、」、」、]、日付の時間。 dd mm yy。 hh:mm:ssグーグーグー
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
日は「月曜日」/「火曜日」/「水曜日」/「木曜日」/「金曜日」/「土曜日」/「Sun」と等しいです。
date = 1*2DIGIT month 2DIGIT ; day month year
; e.g. 20 Jun 82
=1*2DIGIT月の2DIGITとデートしてください。 日の月の年。 例えば、1982年6月20日
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
月は「1月」/「2月」/「3月」/「4月」/「5月」/「6月」/「7月」/「8月」/「9月」/「10月」/「11月」/「12月」等しいです。
time = hour zone ; ANSI and Military
時間は時間ゾーンと等しいです。 ANSIと軍
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
「時間=2DIGIT」:、」 2DIGIT[「:」 2DIGIT]。 00:00:00 - 23:59:59
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)
「ユタ」/「グリニッジ標準時」のゾーン=。 普遍的な時間。 ノース・アメリカン: 「米国東部標準時」かユタ/「東部夏時間」。 イースタン: - 5 /--4/"CST"/"CDT"。 中央: - 6 /--5/"MST"/"MDT"。 山: - 7 /--「太平洋標準時」か6/「太平洋夏時間」。 太平洋: - 8 /(7 / 1ALPHA) 軍: Zはユタと等しいです。 ; A:-1。 (使用されないJ) ; M: -12。 N: +1。 Y: +12/((「+」/「-」)4DIGIT)。 地方のデフ装置。 何時間もの+分 (HHMM)
5.2. SEMANTICS
5.2. 意味論
If included, day-of-week must be the day implied by the date
specification.
含まれているなら、週の曜日は日付の仕様で含意された日でなければなりません。
Time zone may be indicated in several ways. "UT" is Univer-
sal Time (formerly called "Greenwich Mean Time"); "GMT" is per-
mitted as a reference to Universal Time. The military standard
uses a single character for each zone. "Z" is Universal Time.
"A" indicates one hour earlier, and "M" indicates 12 hours ear-
lier; "N" is one hour later, and "Y" is 12 hours later. The
letter "J" is not used. The other remaining two forms are taken
from ANSI standard X3.51-1975. One allows explicit indication of
the amount of offset from UT; the other uses common 3-character
strings for indicating time zones in North America.
時間帯はいくつかの方法で示されるかもしれません。 「ユタ」はUniverサラソウジュTime(以前呼ばれた「グリニッジ標準時」)です。 「グリニッジ標準時に」、ある、-、世界標準時の参照として、mittedしました。 軍事の規格は各ゾーンに単独のキャラクタを使用します。 「Z」は世界標準時です。 「A」は、より早くある時間を示します、そして、「M」は12時間耳のlierを示します。 「N」は1時間より遅れています、そして、「Y」は12時間より遅れています。 文字「J」は使用されていません。 ANSI規格X3.51-1975から他の残っている2つの形を取ります。 1つはユタから相殺額の明白なしるしを許容します。 もう片方が、北アメリカで時間帯を示すのに一般的な3文字列を使用します。
August 13, 1982 - 26 - RFC #822
1982年8月13日--26--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
6. ADDRESS SPECIFICATION
6. アドレス指定
6.1. SYNTAX
6.1. 構文
address = mailbox ; one addressee
/ group ; named list
アドレスはメールボックスと等しいです。 1つの受け取り人/グループ。 リストと命名されます。
group = phrase ":" [#mailbox] ";"
「グループ=句」:、」 「[#メールボックス]」;、」
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
メールボックスはaddr-仕様と等しいです。 簡単なアドレス/句のルート-addr。 名前とaddr-仕様
route-addr = "<" [route] addr-spec ">"
ルート-addrは">"という"<"[ルート]addr-仕様と等しいです。
route = 1#("@" domain) ":" ; path-relative
「ルート=1#@""(ドメイン)」:、」 ; 経路相対的です。
addr-spec = local-part "@" domain ; global address
addr-仕様は地方の部分"@"ドメインと等しいです。 グローバルアドレス
local-part = word *("." word) ; uninterpreted
; case-preserved
地方の部分が単語*と等しい、(「. 」 単語、)、。 非解釈しました。 ケースで、保存されています。
domain = sub-domain *("." sub-domain)
ドメイン=サブドメイン*(「. 」 サブドメイン、)
sub-domain = domain-ref / domain-literal
ドメインサブドメイン=ドメイン審判/文字通りです。
domain-ref = atom ; symbolic reference
ドメイン審判は原子と等しいです。 シンボリックな参照
6.2. SEMANTICS
6.2. 意味論
A mailbox receives mail. It is a conceptual entity which
does not necessarily pertain to file storage. For example, some
sites may choose to print mail on their line printer and deliver
the output to the addressee's desk.
メールボックスはメールを受け取ります。 それは必ずファイル記憶装置に関係するというわけではない概念的な実体です。 例えば、いくつかのサイトが、それらのラインプリンタにメールを印刷して、受け取り人の机に出力を届けるのを選ぶかもしれません。
A mailbox specification comprises a person, system or pro-
cess name reference, a domain-dependent string, and a name-domain
reference. The name reference is optional and is usually used to
indicate the human name of a recipient. The name-domain refer-
ence specifies a sequence of sub-domains. The domain-dependent
string is uninterpreted, except by the final sub-domain; the rest
of the mail service merely transmits it as a literal string.
メールボックス仕様は人、システムか親課税名前参照、ドメイン依存するストリング、および名前ドメイン参照を包括します。 名前参照は、任意であり、通常、受取人の人間の名前を示すのに使用されます。 名前ドメインはenceを参照します。サブドメインの系列を指定します。 最終的なサブドメインを除いて、ドメイン依存するストリングは非解釈されます。 メールサービスの残りは文字通りのストリングとして単にそれを伝えます。
6.2.1. DOMAINS
6.2.1. ドメイン
A name-domain is a set of registered (mail) names. A name-
domain specification resolves to a subordinate name-domain
specification or to a terminal domain-dependent string.
Hence, domain specification is extensible, permitting any
number of registration levels.
名前ドメインは1セットの登録された(メール)名です。 仕様が下位の名前ドメイン仕様、または、端末のドメイン依存するストリングに決議する名前ドメイン。 したがって、いろいろな登録レベルを可能にして、ドメイン仕様は広げることができます。
August 13, 1982 - 27 - RFC #822
1982年8月13日--27--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
Name-domains model a global, logical, hierarchical addressing
scheme. The model is logical, in that an address specifica-
tion is related to name registration and is not necessarily
tied to transmission path. The model's hierarchy is a
directed graph, called an in-tree, such that there is a single
path from the root of the tree to any node in the hierarchy.
If more than one path actually exists, they are considered to
be different addresses.
名前ドメインはグローバルで、論理的で、階層的なアドレシング計画をモデル化します。 モデルは論理的です、アドレスspecifica- tionが名前登録に関連して、必ずトランスミッション経路に結ばれるというわけではないので。 モデルの階層構造は有向グラフです、呼ばれて中で木に登ってください、階層構造には木の根からどんなノードまでもただ一つの経路があるように。 1つ以上の経路が実際に存在しているなら、それらは異なったアドレスであると考えられます。
The root node is common to all addresses; consequently, it is
not referenced. Its children constitute "top-level" name-
domains. Usually, a service has access to its own full domain
specification and to the names of all top-level name-domains.
根のノードはすべてのアドレスに共通です。 その結果、それは参照をつけられません。 子供は「トップレベル」の名前ドメインを構成します。 通常、サービスはそれ自身の完全なドメイン仕様と、そして、すべてのトップレベル名前ドメインの名前にアクセスを持っています。
The "top" of the domain addressing hierarchy -- a child of the
root -- is indicated by the right-most field, in a domain
specification. Its child is specified to the left, its child
to the left, and so on.
ドメインアドレシング階層構造の「先端」(根の子供)は最も権利分野によって示されます、ドメイン仕様で。 子供は左、左への子供などに指定されます。
Some groups provide formal registration services; these con-
stitute name-domains that are independent logically of
specific machines. In addition, networks and machines impli-
citly compose name-domains, since their membership usually is
registered in name tables.
いくつかのグループが正式な登録サービスを提供します。 これらは特定のマシンから論理的に独立しているstitute名前ドメインをだまします。 さらに、それらの会員資格がネームテーブルに通常登録されるので、ネットワークとマシンimpli- citlyは名前ドメインを構成します。
In the case of formal registration, an organization implements
a (distributed) data base which provides an address-to-route
mapping service for addresses of the form:
正式な登録の場合では、組織はフォームのアドレスのためのサービスを写像する発送するアドレスを提供する(分配される)のデータベースを実行します:
person@registry.organization
person@registry.organization
Note that "organization" is a logical entity, separate from
any particular communication network.
「組織」が論理的な実体であることに注意してください、そして、あらゆる特定の通信ネットワークから分離してください。
A mechanism for accessing "organization" is universally avail-
able. That mechanism, in turn, seeks an instantiation of the
registry; its location is not indicated in the address specif-
ication. It is assumed that the system which operates under
the name "organization" knows how to find a subordinate regis-
try. The registry will then use the "person" string to deter-
mine where to send the mail specification.
「組織」にアクセスするためのメカニズムは利益一般にできます。 そのメカニズムは順番に登録の具体化を求めます。 位置はアドレスspecifで示されません。 「組織」という名で作動するシステムが、部下を見つけるために、regisがどのように試みるかを知っていると思われます。 登録は、メール仕様を送るために「人」が私のものを思いとどまらせるために結ぶ当時の使用にどこを望んでいるか。
The latter, network-oriented case permits simple, direct,
attachment-related address specification, such as:
後者の、そして、ネットワーク指向のケースは以下などの簡単で、ダイレクトで、付属関連のアドレス指定を可能にします。
user@host.network
user@host.network
Once the network is accessed, it is expected that a message
will go directly to the host and that the host will resolve
ネットワークがいったんアクセスされていると、メッセージが直接ホストのものになって、ホストが決議すると予想されます。
August 13, 1982 - 28 - RFC #822
1982年8月13日--28--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
the user name, placing the message in the user's mailbox.
ユーザのメールボックスにメッセージを置くユーザ名。
6.2.2. ABBREVIATED DOMAIN SPECIFICATION
6.2.2. 簡略化されたドメイン仕様
Since any number of levels is possible within the domain
hierarchy, specification of a fully qualified address can
become inconvenient. This standard permits abbreviated domain
specification, in a special case:
いろいろなレベルがドメイン階層構造の中で可能であるので、完全に適切なアドレスの仕様は不便になることができます。 この規格は特別なケースの中の簡略化されたドメイン仕様を可能にします:
For the address of the sender, call the left-most
sub-domain Level N. In a header address, if all of
the sub-domains above (i.e., to the right of) Level N
are the same as those of the sender, then they do not
have to appear in the specification. Otherwise, the
address must be fully qualified.
送信者のアドレスのために、最も左のサブドメインLevel N.Inをヘッダーアドレスと呼んでください、上記のサブドメインのすべてなら(すなわち、権利、)、レベルNが送付者のものと同じである、そして、それらは仕様に現れる必要はありません。 さもなければ、完全にアドレスに資格がなければなりません。
This feature is subject to approval by local sub-
domains. Individual sub-domains may require their
member systems, which originate mail, to provide full
domain specification only. When permitted, abbrevia-
tions may be present only while the message stays
within the sub-domain of the sender.
この特徴は地方のサブドメインのそばで承認を必要としています。 個々のサブドメインはそれらのメンバーシステムを必要とするかもしれません。(システムは、完全なドメイン仕様だけを提供するためにメールを溯源します)。 受入れられると、メッセージが送付者のサブドメインの範囲内にとどまるだけである間、abbrevia- tionsは存在しているかもしれません。
Use of this mechanism requires the sender's sub-domain
to reserve the names of all top-level domains, so that
full specifications can be distinguished from abbrevi-
ated specifications.
このメカニズムの使用はすべての最上位のドメインの名前を予約するために送付者のサブドメインを必要とします、abbrevi- ated仕様と完全な仕様を区別できるように。
For example, if a sender's address is:
例えば、送付者のものであるなら、アドレスは以下の通りです。
sender@registry-A.registry-1.organization-X
sender@registry-A.registry-1.organization-X
and one recipient's address is:
そして、1人の受取人のアドレスは以下の通りです。
recipient@registry-B.registry-1.organization-X
recipient@registry-B.registry-1.organization-X
and another's is:
そして、ほかのもののものは以下の通りです。
recipient@registry-C.registry-2.organization-X
recipient@registry-C.registry-2.organization-X
then ".registry-1.organization-X" need not be specified in the
the message, but "registry-C.registry-2" DOES have to be
specified. That is, the first two addresses may be abbrevi-
ated, but the third address must be fully specified.
次に、".registry-1.organization-X"はメッセージで指定される必要はありませんが、「2インチがする登録C.登録は指定されなければなりません」。 すなわち、最初の2つのアドレスがabbrevi- atedであるかもしれませんが、3番目のアドレスを完全に指定しなければなりません。
When a message crosses a domain boundary, all addresses must
be specified in the full format, ending with the top-level
name-domain in the right-most field. It is the responsibility
of mail forwarding services to ensure that addresses conform
メッセージがドメイン境界に交差するとき、完全な形式ですべてのアドレスを指定しなければなりません、トップレベル名前ドメインが最も権利分野にある状態で終わって。 アドレスが従うのを保証するのは、メール転送サービスの責任です。
August 13, 1982 - 29 - RFC #822
1982年8月13日--29--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
with this requirement. In the case of abbreviated addresses,
the relaying service must make the necessary expansions. It
should be noted that it often is difficult for such a service
to locate all occurrences of address abbreviations. For exam-
ple, it will not be possible to find such abbreviations within
the body of the message. The "Return-Path" field can aid
recipients in recovering from these errors.
この要件で。 短縮アドレスの場合では、リレーサービスは必要な拡大をしなければなりません。 そのようなサービスがアドレス略語のすべての発生の場所を見つけるのが、しばしば難しいことに注意されるべきです。 メッセージ欄の中でそのような略語を見つけるのは試験pleに関しては、可能にならないでしょう。 「リターンパス」分野はこれらの誤りから克服する際に受取人を支援できます。
Note: When passing any portion of an addr-spec onto a process
which does not interpret data according to this stan-
dard (e.g., mail protocol servers). There must be NO
LWSP-chars preceding or following the at-sign or any
delimiting period ("."), such as shown in the above
examples, and only ONE SPACE between contiguous
<word>s.
以下に注意してください。 このstan- dard(例えば、メールプロトコルサーバ)によると、データの機械言語に翻訳処理をしない過程にaddr-仕様のどんな部分も通過するとき。 期間を区切りながらサインかいずれにも先行するか、または従うLWSP-雑用が全くあるはずがない、(「」、)、上記の例、および隣接の<単語>sの間のあるスペースだけに示されて。
6.2.3. DOMAIN TERMS
6.2.3. ドメイン用語
A domain-ref must be THE official name of a registry, network,
or host. It is a symbolic reference, within a name sub-
domain. At times, it is necessary to bypass standard mechan-
isms for resolving such references, using more primitive
information, such as a network host address rather than its
associated host name.
ドメイン審判は登録、ネットワーク、またはホストの正式名称であるに違いありません。 それは名前サブドメインの中のシンボリックな参照です。 時には、そのような参照を決議するために標準のmechan主義を迂回させるのが必要です、より原始の情報を使用して、関連ホスト名よりむしろネットワークホスト・アドレスのように。
To permit such references, this standard provides the domain-
literal construct. Its contents must conform with the needs
of the sub-domain in which it is interpreted.
そのような参照を可能にするために、この規格はドメインの文字通りの構造物を提供します。 コンテンツはそれが解釈されるサブドメインの必要性に従わなければなりません。
Domain-literals which refer to domains within the ARPA Inter-
net specify 32-bit Internet addresses, in four 8-bit fields
noted in decimal, as described in Request for Comments #820,
"Assigned Numbers." For example:
ARPA Interネットの中でドメインについて言及するドメイン誤字誤植が32ビットのインターネット・アドレスを指定します、8ビットのComments#820のためにRequestで説明されるように小数で注意した「数は割り当てられた」4つの分野で。 例えば:
[10.0.3.19]
[10.0.3.19]
Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It
is permitted only as a means of bypassing temporary
system limitations, such as name tables which are not
complete.
以下に注意してください。 ドメイン誤字誤植の使用は強くお勧めできないです。 それは単に完全でないネームテーブルなどの一時的なシステム限界を迂回させる手段として受入れられます。
The names of "top-level" domains, and the names of domains
under in the ARPA Internet, are registered with the Network
Information Center, SRI International, Menlo Park, California.
「トップレベル」ドメインの名前、およびARPAインターネットのドメイン下の名前はNetworkインフォメーション・センター、SRIインターナショナル、メンローパーク、カリフォルニアに登録されます。
6.2.4. DOMAIN-DEPENDENT LOCAL STRING
6.2.4. ドメイン扶養家族の地方のストリング
The local-part of an addr-spec in a mailbox specification
(i.e., the host's name for the mailbox) is understood to be
仕様(すなわち、メールボックスのためのホストの名前)が理解されているメールボックスの中のaddr-仕様の地方の部分
August 13, 1982 - 30 - RFC #822
1982年8月13日--30--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
whatever the receiving mail protocol server allows. For exam-
ple, some systems do not understand mailbox references of the
form "P. D. Q. Bach", but others do.
メールプロトコルサーバが許す受信が何であっても。 試験pleに関しては、いくつかのシステムは形式「P」のメールボックス参照を理解していません。 D。 Q。 しかし、「バッハ」、他のものはそうします。
This specification treats periods (".") as lexical separators.
Hence, their presence in local-parts which are not quoted-
strings, is detected. However, such occurrences carry NO
semantics. That is, if a local-part has periods within it, an
address parser will divide the local-part into several tokens,
but the sequence of tokens will be treated as one uninter-
preted unit. The sequence will be re-assembled, when the
address is passed outside of the system such as to a mail pro-
tocol service.
この仕様御馳走の期間、(「」、)、語彙分離符として。 したがって、地方のそうする部分でのそれらの存在は、ストリングを引用しないで、検出されます。 しかしながら、そのような発生は意味論を全く運びません。 すなわち、地方の部分がそれの中で期間を過すと、アドレスパーサは地方の部分を数個の象徴に分割するでしょうが、象徴の系列は1uninter- pretedユニットとして扱われるでしょう。 系列は組み立て直されるでしょう、アドレスがメール親tocolサービスなどのシステムの外に通過されるとき。
For example, the address:
例えば、アドレス:
First.Last@Registry.Org
First.Last@Registry.Org
is legal and does not require the local-part to be surrounded
with quotation-marks. (However, "First Last" DOES require
quoting.) The local-part of the address, when passed outside
of the mail system, within the Registry.Org domain, is
"First.Last", again without quotation marks.
法的であり、地方の部分が引用符で囲まれるのが必要ではありません。 (しかしながら、DOESは、「最初に最後に」引用するのを必要とします。) Registry.Orgドメインの中でメールシステムの外に通過されると、アドレスの地方の部分は「最初に、.Last」です、再び引用符なしで。
6.2.5. BALANCING LOCAL-PART AND DOMAIN
6.2.5. バランスをとることの地方の部分とドメイン
In some cases, the boundary between local-part and domain can
be flexible. The local-part may be a simple string, which is
used for the final determination of the recipient's mailbox.
All other levels of reference are, therefore, part of the
domain.
いくつかの場合、地方の部分とドメインの間の境界はフレキシブルである場合があります。 地方の部分は簡単なストリングであるかもしれません。(そのストリングは受信者のメールボックスの最終的決定に使用されます)。 したがって、参照の他のすべてのレベルがドメインの一部です。
For some systems, in the case of abbreviated reference to the
local and subordinate sub-domains, it may be possible to
specify only one reference within the domain part and place
the other, subordinate name-domain references within the
local-part. This would appear as:
地方の、そして、下位のサブドメインの簡略化された参照の場合におけるいくつかのシステムにおいて、それは、ドメイン部分の中の1つの参照箇所だけを指定して、もう片方(地方の部分の中の下位の名前ドメイン参照)を置くために可能であるかもしれません。 これは以下として現れるでしょう。
mailbox.sub1.sub2@this-domain
mailbox.sub1.sub2@this-domain
Such a specification would be acceptable to address parsers
which conform to RFC #733, but do not support this newer
Internet standard. While contrary to the intent of this stan-
dard, the form is legal.
そのような仕様はRFC#733に従うパーサを記述するのにおいて許容できるでしょうが、このより新しいインターネット標準を支持しないでください。 フォームはこのstan- dardの意図とは逆に法的ですが。
Also, some sub-domains have a specification syntax which does
not conform to this standard. For example:
また、いくつかのサブドメインには、この規格に従わない仕様構文があります。 例えば:
sub-net.mailbox@sub-domain.domain
sub-net.mailbox@sub-domain.domain
August 13, 1982 - 31 - RFC #822
1982年8月13日--31--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
uses a different parsing sequence for local-part than for
domain.
ドメインによって地方の部分に異なった構文解析系列を使用します。
Note: As a rule, the domain specification should contain
fields which are encoded according to the syntax of
this standard and which contain generally-standardized
information. The local-part specification should con-
tain only that portion of the address which deviates
from the form or intention of the domain field.
以下に注意してください。 原則として、ドメイン仕様はこの規格の構文によってコード化されて、一般に標準化された情報を含む分野を含むべきです。 地方の部分仕様はtainにフォームから逸れるアドレスのその部分かドメイン分野の意志だけをだますべきです。
6.2.6. MULTIPLE MAILBOXES
6.2.6. 複数のメールボックス
An individual may have several mailboxes and wish to receive
mail at whatever mailbox is convenient for the sender to
access. This standard does not provide a means of specifying
"any member of" a list of mailboxes.
個人は、数個のメールボックスを持って、送付者がアクセサリーに都合がよいいかなるメールボックスにもメールを受け取りたがっているかもしれません。 この規格が指定する手段を提供しない、「」 メールボックスのリストのどんなメンバー。
A set of individuals may wish to receive mail as a single unit
(i.e., a distribution list). The <group> construct permits
specification of such a list. Recipient mailboxes are speci-
fied within the bracketed part (":" - ";"). A copy of the
transmitted message is to be sent to each mailbox listed.
This standard does not permit recursive specification of
groups within groups.
1セットの個人は単一の単位(すなわち、発送先リスト)としてメールを受け取りたがっているかもしれません。 <グループ>構造物はそのようなリストの仕様を可能にします。 「受取人メールボックスが腕木を付けられた部分の中のspeci- fiedである、(「:」、--、」、;、」、) 伝えられたメッセージのコピーは記載された各メールボックスに送ることです。 この規格はグループの中でグループの再帰的な仕様を可能にしません。
While a list must be named, it is not required that the con-
tents of the list be included. In this case, the <address>
serves only as an indication of group distribution and would
appear in the form:
リストを命名しなければなりませんが、リストのまやかしテントが含まれているのが必要ではありません。 この場合、<アドレス>は単にグループ分配のしるしとして機能して、フォームに現れるでしょう:
name:;
以下を命名してください。
Some mail services may provide a group-list distribution
facility, accepting a single mailbox reference, expanding it
to the full distribution list, and relaying the mail to the
list's members. This standard provides no additional syntax
for indicating such a service. Using the <group> address
alternative, while listing one mailbox in it, can mean either
that the mailbox reference will be expanded to a list or that
there is a group with one member.
いくつかのメールサービスがグループリスト分配施設を提供するかもしれません、ただ一つのメールボックス参照を受け入れて、完全な発送先リストにそれを広げて、リストのメンバーにメールをリレーして。 この規格はそのようなサービスを示すためのどんな追加構文も提供しません。 それの1個のメールボックスを記載している間、<グループ>アドレス代替手段を使用するのは、メールボックス参照がリストに広げられるか、または1人のメンバーがいるグループがあることを意味できます。
6.2.7. EXPLICIT PATH SPECIFICATION
6.2.7. 明白な経路仕様
At times, a message originator may wish to indicate the
transmission path that a message should follow. This is
called source routing. The normal addressing scheme, used in
an addr-spec, is carefully separated from such information;
the <route> portion of a route-addr is provided for such occa-
sions. It specifies the sequence of hosts and/or transmission
時には、メッセージ創始者はメッセージが続くべきであるトランスミッション経路を示したがっているかもしれません。 これはソースルーティングと呼ばれます。 addr-仕様で使用される正常なアドレシング計画はそのような情報と慎重に切り離されます。 ルート-addrの<ルート>部分をそのようなocca- sionsに提供します。 それはホスト、そして/または、トランスミッションの系列を指定します。
August 13, 1982 - 32 - RFC #822
1982年8月13日--32--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
services that are to be traversed. Both domain-refs and
domain-literals may be used.
横断されることになっているサービス。 ドメイン審判とドメイン誤字誤植の両方が使用されるかもしれません。
Note: The use of source routing is discouraged. Unless the
sender has special need of path restriction, the choice
of transmission route should be left to the mail tran-
sport service.
以下に注意してください。 ソースルーティングの使用はお勧めできないです。 メールtranへの左がスポーツサービスであり、送付者が経路制限の特別な必要性を持っていない場合、トランスミッションルートの選択は持っています。
6.3. RESERVED ADDRESS
6.3. 予約されたアドレス
It often is necessary to send mail to a site, without know-
ing any of its valid addresses. For example, there may be mail
system dysfunctions, or a user may wish to find out a person's
correct address, at that site.
メールをサイトに送るのがしばしば必要である、有効なアドレスのingいずれも知ってください。 例えば、メールシステム機能不全がありたいかもしれませんか、またはユーザは人の正しいアドレスを見つけたがっているかもしれません、そのサイトで。
This standard specifies a single, reserved mailbox address
(local-part) which is to be valid at each site. Mail sent to
that address is to be routed to a person responsible for the
site's mail system or to a person with responsibility for general
site operation. The name of the reserved local-part address is:
この規格はシングル、各サイトで有効であることである予約されたメールボックスアドレス(地方の部分)を指定します。 そのアドレスに送られたメールはサイトのメールシステムに責任がある人、または、一般的なサイト操作への責任をもっている人に発送されることです。 予約された地方の部分アドレスの名前は以下の通りです。
Postmaster
郵便局長
so that "Postmaster@domain" is required to be valid.
それで、その" Postmaster@domain "が、有効になるのに必要です。
Note: This reserved local-part must be matched without sensi-
tivity to alphabetic case, so that "POSTMASTER", "postmas-
ter", and even "poStmASteR" is to be accepted.
以下に注意してください。 sensi- tivityなしでこの予約された地方の部分をアルファベットケースに合わせなければならないので、その「郵便局長」"postmas- ter"と「郵便局長」さえ受け入れられることになっています。
August 13, 1982 - 33 - RFC #822
1982年8月13日--33--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
7. BIBLIOGRAPHY
7. 図書目録
ANSI. "USA Standard Code for Information Interchange," X3.4.
American National Standards Institute: New York (1968). Also
in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand-
book", NIC 7104.
ANSI。 「米国の標準の情報交換用符号」、X3.4。 American National Standards Institut: ニューヨーク(1968)。 以下でも FeinlerとE.とJ.ポステル、eds、「Handが予約するアルパネットプロトコル」、NIC7104
ANSI. "Representations of Universal Time, Local Time Differen-
tials, and United States Time Zone References for Information
Interchange," X3.51-1975. American National Standards Insti-
tute: New York (1975).
ANSI。 「情報Interchangeのための世界標準時、Local Time Differen- tials、および合衆国Time Zone Referencesの表現」、X3.51-1975。 アメリカのNational Standards Insti- tute: ニューヨーク(1975)。
Bemer, R.W., "Time and the Computer." In: Interface Age (Feb.
1979).
Bemerと、R.W.と、「時間とコンピュータ。」 中: 時代(1979年2月)を連結してください。
Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther-
ford and Appleton Laboratory: Didcot, England.
ベネット、C.J.「JNTメールプロトコル。」 共同Network Team、ルーサー浅瀬、およびアップルトーン研究所: ジドコット(イギリス)。
Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E.
"Standardizing Network Mail Headers," ARPANET Request for
Comments No. 561, Network Information Center No. 18516; SRI
International: Menlo Park (September 1973).
Bhushan J. (A.K.とPogranとK.T.とトムリンスン、R.S.と白、E. 「ネットワークメールヘッダを標準化します」、コメントNo.561を求めるアルパネット要求)はインフォメーション・センターNo.18516をネットワークでつなぎます。 SRIインターナショナル: Menloは駐車します(1973年9月)。
Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D.
"Grapevine: An Exercise in Distributed Computing," Communica-
tions of the ACM 25, 4 (April 1982), 260-274.
ビレル、西暦、レヴィン、R.、ニーダム、R.M.、およびシュローダー、M.D.、「ぶどうのツル:」 「Distributed ComputingのExercise」、ACM25、4(1982年4月)のCommunica- tions、260-274。
Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A.
"Standard for the Format of ARPA Network Text Message,"
ARPANET Request for Comments No. 733, Network Information
Center No. 41952. SRI International: Menlo Park (November
1977).
クロッカー、D.H.、Vittal、J.J.、Pogran、K.T.、ヘンダーソン、D. A. 「アーパネットテキストメッセージの形式の規格」、コメントNo.733を求めるアルパネット要求はインフォメーション・センターNo.41952をネットワークでつなぎます。 SRIインターナショナル: Menloは駐車します(1977年11月)。
Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net-
work Information Center No. 7104 (NTIS AD A003890). SRI
International: Menlo Park (April 1976).
FeinlerとE.J.とポステル、J.B.アルパネットプロトコルHandbook、ネットはインフォメーション・センターNo.7104(NTIS AD A003890)を扱います。 SRIインターナショナル: Menloは駐車します(1976年4月)。
Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass.
(1969).
ハラリー、F.「グラフ理論。」 アディソン-ウエスリー: 読書、マサチューセッツ州 (1969).
Levin, R. and Schroeder, M. "Transport of Electronic Messages
through a Network," TeleInformatics 79, pp. 29-33. North
Holland (1979). Also as Xerox Palo Alto Research Center
Technical Report CSL-79-4.
レヴィンとR.とシュローダー、M. 「ネットワークを通した電子メッセージの輸送」、TeleInformatics79、ページ 29-33. 北のオランダ(1979)。 ゼロックスパロアルト研究センター技術報告書CSL-79-4としても。
Myer, T.H. and Henderson, D.A. "Message Transmission Protocol,"
ARPANET Request for Comments, No. 680, Network Information
Center No. 32116. SRI International: Menlo Park (1975).
マイヤー、T.H.、およびヘンダーソン(D.A.「メッセージトランスミッションプロトコル」、コメント、No.680を求めるアルパネット要求)はインフォメーション・センターNo.32116をネットワークでつなぎます。 SRIインターナショナル: Menloは(1975)を駐車します。
August 13, 1982 - 34 - RFC #822
1982年8月13日--34--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
NBS. "Specification of Message Format for Computer Based Message
Systems, Recommended Federal Information Processing Standard."
National Bureau of Standards: Gaithersburg, Maryland
(October 1981).
NBS。 「コンピュータのためのメッセージ・フォーマットの仕様はメッセージシステム、お勧めの連邦情報処理基準を基礎づけました。」 規格基準局: ゲイザースバーグ(メリーランド)(1981年10月)。
NIC. Internet Protocol Transition Workbook. Network Information
Center, SRI-International, Menlo Park, California (March
1982).
NIC。 インターネットプロトコル変遷ワークブック。 インフォメーション・センター、SRIインターナショナル、メンローパーク、カリフォルニア(1982年3月)をネットワークでつないでください。
Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized
Agent for Locating Named Objects in a Distributed Environ-
ment," OPD-T8103. Xerox Office Products Division: Palo Alto,
CA. (October 1981).
Oppen、D.C.とDalal、Y.K.、「情報センター:」 「Distributed Environ- mentのLocating Named ObjectsのDecentralizedエージェント」、OPD-T8103。 ゼロックスオフィス製品師団: パロアルト(カリフォルニア)。 (1981年10月。)
Postel, J.B. "Assigned Numbers," ARPANET Request for Comments,
No. 820. SRI International: Menlo Park (August 1982).
ポステル、J.B.「規定番号」、コメント、No.820を求めるアルパネット要求。 SRIインターナショナル: Menloは駐車します(1982年8月)。
Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request
for Comments, No. 821. SRI International: Menlo Park (August
1982).
ポステル、J.B.「簡単なメール転送プロトコル」、コメント、No.821を求めるアルパネット要求。 SRIインターナショナル: Menloは駐車します(1982年8月)。
Shoch, J.F. "Internetwork naming, addressing and routing," in
Proc. 17th IEEE Computer Society International Conference, pp.
72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
J. F. Shochと、Procの「インターネットワーク命名、アドレシング、およびルーティング。」 第17IEEEのコンピュータのSocietyの国際コンファレンス、ページ 72-79、1978年9月、IEEE猫。 No.78 CH1388-8C。
Su, Z. and Postel, J. "The Domain Naming Convention for Internet
User Applications," ARPANET Request for Comments, No. 819.
SRI International: Menlo Park (August 1982).
コメント、No.819を求めるSuとZ.とJ. ポステル、「インターネットユーザアプリケーションのためのドメイン命名規則」アルパネット要求。 SRIインターナショナル: Menloは駐車します(1982年8月)。
August 13, 1982 - 35 - RFC #822
1982年8月13日--35--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
APPENDIX
付録
A. EXAMPLES
A.の例
A.1. ADDRESSES
A.1。 アドレス
A.1.1. Alfred Neuman <Neuman@BBN-TENEXA>
A.1.1。 アルフレッド Neuman <Neuman@BBN-TENEXA 、gt。
A.1.2. Neuman@BBN-TENEXA
A.1.2。 Neuman@BBN-TENEXA
These two "Alfred Neuman" examples have identical seman-
tics, as far as the operation of the local host's mail sending
(distribution) program (also sometimes called its "mailer")
and the remote host's mail protocol server are concerned. In
the first example, the "Alfred Neuman" is ignored by the
mailer, as "Neuman@BBN-TENEXA" completely specifies the reci-
pient. The second example contains no superfluous informa-
tion, and, again, "Neuman@BBN-TENEXA" is the intended reci-
pient.
これらの2つの「アルフレッド・ヌーマン」の例には同じsemanチックがあります、プログラム(また、時々「郵送者」と呼ばれる)とリモートホストのメールプロトコルサーバを(分配)に送るローカル・ホストの郵便配達人の操作に関する限り。 最初の例では、" Neuman@BBN-TENEXA "がreci- pientを完全に指定するとき、「アルフレッド・ヌーマン」は郵送者によって無視されます。 2番目の例はどんな余計なinforma- tionも含んでいません、そして、一方、" Neuman@BBN-TENEXA "は意図しているreci- pientです。
Note: When the message crosses name-domain boundaries, then
these specifications must be changed, so as to indicate
the remainder of the hierarchy, starting with the top
level.
以下に注意してください。 メッセージが名前ドメイン境界に交差していると、これらの仕様を変えなければなりません、階層構造の残りを示すために、トップレベルから始まって。
A.1.3. "George, Ted" <Shared@Group.Arpanet>
A.1.3。 「ジョージ、テッド、「 <Shared@Group.Arpanet 、gt;、」
This form might be used to indicate that a single mailbox
is shared by several users. The quoted string is ignored by
the originating host's mailer, because "Shared@Group.Arpanet"
completely specifies the destination mailbox.
このフォームは、単一のメールボックスが数人のユーザによって共有されるのを示すのに使用されるかもしれません。 " Shared@Group.Arpanet "があて先メールボックスを完全に指定するので、引用文字列は送信元ホストの郵送者によって無視されます。
A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US
A.1.4。 ウィルト(竹馬) Chamberlain@NBA.US
The "(the Stilt)" is a comment, which is NOT included in
the destination mailbox address handed to the originating
system's mailer. The local-part of the address is the string
"Wilt.Chamberlain", with NO space between the first and second
words.
「(竹馬)」はコメントです。(そのコメントは由来しているシステムの郵送者に手渡されたあて先メールボックスアドレスに含まれていません)。 アドレスの地方の部分は1番目と2番目の単語の間には、スペースが全くないストリング"Wilt.Chamberlain"です。
A.1.5. Address Lists
A.1.5。 住所録
Gourmets: Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
Childs@WGBH.Boston, Galloping Gourmet@
ANT.Down-Under (Australian National Television),
Cheapie@Discount-Liquors;,
Cruisers: Port@Portugal, Jones@SEA;,
Another@Somewhere.SomeOrg
グルメ: もったいぶっている Person <WhoZiWhatZit@Cordon-Bleu 、gt;、チャイルズ@WGBH.Boston、グルメ@ANT.Down-Under(オーストラリアの全国テレビ放送)を駆けさせる Cheapie@Discount-Liquors; 、クルーザー: Port@Portugal 、ジョーンズ@SEA;、 Another@Somewhere.SomeOrg
August 13, 1982 - 36 - RFC #822
1982年8月13日--36--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
This group list example points out the use of comments and the
mixing of addresses and groups.
このグループリストの例はコメントの使用とアドレスとグループの混合を指摘します。
A.2. ORIGINATOR ITEMS
A.2。 創始者項目
A.2.1. Author-sent
A.2.1。 作者によって送られます。
George Jones logs into his host as "Jones". He sends
mail himself.
ジョージ・ジョーンズは「ジョーンズ」として彼のホストにログインします。 彼は自分でメールを送ります。
From: Jones@Group.Org
From: Jones@Group.Org
or
または
From: George Jones <Jones@Group.Org>
From: ジョージ Jones <Jones@Group.Org 、gt。
A.2.2. Secretary-sent
A.2.2。 長官によって送られます。
George Jones logs in as Jones on his host. His secre-
tary, who logs in as Secy sends mail for him. Replies to the
mail should go to George.
ジョージ・ジョーンズはジョーンズとして彼のホストの上でログインします。 彼のsecre- tary。(Secyが彼へのメールを送るとき、そのsecre- taryはログインします)。 メールに関する回答はジョージのものになるべきです。
From: George Jones <Jones@Group>
Sender: Secy@Other-Group
From: ジョージ Jones <Jones@Group 、gt;、送付者: Secy@Other-Group
A.2.3. Secretary-sent, for user of shared directory
A.2.3。 共有ディレクトリのユーザのために長官によって送られます。
George Jones' secretary sends mail for George. Replies
should go to George.
ジョージ・ジョーンズの秘書はジョージへのメールを送ります。 回答はジョージのものになるべきです。
From: George Jones<Shared@Group.Org>
Sender: Secy@Other-Group
From: ジョージ Jones<Shared@Group.Org 、gt;、送付者: Secy@Other-Group
Note that there need not be a space between "Jones" and the
"<", but adding a space enhances readability (as is the case
in other examples.
スペースが「ジョーンズ」と"<"の間のスペースではなく、付加でなければならないというメモは読み易さを高めます。(他の例におけるケースのように。
A.2.4. Committee activity, with one author
A.2.4。 1人の作者との委員会の活動
George is a member of a committee. He wishes to have any
replies to his message go to all committee members.
ジョージは委員会のメンバーです。 彼は、彼のメッセージに関するどんな回答もすべての委員のものになるのを持ちたがっています。
From: George Jones <Jones@Host.Net>
Sender: Jones@Host
Reply-To: The Committee: Jones@Host.Net,
Smith@Other.Org,
Doe@Somewhere-Else;
From: ジョージ Jones <Jones@Host.Net 、gt;、送付者: Jones@Host Reply-To 委員会: Jones@Host.Net 、スミス@Other.Org、 Doe@Somewhere-Else;
Note that if George had not included himself in the
ジョージが中で自分を入れていなかったなら、それに注意してください。
August 13, 1982 - 37 - RFC #822
1982年8月13日--37--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
enumeration of The Committee, he would not have gotten an
implicit reply; the presence of the "Reply-to" field SUPER-
SEDES the sending of a reply to the person named in the "From"
field.
列挙、Committeeでは、彼は暗黙の回答を得ていないでしょう。 存在、「」 人への回答の送付が“From"分野で命名した分野SUPER- SEDESに答えてください。
A.2.5. Secretary acting as full agent of author
A.2.5。 作者の完全なエージェントとして務めている長官
George Jones asks his secretary (Secy@Host) to send a
message for him in his capacity as Group. He wants his secre-
tary to handle all replies.
ジョージ・ジョーンズは、彼のためにGroupとして彼の立場でメッセージを送るように彼の秘書( Secy@Host )に頼みます。 彼は、彼のsecre- taryにすべての回答を扱って欲しいです。
From: George Jones <Group@Host>
Sender: Secy@Host
Reply-To: Secy@Host
From: ジョージ Jones <Group@Host 、gt;、送付者: Secy@Host Reply-To Secy@Host
A.2.6. Agent for user without online mailbox
A.2.6。 オンラインメールボックスのないユーザのためのエージェント
A friend of George's, Sarah, is visiting. George's
secretary sends some mail to a friend of Sarah in computer-
land. Replies should go to George, whose mailbox is Jones at
Registry.
ジョージの友人(サラ)は訪問する予定です。 ジョージの秘書はコンピュータ陸で何らかのメールをサラの友人に送ります。 回答はジョージのものになるべきです。(ジョージのメールボックスはRegistryのジョーンズです)。
From: Sarah Friendly <Secy@Registry>
Sender: Secy-Name <Secy@Registry>
Reply-To: Jones@Registry.
From: サラ Friendly <Secy@Registry 、gt;、送付者: Secy-Name <Secy@Registry 、gt;、Reply-To Jones@Registry 。
A.2.7. Agent for member of a committee
A.2.7。 委員会のメンバーのためのエージェント
George's secretary sends out a message which was authored
jointly by all the members of a committee. Note that the name
of the committee cannot be specified, since <group> names are
not permitted in the From field.
ジョージの秘書は委員会のすべてのメンバーによって共同で書かれたメッセージを出します。 <グループ>名がFrom分野で受入れられないので、委員会の名前を指定できないことに注意してください。
From: Jones@Host,
Smith@Other-Host,
Doe@Somewhere-Else
Sender: Secy@SHost
From: Jones@Host 、スミス@Otherホスト、 Doe@Somewhere-Else 送付者: Secy@SHost
August 13, 1982 - 38 - RFC #822
1982年8月13日--38--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
A.3. COMPLETE HEADERS
A.3。 完全なヘッダー
A.3.1. Minimum required
A.3.1。 最小限が必要です。
Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT
From: Jones@Registry.Org or From: Jones@Registry.Org
Bcc: To: Smith@Registry.Org
日付: 1976年8月26日の東部夏時間1429日付: 1976年8月26日の東部夏時間1429From: Jones@Registry.Org かFrom: Jones@Registry.Org Bcc: To: Smith@Registry.Org
Note that the "Bcc" field may be empty, while the "To" field
is required to have at least one address.
"Bcc"分野が人影がないかもしれないのにもかかわらずの、“To"分野がそうというメモが少なくとも1つのアドレスを持つのが必要です。
A.3.2. Using some of the additional fields
A.3.2。 追加分野のいくつかを使用します。
Date: 26 Aug 76 1430 EDT
From: George Jones<Group@Host>
Sender: Secy@SHOST
To: "Al Neuman"@Mad-Host,
Sam.Irving@Other-Host
Message-ID: <some.string@SHOST>
日付: 1976年8月26日の東部夏時間1430From: ジョージ Jones<Group@Host 、gt;、送付者: Secy@SHOST To: 「アル・ヌーマン」@Madホスト、 Sam.Irving@Other-Host Message ID: <some.string@SHOST>。
A.3.3. About as complex as you're going to get
A.3.3。 得るためにあなたが行く予定であるのとほぼ同じくらい複雑です。
Date : 27 Aug 76 0932 PDT
From : Ken Davis <KDavis@This-Host.This-net>
Subject : Re: The Syntax in the RFC
Sender : KSecy@Other-Host
Reply-To : Sam.Irving@Reg.Organization
To : George Jones <Group@Some-Reg.An-Org>,
Al.Neuman@MAD.Publisher
cc : Important folk:
Tom Softwood <Balsa@Tree.Root>,
"Sam Irving"@Other-Host;,
Standard Distribution:
/main/davis/people/standard@Other-Host,
"<Jones>standard.dist.3"@Tops-20-Host>;
Comment : Sam is away on business. He asked me to handle
his mail for him. He'll be able to provide a
more accurate explanation when he returns
next week.
In-Reply-To: <some.string@DBM.Group>, George's message
X-Special-action: This is a sample of user-defined field-
names. There could also be a field-name
"Special-action", but its name might later be
preempted
Message-ID: <4231.629.XYzi-What@Other-Host>
日付: 以下からの1976年8月27日の太平洋夏時間0932 ケン Davis <KDavis@This-Host.This-net 、gt;、subject: Re: RFC送付者の構文: KSecy@Other-Host は以下に答えます。 以下への Sam.Irving@Reg.Organization ジョージ Jones <Group@Some-Reg.An-Org 、gt;、Al.Neuman@MAD.Publisher cc: 重要な人々: トム Softwood <Balsa@Tree.Root 、gt;、「サム・アービング」@Otherホスト;、標準分布: /main/davis/people/standard@Other-Host 、「lt;、ジョーンズ、gt;、standard.dist0.3インチの@Tops-20ホスト>、」、。 コメント: サムは商用で遠くにいます。 彼は、彼のために彼のメールを扱うように私に頼みました。 来週戻るとき、彼は、より正確な説明を提供できるでしょう。 以下に対して <some.string@DBM.Group>、ジョージのメッセージのX特別な動き: これはユーザによって定義された分野名のサンプルです。 また、「特別な動き」というフィールド名があるかもしれませんが、後で名前は先取りされたMessage-IDであるかもしれません: <4231.629.XYzi、-ことは>を@Other接待します。
August 13, 1982 - 39 - RFC #822
1982年8月13日--39--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
B. SIMPLE FIELD PARSING
B.の簡単な分野構文解析
Some mail-reading software systems may wish to perform only
minimal processing, ignoring the internal syntax of structured
field-bodies and treating them the same as unstructured-field-
bodies. Such software will need only to distinguish:
いくつかのメールを閲読するソフトウェア・システムが最小量の処理だけを実行したがっているかもしれません、構造化された分野本体の内部の構文を無視して、同じように不統一な分野本体としてそれらを扱って。 そのようなソフトウェアは、単に区別する必要があるでしょう:
o Header fields from the message body,
o メッセージ本体からのヘッダーフィールド
o Beginnings of fields from lines which continue fields,
o 分野を続けている線からの分野の始まり
o Field-names from field-contents.
o 分野コンテンツからのフィールド名。
The abbreviated set of syntactic rules which follows will
suffice for this purpose. It describes a limited view of mes-
sages and is a subset of the syntactic rules provided in the main
part of this specification. One small exception is that the con-
tents of field-bodies consist only of text:
従う簡略化されたセットの構文の規則はこのために十分でしょう。 それは、mes賢人の限られた視点について説明して、この仕様の主部に提供された構文の規則の部分集合です。 1つの小さい例外は分野本体のまやかしテントがテキストだけから成るということです:
B.1. SYNTAX
B.1。 構文
message = *field *(CRLF *text)
メッセージ=*分野*(CRLF*テキスト)
field = field-name ":" [field-body] CRLF
「分野=フィールド名」:、」 [分野本体] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
「」 : CTLsを除いたどんなCHAR、SPACE、および">"というフィールド名=1*<。
field-body = *text [CRLF LWSP-char field-body]
分野本体=*テキスト[CRLF LWSP-炭の分野本体]
B.2. SEMANTICS
B.2。 意味論
Headers occur before the message body and are terminated by
a null line (i.e., two contiguous CRLFs).
ヘッダーは、メッセージ本体の前に起こって、空行(すなわち、2隣接のCRLFs)によって終えられます。
A line which continues a header field begins with a SPACE or
HTAB character, while a line beginning a field starts with a
printable character which is not a colon.
ヘッダーフィールドを続けている線はSPACEかHTABキャラクタと共に始まります、分野を始める線がコロンでない印刷可能なキャラクタから始まりますが。
A field-name consists of one or more printable characters
(excluding colon, space, and control-characters). A field-name
MUST be contained on one line. Upper and lower case are not dis-
tinguished when comparing field-names.
フィールド名は1つ以上の印刷可能なキャラクタ(コロン、スペース、および制御文字を除いた)から成ります。 1つの線の上にフィールド名を保管しなければなりません。 フィールド名を比較するとき、上側の、そして、より低いケースは不-tinguishedされません。
August 13, 1982 - 40 - RFC #822
1982年8月13日--40--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
C. DIFFERENCES FROM RFC #733
RFC#733からのC.差
The following summarizes the differences between this stan-
dard and the one specified in Arpanet Request for Comments #733,
"Standard for the Format of ARPA Network Text Messages". The
differences are listed in the order of their occurrence in the
current specification.
以下はArpanet RequestでComments#733に指定されたこのstan- dardとものの違いをまとめます、「アーパネットテキスト・メッセージの形式において、標準です」。 違いは現在の仕様による彼らの発生の注文に記載されています。
C.1. FIELD DEFINITIONS
C.1。 フィールド定義
C.1.1. FIELD NAMES
C.1.1。 フィールド名
These now must be a sequence of printable characters. They
may not contain any LWSP-chars.
現在、これらは印刷可能なキャラクタの系列であるに違いありません。 それらはどんなLWSP-雑用も含まないかもしれません。
C.2. LEXICAL TOKENS
C.2。 字句
C.2.1. SPECIALS
C.2.1。 特別番組
The characters period ("."), left-square bracket ("["), and
right-square bracket ("]") have been added. For presentation
purposes, and when passing a specification to a system that
does not conform to this standard, periods are to be contigu-
ous with their surrounding lexical tokens. No linear-white-
space is permitted between them. The presence of one LWSP-
char between other tokens is still directed.
キャラクタの期間、(「」、)、左角括弧、(「[「)、右角括弧(「]」)が加えられる、」 プレゼンテーション目的と仕様をシステムに通過して、それがいつこの規格に従わないか間、期間はそれらの周囲の字句があるcontigu- ousであることです。 どんな直線的に白いスペースもそれらの間で受入れられません。 他の象徴の間の1LWSPの炭の存在はまだ指示されています。
C.2.2. ATOM
C.2.2。 原子
Atoms may not contain SPACE.
原子はSPACEを含まないかもしれません。
C.2.3. SPECIAL TEXT
C.2.3。 特別なテキスト
ctext and qtext have had backslash ("\") added to the list of
prohibited characters.
ctextとqtextはバックスラッシュ(「\」)を禁止されたキャラクタのリストに追加させました。
C.2.4. DOMAINS
C.2.4。 ドメイン
The lexical tokens <domain-literal> and <dtext> have been
added.
字句の<のドメイン文字通りの>と<dtext>は加えられます。
C.3. MESSAGE SPECIFICATION
C.3。 メッセージ仕様
C.3.1. TRACE
C.3.1。 跡
The "Return-path:" and "Received:" fields have been specified.
「リターンパス:」 そして、「受け取りました」。 分野は指定されました。
August 13, 1982 - 41 - RFC #822
1982年8月13日--41--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
C.3.2. FROM
C.3.2。 from
The "From" field must contain machine-usable addresses (addr-
spec). Multiple addresses may be specified, but named-lists
(groups) may not.
“From"分野はマシン使用可能なアドレス(addr仕様)を含まなければなりません。 複数のアドレスが指定されるかもしれませんが、命名されたリスト(グループ)は指定されるかもしれないというわけではありません。
C.3.3. RESENT
C.3.3。 再送します。
The meta-construct of prefacing field names with the string
"Resent-" has been added, to indicate that a message has been
forwarded by an intermediate recipient.
ストリングが「再送されている」前書きフィールド名のメタ構造物は、メッセージが中間的受取人によって転送されたのを示すために加えられます。
C.3.4. DESTINATION
C.3.4。 目的地
A message must contain at least one destination address field.
"To" and "CC" are required to contain at least one address.
メッセージは少なくとも1つの目的地アドレス・フィールドを含まなければなりません。 "To"と「CC」が、少なくとも1つのアドレスを含むのに必要です。
C.3.5. IN-REPLY-TO
C.3.5。 in reply to
The field-body is no longer a comma-separated list, although a
sequence is still permitted.
系列はまだ受入れられていますが、分野本体はもうコンマで切り離されたリストではありません。
C.3.6. REFERENCE
C.3.6。 参照
The field-body is no longer a comma-separated list, although a
sequence is still permitted.
系列はまだ受入れられていますが、分野本体はもうコンマで切り離されたリストではありません。
C.3.7. ENCRYPTED
C.3.7。 コード化されます。
A field has been specified that permits senders to indicate
that the body of a message has been encrypted.
送付者が、メッセージのボディーがコード化されたのを示すことを許可する分野は指定されました。
C.3.8. EXTENSION-FIELD
C.3.8。 拡大分野
Extension fields are prohibited from beginning with the char-
acters "X-".
拡大分野は炭のacters「X」で始まるのが禁止されています。
C.4. DATE AND TIME SPECIFICATION
C.4。 日時の仕様
C.4.1. SIMPLIFICATION
C.4.1。 簡素化
Fewer optional forms are permitted and the list of three-
letter time zones has been shortened.
より少ない任意のフォームが受入れられます、そして、3手紙の時間帯のリストは短くされました。
C.5. ADDRESS SPECIFICATION
C.5。 アドレス指定
August 13, 1982 - 42 - RFC #822
1982年8月13日--42--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
C.5.1. ADDRESS
C.5.1。 アドレス
The use of quoted-string, and the ":"-atom-":" construct, have
been removed. An address now is either a single mailbox
reference or is a named list of addresses. The latter indi-
cates a group distribution.
そして、「引用文字列の使用、」、:、」、-、原子、-、」、:、」 構造物、取り除いてください、そうした。 アドレスは、現在ただ一つのメールボックス参照であるか命名された住所録です。 後者のindi美味aは分配を分類します。
C.5.2. GROUPS
C.5.2。 グループ
Group lists are now required to to have a name. Group lists
may not be nested.
リストが現在名前を持たなければならないグループ。 グループリストは入れ子にされないかもしれません。
C.5.3. MAILBOX
C.5.3。 メールボックス
A mailbox specification may indicate a person's name, as
before. Such a named list no longer may specify multiple
mailboxes and may not be nested.
メールボックス仕様は従来と同様人の名前を示すかもしれません。 そのような命名されたリストは、もう複数のメールボックスを指定しないで、また入れ子にされないかもしれません。
C.5.4. ROUTE ADDRESSING
C.5.4。 ルートアドレシング
Addresses now are taken to be absolute, global specifications,
independent of transmission paths. The <route> construct has
been provided, to permit explicit specification of transmis-
sion path. RFC #733's use of multiple at-signs ("@") was
intended as a general syntax for indicating routing and/or
hierarchical addressing. The current standard separates these
specifications and only one at-sign is permitted.
現在、トランスミッション経路の如何にかかわらず絶対の、そして、グローバルな仕様になるようにアドレスを取ります。 transmis- sion経路の明白な仕様を可能にするために<ルート>構造物を提供しました。 サインの複数の("@")のRFC#733使用はルーティング、そして/または、階層的なアドレシングを示すための一般的な構文として意図しました。 現在の規格はこれらの仕様を切り離します、そして、1つだけがサインで受入れられます。
C.5.5. AT-SIGN
C.5.5。 サイン
The string " at " no longer is used as an address delimiter.
Only at-sign ("@") serves the function.
ストリング、「」 もうアドレスデリミタとして使用されません。 サインだけの("@")は機能を果たします。
C.5.6. DOMAINS
C.5.6。 ドメイン
Hierarchical, logical name-domains have been added.
階層的で、論理的な名前ドメインは加えられます。
C.6. RESERVED ADDRESS
C.6。 予約されたアドレス
The local-part "Postmaster" has been reserved, so that users can
be guaranteed at least one valid address at a site.
地方の部分「郵便局長」は、サイトの少なくとも1つの有効なアドレスをユーザに保証できるように予約されました。
August 13, 1982 - 43 - RFC #822
1982年8月13日--43--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
D. ALPHABETICAL LISTING OF SYNTAX RULES
シンタックス・ルールのD.アルファベット順のリスト
address = mailbox ; one addressee
/ group ; named list
addr-spec = local-part "@" domain ; global address
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
atom = 1*<any CHAR except specials, SPACE and CTLs>
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
; or not sender
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
comment = "(" *(ctext / quoted-pair / comment) ")"
CR = <ASCII CR, carriage return> ; ( 15, 13.)
CRLF = CR LF
ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
date = 1*2DIGIT month 2DIGIT ; day month year
; e.g. 20 Jun 82
dates = orig-date ; Original
[ resent-date ] ; Forwarded
date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
delimiters = specials / linear-white-space / comment
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
domain = sub-domain *("." sub-domain)
domain-literal = "[" *(dtext / quoted-pair) "]"
domain-ref = atom ; symbolic reference
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
アドレスはメールボックスと等しいです。 1つの受け取り人/グループ。 命名されたリストaddr-仕様は地方の部分"@"ドメインと等しいです。 グローバルアドレスアルファー=<、どんなASCII英字>も。 (101-132, 65.- 90.) ; (141-172, 97.-122.) 「原子がどんなCHARも除く1*<と特別番組で、SPACEとCTLs>正統の状態で等しい、=“From"、」、:、」 メールボックス。 「作者/を選抜してください、(「送付者、」 」 : 」 メールボックス;、実際のsubmittor “From"、」 : 」 1#メールボックス、)、。 複数の作者。 どんな送付者CHAR=<もどんなASCII文字>もそうしない、。 ( 0-177, 0.-127.) 「(「*(引用されたctext/組の/コメント)」)」というコメント=CRは<ASCII CR、復帰>と等しいです。 ( 15, 13.) <のどんなCHAR「(「;= >が折り重ねられるかもしれない 」)」という除外、「\」、およびCR、そして、も含んでいる直線的な余白>CRLF=CR LF ctext=CTLはどんなASCIIも制御する<と等しいです。 ( 0- 37, 0.- 31.) キャラクタとDEL>。 ( 177, 127.) =1*2DIGIT月の2DIGITとデートしてください。 日の月の年。 例えば、1982年6月20日はorig-日付と=の日付を入れます。 オリジナル[日付に憤慨している]。 「日付-時間=を進める、[日、」、」、]、日付の時間。 dd mm yy。 「hh:mm:ssグーグーグー日は「月曜日に、」 /「火曜日」/「水曜日」/「木曜日」/「金曜日」/「土曜日」/「Sun」デリミタは直線的な特別番組/余白/コメントの目的地=“To"と等しいこと」と等しいです」 1#アドレス。 「予備選挙/、「憤慨、-、」、」、:、」 「1#アドレス/「cc」」:、」 1#アドレス。 「2番目/、「ccに憤慨する、」、」、:、」 「1#アドレス/"bcc"」:、」 #アドレス。 「盲目の炭素/「-bccに再送」であっていた」:、」 #アドレスDIGITが<と等しい、どんなASCII10進数字>も。 ( 60- 71, 48.- 57.) ドメイン=サブドメイン*、(「. 」 サブドメイン) 「[「*(引用されたdtext/組の)」]」というドメイン文字通りの=ドメイン審判は原子と等しいです。 「[「;= >が折り重ねられるかもしれない 」]」というどんなCHAR除外、「\」というシンボリックな参照dtext=<とも、CRと、直線的な余白>拡大分野を含んでいるのはいずれもさばく正式な拡大としてこの仕様に発表されたドキュメントで定義される<と等しいです。 なにもひもで始まる名前を持たない、「X">"
August 13, 1982 - 44 - RFC #822
1982年8月13日--44--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
field = field-name ":" [ field-body ] CRLF
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
group = phrase ":" [#mailbox] ";"
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
; CRLF => folding
local-part = word *("." word) ; uninterpreted
; case-preserved
LWSP-char = SPACE / HTAB ; semantics = SPACE
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
msg-id = "<" addr-spec ">" ; Unique message id
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
orig-date = "Date" ":" date-time
originator = authentic ; authenticated addr
[ "Reply-To" ":" 1#address] )
phrase = 1*word ; Sequence of words
「分野=フィールド名」:、」 [分野本体]CRLFは=日付をさばきます。 創造時間、ソース。 イドと1つ1の*目的地を書いてください。 アドレスは*任意の分野を必要としました。 「他のもの任意の分野本体=分野ボディーコンテンツ[CRLF LWSP-炭の分野本体]分野ボディーコンテンツは分野本体を作るASCII文字の<と等しいです、原子、引用文字列、および特別番組象徴の組み合わせ、または」 : CTLsを除いたどんなCHAR、SPACE、および「>グループ=句」というテキスト>フィールド名=1*<からも成るのから以下のセクションで定義して、成るとして」 「[#メールボックス]」;、」 「時間=2DIGIT」:、」 2DIGIT[「:」 2DIGIT]。 00:00:00、--、23:59:59HTAB、=<ASCII HT、水平タブ>。 ( 11, 9.) LFは<ASCII LF、ラインフィード>と等しいです。 ( 12, 10.) 直線的な余白=1*([CRLF]LWSP-炭)。 意味論はSPACEと等しいです。 >の折りたたみの地方のCRLF=部分が単語*と等しい、(「. 」 単語、)、。 非解釈しました。 ケースで保存されたLWSP-炭はSPACE / HTABと等しいです。 意味論はSPACEメールボックス=addr-仕様と等しいです。 簡単なアドレス/句のルート-addr。 名前とaddr-仕様メッセージ=は*(CRLF*テキスト)をさばきます。 後のすべて。 最初の空行。 メッセージボディー月が=「12月」msg-イド=「1月」/「2月」/「3月」/「4月」/「5月」/「6月」/「7月」/「8月」/「9月」/「10月」/「11月」/"<"であるというaddr-仕様">"。 「ユニークなメッセージイド任意の分野の=/「メッセージID」」:、」 「msgイド/、「Message IDに憤慨してください」、」、:、」 「msgイド/、「に対して」、」、:、」 *(msg句/イド) 「/「参照」」:、」 *(msg句/イド) 「/「キーワード」」:、」 #「句/「対象」」:、」 *「テキスト/「コメント」」:、」 *「テキスト/「コード化」にされる」:、」 拡大1#2word/分野。 定義された/ユーザ定義された分野になるように。 「先取りされたorig-日付の=が「日付」であったかもしれないなら」:、」 日付-時間創始者=正統。 「認証されたaddr[」 : 」 1#アドレスに「答える」]) =1*単語を言葉で表してください。 単語の続き
August 13, 1982 - 45 - RFC #822
1982年8月13日--45--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
quoted-pair = "\" CHAR ; may quote any char
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
received = "Received" ":" ; one per relay
["from" domain] ; sending host
["by" domain] ; receiving host
["via" atom] ; physical path
*("with" atom) ; link/mail protocol
["id" msg-id] ; receiver msg id
["for" addr-spec] ; initial form
";" date-time ; time received
qtextが<と等しい、<を除いたどんなCHAR、も「>、」、。 =>は折り重ねられた「\」と、CRと、直線的な余白>引用された組=「\」炭を含むことであるかもしれません。 どんな炭の引用文字列も=<が引用するかもしれない、「>*(引用されたqtext/組の)<">" または、通常のqtext、。 「引用された雑用容認された=は「受信」だった」:、」 ; リレー[“from"ドメイン]あたり1つ。 送付ホスト[“by"ドメイン]。 受信ホスト[原子「を通した」の]。 物理的な経路*(“with"原子)。 リンク/メールプロトコル[「イド」msg-イド]。 受信機msgイド[“for" addr-仕様]。 「書式に頭文字をつけてください」;、」 日付-時間。 受付時刻
resent = resent-authentic
[ "Resent-Reply-To" ":" 1#address] )
resent-authentic =
= "Resent-From" ":" mailbox
/ ( "Resent-Sender" ":" mailbox
"Resent-From" ":" 1#mailbox )
resent-date = "Resent-Date" ":" date-time
return = "Return-path" ":" route-addr ; return address
route = 1#("@" domain) ":" ; path-relative
route-addr = "<" [route] addr-spec ">"
source = [ trace ] ; net traversals
originator ; original mail
[ resent ] ; forwarded
SPACE = <ASCII SP, space> ; ( 40, 32.)
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
sub-domain = domain-ref / domain-literal
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
time = hour zone ; ANSI and Military
trace = return ; path to sender
1*received ; receipt tags
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
word = atom / quoted-string
「=に憤慨してください、憤慨、-、正統である、[「回答に憤慨する、」 」 : 」 1#アドレス、)、憤慨、-、正統である、=が等しい、「憤慨、-、」、」、:、」 「メールボックス/、(「送付者に憤慨する、」、」、:、」 「メールボックス、「憤慨、-、」、」、:、」 「1#メールボックス) 日付に憤慨している=、「-再送して、デートしてください」、」、:、」 「日付-時間リターンは「リターンパス」と等しい」:、」 ルート-addr。 返送先ルート=1#@""(ドメイン) ":" ; "<"[ルート]addr-仕様">"経路親類ルート-addr=ソースは[跡]と等しいです。 ネットの縦断創始者。 オリジナルのメール[憤慨します]。 進められたSPACEは<ASCII SP、スペース>と等しいです。 ( 40, 32.) 特別番組は「(「/」)」/"<"/">"/"@"と等しいです。 「引用されたコネが/であったに違いないなら」」 /、」、;、」 / ":" /「\」/<">"。 「使用/に結ぶ」、」 / "[" / "]" ; 単語の中では. ドメインサブドメイン=ドメイン審判/文字通りのテキストは<とどんなCHARで、包含むき出しでも等しいです。 =しかし、>原子、特別番組、CR、およびむき出しのLF、NOT。 コメントとCRLF>を含んでいます。 引用文字列はそうです。 .時間が時間ゾーンと等しいと認めません。 ANSIとMilitary跡はリターンと等しいです。 送付者1*への経路は受信されました。 領収書はAnyがさばくこの仕様に基づき定義されないか、または拡大としてこの仕様に発行されていないユーザの定義された分野=<にタグ付けをします。 そのような分野への名前は、ユニークでなければならなく、発行された拡大>単語=原子/引用文字列によって先取りされるかもしれません。
August 13, 1982 - 46 - RFC #822
1982年8月13日--46--RFC#822
Standard for ARPA Internet Text Messages
アルパインターネットテキスト・メッセージにおいて、標準です。
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
<"> = <ASCII quote mark> ; ( 42, 34.)
「ユタ」/「グリニッジ標準時」のゾーン=。 普遍的な時間。 ノース・アメリカン: 「米国東部標準時」かユタ/「東部夏時間」。 イースタン: - 5 /--4/"CST"/"CDT"。 中央: - 6 /--5/"MST"/"MDT"。 山: - 7 /--「太平洋標準時」か6/「太平洋夏時間」。 太平洋: - 8 /(7 / 1ALPHA) 軍: Zはユタと等しいです。 <「>=<ASCII引用符>」。 ( 42, 34.)
August 13, 1982 - 47 - RFC #822
1982年8月13日--47--RFC#822
一覧
スポンサーリンク
