RFC49 日本語訳

NWG/RFC 49      Conversations with Steve Crocker (UCLA)

スティーブ・クロッカーとのNWG/RFC49の会話(UCLA)

                          Edwin W. Meyer, Jr.
                            MIT Project MAC
                             April 25, 1970

エドウィン・W.マイヤー、1970年4月25日のJr.MITプロジェクトMAC

   (Both my personal opinions and those that I believe represent a
   consensus of the Network Working Group at Project MAC are presented
   here.  The pronouns "I" and "we" are used to distinguish between
   these.)

(Project MACにNetwork作業部会のコンセンサスを表す私が、信じている私の個人的な見解とそれらの両方がここに提示されます。 代名詞「私」と「私たち」は、これらを見分けるのに使用されます。)

On April 21 and 23 Thomas P. Skinner and I had telephone conversations
with Steve Crocker at UCLA relating to the network protocol,
specifically regarding our proposal in NWG/RFC 46.  The following items
were discussed.  (I hope that Steve will pardon me if I happen to
misparaphrase him.)

4月21日と23日に、トーマスP.スキナーと私には、UCLAのネットワーク・プロトコルに関連するスティーブ・クロッカーとの電話での会話がありました、特にNWG/RFC46での私たちの提案に関して。 以下の項目について議論しました。 (私がたまたま彼をmisparaphraseすればスティーブが許してくださいことを願っています。)

1) Steve stated that he felt that a need for dynamic reconnection would
later be recognized by the network participants.  However, because of a
lack of consensus, it will not be included in the initial
implementation.  (We at Project MAC favor this approach of not including
it initially.)

1) スティーブは、ダイナミックな再接続の必要性が後でネットワーク関係者によって認められると感じたと述べました。 しかしながら、意見の不一致のために、それは初期の実装に含まれないでしょう。 (Project MACの私たちは初めはそれを含まないこのアプローチを支持します。)

2) Steve supported the implementation of the INT network command
described in NWG/RFC 46.

2) スティーブはNWG/RFC46で説明されたINTネットワークコマンドの実装をサポートしました。

This command allows a process that has agreed to accept interrupts over
a socket connection to be reliably interrupted by the process at the
other end.  The interrupt causes a process to abey its current execution
and execute a procedure that it has specified as the INT handler.  (The
NCP does not specify the INT handler.  That is the function of higher
level protocols.)

このコマンドで、ソケット接続の上に中断を受け入れるのに同意したプロセスはもう一方の端のときにプロセスで確かに中断します。 中断はabeyへの現在の実行をプロセスに引き起こします、そして、それがINT操作者として指定した手順を実行してください。 (NCPはINT操作者を指定しません。 それは、より高い平らなプロトコルの機能です。)

The INT command is designed specifically for use by a third level User
Control and Communication (UCC) protocol to implement a "quit" signal.
Under such a protocol, both the requestor and the created process agree
that an INT related to a specific socket connection and transmitted over
the NCP control link to the created process is the standard "quit"
signal.  The created process provides an INT handler that implements
this "quit" function.  (This does not preclude a different
interpretation of INT by other third level protocols.)

特に第3レベルUser ControlとCommunication(UCC)プロトコルによる使用が「やめてください」という信号を実装するように、INTコマンドは設計されています。 そのようなプロトコルの下では、要請者と作成されたプロセスの両方が、特定のソケット接続に関連して、作成されたプロセスへのNCPコントロールリンクの上に伝えられたINTが「やめてください」という標準の信号であるのに同意します。 作成されたプロセスは「やめてください」というこの機能を実装するINT操作者を提供します。 (これは他の3番目の平らなプロトコルでINTの異なった解釈を排除しません。)

Although many systems implement the "quit" as a control character in the
Teletype input stream, systems such as CTSS, Multics, and others
implement it as a 200 ms spacing on the line.  We at MAC think that the

多くのシステムがテレタイプ入力ストリームの制御文字としての「やめてください」を実装しますが、CTSSや、Multicsや、他のものなどのシステムは系列で区切られる200msとしてそれを実装します。 MACの私たちはそれを考えます。

                                                                [Page 1]

NWG/RFC 49      Conversations with Steve Crocker (UCLA)

[1ページ] スティーブ・クロッカーとのNWG/RFC49の会話(UCLA)

first method is an undesirable implementation within the network (while
the second is impossible).  I put forth several reasons why (and I think
Steve agreed).

まず最初に、メソッドはネットワークの中の望ましくない実装(2番目は不可能ですが)です。 私はいくつかの理由を差し出します(私は、スティーブが同意したと思います)。

(a) The link over which the quit character is to be transmitted may be
blocked.

(a) リンクする、どれ、やめられて、伝えられて、妨げられるかもしれないということになるように、キャラクタはあるか。

(b) While the interrupt is most effectively implemented within the NCP,
it is undesirable for the NCP to place any particular structure on the
data being transmitted.  (See discussion below.)  This would be required
if the NCP were to scan a data stream for a control character.

(b) 中断はNCPの中で最も効果的に実装されますが、NCPがどんな特定の構造も送られるデータに置くのは、望ましくありません。 (以下での議論を見てください。) これがNCPが制御文字のためのデータ・ストリームをスキャンすることであるなら必要です。

(c) Scanning the input stream greatly reduces NCP efficiency in a
subsystem where speed is critical to effective operation.

(c) 入力ストリームをスキャンすると、NCP効率は速度が有効な操作に重要であるサブシステムで大いに減少します。

Steve pointed out that the implementation of INT as a "quit" should not
necessarily preclude a HOST's interpretation of a control character in
the input stream from also acting as a "quit".

スティーブは、「辞任」としてのINTの実装が必ずまた、「辞任」として機能するのからの入力ストリームにおける、HOSTの制御文字の解釈を排除するべきであるというわけではないと指摘しました。

3) Steve is opposed both to including the instance tag in the socket
identifier and reserving a null field in the identifier for future
definition.  He cited several reasons:

3) スティーブはソケット識別子にインスタンスタグを含んで、今後の定義のための識別子で空フィールドを予約するのに反対されます。 彼はいくつかの理由を挙げました:

(a) Multiple processes of a single user should be indistinguishable to a
foreign process.  (I agree with this in certain cases when processes are
co-ordinated in joint action.  But what about the case where two
processes of the same user both want to independently use the network?)

(a) シングルユーザーの複数のプロセスが外国プロセスに区別がつかないはずです。 (私は、ある場合には、プロセスがいつ共同訴訟で調整されるかとこれに同意します。 しかし、同じユーザの2つのプロセスがともに独自にネットワークを使用したがっているケースはどうですか?)

(b) A process wishing to connect to one of a foreign user's processes
does not know the instance tag of the particular process that he wants,
and he can't easily find out.

(b) 外国人のユーザのプロセスの1つに接続するプロセス願望は彼が欲しい特定のプロセスのインスタンスタグを知りません、そして、彼は容易に見つけることができません。

(c) If an instance tag should later prove desirable it could be added
with some difficulty.  (I claim that something as fundamental as the
length of a socket identifier will prove very resistant to change.)

(c) インスタンスタグが後で望ましいと判明するはずであるなら、それは困難で加えられるかもしれません。 (私は、ソケット識別子の長さが非常に抵抗力があると判明するのとその何か同じくらい基本的なものが変化すると主張します。)

Tom stated that perhaps the low order three bits of the user code could
be reserved for later interpretation as an instance tag.  He doesn't
think that a separate field is of great importance.

トムは、恐らく、後の解釈のためにインスタンスタグとしてユーザコードの下位3ビットを予約できると述べました。 彼は、別々の分野がかなり重要であると考えません。

Steve's arguments seem to have merit.  Perhaps Tom's suggestion is the
way to go.  I am currently undecided on this matter.

スティーブの議論は長所を持っているように思えます。 恐らくトムの提案は行く方法です。 私は現在、この件に関して未定です。

4) We all (Steve and MAC) seem to agree that at the NCP level there
should be no special structure imposed on the data transmitted.  To an
NCP all data to be transmitted are bit strings of arbitrary length.  One

4) 私たち(スティーブとMAC)は皆、そこのNCPレベルにおけるそれがデータに課された特別な構造でないのに同意するのが伝わったように思えます。 NCPに、すべての伝えられるべきデータが任意の長さのビット列です。 1つ

                                                                [Page 2]

NWG/RFC 49      Conversations with Steve Crocker (UCLA)

[2ページ] スティーブ・クロッカーとのNWG/RFC49の会話(UCLA)

happy result is that the difficult question of character sets does not
have to be resolved at this protocol level.  To include a character set
specification at the NCP level would delay agreement on the protocol and
make this character set more resistant to change.  (If there is to be a
standard character set, we prefer ASCII.  After all, it is the prefered
standard of our sponsoring organization.)

満足な結果は文字集合の難問題がこのプロトコルレベルで決議される必要はないということです。 NCPレベルで文字集合仕様を含んでいるのに、協定をプロトコルに遅らせて、この文字集合は変えるために、より抵抗力があるようになるでしょう。 (標準文字セットがあれば、私たちはASCIIを好みます。 結局、それは私たちが組織を後援するprefered規格です。)

We also agree with Steve that there should be no optional echoing of
messages at the NCP protocol level.  (This is also the position of the
SDC people in RFC 44.)

また、私たちは、NCPプロトコルレベルにメッセージの任意の反響がいるべきでないとスティーブに同意します。 (また、これはRFC44のSDCの人々の位置です。)

5) Shoshani, Long, and Landsberg also state (RFC 33) that they prefer to
align messages to end on a word boundary as opposed to double padding.
Steve agrees with us in not liking double padding.

5) また、Shoshani、Long、およびランツベルクは彼らが二重詰め物と対照的に語境界で終わるメッセージを並べるのを好む(RFC33)を述べます。 スティーブは二重詰め物が好きでないように私たちに同意します。

6) In our proposal (RFC 46) we suggest that RFCs be queued only for open
sockets, that RFCs to inactive or connected sockets are to be
automatically rejected via the CLS command.  Steve proposes that RFCs to
these sockets be briefly queued.  If the socket remains in an
unacceptable state for a specific interval after the RFC comes in, it is
rejected.  This scheme allows certain types of network command
interaction involving critical races to be implementable.  Such a scheme
of limited queueing does not seem unreasonable to me.

6) 提案(RFC46)では、私たちは、RFCsが開いているソケットのためだけに列に並ばせられて、不活発であるか接続されたソケットへのRFCsがCLSコマンドで自動的に拒絶されることになっていることを提案します。 スティーブは、これらのソケットへのRFCsが簡潔に列に並ばせられるよう提案します。 RFCが入った後にソケットが特定の間隔の間、容認できない州に残っているなら、それは拒絶されます。 この体系は、実装可能になるようにあるタイプのネットワークコマンドに相互作用の意味ありげな重要なレースを許容します。 限られた待ち行列のそのような体系は私にとって無理に思えません。

7) Steve, Tom, and I discussed strategies for a User Control and
Communication (UCC) Protocol.  Steve said that he disliked our UCC
strategy (RFC 46) because it requires maintaining two full-duplex
connections to the requestor process and switching between them.

7) スティーブ、トム、および私はUser ControlとCommunication(UCC)のために戦略を検討しました。 議定書を作ってください。 スティーブは、2つの全二重接続を要請者プロセスに維持して、彼らを切り換えるのが必要であるので、私たちのUCC戦略(RFC46)が嫌であったと言いました。

Steve put forth an alternate proposal: a process wishing to create a
user process at a foreign HOST issues RFCs to sockets 0 and 1 belonging
to the user whose process he wishes to create.  If these sockets are
inactive, the NCP automatically directs these requests to the foreign
HOST's logger process.  The logger accepts connection and performs the
login ritual.  If successful, the logger creates a user process and lets
go of the usurped sockets so that the created process may use them to
communicate with the requestor process.  (I note that this does not use
reconnection at a network level, since the logger uses sockets belonging
to the ultimate user.  However, it does involve internal reconnection.)

スティーブは代替の提案を差し出しました: 外国HOSTにユーザ・プロセスを作成するプロセス願望は彼がプロセスを作成したがっているユーザのものであるソケット0と1にRFCsを発行します。 これらのソケットが不活発であるなら、NCPは自動的に外国HOSTのきこりのプロセスにこれらの要求を向けます。 きこりは、接続を受け入れて、ログイン儀式を実行します。 うまくいくなら、きこりは、作成されたプロセスが要請者プロセスで交信するのにそれらを使用できるように、ユーザ・プロセスを作成して、僣称されたソケットを手離します。 (私は、これがネットワークレベルに再接続を使用しないことに注意します、きこりが究極のユーザのものであるソケットを使用するので。 しかしながら、それは内部の再接続にかかわります。)

Tom and I objected to this because it introduces UCC protocol into the
NCP level.  (The NCP must direct all RFCs to inactive sockets 0 and 1 to
a logger process.)  I made a quick suggestion that perhaps our two
proposals could be combined such that the requestor issues a
"signalling" RFC to a "signal" socket of the UCC process.  The UCC

それがNCPレベルにUCCプロトコルを取り入れるので、トムと私はこれに反対しました。 (NCPは不活発なソケット0と1対aきこりのプロセスにすべてのRFCsを向けなければなりません。) 私は要請者が恐らく、私たちの2つの提案を結合できたのでUCCプロセスの「信号」ソケットに「合図」RFCを発行するという迅速な提案をしました。 UCC

                                                                [Page 3]

NWG/RFC 49      Conversations with Steve Crocker (UCLA)

[3ページ] スティーブ・クロッカーとのNWG/RFC49の会話(UCLA)

rejects the RFC but remembers who is calling.  It then tries to connect
two sockets of the process to be created to the requestor's sockets, and
conducts the login ritual through these.  Steve liked this and suggested
that I write it up.

RFCを拒絶しますが、だれが電話をしているかを覚えています。 それは、次に、要請者のソケットに作成されるためにプロセスの2個のソケットを接続しようとして、これらを通してログイン儀式を行います。 スティーブは、これが好きであり、私がそれを詳しく書くことを提案しました。

Following the conversation, I thought of several disadvantages to this
UCC strategy:

会話に続いて、私はこのUCC戦略への数回の損失を考えました:

(a) If the control sockets at a created process are limited to 0 and 1,
there is the possibility that a rightful user may not be able to
communicate with a foreign UCC because the UCC already is using those
sockets to communicate with an imposter.  The logger will discover this
and turn off the imposter, but this is an aggravating security breach.
A malicious process could issue simultaneous multiple requests to tie up
the sockets and prevent access to a rightful user.  A better solution is
to allow any socket pair of the potential user process to act as the
control path.  This permits the UCC to conduct simultaneous
interrogations of competing requestors.

(a) 作成されたプロセスの制御ソケットが0と1に制限されるなら、UCCが詐欺師とコミュニケートするのに既にそれらのソケットを使用しているので正しいユーザが外国UCCとコミュニケートできないかもしれない可能性があります。 きこりは、これを発見して、詐欺師の興味を失わせるでしょうが、これはいらいらさせる機密保護違反です。 悪意があるプロセスはソケットをタイアップして、正しいユーザへのアクセスを防ぐという同時の倍数要求を出すかもしれません。 より良いソリューションは潜在的ユーザ・プロセスのどんなソケット組もコントロール経路として務めるのを許容することです。 これは、UCCが競争している要請者の同時の査問を行うことを許可します。

(b) A disadvantage of both Crocker's and the combined UCC is that the
user to be logged in is specified by supplying a socket belonging to a
particular user.  The logger must now make the additional check that the
user it is logging in actually belongs to the socket pair it is talking
over.  This seems the reverse of the prefered process: to identify a
user and then determine the user code for his socket identifiers.

(b) クロッカーと合併しているUCCの両方の不都合はログインされるべきユーザが特定のユーザのものであるソケットを供給することによって指定されるということです。 きこりは追加に今、それがログインしているユーザが実際にそれが論議しているソケット組のものであることをチェックさせなければなりません。これはpreferedプロセスの逆に思えます: ユーザを特定して、次に、ユーザを決定するには、彼のソケットのために識別子をコード化してください。

(c) The user may not know the socket user code of the user he wishes to
log in at the foreign HOST.  (After all, there is no basic reason why
the requestor and created processes should have the same user code so
long as the requestor satisfies the foreign logger.)

(c) ユーザは彼が外国HOSTでログインしたがっているユーザのソケットユーザコードを知らないかもしれません。(結局、要請者が外国人のきこりを満たす限り、要請者と作成されたプロセスには同じユーザコードがあるはずである根本的な理由が全くありません。)

(d) In the combined strategy, there is no way for the requestor to
specify which socket user code it wants.  The only assumption that the
UCC can make is that the requestor process wishes to log in a process
having the same socket user code as itself.  (This may not seem very
important, but I envision a scheme in which a local process exists to
allow consoles attached to the local HOST to login at a foreign HOST
without being logged in locally.)

(d) 結合した戦略には、要請者が、それがどのソケットユーザコードが欲しいかを指定する方法が全くありません。 UCCがすることができる唯一の仮定は要請者がそれ自体と同じソケットユーザコードを持っているプロセスにログインするという願望を処理するということです。 (これは非常に重要に見えないかもしれませんが、私は地方のプロセスが地方のHOSTに取り付けられたコンソールが外国HOSTに局所的にログインされないでログインするのを許容するために存在する体系を思い描きます。)

(e) The idea of allowing a process to masquerade within the network as
another process (even with the best of intentions) by using its socket
user code introduces a potentially dangerous security breach.  I think
that it should be a basic protocol law that NO PROCESS WHATSOEVER may
request or accept connections or transmit or receive data over a socket
having a user code not its own.  This does not apply to an NCP process
which has responsibility for such transmission, nor does it prevent a
priviliged process from closing or rejecting connections between a
foreign process and another local process.

(e) プロセスが別のプロセス(誠心誠意さえ)としてネットワークの中でソケットユーザコードを使用することによって仮装されるのを許容するという考えは潜在的に危険な機密保護違反を導入します。 私は、ユーザコードをそれ自身にしないソケットの上にデータをNO PROCESS WHATSOEVERが接続を要求するか、または受け入れるかもしれないのが、基本プロトコル法であるべきであると考えるか、送るか、または受け取ります。 これはそのようなトランスミッションへの責任を持っているNCPプロセスに申し込まれないで、またそれは、priviligedプロセスが外国プロセスと別の地方のプロセスとの接続を終えるか、または拒絶するのを防ぎません。

                                                                [Page 4]

NWG/RFC 49      Conversations with Steve Crocker (UCLA)

[4ページ] スティーブ・クロッカーとのNWG/RFC49の会話(UCLA)

I still think that the UCC proposal we advanced in RFC 46 is a good
workable scheme.  It does not require socket reconnection (either
expressly throughout the network or implicitly within an NCP), nor do
any of the objections raised above apply.  The only particular
disadvantage I see is that it requires the requestor process to maintain
and switch between two full-duplex connections.  I don't see this as a
serious hindrance.  I would like the comments of the network
participants on this point in particular.

私は、私たちがRFC46で進めたUCCの提案が良い実行可能な計画であるとまだ思っています。 ソケット再接続を必要としない、(どちらか、明白に、ネットワークかそれとなく、中、NCP)、また、上に上げられた反論のいずれも適用されません。 私が見る唯一の特定の不都合は2つの全二重接続を維持して、切り換えるのが要請者プロセスを必要とするということです。 私は重大な妨害であるとこれをみなしません。 私は、特にこのポイントにおけるネットワーク関係者のコメントが欲しいと思います。

Fortunately the UCC is a third level protocol.  The second level NCP can
be specified before we reach final agreement on a UCC, provided that the
NCP allows implementation of a workable UCC.

幸い、UCCは3番目の平らなプロトコルです。 私たちがUCCの最終合意に達する前に第2平らなNCPを指定できます、NCPが実行可能なUCCの実装を許容すれば。

Steve expressed the thought that there need not be an initial standard
UCC, that there might be several UCCs.  We at MAC disagree.  If we are
all to talk to each other, and not between limited subsets of HOSTs
within the network, there must be an initial standard UCC which
EVERYBODY implements.  (Steve is of course correct that there can be
other experimental UCCs also implemented.)

スティーブは初期の標準のUCCがある必要はなくて、数個のUCCsがあるかもしれないという考えを言い表しました。 MACの私たちは意見を異にします。 すべてHOSTsの限られた部分集合ではなく、互いに話に私たちがネットワークの中にいるなら、EVERYBODYが実装する初期の標準のUCCがあるに違いありません。 (スティーブはもちろんまた、実装された他の実験的なUCCsがあることができるのが正しいです。)

It is theoretically possible for each HOST to provide multiple sets of
software to allow a requestor process to communicate with the loggers at
HOSTs implementing different UCCs.  I don't think that it will work this
way in practice.  Each HOST will implement the UCC protocol that is most
agreeable to it, and will provide one set of software so that a
requestor process can communicate only with those HOSTs which implement
similar UCCs.

各HOSTが要請者プロセスが異なったUCCsを実装するHOSTsのきこりとコミュニケートするのを許容するために複数のセットのソフトウェアを提供するのは、理論的に可能です。 私は、それが実際にはこのように働くと思いません。 各HOSTは、それに最も快いUCCプロトコルを実装して、要請者プロセスが同様のUCCsを実装するそれらのHOSTsだけとコミュニケートできるように、1セットのソフトウェアを提供するでしょう。

I don't think that there is much enthusiasm at Project MAC for
implementing a non-standard UCC just so we can talk to ourselves.  We
want to implement a single UCC supported at all installations, so that
we can log in to all HOSTs using this protocol, and that users at all
foreign HOSTs can log in to us.

私は、多くの熱意がただ私たちが自分達と話すことができるように標準的でないUCCを実装するためのProject MACにあると思いません。 すべてのインストールのときにサポートされた単一のUCCを実装したいと思って、ユーザの全く外国のHOSTsは、私たちが様々なプロトコルを使用することですべてのHOSTsにログインできるように、私たちにログインできます。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Altair Petrofsky 7/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][牽牛星Petrofsky7/97によるオンラインRFCアーカイブへの]

                                                                [Page 5]

[5ページ]