RFC733 日本語訳

RFC #   733
NIC # 41952

RFC#733NIC#41952

Obsoletes:  RFC #561  (NIC #18516)
            RFC #680  (NIC #32116)
            RFC #724  (NIC #37435)

時代遅れにします: RFC#561(NIC#18516)RFC#680(NIC#32116)RFC#724(NIC#37435)

                   STANDARD FOR THE FORMAT OF

形式における標準

                  ARPA NETWORK TEXT MESSAGES(1)

アルパネットワークテキスト・メッセージ(1)

                        21 November 1977

1977年11月21日

                               by

by

                        David H. Crocker
                      The Rand Corporation

デヴィッド・H.クロッカーランド研究所

                         John J. Vittal
                  Bolt Beranek and Newman Inc.

ジョンJ.VittalボルトBeranekとニューマン株式会社

                        Kenneth T. Pogran
              Massachusets Institute of Technology

ケネスT.Pogranマサチューセット族工科大学

                   D. Austin Henderson, Jr.(2)
                  Bolt Beranek and Newman Inc.

D.オースチンヘンダーソン、Jr.(2)ボルトBeranek、およびニューマン株式会社

_________________________________________________________________
(1)This work was  supported  by  the  Defense  Advanced  Research
Projects Agency of the Department of Defense, under contract Nos.
N00014-75-C-0661, MDA903-76-C-0212, and DAHC15-73-C0181.

_________________________________________________________________ (1)この仕事は国防総省国防高等研究計画庁によってサポートされました、契約No.のN00014 75C0661、MDA903 76C0212、およびDAHC15-73-C0181の下で。

(2)The authors' postal  addresses  are:   D.  Crocker,  The  Rand
Corporation,  Information  Sciences  Dept.,  1700 Main St., Santa
Monica, California 90406; J.  Vittal  &  D.  A.  Henderson,  Bolt
Beranek & Newman, 50 Moulton St., Cambridge, Massachusetts 02138;
and  K.  Pogran,  MIT  Laboratory  for  Computer   Science,   545
Technology  Square, Cambridge, Massachusetts 02139.  The authors'
ARPANET addresses are:  DCrocker at  Rand-Unix,  Vittal  at  BBN-
TenexD, Pogran at MIT-Multics, and Henderson at BBN-TenexD.

                              -iii-

(2)作者の郵便の宛先は以下の通りです。 D。 サンタモニカ、カリフォルニア クロッカー、ランド研究所、情報科学部、1700の主な通り、90406。 J。 50モールトン通り、ケンブリッジ、マサチューセッツ VittalとD.A.ヘンダーソンとボルトBeranekとニューマン、02138。 ケンブリッジ、マサチューセッツ K.Pogran、MITコンピュータサイエンス研究所、545技術正方形、02139。 作者のアルパネットアドレスは以下の通りです。 底ならし革unixにおけるDCrocker、BBN- TenexDのVittal、MIT-MulticsのPogran、およびBBN-TenexDのヘンダーソン。 -iii

                             PREFACE

序文

     ARPA's  Committee  on  Computer-Aided  Human   Communication
(CAHCOM)  wishes  to promulgate a standard for the format of ARPA
Network text message (mail) headers which  will  reasonably  meet
the  needs  of  the  various  message  service  subsystems on the
Network today.  The  authors  of  this  document  constitute  the
CAHCOM  subcommittee charged with the task of developing this new
standard.

コンピュータで支援されたHuman Communication(CAHCOM)の上のARPAのCommitteeは今日Networkで合理的に様々なメッセージサービスサブシステムの需要を満たすアーパネットテキストメッセージ(メール)ヘッダーの形式の規格について公表したがっています。 このドキュメントの作者はこの新しい規格を開発するタスクを課されたCAHCOM小委員会を構成します。

     Essentially, we specify a revision to  ARPANET  Request  for
Comments (RFC) 561, "Standardizing Network Mail Headers", and RFC
680, "Message Transmission Protocol".  This revision removes  and
compacts  portions  of  the  previous  syntax  and  adds  several
features to network address  specification.   In  particular,  we
focus  on  people  and  not  mailboxes  as  recipients  and allow
reference to stored address lists.   We  expect  this  syntax  to
provide  sufficient  capabilities  to  meet most users' immediate
needs and, therefore, give developers enough  breathing  room  to
produce  a new mail transmission protocol "properly".  We believe
that there is enough of a consensus in the Network  community  in
favor  of such a standard syntax to make possible its adoption at
this time.  An earlier draft of this specification was  published
as  RFC  #724, "Proposed Official Standard for the Format of ARPA
Network Messages"  and  contained  extensive  discussion  of  the
background and issues in ARPANET mail standards.

本質的には、Comments(RFC)561、「ネットワークメールヘッダを標準化します」、およびRFC680、「メッセージトランスミッションプロトコル」として私たちはアルパネットRequestに改正を指定します。 この改正は、取り外して、前の構文の部分を固まらせて、いくつかの特徴をネットワークアドレス指定に追加します。 私たちは、特に、受取人としてメールボックスではなく、人々に焦点を合わせて、保存された住所録に参照を許します。 私たちは、この構文が「適切に」新しいメールトランスミッションプロトコルを作成する余地を吸い込みながらユーザの即座の需要を最も満たして、したがって、十分を開発者に与えることができるくらいの能力を提供すると予想します。 私たちは、今回の採用を可能にするそのような標準の構文を支持してNetwork共同体のコンセンサスが十分あると信じています。 この仕様の以前の草稿は、RFC#724として発行されて、「アーパネットメッセージの形式の公式の規格を提案し」て、アルパネットメール規格における、バックグラウンドと問題の大規模な議論を含みました。

     This specification was developed  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,
participated in this discussion and we would like to  acknowledge
their  considerable  efforts.   The  syntax  of  the standard 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  which  compacts  the
specification and allows increased comprehensibility.

1年のコース、アルパネットメール環境を使用する上でこの仕様は、含まれるべき能力について議論するのに継続しているフォーラムを提供するためにそれ自体で開発されました。 国中から、20人以上の個人がこの議論に参加しました、そして、彼らのかなりの取り組みを承認したいと思います。 規格の構文は元々、BN記法(BNF)メタ言語で指定されました。 SRIインターナショナルのケンL.Harrenstienは仕様を固まらせて、増強された分かり易さを許容する増大しているBNFにBNFを再コード化するのに責任がありました。


                               -v-

-v

                            CONTENTS

コンテンツ

PREFACE..................................................... iii

PREFACE… iii

Section
   I.  INTRODUCTION.........................................   1

セクションI.序論… 1

  II.  FRAMEWORK............................................   2

II。 フレームワーク… 2

 III.  SYNTAX...............................................   4
       A. Notational Conventions............................   4
       B. Lexical Analysis of Messages......................   5
       C. General Syntax of Messages........................  13
       D. Syntax of General Addressee Items.................  15
       E. Supporting Constructs.............................  15

III。 構文… 4 A.の記号法のコンベンション… 4 メッセージのB.字句解析… メッセージの5のC.の一般構文… 一般受け取り人項目の13D.構文… 15 E. 構造物をサポートします… 15

  IV.  SEMANTICS............................................  17
       A. Address Fields....................................  17
       B. Reference Specification Fields....................  22
       C. Other Fields and Syntactic Items..................  23
       D. Dates and Times...................................  24

IV。 意味論… 17 A. 分野を扱ってください… 17 B.関連仕様書分野… 22 C. 他の分野と構文の項目… 23D.日付と回… 24

   V.  EXAMPLES.............................................  25
       A. Addresses.........................................  25
       B. Address Lists.....................................  26
       C. Originator Items..................................  26
       D. Complete Headers..................................  28

V.の例… 25 A.アドレス… 25 B. リストを扱ってください… 26 C.創始者項目… 26 D. ヘッダーを完成してください… 28

Appendix
   A.  ALPHABETICAL LISTING OF SYNTAX RULES.................  31
   B.  SIMPLE PARSING.......................................  35

構文の付録A.アルファベット順のリストは統治されます… 31 B.の簡単な構文解析… 35

BIBLIOGRAPHY................................................  37

図書目録… 37


Standard for the Format of Text Messages                        1
I. Introduction

テキスト・メッセージ1I.序論の形式において、標準です。

                        I.  INTRODUCTION

I.序論

     This standard specifies a syntax for text messages which are
passed between computer users within the framework of "electronic
mail".  The standard supersedes the informal standards  specified
in  ARPANET  Request  for  Comments  numbers  561, "Standardizing
Network Mail Headers", and 680, "Message Transmission  Protocol".
In  this  document,  a  general framework is first described; the
formal syntax is then specified, followed by a discussion of  the
semantics.  Finally, a number of examples are given.

この規格は「電子メール」のフレームワークの中でコンピュータユーザの間で通過されるテキスト・メッセージに構文を指定します。 規格はComments No.561のためのアルパネットRequest、「ネットワークメールヘッダを標準化します」、および680、「メッセージトランスミッションプロトコル」で指定された非公式の規格に取って代わります。 本書では、一般的なフレームワークは最初に、説明されます。 そして、意味論の議論があとに続いていて、正式な構文は指定されます。 最終的に、多くの例が出されます。

     This specification is intended strictly as a  definition  of
what  is  to  be  passed between hosts on the ARPANET.  It is NOT
intended to dictate either features which systems on the  Network
are  expected  to support, or user interfaces to message creating
or reading programs.

この仕様はアルパネットでホストの間で通過されることになっているべきものに関する定義として厳密に意図します。 それがNetworkの上のシステムがサポートすると予想される特徴かユーザインタフェースのどちらかをプログラムを作成するか、または読むメッセージに書き取ることを意図しません。

     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.  These simplifications facilitate the formal
specification and indicate what the OFFICIAL  semantics  are  for
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。 メッセージを情報の正式に構造化された成分に複雑で豊かに作ることができるか、または小さく簡単に保つことができます、最小そのような情報で。 また、規格はメッセージにおける、異なった視覚形式の解釈を簡素化します。 これらの簡素化は、形式仕様を容易にして、OFFICIAL意味論がメッセージのための何であるかを示します。 メッセージの視覚局面だけが影響を受けますが、それの中の情報の解釈は影響を受けません。 作成者は、そのような視覚区別を保有するのを選ぶかもしれません。


Standard for the Format of Text Messages                        2
II. Framework

テキスト・メッセージ2IIの形式において、標準です。 フレームワーク

                         II.  FRAMEWORK

II。 フレームワーク

     Since there are many message systems which exist outside the
ARPANET environment, as well as those within it, it may be useful
to consider the general framework, and resulting capabilities and
limitations, provided by this standard.

それの中にアルパネット環境、およびそれらの外に存在する多くのメッセージシステムがあるので、この規格によって提供された一般的なフレームワーク、結果として起こる能力、および限界を考えるのは役に立つかもしれません。

     Messages are expected to  consist  of  lines  of  text.   No
special provisions are made, at this time, for encoding drawings,
facsimile, speech, or structured text.

メッセージがテキストの系列から成ると予想されます。 特別条項は、全くこのとき、図面、ファクシミリ、スピーチ、または構造化されたテキストをコード化するために作られません。

     No significant consideration has been given to questions  of
data   compression   or   transmission/storage  efficiency.   The
standard, in fact, tends to be very free with the number of  bits
consumed.   For  example, field names are specified as free text,
rather than special terse codes.

データ圧縮かトランスミッション/ストレージ効率の質問に対してどんな重要な考慮も払っていません。 事実上、規格は、ビットの数が消費されている状態で非常に自由である傾向があります。 例えば、フィールド名は特別な簡潔なコードよりむしろ無料のテキストとして指定されます。

     A general "memo" framework is  used.   That  is,  a  message
consists  of some information, in a rigid format, followed by the
main part of the message, which is text and whose format  is  not
specified  in this document.  The syntax of several fields of the
rigidly-formated  ("header")   section   is   defined   in   this
specification;  some of the header fields must be included in all
messages.  The syntax  which  distinguishes  between  headers  is
specified  separately  from  the  internal  syntax for particular
headers.  This separation is intended to allow  extremely  simple
parsers  to operate on the overall structure of messages, without
concern  for  the  detailed  structure  of  individual   headers.
Appendix B is provided to facilitate construction of these simple
parsers.  In addition to the fields specified in  this  document,
it  is  expected  that  other fields will gain common use.  User-
defined header fields allow systems to extend their functionality
while  maintaining  a uniform framework.  The approach is similar
to that of the TELNET protocol,  in  that  a  basic  standard  is
defined  which  includes  a  mechanism for (optionally) extending
itself.  As necessary, the authors of this document will regulate
the  publishing  of  specifications for these "extension-fields",
through the same mechanisms used to publish this document.

一般的な「メモ」フレームワークは使用されています。 すなわち、メッセージは何らかの情報から成ります、メッセージの主部があとに続いたテキストであり、形式が本書では指定されない堅い形式で。 厳格にformatedされた(「ヘッダー」)セクションのいくつかの分野の構文はこの仕様に基づき定義されます。 すべてのメッセージにヘッダーフィールドのいくつかを含まなければなりません。 ヘッダーを見分ける構文は別々に内部の構文から特定のヘッダーに指定されます。 この分離が、非常に簡単なパーサがメッセージの全体的な構造を作動させるのを許容することを意図します、個々のヘッダーの詳細な構造に関する心配なしで。 これらの簡単なパーサの工事を容易にするために付録Bを提供します。 本書では指定された分野に加えて、他の分野が一般の使用を獲得すると予想されます。 ユーザの定義されたヘッダーフィールドで、システムは一定のフレームワークを維持している間、それらの機能性を広げることができます。 アプローチはTELNETプロトコルのものと同様です、基本的な規格が定義されるので((任意に)広がるためのメカニズム自体を含んでいます)。 必要に応じて、このドキュメントの作者はこれらの「拡大分野」のための仕様の出版を規制するでしょう、このドキュメントを発表するのに使用される同じメカニズムを通して。

     Such a  framework  severely  constrains  document  tone  and
appearance  and  is  primarily useful for most intra-organization
communications  and  relatively   structured   inter-organization
communication.   A more robust environment might allow for multi-
font, multi-color, multi-dimension encoding  of  information.   A
less  robust  environment,  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
to paper-based communication, it is interesting to note that  the

Standard for the Format of Text Messages                        3
II. Framework

そのようなフレームワークは、厳しくドキュメントトーンと外観を抑制して、主としてほとんどのイントラ組織コミュニケーションと比較的構造化された相互組織コミュニケーションの役に立ちます。 より強健な環境は情報のマルチフォントの、そして、マルチ色の、そして、マルチ寸法のコード化を考慮するかもしれません。 ほとんどの単一マシンメッセージシステムでのプレゼントのように、それほど強健でない環境は、より厳しく、分野を加える能力と特定の分野を含んでいるという決定を抑制するでしょう。 紙のベースのコミュニケーションと対照してそれに注意するのがおもしろい、Text MessagesのFormatのためのStandard、3、II フレームワーク

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.

メッセージのRECEIVERは並はずれた量のコントロールをメッセージの外観に及ぼすことができます。 メッセージ受信機に利用可能な実際のコントロールの量がそれらの個々のメッセージシステムの能力次第であります。


Standard for the Format of Text Messages                        4
III. Syntax

テキスト・メッセージ4IIIの形式において、標準です。 構文

                          III.  SYNTAX

III。 構文

     This  syntax  is  given  in  five  parts.   The  first  part
describes  the  notation  used  in the specification.  The second
part describes the base-level lexical analyzers  which  feed  the
higher-level  parser  described  in the succeeding sections.  The
third part gives a  general  syntax  for  messages  and  standard
header  fields;  and  the  fourth  part  specifies  the syntax of
addresses.  A final part  specifies  some  general  syntax  which
supports the other sections.

5つの部品でこの構文を与えます。 最初の部分は仕様で使用される記法を説明します。 第二部は続くセクションで説明されたよりハイレベルのパーサを与える基準面の語彙分析器について説明します。 3番目の部分はメッセージと標準のヘッダーフィールドのために一般的な構文を与えます。 そして、4番目の部分はアドレスの構文を指定します。 最終部分は他のセクションをサポートする何らかの一般的な構文を指定します。

A.  NOTATIONAL CONVENTIONS

A。 記号法のコンベンション

These specifications are made in an  augmented  Backus-Naur  Form
(BNF).  Differences  from  standard  BNF  involve  the  naming of
rules, the indication of repetition and of "local" alternatives.

これらの仕様は増大しているBN記法(BNF)で作られています。 標準のBNFからの違いは規則の命名、反復と「地方」の代替手段のしるしにかかわります。

1.  Rule naming

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.  Parentheses:  Local alternatives

2. 括弧: ローカルの代替手段

Elements enclosed in parentheses are treated as a single element.
Thus,  "(elem  (foo  /  bar)  elem)" allows "(elem foo elem)" and
"(elem bar elem)".

括弧に同封された要素はただ一つの要素として扱われます。 したがって、「(elem(foo/バー)elem)」は「(elem foo elem)」と「(elemバーelem)」を許容します。

3.  * construct:  Repetition

3. * 以下を組み立ててください。 反復

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.

Standard for the Format of Text Messages                        5
III. Syntax
  A. Notational Conventions

少なくとも<l>とほとんどの<mでは、要素の>発生を示します。 「デフォルト値が0であり、無限がそう、それ、」 *、(要素) 」 ゼロを含むどんな数も許容します。 「1*要素」は少なくとも1を必要とします。 そして、「1*2element」は1か2を許容します。 テキスト・メッセージ5IIIの形式において、標準です。 構文のA.の記号法のコンベンション

4.  <number>element

4. <数の>要素

"<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つの英字です。

5.  # construct:  Lists

5. # 以下を組み立ててください。 リスト

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
element  is  required,  at  least  one  non-null  element must be
present.

少なくとも<l>と高々<m>を示して、要素でありそれぞれが1つ以上のコンマで分離した、(「」、) これで、普通の形式のリストは非常に簡単になります。 aが統治する、'、(要素*、(「」、要素) '「1#要素」として示すことができます。 この構造物が中古であって、どこでも、ヌルであるところでは、要素が許容されていますが、要素の現在のカウントに貢献しないでください。 すなわち、「(要素)、(要素) 」 受入れられますが、2つの要素だけにみなします。 したがって、少なくとも1つの要素が必要であるところでは、少なくとも1つの非ヌル要素が存在していなければなりません。

6.  [optional]

6. [任意]です。

Square  brackets  enclose  optional  elements;  "[foo  bar]"   is
equivalent to "*1(foo bar)".

角括弧は随意的な要素を同封します。 「「[fooバー]」は」 *1(fooバー)に同等です。」

7.  ; Comments

7. ; コメント

A semi-colon, set off some distance to the right  of  rule  text,
starts  a  comment which continues to the end of line.  This is a
simple way  of  including  useful  notes  in  parallel  with  the
specifications.

規則テキストの右への何らかの距離に引きたったセミコロンは行末に続くコメントを始めます。 これは仕様と平行して役に立つ注意を含む簡単な方法です。

B.  LEXICAL ANALYSIS OF MESSAGES

B。 メッセージの字句解析

1.  General Description

1. 概説

A message consists of headers and, optionally,  a  body  (i.e.  a
series of text lines).  The text part is just a sequence of lines
containing ASCII characters; it is separated from the headers  by
a null line (i.e., a line with nothing preceding the CRLF).

メッセージはヘッダーと任意にボディー(すなわち一連のテキスト系列)から成ります。 テキスト部分はただASCII文字を含む系列の系列です。 空行(すなわち、何もCRLFに先行していない系列)によってそれはヘッダーと切り離されます。


Standard for the Format of Text Messages                        6
III. Syntax
  B. Lexical Analysis

テキスト・メッセージ6IIIの形式において、標準です。 構文B.字句解析

a.  Folding and unfolding of headers

a。 ヘッダーの折り重なりと開き

    Each header item can be viewed as a single, logical  line  of
    ASCII characters.  For convenience, the field-body portion of
    this conceptual entity can  be  split  into  a  multiple-line
    representation  (i.e.,  "folded").   The general rule is that
    wherever there can be linear-white-space  (NOT  simply  LWSP-
    chars), a CRLF immediately followed by AT LEAST one LWSP-char
    can instead be inserted.  (However, a header's name  and  the
    following  colon  (":"),  which occur at the beginning of the
    header item, may NOT be folded onto multiple  lines.)   Thus,
    the single line

ASCII文字の単一の論理行としてそれぞれのヘッダーの品目を見なすことができます。 便利において、この概念的な実体の分野本体部分を複数の系列表現(すなわち、「折り重なる」)に分けることができます。 直線的な余白(単にLWSP雑用でない)があることができます、とCRLFがすぐにどこで1つがLWSP炭にするAT LEASTで続いたとしても代わりに挿入できる一般的な規則があります。 しかしながら、(ヘッダーの名前と以下のコロン、(「:」、)、ヘッダーの品目の始めに起こって、複数の系列に折り重ねられないかもしれないもの)。 その結果、単線

       To:  "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN

To: ホスト>、BBNのJJVの「ジョーDokesとJ.ハーヴェイ」<ddd

    can be represented as

表すことができます。

       To:  "Joe Dokes & J. Harvey" <ddd at Host>,
            JJV at BBN

To: ホスト>、BBNのJJVの「ジョーDokesとJ.ハーヴェイ」<ddd

    and

そして

       To:  "Joe Dokes & J. Harvey"
                        <ddd at Host>,
        JJV at BBN

To: ホスト>、BBNのJJVの「ジョーDokesとJ.ハーヴェイ」<ddd

    and

そして