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

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Zend Frameworkのデータベース接続

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る