RFC773 日本語訳

Network Working Group                                            V. Cerf
Request for Comments: 773                                          DARPA
                                                            October 1980

コメントを求めるワーキンググループV.サーフの要求をネットワークでつないでください: 773 DARPA1980年10月

          COMMENTS ON NCP/TCP MAIL SERVICE TRANSITION STRATEGY

NCP/TCPメールサービス変遷戦略のコメント

INTRODUCTION

序論

   This memo reviews and expands on the mail service transition plan
   [20].

このメモは、メールサービス変遷プラン[20]を見直して、詳述します。

   The principal aim of the plan is to provide for the orderly support
   of the most commonly used network service (mail) during the period of
   transition from ARPANET to Internet Protocol-based operation.

プランの主な目的はアルパネットからプロトコルベースのインターネット操作までの過渡期の間、最も一般的に使用されたネットワーク・サービス(メール)の規則的なサポートに備えることです。

   The goal of the transition is, at the end, to provide in the internet
   environment service which is equivalent to or better than what has
   been available in the ARPANET environment.  During the interim
   period, when both internet and the older ARPANET-based protocols are
   in use, the goal of the transition is to minimize user impact and, to
   the extent possible, to minimize software development or modification
   required to deal with transitional problems.

終わりに、アルパネット環境で、同等であるか、または利用可能であることより良いインターネット環境サービスに提供するために、変遷の目標はあります。 当座の期間、変遷の目標はユーザ衝撃を最小にすることでした、そして、可能な範囲内で、ソフトウェア開発か変更を最小にするのは過渡的な問題に対処するのを必要としました。(その時、インターネットと、より古いアルパネットベースのプロトコルの両方が使用中です)。

   It is assumed that the reader is familiar with both the ARPANET and
   internet protocol hierarchies [1-17].  The internet hierarchy is
   designed to interface to many different packet networks (e.g., packet
   satellite, packet radio, Ethernet, LCS Ring net, X.25 public
   nets, ...), while the ARPANET hierarchy is limited to ARPANET IMPs
   (This is less true of the levels above NCP, but NCP itself is closely
   bound to ARPANET services).

読者がアルパネットとインターネットプロトコル階層[1-17]の両方に詳しいと思われます。 インターネット階層構造は多くの異なったパケット網に連結するように設計されています(例えば、パケット衛星、パケットラジオ、イーサネット、LCS Ringネット、X.25公衆は網状になります…)、アルパネット階層構造はアルパネットIMPsに制限されますが(これがレベルに関してそれほどNCPを超えて本当ではありませんが、NCP自体は密接にアルパネットサービスに縛られます)。

   The objective of the transition plan is to specify means by which the
   ARPANET electronic mail services may be supported across the boundary
   between the purely ARPANET environment and the more general internet
   environment during the period of transition by ARPANET hosts to the
   richer internet world.

変遷プランの目的がアルパネット電子メールサービスが間に境界の向こう側に支持されるかもしれない手段を指定することである、純粋にアルパネット環境、そして、より豊かなインターネット世界へのアルパネットホストによる過渡期の間の、より一般的なインターネット環境。

ELECTRONIC MESSAGE SERVICES

電子メッセージサービス

   DARPA is beginning a new phase of research into automatic electronic
   message handling systems.  Ultimately, it is intended that electronic
   messages incorporate multiple media such as text, facsimile,
   compressed digitized voice, graphics and so on.  Success in this new
   research will require substantial progress in developing multimode
   user interfaces to computer-based services (voice input/output,
   graphics, tablet/light pen, facsimile input/output, video/bit mapped
   displays, ...).

DARPAは自動電子メッセージハンドリングシステムの研究の新しいフェーズを始めています。結局、電子メッセージがテキスト、ファクシミリ、圧縮されたデジタル化している声、グラフィックスなどなどのマルチメディアを取り入れることを意図します。 この新しい研究の成功はコンピュータベースのサービスにマルチモードユーザインタフェースを開発する際に具体的進展を必要とするでしょう(音声入出力、グラフィックス、タブレット/ライトペン、ファクシミリ入力/出力、ビデオ/ビットは表示を写像しました…)。

   At the same time, progress must be made towards an environment based
   on internet protocols so as to avoid confining the results of the

同時に、進歩を結果を閉じ込めるのを避けるためにインターネットプロトコルに基づく環境に向かってしなければなりません。

                                   1


1

October 1980                                                     RFC 773
Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPの1980年10月のRFC773コメントはサービス変遷戦略を郵送します。

   multimedia effort to any one network.  As a result, DARPA is planning
   to make several transitions over the next few years, from the
   existing, text-based ARPANET electronic message system to an
   internet-based, multimedia electronic message system.

どんなネットワークへのマルチメディアの努力。 その結果、DARPAは、この数年間にわたっていくつかの変遷をするのを計画しています、既存の、そして、テキストベースのアルパネット電子メッセージシステムからインターネットベースの、そして、マルチメディア電子のメッセージシステムまで。

   This paper addresses only the first of the transitions from NCP-based
   text mail to TCP-based multimedia mail.  The transition to the new
   multimedia mail system [7,19] lies ahead, but need not be planned in
   detail until we have some experience with the basic concepts.  This
   first step only provides for the transition to TCP-based text mail.

この論文はNCPベースのテキストメールからTCPベースのマルチメディアメールまでの変遷の1番目だけを記述します。 新しいマルチメディアメールシステム[7、19]への変遷は、目の前に位置しますが、私たちには基本概念の何らかの経験があるまで、詳細に計画される必要はありません。 この第一歩はTCPベースのテキストメールへの変遷に備えるだけです。

   The basic ground rules for transition from ARPANET-based electronic
   mail to internet electronic mail are the following:

アルパネットベースの電子メールからインターネット電子メールまでの変遷のための基本的な基本規則は以下です:

      1.  ARPANET mailbox names must continue to work correctly.

1. アルパネットメールボックス名は、正しく働き続けなければなりません。

      2.  No change required to mail editors which parse message headers
          to compose replies and the like.

2. どんな変化も構成するためにメッセージヘッダーを分析するエディタに回答と同様のものを郵送するのが必要ではありません。

      3.  Accommodation of non-ARPANET mailbox designators without
          change to the header parsing and checking mechanisms of mail
          composition programs.

3. ヘッダーへの変化がメール構成プログラムのメカニズムを分析して、チェックすることのない非アルパネットメールボックス指示子の宿泊設備。

      4.  Automatic forwarding of messages between NCP and TCP
          environments without user intervention.

4. NCPとTCP環境の間のユーザ介入のないメッセージの自動推進。

      5.  During the transition, old style mail mechanisms must still
          work.

5. 変遷の間、古いスタイルメールメカニズムはまだ動作しなければなりません。

ELECTRONIC MESSAGE MECHANISMS

電子メッセージメカニズム

   In order to make progress at all, it has been necessary to postulate
   fairly sophisticated changes to the "mailer" function which accepts
   as input an electronic text message and causes it to be delivered to
   the destination (or to an intermediate forwarder).

全く進展するように、電子出版物メッセージを入力して、それが送付先に届けられることを引き起こすとき(または中間的混載業者に)受け入れる「郵送者」機能への洗練された変化を公正に仮定するのが必要です。

   We also posit the existence of special, well-known mail forwarding
   hosts on the ARPANET which are responsible for accepting messages
   from NCP (TCP)-based message senders and forwarding them to
   TCP (NCP)-based message receivers.

また、私たちは特別で、周知のメール転送ホストの存在をアルパネットに置きます(NCPの(TCP)ベースのメッセージ送付者からメッセージを受け入れて、TCPの(NCP)ベースのメッセージ受信機に彼らを送るのに責任があります)。

   In the ARPANET, electronic messages are transported via special
   procedures of the File Transfer Protocol:  MAIL and MLFL.  The former
   method sends electronic messages via the FTP Telnet command channel

アルパネットでは、電子メッセージはFile Transferプロトコルの特別な手順で輸送されます: メールとMLFL。 前の方法はFTP Telnet指揮系統で電子メッセージを送ります。

                                   2


2

RFC 773                                                     October 1980
                    Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPのRFC773 1980年10月コメントがサービス変遷戦略を郵送します。

   while the latter achieves this by actual file transfer.  In both
   cases, it is generally assumed that the receiving FTP server is
   colocated with the destination mailbox.

後者は実際のファイル転送でこれを実現しますが。 どちらの場合も、一般に、受信FTPサーバがあて先メールボックスでcolocatedされると思われます。

   Thus, the sending procedure identifies to the receiver the
   destination mailbox identifier, but not the destination host (or
   network) identifier.  For example, messages sent from Postel at
   USC-ISIF to Adams at USC-ISIA would arrive at ISIA with an indicator
   "Adams" but no indication of "ISIA".  This creates some problems when
   messages must be staged at an intermediate host for further
   processing, as is the case when moving from an NCP-based sender to a
   TCP-based receiver, or vice-versa.  Similar considerations arise when
   dealing with compatible, but different, message systems requiring
   re-formatting of messages at intermediate points.

したがって、送付手順はあて先ホスト(または、ネットワーク)識別子ではなく、あて先メールボックス識別子を受信機に特定します。 例えば、USC-ISIFのポステルからUSC-ISIAのアダムスに送られたメッセージはインディケータ「アダムス」にもかかわらず、"ISIA"のどんなしるしでもISIAに到着しないでしょう。 さらなる処理のために中間的ホストでメッセージを上演しなければならないとき、これはいくつかの問題を生じさせます、NCPベースの送付者からTCPベースの受信機まで動くとき、そうであるように、逆もまた同様です。 中間的のメッセージの再形式ポイントを必要とするコンパチブル、しかし、異なったメッセージシステムに対処するとき、同様の問題は起こります。

   In the following paragraphs, a mechanism is proposed for dealing with
   the naming, addressing and routing [18] of messages between systems.

以下のパラグラフで、メカニズムは命名に対処するために提案されます、メッセージの[18]をシステムの間に記述して、発送して。

   At the source, it is assumed that the user has prepared the text of
   the message (including "To:" and "CC:" fields) in the conventional
   way [12].  The mailbox identifiers will continue to exhibit the
   format:

ソースでは、ユーザが従来の方法[12]でメッセージの本文を準備したと(「To:」と「CC:」分野を含んでいます)思われます。 メールボックス識別子は、形式を示し続けるでしょう:

      User@Host

User@Host

   but "host" may in fact be a compound name (which is not necessarily
   parsed), such as:

しかし、事実上、「ホスト」は以下などの化合物名であるかもしれません(必ず分析されるというわけではありません)。

      USC-ISIA
      ARPANET-ISIA
      SATNET-NDRE
      PPSN-RSRE
      HOST1.SRINET
      LCSNET/MAILROOM

USC-ISIAアルパネット-ISIA SATNET-NDRE PPSN-RSRE HOST1.SRINET LCSNET/郵便室

   or even the name of an organization, such as:

または、以下などの組織の名前さえ

      BBN
      ARPA
      MIT
      SRI

BBNアルパMIT様

   The only restriction is that the "@" not appear in either "user" or
   "host" strings in the mailbox identifier.

唯一の制限は"@"がメールボックス識別子の「ユーザ」か「ホスト」ストリングのどちらかに現れないということです。

   During message composition, the "user" or "host" portions of the

構成、「ユーザ」または「ホスト」が分配するメッセージ

                                   3


3

October 1980                                                     RFC 773
Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPの1980年10月のRFC773コメントはサービス変遷戦略を郵送します。

   mailbox identifier may be verified for correctness (or at least for
   validity).  The "user" string may incorporate parenthetical
   information such as

メールボックス識別子は正当性(または少なくとも正当性のために)のために確かめられるかもしれません。 ストリングが挿入句の情報を取り入れるかもしれない「ユーザ」

      RAK(Richard A. Karp)@SU-AI

RAK(リチャード・A.カープ)@SU AI

   as is currently allowed.

現在許容されているように。

   After composition, messages are either sent immediately or left as
   "unsent mail" files to be sent later by mailer demons.  The actual
   sending process uses the "host" string to determine where and how to
   send the message.

構成の後に、後で郵送者悪霊によって送られるように「unsentメール」がファイルされるとき、メッセージをすぐに、送るか、または出ます。 実際の送付の過程は、どことメッセージを送る方法を決定するかに「ホスト」ストリングを使用します。

NEW MAIL MECHANISMS

新しいメールメカニズム

   At this point, we encounter the first critical new requirement to
   support the transition plan.  A new table is needed within the mailer
   or in the host supporting the mailer or accessible to the mailer via
   the internet name server (for instance).  This table must provide for
   mapping of the "host" string into an internet destination address
   (i.e., 32 bits: 8 bits of net, 24 bits of host), and must also
   indicate whether the destination is NCP or TCP capable.

ここに、私たちは変遷プランを支持するという最初の批判的な新しい要件に遭遇します。 新しいテーブルは、郵送者以内か郵送者を支持しているホストで必要であるか、または郵送者に、インターネットネームサーバ(例えば)でアクセスしやすいです。 このテーブルは、インターネット送付先アドレス(すなわち、32ビット: ネットの8ビット、ホストの24ビット)に「ホスト」ストリングに関するマッピングに備えなければならなくて、また、目的地がNCPかTCPできるかどうかを示さなければなりません。

   In the event that the source and destination hosts do not have a
   compatible host level protocol (e.g. source is NCP only, destination
   is TCP only) then the message must be passed to a "forwarder" which
   can stage the transport by accepting via one protocol and forwarding
   by another.

ソースとあて先ホストがコンパチブルホストレベルについて議定書の中で述べさせない場合(例えば、ソースがNCP専用である、目的地はTCP専用です)、次に、「混載業者」にメッセージを通過しなければなりません(別のものによる1つのプロトコルで受け入れて、推進で輸送を上演できます)。

   This leads to a problem for the forwarding host since the basic FTP
   mail mechanism sends only the "user" portion of the mailbox
   identifier ("user@host") because the assumption is that the "host" is
   the destination.  In the case of forwarding, the "host" is not the
   forwarder.  Even if we cleverly arrange for "host" to translate into
   the internet address of a forwarder, we will have two problems.
   First, the forwarder may need the "host" information to figure where
   now to forward the message and second, depending on which network the
   source is in, "host" may need to translate into different forwarder
   addresses.  The latter observation raises the spectre of many
   different mappings of a given "host" string which would require
   different tables for different mail sources.  This would lead to
   considerable complexity in the maintenance and distribution of tables
   of forwarder addresses.  Furthermore, a single-entry table mapping
   "host" to forwarder would limit reliability since only one forwarder
   would be bound to serve a giver "host".

それが「ホスト」であるという仮定が目的地であるので基本的なFTPメールメカニズムがメールボックス識別子(" user@host ")の「ユーザ」部分だけを送るので、これは推進ホストのための問題を引き起こします。 推進の場合では、「ホスト」は混載業者ではありません。 「ホスト」が混載業者のインターネットアドレスに翻訳するように賢く手配しても、私たちには2つの問題があるつもりです。最初に、混載業者は、今、中でどのネットワークでソースがそうであるかによってメッセージと2番目を転送するのに、「ホスト」が、どこで異なった混載業者アドレスに翻訳する必要であるかもしれないかを計算するために「ホスト」情報を必要とするかもしれません。 後者の観測は異なったメール送信元に異なったテーブルを必要とする与えられた「ホスト」ストリングの多くの異なったマッピングの亡霊を提起します。 これは混載業者アドレスのテーブルの維持と分配におけるかなりの複雑さに通じるでしょう。 1人の混載業者だけが必ず与える人「ホスト」に役立つでしょう、その上、したがって、混載業者の「ホスト」を写像するただ一つのエントリテーブルは信頼性を制限するでしょう。

                                   4


4

RFC 773                                                     October 1980
                    Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPのRFC773 1980年10月コメントがサービス変遷戦略を郵送します。

   For the NCP/TCP transition, it may be sufficient to declare some set
   of well-known hosts to be NCP/TCP forwarders.  Each mailer, when it
   discovers an incompatible destination, can send the message to any
   forwarder which is available.  In addition, however, the mailer must
   provide full mailbox identifier information "user@host" to the
   forwarding host.

NCP/TCP変遷では、何らかのセットの周知のホストがNCP/TCP混載業者であると宣言するのは十分であるかもしれません。 それが非互換な目的地を発見するとき、各郵送者はどんな混載業者への利用可能なメッセージも送ることができます。 しかしながら、さらに、郵送者は" user@host "という完全なメールボックス識別子情報を推進ホストに提供しなければなりません。

   In the present mailers, only the "user" portion of the mailbox
   identifier is sent, so all mailers must change to send "user@host"
   when sending to a forwarder.  The mailers all have to learn how to do
   table look-up a new way, also, to map "host" into internet addresses
   and to interpret the NCP or TCP capability information.

現在の郵送者では、メールボックス識別子の「ユーザ」部分だけを送るので、すべての郵送者が混載業者に発信するとき、" user@host "を送るために変化しなければなりません。 また、「ホスト」をインターネットアドレスに写像して、NCPかTCP能力情報を解釈するために新しい方法でテーブル索引をする方法を学ぶためにすべてにはある郵送者。

   For purposes of this discussion, we postulate three different cases
   of electronic mail service implementation which must be made to
   interoperate during the transition:

この議論の目的のために、私たちは変遷の間、共同利用するのをしなければならない電子メールサービス実現の3つの異なったケースを仮定します:

      1.  Unchanged OLD NCP (RFC733) mail

1. 変わりのないOLD NCP(RFC733)メール

      2.  NCP mail with new internet tables

2. 新しいインターネットテーブルがあるNCPメール

      3.  TCP mail with new internet tables.

3. TCPは新しいインターネットと共にテーブルを郵送します。

   The second case assumes that the host has adopted a new host-string
   to address table (including NCP/TCP capability bits) and new mailer -
   mail server programs, but continues to use the old NCP host level
   protocol, modified to send "user@host" when sending to a forwarder.
   For such hosts, the only table entries which result in direct
   source-destination mail delivery are those showing NCP capability.
   If the destination is TCP capable only then the source host selects a
   forwarder address from another table and sends the message to it for
   further processing.

2番目のこの件は、ホストがアドレス・テーブル(NCP/TCP能力ビットを含んでいる)と新しい郵送者に新しいホストストリングを採用したと仮定します--メールサーバは、プログラムを作りますが、混載業者に発信するとき、" user@host "を送るのにプロトコルであって、変更されていた状態で古いNCPホストレベルを使用し続けています。 そのようなホストにとって、ダイレクトソース目的地郵便配達をもたらす唯一のテーブル項目がNCP能力を示しているものです。 目的地が次にだけ、できるTCPであるなら、送信元ホストは、別のテーブルから混載業者アドレスを選択して、さらなる処理のためにメッセージをそれに送ります。

   In the third case, the source host has fully transitioned to TCP,
   uses the new internet address tables to translate host-strings into
   internet addresses, and uses the new mailer - mail server.
   Destinations which are NCP-compatible only are reached via NCP/TCP
   forwarders.

3番目の場合では、送信元ホストは、TCPに完全に移行して、ホストストリングをインターネットアドレスに翻訳するのに新しいインターネットアドレス・テーブルを使用して、新しい郵送者を使用します--メールサーバNCP互換性がある目的地だけにNCP/TCP混載業者を通して達しています。

   Mail composition programs (e.g. SNDMSG, MSG, Hermes, MH,...) which
   today use ARPANET string-to-address tables to verify the legality of
   host names in mailbox entries can continue to use these "old" tables
   as long as these are updated to include internet host names as well
   as ARPANET host names.

アルパネットホスト名と同様にインターネットホスト名を含むようにこれらをアップデートする限り、今日メールボックスエントリーにおける、ホスト名の合法について確かめるのにアルパネットのストリングからアドレス・テーブルを使用するプログラム(例えば、SNDMSG、MSG、エルメス、MH)が使用し続けることができる構成にこれらの「古い」テーブルを郵送してください。

   Indeed, expanding the old tables is essential to handle the hardest

本当に、古いテーブルを広げるのは、最も一生懸命扱うのに不可欠です。

                                   5


5

October 1980                                                     RFC 773
Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPの1980年10月のRFC773コメントはサービス変遷戦略を郵送します。

   transition case:  OLD NCP to new TCP mail.  The three types of hosts
   lead to a 3 by 3 matrix of cases of mail transfer.  In all but one
   case, mail is either handled directly or explicitly by forwarder.
   The only case needing further explanation is OLD NCP to NEW TCP which
   uses an "implicit forwarder."

変遷ケース: 新しいTCPメールへのOLD NCP。 3つのタイプのホストは郵便為替に関するケースの3×3マトリクスに通じます。 1つのケース以外のすべてでは、メールは混載業者によって直接か明らかに扱われます。 詳細な説明を必要とする唯一のこの件が「内在している混載業者」を使用するNEW TCPへのOLD NCPです。

IMPLICIT FORWARDING VS EXPLICIT FORWARDING

暗黙の推進対明白な推進

   If the source host has adopted the new internet tables, it can tell
   whether the destination host has a compatible mail acceptance
   protocol.  Incompatibility is explicitly resolved by selection of an
   intermediate forwarder.

送信元ホストが新しいインターネットテーブルを採用したなら、それは、あて先ホストにはコンパチブルメール承認プロトコルがあるかどうか言うことができます。 不一致は中間的混載業者の選択で明らかに決議されています。

   If, however, the source host is still using pure NCP tables, it will
   not be able to tell that a particular destination host is only
   TCP-capable.  To provide service for this case, it is proposed to
   expand the conventional NCP host table to include internet host
   names, but to map them into the addresses of implicit mail forwarders
   (i.e. Aliases).

しかしながら、送信元ホストがまだ純粋なNCPテーブルを使用していると、特定のあて先ホストがTCPできるだけであると言うことができないでしょう。 このような場合サービスを提供するなら、それはインターネットホスト名を含むように従来のNCPホストテーブルを広げるために提案されますが、暗黙のアドレスにそれらを写像するには、混載業者(すなわち、Aliases)に郵送してください。

   Since we are postulating a case in which the NCP host has made no
   change (except for extending the host table). we also assume that the
   source host cannot send the "user@host" information via FTP to the
   intermediate forwarder.

以来、私たちはNCPホストが変更(ホストテーブルを広げるのを除いた)を全く行っていない場合を仮定します。また、送信元ホストが中間的混載業者へのFTPで" user@host "情報を送ることができないと思います。

   This leaves the intermediate forwarder with the problem of figuring
   out where to forward a message identified by "user" only.  In this
   case, we postulate that internet TCP-only mailboxes are registered at
   implicit forwarders so that incoming mail from conventional NCP
   sources can be forwarded successfully to the destination.

これは「ユーザ」だけによって特定されたメッセージをどこに転送するかを理解するという問題を中間的混載業者に残します。 この場合、私たちは、インターネットTCPだけメールボックスが首尾よく従来のNCPソースからの入って来るメールを目的地に転送できるように内在している混載業者に登録されるのを仮定します。

   In the reverse direction, the source can use explicit forwarding
   because it is assumed that all TCP hosts use the new internet tables.

反対の方向に、すべてのTCPホストが新しいインターネットテーブルを使用すると思われるので、ソースは明白な推進を使用できます。

   The use of registered names in the implicit forwarder raises two
   problems:

内在している混載業者における登録名の使用は2つの問題を提起します:

      1.  How can we deal with ambiguous mailbox names?  (e.g. USERX@BBN
          and USERX@ISI look the same if only the string "USERX" is
          presented to the intermediate forwarder)

1. 私たちはどうしたらあいまいなメールボックス名に対処できますか? (ストリングだけ"USERX"が中間的混載業者に提示されるなら、例えば、 USERX@BBN と USERX@ISI は同じに見えます)

      2.  How can we collect, update and distribute changes to the
          registries at implicit forwarders?

2. 私たちは、内在している混載業者でどうしたら登録への変化を集めて、アップデートして、分配できますか?

   In the first case, we propose to duck the problem by insisting on

前者の場合、私たちは、主張することによって問題をすくめるよう提案します。

                                   6


6

RFC 773                                                     October 1980
                    Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPのRFC773 1980年10月コメントがサービス変遷戦略を郵送します。

   unambiguous mailbox names everywhere.  This may force some internet
   mail users to change their mailbox names, but we believe this will be
   rare.

いたる所の明白なメールボックス名。 これによって、何人かのインターネットメールユーザがやむを得ず彼らのメールボックス名を変えるかもしれませんが、私たちは、これがまれになると信じています。

   The second problem can be solved by collecting information on a
   regular basis from all network mail users and cataloging this data in
   a database which can be accessed automatically (e.g. by mailer
   programs).

2番目の問題は、情報集めによってすべてのネットワークメールユーザから定期的に解決されていて、自動的(例えば、郵送者プログラムで)にアクセスできるデータベースでこのデータをカタログに載せることができます。

   One possible mechanism is to make the data available through an
   internet mailbox name server analogous to the internet host name
   server [6].  This data might be collectible as a natural part of the
   TIP LOGIN database which is under development to permit expanded
   access to the ARPANET TIPs by legitimate ARPANET users.

1台の可能なメカニズムはデータをインターネットホストネームサーバ[6]への類似のインターネットメールボックスネームサーバを通して利用可能にすることです。 可能にするために開発中であるTIP LOGINデータベースの本来の部分が正統のアルパネットユーザでアルパネットTIPsにアクセスを広くしたので、このデータは収集品であるかもしれません。

   In any case, internet mail users need supply their mailbox
   information to a single collection site which would disseminate it to
   all implicit forwarders on ARPANET.  Note that such forwarders are
   only needed on ARPANET since all other systems are starting with the
   TCP-base.  It is the internet mailbox users who must register,
   however, since they are the ones who cannot otherwise be reached via
   NCP.

どのような場合でも、インターネットメールユーザはアルパネットですべての内在している混載業者にそれを広めるただ一つの収集サイトに彼らのメールボックス情報を供給しなければなりません。 他のすべてのシステムがTCP-ベースから始まるのでそのような混載業者がアルパネットで必要であるだけであることに注意してください。 それはしかしながら、彼らがそうでなければNCPで達することができない人であるので登録しなければならないインターネットメールボックスユーザです。

FORWARDER CHARACTERISTICS

混載業者CHARACTERISTICS

   By their definition, NCP/TCP forwarders must be both NCP and TCP
   capable. Consequently, all NCP/TCP forwarders must be ARPANET hosts.

彼らの定義で、NCP/TCP混載業者はNCPとTCPともにできなければなりません。 その結果、すべてのNCP/TCP混載業者がアルパネットホストであるに違いありません。

   Implicit forwarders must accept conventional NCP/FTP mail [11] and be
   equipped with tables of valid internet user mailbox names which can
   be associated with the proper destination host.  To allow implicit
   forwarders to also accept ordinary mail for users with mailboxes on
   the implicit forwarder, the forwarder should check first whether
   incoming mail is for a local user.

内在している混載業者は、従来のNCP/FTPメール[11]を受け入れて、適切なあて先ホストに関連づけることができる妥当なインターネットユーザメールボックス名のテーブルを備えなければなりません。 また、内在している混載業者の上にメールボックスがある状態で内在している混載業者がユーザへの普通郵便を受け入れるのを許容するために、混載業者は、最初に、入って来るメールが地元のユーザのためのものであるかをチェックするべきです。

   Explicit mail forwarders must be able to accept both conventional
   NCP-FTP mail commands (for local user mail) and both NCP-based and
   TCP-based mail server commands (whose arguments include the full
   destination mailbox strings "user@host").

明白なメール混載業者は従来のNCP FTPメールコマンド(ローカルのユーザメールのための)とNCPベースの、そして、TCPベースの両方のメールサーバコマンド(議論は完全なあて先メールボックスストリング" user@host "を含んでいる)の両方を受け入れることができなければなりません。

   To prevent potentially anomalous behavior, the NCP-based and
   TCP-based mail servers will offer service on socket/port 57 (71
   octal).  To summarize the communication patterns:

潜在的に変則的な振舞いを防ぐために、NCPベースの、そして、TCPベースのメールサーバはソケット/ポート57(71 8進)に対してはサービスを提供するでしょう。 コミュニケーションをまとめるのは型に基づいて作ります:

      (a)  TCP sends/receives mail via well known port 57.

(a) TCPはよく知られているポート57を通してメールを送るか、または受け取ります。

                                   7


7

October 1980                                                     RFC 773
Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPの1980年10月のRFC773コメントはサービス変遷戦略を郵送します。

      (b)  implicit forwarder receives conventional NCP/FTP mail on
           well-known socket 3, and sends TCP mail to port 57.

(b) 内在している混載業者は、よく知られるソケット3に関する従来のNCP/FTPメールを受け取って、57を移植するためにメールをTCPに送ります。

      c)  explicit forwarder receives NCP mail on well-known socket 57,
           but sends NCP mail via NCP/FTP on socket 3.  TCP mail is
           sent/received via port 57.

c)明白な混載業者は、よく知られるソケット57の上にNCPメールを受け取りますが、NCP/FTPでNCPメールをソケット3に送ります。 ポート57を通してTCPメールを送るか、または受け取ります。

USER HOST CHARACTERISTICS

ユーザー・ホストの特性

   NCP hosts must at minimum, update host name tables to include aliases
   for internet hosts (i.e. map to NCP implicit forwarder host
   addresses).

NCPホストは最小限でそうしなければなりません、インターネットホスト(すなわち、NCPの暗黙の混載業者ホスト・アドレスへの地図)のための別名を含むアップデートホスト名テーブル。

   The next most useful step is to update NCP hosts to include internet
   address tables and NCP/TCP capability bits so as to make use of
   explicit forwarders.  This requires implementation of the mail server
   and modification of the mailer programs for sending mail to explicit
   forwarders.  This also requires addition of explicit forwarder
   address tables.

次の最も役に立つステップは明白な混載業者を利用するためにインターネットアドレス・テーブルとNCP/TCP能力ビットを含むようにNCPホストをアップデートすることです。 これはメールサーバの実装と送付メールのための郵送者プログラムの変更を明白な混載業者に必要とします。 また、これは明白な混載業者アドレス・テーブルの追加を必要とします。

   Finally, a host can implement full TCP mail services, incorporating
   internet name tables and explicit forwarder address tables as well.

最終的に、インターネットネームテーブルとまた、明白な混載業者アドレス・テーブルを組み込んで、ホストは、完全なTCPメールがサービスであると実装することができます。

DANGLING PARTICIPLES

懸垂分詞

   1.  Error message handling needs to be worked out in detail to assure
       reasonable reporting of problems with the use of forwarders.

1. エラーメッセージ取り扱いは、混載業者の使用に関する問題を妥当な報告に保証するために詳細に解決される必要があります。

   2.  Designation of forwarding hosts.

2. 推進ホストの名称。

   3.  Collection of internet mailbox names for implicit forwarders.

3. 内在している混載業者のためのインターネットメールボックス名の収集。

   4.  Format and distribution of internet name table and NCP/TCP
       capability information.

4. インターネットの形式と分配はテーブルとNCP/TCP能力を情報と命名します。

   5.  Dealing with mail systems not compatible with NCP, TCP or RFC733.
       (e.g. Telemail, On-Tyme, Phonenet, TWX, TELEX,...)

5. NCP、TCPまたはRFC733とのコンパチブルでないメールシステムに対処します。 (例えば、Tymeの上のTelemail(Phonenet、テレックス)はテレックスで送信します…)

                                   8


8

RFC 773                                                     October 1980
                    Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPのRFC773 1980年10月コメントがサービス変遷戦略を郵送します。

PLANS

プラン

   To encourage this transition, the following schedule is proposed:

この変遷を奨励するために、以下のスケジュールは提案されます:

      1.  January 1, l981 - implicit and explicit NCP/TCP forwarders
          made available on various service hosts (e.g. TOPS-20).

1. 1月1日、l981--混載業者が様々なサービス・ホスト(例えば、TOPS-20)で利用可能にした暗黙の、そして、明白なNCP/TCP。

      2.  January 1, l982 - implicit NCP/TCP forwarder service removed;
          explicit forwarding service continues.

2. 1月1日、l982--内在しているNCP/TCP混載業者サービスは取り外されました。 明白な推進サービスは続きます。

      3.  January 1, l983 - explicit NCP/TCP forwarding service
          terminated, transition to TCP complete.

3. 1月1日、l983--明白なNCP/TCP推進サービスが終えられて、TCPに完全な状態で移行してください。

ACKNOWLEDGEMENTS

承認

   A number of people have reviewed and commented on this contribution.
   Particular comments by J. Pickens, J. Postel, J. Haverty, D. Farber
   and D. Adams are gratefully acknowledged.

多くの人々が、この貢献を見直して、批評しました。 J.ピケンズ、J.ポステル、J.Haverty、D.ファーバー、およびD.アダムスによる特定のコメントは感謝して承諾されます。

                                   9


9

October 1980                                                     RFC 773
Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPの1980年10月のRFC773コメントはサービス変遷戦略を郵送します。

                               REFERENCES

参照

   1.  DoD Standard Internet Protocol, IEN 128, RFC 760, NTIS
       ADA 079730, Jan 1980.

1. DoDの標準のインターネットプロトコル、IEN128、RFC760、NTIS ADA079730、1980年1月。

   2.  DoD Standard Transmission Control Protocol, IEN 129, RFC 761,
       NTIS ADA 082609, Jan 1980.

2. DoDの標準の通信制御プロトコル、IEN129、RFC761、NTIS ADA082609、1980年1月。

   3.  Postel, J., Telnet Protocol Specification, IEN 148, RFC 764,
       Jun 1980.

3. ポステル、J.、telnetプロトコル仕様、IEN148、RFC764、1980年6月。

   4.  Postel, J., File Transfer Protocol, IEN 149, RFC 765, Jun 1980.

4. ポステル、J.、ファイル転送プロトコル、IEN149、RFC765、1980年6月。

   5.  Postel, J., User Datagram Protocol, RFC 768, Aug 1980.

5. ポステル、J.、ユーザー・データグラム・プロトコル、RFC768、1980年8月。

   6.  Postel, J., Internet Name Server, IEN 116, Aug 1979.

6. ポステル、J.、インターネットネームサーバ、IEN116、1979年8月。

   7.  Postel, J., Internet Message Protocol, IEN 113, RFC 759, Aug
       1980.

7. ポステル、J.、インターネットメッセージプロトコル、IEN113、RFC759、1980年8月。

   8.  Postel, Sunshine, Cohen, The ARPA Internet Protocol, in
       preparation.

8. ポステル、サンシャイン、コーエン、準備におけるARPAインターネットプロトコル。

   9.  NCP:  ARPANET Protocol Handbook, NIC 7104, Jan 1978.

9. NCP: アルパネットプロトコルハンドブック、NIC7104、1978年1月。

   10.  Telnet:  ARPANET Protocol Handbook, NIC 7104, Jan 1978.

10. telnet: アルパネットプロトコルハンドブック、NIC7104、1978年1月。

   11.  FTP:  ARPANET Protocol Handbook, NIC 7104, Jan 1978.

11. FTP: アルパネットプロトコルハンドブック、NIC7104、1978年1月。

   12.  D. Crocker, J. Vittal, K. Pogran, A. Henderson, Standard for the
        Format of ARPA Network Text Messages, RFC 733, Nov 1977.

12. D。 クロッカー、J.Vittal、K.Pogran、アーパネットテキスト・メッセージ、RFC733、1977年11月の形式における、標準のA.ヘンダーソン。

   13.  Crocker, et.al., Function-Oriented Protocols for the ARPA
        Computer Network, SJCC, May, 1972.

13. クロッカー、et.al、ARPAコンピュータNetwork、SJCC、5月、1972年のFunctionが指向のプロトコル

   14.  Carr, Crocker, Cerf, Host-Host Communication Protocol in the
        ARPA Network, SJCC, May, 1970.

14. カー、クロッカー、サーフ、アーパネット、SJCC、1970年5月のホスト兼ホスト通信プロトコル。

   15.  Cerf, V., The Catenet Model for Internetworking, IEN 48,
        DARPA/IPTO, Jul 1978.

15. サーフ、V.、インターネットワーキングのためのCatenetモデル、IEN48、DARPA/IPTO、1978年7月。

   16.  BBN 1822:  Specifications for the Interconnection of a Host and
        an IMP, BBN Report No. 1822.

16. BBN1822: ホストと悪童、BBNのインタコネクトのための仕様はNo.1822を報告します。

   17.  Heart, et.al., The Interface Message Processor for the ARPA
        Computer Network, SJCC, May, 1970.

17. 心臓、et.al、ARPAコンピュータNetworkのためのInterface Message Processor、SJCC、5月、1970

                                   10


10

RFC 773                                                     October 1980
                    Comments on NCP/TCP Mail Service Transition Strategy

NCP/TCPのRFC773 1980年10月コメントがサービス変遷戦略を郵送します。

   18.  Shoch, J., Inter-Network Naming, Addressing, and Routing,
        COMPCOM, Fall 1978.

18. ShochとJ.とインターネットワーク命名、アドレシングとルート設定、COMPCOM、1978年秋。

   19.  Postel, J., A Structured Format for Transmission of Multi-Media
        Documents, RFC 767, Aug 1980.

19. ポステル、J.、マルチメディアドキュメント、RFC767、1980年8月のトランスミッションのための構造化された形式。

   20.  Cerf, V. and, J. Postel, Mail Transition Plan, RFC 771,
        Sep 1980.

20. そして、サーフ、V.、J.ポステル、メールTransition Plan、RFC771、9月1980日

   21.  Sluizer, S. and, J. Postel, Mail Transfer Protocol, RFC 772,
        Sep 1980.

21. そして、Sluizer、S.、J.ポステル、メールTransferプロトコル、RFC772、9月1980日

                                   11

11