RFC98 日本語訳
0098 Logger Protocol Proposal. E. Meyer, T. Skinner. February 1971. (Format: TXT=24536 bytes) (Updated by RFC0123) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Request for Comments #98 Network Information Center #5744
コメント#98ネットワーク情報センター#5744に関するネットワークワーキンググループ要求
Logger Protocol Proposal
きこりのプロトコル提案
Edwin W. Meyer, Jr.
Thomas P. Skinner
February 11, 1971
エドウィン・W.マイヤー、1971年2月11日のJr.トーマスP.スキナー
With the ARPA Network Host-to-Host Protocol specified and at
least partially implemented at a number of sites, the question of what
steps should be taken next arises. There appears to be a widespread
feeling among Network participants that the first step should be the
specification and implementation of what has been called the "Logger
Protocol"; the Computer Network Group at project MAC agrees. The term
"logger" has been commonly used to indicate the basic mechanism to gain
access (to "login") to a system from a console. A network logger is
intended to specify how the existing logger of a network host is to
interface to the network so as to permit a login from a console attached
to another host.
アーパネットHostからホストへのプロトコルが指定されて、多くのサイトで少なくとも部分的に実装されている状態で、次にどんな方法を取るべきであるかに関する質問は起こります。 第一歩が「きこりのプロトコル」と呼ばれたものに関する仕様と実装であるべきであるというNetwork関係者の中の広範囲の感じはあるように見えます。 プロジェクトMACのコンピュータNetwork Groupは同意します。 「きこり」という期間はコンソールからアクセスをシステムに得る(「ログインする」)ために基本的機構を示すのにおいて一般的に使用されています。 ネットワークきこりがネットワークホストの既存のきこりが別のホストに愛着しているコンソールからログインを可能にするためにネットワークに連結することになっている方法を指定することを意図します。
To implement network login capability now seems quite
desirable.In the first place, it is natural for Network participants to
wish to learn more about the remote systems in the immediate fashion
afforded by direct use of those systems. In the second place, the
technical problems introduced by remote logins are probably less complex
than those involved with such further tasks as generalized file
transfer; thus, a Logger Protocol could be implemented relatively
quickly, furnishing additional impetus and encouragement for taking
still further steps.
Network関係者にとって、1位であり能力が今思えるネットワークログインに全くdesirable.Inを実装するために、それはもう少し学ぶ願望に当然です。ファッションがそれらのシステムのダイレクト使用で. 第二にリモート・ログインで紹介された技術的問題を提供した即座のリモートシステムはたぶんファイル転送を一般化するような、より遠いタスクがある関係者より複雑ではありません。 したがって、まださらなる方法がかかっているための追加起動力と奨励を提供して、比較的すぐにLoggerプロトコルを実装することができました。
In order to furnish at least a basis for discussion (and at most
an initial version of a Logger Protocol), we have prepared this
document, which attempts to present a minimal set of conditions for
basing a Logger Protocol. This proposal covers only the mechanism for
accomplishing login. What occurs following login is not discussed here,
because we feel more experimentation is necessary before any protocol
for general console communication can be established as standard. In its
absence, each site should specify its own experimental standards for
console communications following login.
少なくとも議論(そして、高々Loggerプロトコルの初期のバージョン)の基礎を提供するために、私たちはこのドキュメントを準備しました。(それは、Loggerプロトコルを基礎づけるための1人の極小集合の状態を提示するのを試みます)。 この提案は、ログインを実行するためにメカニズムだけをカバーしています。 ここでログインに続いて、起こることについて議論しません、私たちが、同じくらい標準で一般的なコンソールコミュニケーションのためのどんなプロトコルも確立できる前により多くの実験が必要であると感じるので。 不在では、ログインに続いて、各サイトはそれ自身のコンソールコミュニケーションの実験規格を指定するべきです。
Some of the points raised in this document have already reached
a certain level of consensus among network participants while at least
one point is rather new. It should be clearly understood, however, that
we feel regardless of the disposal of particular issues, Networkwide
少なくとも1ポイントがかなり新しい間、本書では上げられたポイントのいくつかがネットワーク関係者の中で既にあるレベルのコンセンサスに達しています。 Networkwide、しかしながら、私たちが事項の処分にかかわらず問題を感じるのが明確に理解されるべきです。
[Page 1]
RFC 98 Logger Protcol Proposal Feb 1971
[1ページ] RFC98きこりのProtcol提案1971年2月
agreement should be reached as soon as possible on some general protocol. This is all the more desirable in view of the fact that it is quite likely that certain points which should be covered in this protocol will only become apparent during the course of implementation; therefore, the sooner a common basis for implementation can be reached, the sooner a more rigorous protocol can be enunciated.
できるだけ早く、何らかの一般的なプロトコルで合意に達するべきです。 これはこのプロトコルでカバーされているべきである、ある一定のポイントが実装のコースの間かなり明らかになるだけでありそうであるという事実から見てひとしお望ましいです。 したがって、実装の共有基準により早く達することができれば、より早くより厳密なプロトコルを述べることができます。
Before turning to 1) a discussion of the points with which to
decide the protocol should deal, and 2) specifications for the current
state of the protocolm we feel that we should acknowledge the
consideration that a case could be made for avoidingthe difficulty of
generating a Logger Protocol by simply declaring that each host may
specify its own, perhaps unique, preferences for being approached over
the Network. Although such a course is certainly possible, it does not
seem to us to be desirable. One reason for avoiding such a course is
simply that following it hamper general Network progress, in that
adressing the task of interfacing with some 20 systems is bound to more
time-consuming than to interface with "one" system, even though each
indivudual one of the former, multiple interfaces might be in some sense
simpler than the latter, single interface. Another consideration is less
pragmatic, but nonetheless important: agreement on a common protocol
would tend to foster a sense of Network "community", which would tend to
be fragmented by the local option route. After all, the Host-to-Host
Protocol could have been handled on a per-host basis as well; assumedly,
one reason why it has not had something to do with similar, admittedly
abstract considerations.
以前、1に変わります) プロトコルについて決めるポイントの議論は取引、およびケースが考慮であるかもしれませんが、各ホストがそれ自身の、そして、恐らくユニークな好みを指定するかもしれないと単に宣言することによってNetworkの上でアプローチされるためにLoggerプロトコルを生成するというavoidingthe困難のために作られていて、私たちが承認するべきである私たちが感じるprotocolmの現状のための2つの)仕様がそうするべきです。 そのようなコースは確かに可能ですが、それは望ましいように私たちにとって思えません。 単に、そのようなコースを避ける1つの理由はそれに続くと一般的なNetwork進歩が妨げられるということです、およそ20台のシステムに接続するタスクをadressingするのが前者のそれぞれのindivudual1つですが、「1つ」システムに接続するために後者より簡単な何らかの意味には複数のインタフェースがあるかもしれないより手間がかかって、単一のインタフェースに縛られるので。 別の考慮すべき事柄は、それほど実践的ではありませんが、それにもかかわらず、重要です: 一般的なプロトコルの協定は、地方選択権ルートで断片化される傾向があるだろうNetwork「共同体」の感覚を伸ばす傾向があるでしょう。 結局、Hostからホストへのプロトコルはまた、1ホストあたり1個のベースで扱われたかもしれません。 当然のことのように、それが持っている1つの理由は同様の、そして、明白に抽象的な問題と関係がありませんでした。
Context
文脈
Structurally, the mechanism serving to login a user over the Network consists of two parts, one part at the using host, the other at the serving host. The using or local host is the one to which the users typewriter is directly connected; it contains a modulewhich channels and transforms communications between the Network connection and the typewriter. The serving or foreign host provides the service to be used; it contains programming that adapts the logger and command system to use through the Network rather than a local typewriter.
構造的に、Networkの上でログインにユーザに役立つメカニズムは2つの部品から成ります、使用しているホストの一部、給仕のホストのもう片方。 使用かローカル・ホストがユーザタイプライタが直接接続されるものです。 それは、Network接続とタイプライタの間でmodulewhichチャンネルを含んでいて、コミュニケーションを変えます。 給仕か異種宿主が使用されるためにサービスを提供します。 それは地方のタイプライタよりむしろきこりを適合させるプログラミングとNetworkを通して使用する指令方式を含んでいます。
There are three different phases to a login through the network.
ネットワークを通したログインへの3つの異なったフェーズがあります。
1. During the connection phase the users console is connected to
the serving logger through the network. This is, of course,
the most important phase from the protocol viewpoint.
1. 接続段階の間、ユーザコンソールはネットワークを通して給仕のきこりに接続されます。 これはもちろんプロトコル観点からの最も重要なフェーズです。
2. The second or dialog phase consists of a sequence of exchange
between the user and the logger that serves to identify the
user and verify his right to use the system. In some hosts,
this phase may be minimal or non-existent.
2. 2番目か対話フェーズがユーザときこりの間のユーザを特定して、システムを使用する彼の権利について確かめるのに役立つ交換の系列から成ります。 何人かのホストでは、このフェーズは、最小量である、または実在しないかもしれません。
[Page 2]
RFC 98 Logger Protcol Proposal Feb 1971
[2ページ] RFC98きこりのProtcol提案1971年2月
3. The admission phase occurs after the user has successfully
completed the login dialog. It consists of switching his
network typewriter connections from the logger to an entity
providing a command processor of some sort. In some hosts
this switching may be totally conceptual; in others there
may be a real internal switching between entities.
3. ユーザが首尾よくログイン対話を完成した後に入場フェーズは起こります。 それは彼のきこりからある種のコマンドプロセサを提供する実体までのネットワークタイプライタ接続を切り換えるのから成ります。 何人かのホストでは、この切り換えは全く概念的であるかもしれません。 他のものには、実体の間には、全く内部の切り換えがあるかもしれません。
The Connection Phase
接続フェーズ
The issues involved in specifying a protocol for implementing
login can be separatedintop two major parts: how to establish and
maintain the network connection between the typewriter and the logger,
and how to conduct a dialog after the connection is made. The first part
is called the Initial Connection Protocol by Harlem and Heafner in RFC
80. It in turn consists of two subparts: how to establish a connection
and how and when to destroy it.
実装するのにプロトコルを指定するのにかかわる問題はseparatedintopが2つの大半であったかもしれないならログインします: タイプライタときこりの間でネットワーク接続を確立して、維持して、接続の後にどうどう対話を行うかを維持するかは作られています。 最初の部分はRFC80にハーレムとHeafnerによってInitial Connectionプロトコルと呼ばれます。 それは2つの下位区分から順番に成ります: どのように取引関係を築くか、そして、どのように、いつそれを破壊しますか?
We endorse the proposal for establishing a connection made in
RFC 80, which we summarize briefly for convenience. It is a two-step
process utilizing the NCP control messages to effect a connection
between the logger and the console of a potential user. First, the user
causes the hosts NCP to send out a "request for connection" control
message destined for the serving hosts loggers contact socket. The two
purposes of this message are to indicate to the logger that this user
wishes to initiate a login dialog and to communicate the identifiers of
the and send socket he wishes to operate for this purpose. The logger
rejects this request to free its contact socket. As the second step the
logger choses two sockets to connect to the user's sockets, and
dispatches connection requests for these. If the user accepts the
connection within a reasonable period, the connection phase is over, and
the dialog phase can begin. If the user does not respond, the requests
are aborted and the logger abandons this login attempt.
私たちは私たちが便宜のために簡潔にまとめるRFC80で作られた接続を確立するための提案を是認します。 それは潜在的ユーザのきこりとコンソールとの接続に作用するNCPコントロールメッセージを利用する二段構えの体制です。 まず最初に、ユーザは給仕のホストのために運命づけられて、きこりがソケットに連絡するという「接続を求める要求」コントロールメッセージを出すNCPをホストに引き起こします。 そして、このメッセージの2つの目的がこのユーザがログイン対話を開始したがっているきこりに示して、識別子をコミュニケートすることになっている、彼がこのために操作したがっているソケットを送ってください。 きこりは接触ソケットを解放するというこの要求を拒絶します。 2番目として、きこりのchosesのためにユーザのソケットに接続する2個のソケット、および接続がこれらのために要求する発信を踏んでください。 ユーザが相当期間以内に接続を受け入れるなら、接続フェーズは終わっています、そして、対話フェーズは始まることができます。 ユーザが応じないなら、要求は中止されます、そして、きこりはこのログイン試みを捨てます。
There is another part to an NCP: when and how to disconnect.
There are two basic situations when a logger should disconnect. The
first situation may arise of the serving host's volition. The logger may
decide to abandon a login attempt or a logged-in user may decide to log
out. The second situation may be due to the using host's volition or
network difficulties. This situation occurs when the serving host
receives a "close connection" control message or one of the network
error messages signifying that further transmission is impossible. This
may happen for either the "read" or the "write" connection,
Disconnecting involves both the deletion of the network connections and
the stoppage of any activity at the serving host related to that user.
If the login is in progress, it should be abandoned. If the user is
already logged in, his process should be stopped, since he no longer has
control over what it is doing. This is not intended to restrict absentee
NCPには別の部分があります: 切断するいつ、方法。 きこりが切断するべきであるとき、2つの基本的な状況があります。 最初の状況は給仕のホストの意志を生じるかもしれません。 きこりが、ログイン試みを捨てると決めるかもしれませんか、またはログインしているユーザは、ログアウトすると決めるかもしれません。 2番目の状況は使用しているホストの意志かネットワーク困難のためであるかもしれません。 給仕のホストが「浅からぬ関係」コントロールメッセージかさらなるトランスミッションが不可能であることを意味するネットワークエラーメッセージの1つを受け取るとき、この状況は起こります。 これは「読み」か「書いてください」という接続のどちらかのために起こるかもしれなくて、Disconnectingはそのユーザと関係がある給仕のホストのネットワーク接続の削除とどんな活動の途絶の両方にもかかわります。 ログインが進行しているなら、それは捨てられるべきです。 ユーザが既にログインされるなら、彼のプロセスは止められるべきです、彼がもう、それがしていることを管理しないので。 これが欠席者を制限することを意図しません。
[Page 3]
RFC 98 Logger Protcol Proposal Feb 1971
[3ページ] RFC98きこりのProtcol提案1971年2月
(i.e. consoleless) jobs.
(すなわち、consoleless) 仕事。
The Dialog Phase
対話フェーズ
The second major part other than getting connected is how to
conduct the login dialog. This resolves itself into two parts: what to
say and in what form to say it. The login dialog generally consist of a
sequence of exchanges, a prompting by the logger followed by a user
reply specifying a name, a project, or password. However, exactly what
information is desired in what sequence is idiosyncratic to each host.
Rather than attempt to specify a standard sequence for this dialog, we
have taken the approach that each host may specify its own sequence, so
long as it is expressible as an exchange of messages in a basic
transmission format. A message is a set of information transmitted by
one of the parties that is sufficient for the other party to reply.By
host specification, either the logger or the user sends sends the first
message of the dialog. After that, messages are exchanged sequentially
until the dialog is completed. In this context "message" has no relation
to "IMP message".
接続されるのを除いた2番目の大半はどうログイン対話を行うかということです。 これは2つの部品に変わります: それを言うために言って、こと形成するべきこと。 一般に、ログイン対話は交換の系列から成ります、ときこりによるうながすのが名前を指定するユーザ回答、プロジェクト、またはパスワードで続きました。 しかしながら、各ホストにとって、どんな系列が特有であるかでまさにどんな情報が必要ですか? むしろ、この対話に標準の系列を指定するのを試みるより私たちは基本的なトランスミッション形式における、メッセージの交換として表現できた状態でそれがそれ自身の系列であって、とても長いのですが、各ホストが指定するかもしれないアプローチを取りました。 メッセージがパーティーの相手にreply.Byホスト仕様に十分なひとりによって伝えられた、1セットの情報である、きこりかユーザが送るどちらかが対話の最初のメッセージを送ります。 その後に、対話が完成するまで、メッセージを連続して交換します。 このような関係においては「メッセージ」は「IMPメッセージ」に関係がありません。
The other issue involved in the login dialog is the format for
transmitting a message. We propose that it be transmitted as a sequence
of ASCII characters (see Specificarions) in groupings calle transaction
blocks.
ログイン対話にかかわるもう片方の問題は、送信するための形式です。 私たちは、それが組分けcalleトランザクションブロックのASCII文字(Specificarionsを見ます)の系列として伝えられるよう提案します。
1. Character Set, We feel that there should be a standard
character set for logging-in. The alternative, requiring a
using host to maintain different transformation between its set
and of each serving host, is a burden that can only narrow the
scope of interhost usage, The character set proposed, ASCII is
widely used standard. Each host must define a transformation
sufficient to transform an arbitrary character sequence in the
host's code into ASCII and back again, without any ambiguity,
The definition of ASCII sequences to express characters not
contained in ASCII is appropriate.
1. 文字コード、Weは、ログインするための標準文字セットがあるべきであると感じます。 代替手段、文字集合は使用しているホストをセットとそれぞれの給仕のホストに異なった変換を維持する必要とするのが、interhost用法の範囲を狭くすることができるだけである負担であるよう提案して、ASCIIは広く使用された規格です。 各ホストは気紛れな質系列を変えることができるくらいの変換をASCIIと定義して、ホストのコードで戻さなければなりません、少しもあいまいさなしでASCIIに含まれなかったキャラクタを示すASCII系列の定義は適切です。
2. Transaction Blocks. A message is transmitted as an arbitrary
integral number of transaction blocks. A transaction block
consists basically of a string of ASCII characters preceeded
by a character count. (It also contains a code field. See
below.) The count is included as an aid to efficiently
assembling a message. Some systems do not scan each character
as it is input from the console. Rather, such systems have
hardware IO controllers that place input characters into a
main memory buffer and interrupt the central processor only
when it receives an "action" character (such as "newline").
This reduces the load on the central processor. Because such
a hardware facility is not available for interpreting
2. トランザクションブロック。 メッセージは任意の整数のトランザクションブロックとして送られます。 トランザクションブロックはキャラクタカウントでpreceededされた一連のASCII文字から基本的に成ります。 (また、それはコード分野を含んでいます。 以下を見てください。) カウントは効率的にメッセージを組み立てることへの援助として含まれています。 それがコンソールから入力されるとき、いくつかのシステムは各キャラクタをスキャンしません。 むしろ、そのようなシステムには、「動作」キャラクタ(「ニューライン」などの)を受けるときだけ、主記憶装置バッファの中に入力キャラクタを任命して、中央のプロセッサを中断するハードウェアIOコントローラがあります。 これは中央のプロセッサで負荷を減少させます。 そのようなハードウェア施設が解釈するのに利用可能でないので
[Page 4]
RFC 98 Logger Protcol Proposal Feb 1971
[4ページ] RFC98きこりのProtcol提案1971年2月
network messages this scheme is proposed as a substitute. It
helps in two ways. First, a system need take no action until
it receives all characters specified in the count. Second, it
need not scan each character to find the end of the message.
The message ends at the end of the of a transaction block.
この体系が代用品として提案されるというメッセージをネットワークでつないでください。 それは2つの方法で助かります。 まず最初に、カウントで指定されたすべてのキャラクタを受けるまで、システムは行動を全く取る必要はありません。 2番目に、それは、メッセージの端を見つけるために各キャラクタをスキャンする必要はありません。 メッセージが終わりに終わる、1つのトランザクションブロックについて。
Other Issues
他の問題
There are several other issues involved in the area of remote
logins which we feel should be raised, although most need not
necessarily have firm agreements reached for an intial protocal.
私たちが上げられるべきであると感じるリモート・ログインの領域にかかわる他のいくつかの問題があります、大部分はintial protocalのために必ず確定協定を達させていなければならないというわけではありませんが。
1. "Echoplex". Echoplex is a mode of typewriter operation in which
all typed material is directed by the computer. A key struck by
a user does not print directly. Rather the code is sent to the
computer, which "echoes" it back to be printed on the typewriter.
To reduce complexity, there is to be no option for network
echoplexing (for the login only). A using system having its
typewriters operating in echoplex mode must generate a local
echo to its typewriters. However, a serving system operating
echoplexed should suppress the echo of the input during the login
phase.
1. "Echoplex"。 Echoplexはすべてのタイプされた材料がコンピュータによって指示されるタイプライタ操作のモードです。 ユーザによって打たれたキーは直接印刷しません。 むしろコードをコンピュータに送ります。(それは、タイプライタに印刷されるために逆でそれを「反響します」)。 複雑さを減少させるために、ネットワークechoplexing(ログインだけのための)のためのオプションは全くないでしょう。 タイプライタがechoplexモードで作動する使用システムはタイプライタにローカルエコーを生成しなければなりません。 しかしながら、作動がechoplexedした給仕システムはログイン段階の間、入力のエコーを抑圧するはずです。
2. Correction of Mistakes. During the login dialog the user may make
a typing mistake. There is no mistake correction ecplicitly
proposed here. If the message in error has not yet been
transmitted, the user can utilize the input editing conventions
of either the using or the serving host. In the first case, the
message is corrected before transmission; in the second, it is
corrected at the serving host. If the user has made an
uncorrectlable mistake, he should abort the login and try again.
To abort, he instructs the local (using) host to "close" one of
the connections. The connections are disconnected as specified in
the Initial Connection Protocol.
2. 誤りの修正。 ログイン対話の間、ユーザはミスタイプをするかもしれません。 ここでecplicitlyに提案されたノーミス修正があります。 間違いメッセージがまだ送られていないなら、ユーザは使用か給仕のホストのどちらかのコンベンションを編集する入力を利用できます。 前者の場合、メッセージはトランスミッションの前に修正されます。 2番目では、それは給仕のホストで修正されます。 ユーザがuncorrectlable誤りをしたなら、彼は、ログインを中止して、再試行するべきです。 中止になるように、彼は、接続のひとりを「閉じる」よう(使用します)地元のホストに命令します。 接続Initial Connectionプロトコルで指定されるように切断されます。
3. "Waiting". It may happen that the user may get into a login dialog
but for some reason does not complete it. The logger is left
waiting for a response by the user. The logger should not wait
indefinitely but after a reasonable interval (perhaps a minute)
abort the login and "close" the connections according to the
provisions of the Initial Connection Protocol.
3. 「待ち。」 ユーザがログイン対話に入るかもしれませんが、ある理由でそれを完成しないのは起こるかもしれません。 きこりはユーザによって応答の待ちに残されます。 きこりが無期限に待つべきではありませんが、Initial Connectionプロトコルに関する条項に従った接続は、(恐らく1分)あたり1回の妥当な間隔の後に、ログインを中止して、「閉じています」。
4. Socket Assignments. The Initial Connection Protocol does not
specify the ownership of the sockets to be used by the logger in
connecting to the user. (The use code field of the socket
identifier determines ownership.) The sockets may belong to the
logger or may have an arbitraryuser code not used by another
process currently existing at the serving host. Under this initial
4. ソケット課題。 ユーザに接する際にきこりによって使用されるように、Initial Connectionプロトコルはソケットの所有権を指定しません。 (コードがさばくソケット識別子の使用は所有権を決定します。) ソケットには、きこりのものか、または現在別のプロセスによって使用されていないarbitraryuserコードが、給仕のホストに存在しながら、あるかもしれません。 このイニシャルの下で
[Page 5]
RFC 98 Logger Protcol Proposal Feb 1971
[5ページ] RFC98きこりのProtcol提案1971年2月
scheme, it is not possible to implement administratively assigned
user codes, because the logger must assign permanent sockets
before the identity of the user is verified. A future connection
protocol can avoid this problem by implementing a socket
connection as a part of the admission phase. The logger would talk
to the user over the logger's sockets. Following identification it
would transfer the connections to the sockets belonging to the
user.
体系、行政上割り当てられたユーザコードを実装するのは可能ではありません、ユーザのアイデンティティが確かめられる前にきこりが本ソケットを割り当てなければならないので。 将来の接続プロトコルは、入場フェーズの一部としてソケット接続を実装することによって、この問題を避けることができます。 きこりはきこりのソケットの上にユーザと話すでしょう。 識別に続いて、それはユーザのものであるソケットに接続を移すでしょう。
5. General Console Communications. A companion paper under
preparation outlines a protocol for general console communcations
between hosts. This paper will seek to adress most of the
problems associated with typewriter like communications. This
includes discussion of full and half duplex, character escapes,
action characters and other pertinent topics. Such a protocol
might not be suitable for all terminals and host systems but
would include solutions to problems for many. It is not
intended as a monolithic standard, but rather as a recommendation
for those sites who wish to implement a common protocol. The
important point is that we feel quite a bit of actual network
usage is required before all the problems are better understood.
This is a prerequisite for devising a standard.
5. 一般コンソールコミュニケーション。 準備中の仲間論文は一般的なコンソールcommuncationsのためにホストの間にプロトコルについて概説します。 この紙はコミュニケーションのようにタイプライタに関連している問題の大部分をadressに求めるでしょう。 これは完全の議論、半二重、キャラクタエスケープ、動作キャラクタ、および他の適切な話題を含んでいます。 そのようなプロトコルは、すべての端末とホストシステムに適しないかもしれませんが、多くのために問題にソリューションを含んでいるでしょう。 それは一枚岩的な規格として意図するのではなく、むしろ一般的なプロトコルを実装することを願っているそれらのサイトのための推薦として意図します。 重要なポイントは私たちが、すべての問題が理解されるほうがよい前にかなりの実際のネットワーク用法が必要であると感じるということです。 これは、規格について工夫するための前提条件です。
SPECIFICATIONS
仕様
Initial Connection Protocol - Connection Phase
初期の接続プロトコル--接続フェーズ
The following sequence is as presented in RFC 80. It is restated
here for completeness.
以下の系列はRFC80に提示されるようにあります。 それは完全性のためにここで言い直されます。
1. To intiate contact , the using process requests a connection of
his receive socket (US) to a socket (SERV) in the serving host.
By convention, this socket has the 24-bit user number field set
to zero. The 8-bit tag or AEN field is set to one indicating
the socket gender to be that of a sending socket. There is no
restriction on the choice of the socket US other than it be of
of the proper gender; in this case a receive socket. As a result
the using NCP sends:
1. intiate接触に、使用プロセスは、彼の接続が給仕のホストのソケット(SERV)にソケット(米国)を受け取るよう要求します。 コンベンションで、このソケットは24ビットのユーザナンバーフィールドをゼロに設定します。 8ビットのタグかAEN分野がソケット性が送付ソケットのものであることを示す1つに設定されます。 それ以外のソケット米国の選択には制限が全くない、適切な性がある、。 この場合、aはソケットを受けます。 その結果、使用NCPは発信します:
User -> Server
ユーザ->サーバ
8 32 32 8
+-----+------------+------------+-----+
| RTS | US | SERV | P |
+-----+------------+------------+-----+
8 32 32 8 +-----+------------+------------+-----+ | RTS| 米国| SERV| P| +-----+------------+------------+-----+
[Page 6]
RFC 98 Logger Protcol Proposal Feb 1971
[6ページ] RFC98きこりのProtcol提案1971年2月
over the control link one, where P is the receive link assigned
by the user's NCP.
コントロールリンク1の上、ユーザのNCPによって割り当てられたリンクを受けてください。そこでは、Pがそうです。
2. The serving host now has the option of accepting the request for
connection or closing the the connection.
2. 給仕のホストには、現在、接続のために要請を受け入れるか、または接続を終えるオプションがあります。
a. If he sends a close it is understood by the user that the
foreign host is unable to satisfy a request for service at
this time. The serving host's NCP would send:
a。 彼が閉鎖を送るなら、異種宿主がこのときサービスを求める要望に応じることができないのがユーザによって理解されています。 給仕のホストのNCPは発信するでしょう:
Server -> User
サーバ->ユーザ
8 32 32
+-----+-----------+------------+
| CLS | SERV | US |
+-----+-----------+------------+
8 32 32 +-----+-----------+------------+ | CLS| SERV| 米国| +-----+-----------+------------+
with the user's NCP sending the echoing close:
ユーザのNCPが反響を送って、閉じてください:
User -> Server
ユーザ->サーバ
8 32 32
+-----+-----------+------------+
| CLS | US | SERV |
+-----+-----------+------------+
8 32 32 +-----+-----------+------------+ | CLS| 米国| SERV| +-----+-----------+------------+
b. If the serving host is willing to provide service it will
accept the connection and immediately close the connection.
This results in the the serving host's NCP sending:
b。 給仕のホストが、サービスを提供しても構わないと思っていると、それは、接続を受け入れて、すぐに、接続を終えるでしょう。 これは給仕のホストのNCP発信をもたらします:
Server -> User
サーバ->ユーザ
8 32 32
+-----+-----------+------------+
| STR | SERV | US |
+-----+-----------+------------+
8 32 32 +-----+-----------+------------+ | STR| SERV| 米国| +-----+-----------+------------+
8 32 32
+-----+-----------+------------+
| CLS | SERV | US |
+-----+-----------+------------+
8 32 32 +-----+-----------+------------+ | CLS| SERV| 米国| +-----+-----------+------------+
[Page 7]
RFC 98 Logger Protcol Proposal Feb 1971
[7ページ] RFC98きこりのProtcol提案1971年2月
with the user's NCP sending the echoing close. It sends:
ユーザのNCPが反響を送って、閉じてください。 それは発信します:
User -> Server
ユーザ->サーバ
8 32 32
+-----+-----------+------------+
| CLS | US | SERV |
+-----+-----------+------------+
8 32 32 +-----+-----------+------------+ | CLS| 米国| SERV| +-----+-----------+------------+
It should be mentioned that the echoing closes are required
by the host-to-host protocol and not by the logger initial
connection protocol.
反響閉鎖がきこりの初期の接続プロトコルではなく、ホスト間プロトコルによって必要とされると言及されるべきです。
Character Set
文字コード
The character set used in conducting the login dialog is
standard ASCII as documented in "American National Standard Code for
Information Interchange", ANS X3, 4-1968, American National Standard
Institute, October, 1968. A logger at a serving host may demand any kind
of input that can be expressed as a string of one or more ASCII
characters. It similarly, it may output any such string.
ログイン対話を行う際に使用される文字集合は「情報交換用米国標準コード」に記録されるように標準のASCIIです、ANS X3、4-1968、米国標準規格Institute、1968年10月。 給仕のホストのきこりは一連の1人以上のASCII文字として言い表すことができるどんな種類の入力も要求するかもしれません。 それ、同様に、それはどんなそのようなストリングも出力するかもしれません。
All ASCII characters are legal, including the graphics and
control characters. However, it is proposed that the only standard way
of indicating the end of a console line be the line feed character
(012). This is in accordance with an anticipated change to the ASCII
standard.
グラフィックスと制御文字を含んでいて、すべてのASCII文字が法的です。 しかしながら、コンソール行の終わりを示す唯一の標準の方法が改行文字(012)であるよう提案されます。 ASCII規格への予期された変化に従って、これはあります。
Currently the ASCII standard permits two methods of ending a
line. One method defines a single character, line feed (012), as
incorporating the combined functions of line space and carriage return
to the lefthand margin. The second method, implicitly permitted by
ASCII, uses the two character sequence line feed (012) and carriage
return (015) to perform the same function.
現在の、ASCII規格は系列を終わらせる2つのメソッドを可能にします。 1つのメソッドが単独のキャラクタを定義します、改行(012)、系列スペースと復帰の結合機能をlefthandマージンに取り入れるとして。 2番目のASCIIによってそれとなく受入れられたメソッドは2キャラクタに系列改行(012)と同じ機能を実行する復帰(015)を使用します。
There is a proposal that the ASCII standard be changed to
include a return to the left-hand margin in all vertical motion
characters of at least one full space (line feed, vertical tab and new
page). This will disallow the dual character sequence to end a line.
少なくとも1つの満杯(改行、垂直タブ、および新しいページ)のすべての上下動キャラクタに左手のマージンへのリターンを含むようにASCII規格を変えるという提案があります。 これは、系列を終わらせるために二重人格系列を禁じるでしょう。
It is suggested that a character in a hostst character set not
having any ASCII equivalnet be represented by the ASCII two character
sequence ESC (033) and one of the ASCII characters. Each host should
publish a list of the escape sequence it has defined.
少しのASCII equivalnetも持っていないhostst文字集合におけるキャラクタがASCII twoキャラクタシーケンスESC(033)とASCII文字のひとりによって代理をされることが提案されます。 各ホストはそれが定義したエスケープシーケンスのリストを発表するべきです。
[Page 8]
RFC 98 Logger Protcol Proposal Feb 1971
[8ページ] RFC98きこりのProtcol提案1971年2月
Transaction Block Format
トランザクションブロックフォーマット
All textual messages exchanged between user and logger are to
consist of one or more "transaction blocks". Each transaction block is a
sequence of 8-bit elements in the following format:
ユーザときこりの間で交換されたすべての原文のメッセージは1「トランザクションブロック」から成ることです。 それぞれのトランザクションブロックは以下の形式の8ビットの要素の系列です:
<code> <count> <char1> ... <charn>
<コード><カウント><char1>… <charn>。
<code> is an 8-bit element that is not interpreted in this
protocol. In the proposed general console communications
protocol, this field specifies communication modes or
special characteristics of this transaction block. Here
<code> is to be zero.
<コード>はこのプロトコルで解釈されない8ビットの要素です。 提案された一般的なコンソール通信規約では、この分野はこのトランザクションブロックのコミュニケーションモードか特別な特性を指定します。 <コード>によるここの、ゼロであることになっています。
<count> is an 8-bit element that specifies the number of character
elements that follow in this transaction block. It is
interpreted as a binary integer which has a permissible
range between 0 and 127. The most significant bit is zero.
<カウント>はこのトランザクションブロックで従うキャラクタ要素の数を指定する8ビットの要素です。 それは0〜127の許されている範囲を持っている2進整数として解釈されます。 最も重要なビットはゼロです。
<chari> is an 8-bit element containing a standard 7-bit ASCII
character right-adjusted. The most significant bit is
zero. The number of <chari> in the transaction block is
governed by the <count> field. A maximum of 127 and
minimum of zero characters are permitted in a single
transaction block.
<chari>はASCII文字が権利で調整した標準の7ビットを含む8ビットの要素です。 最も重要なビットはゼロです。 トランザクションブロックの<chari>の数は<カウント>分野によって決定されます。 キャラクタがない最大127と最小限は単一取引ブロックで受入れられます。
The most significant bit of each of these elements is zero,
effectively limiting each of these elements to seven bits of
significance. The reason for doing this is twofold: the eighth bit of
the <chari> elements is specifically reserved for future expansion, and
it was desired to limit all the elements so as to permit certain
implementations to convert the incoming stream from 8-bit elements to
7-bit elements prior to decoding.
それぞれのこれらの要素の最も重要なビットはゼロです、事実上、それぞれのこれらの要素を意味の7ビットに制限して。 これをする理由は二つです: <chari>要素の8番目のビットは今後の拡張のために明確に予約されました、そして、ある実装が解読の前に8ビットの要素から7ビットの要素まで入って来るストリームを変換することを許可するためにすべての要素を制限することが望まれていました。
With one exception, there is to be no semantic connotation
attached with the division of a logger-user message into one or more
transaction blocks. The character string comprising the message to be
transmitted may be divided and apportioned among multiple transaction
blocks according to the whim of the sending host. If less than 128
characters in length, the message may be sent as a single transaction
block. The exception is that separate messages may not appear in the
same transaction block. That is, a message must start at the beginning
of a transaction block and finish at the end of one. Note also that
there is no syntactic device for specifying the last transaction block
of a message. It is presumed that the logger end user both have
sufficient knowledge of the format to know when all of a message has
arrived
ただ1つを例外として、きこりユーザメッセージの分割と共に1つ以上のトランザクションブロック以上に付けられたどんな意味含蓄もないでしょう。 送付ホストの気まぐれに従って、伝えられるべきメッセージを包括する文字列は、複数のトランザクションブロックの中で分割されて、分配されるかもしれません。 長さにおける128未満のキャラクタであるなら、単一取引ブロックとしてメッセージを送るかもしれません。 例外は別々のメッセージが同じトランザクションブロックに現れないかもしれないということです。 すなわち、メッセージは、1つのトランザクションブロックの始めに始まって、1の終わりで終わらなければなりません。 また、メッセージの最後のトランザクションブロックを指定するためのどんな構文のデバイスもないことに注意してください。 きこりのエンドユーザには形式に関するメッセージのすべてがいつ到着したかを知ることができるくらいの知識がともにあると推定されます。
[Page 9]
RFC 98 Logger Protcol Proposal Feb 1971
[9ページ] RFC98きこりのProtcol提案1971年2月
Note that the first 8-bits of data transmitted through a newly
established connection must be a type code as specified in Protocol
Document 1. This type code must be sent prior to the first transaction
block and should be discarded by the receiving host.
新設された接続で送られた最初の8ビットのデータが指定されるとしてプロトコルDocument1のタイプコードであるに違いないことに注意してください。 このタイプコードは、最初のトランザクションブロックの前に送らなければならなくて、受信ホストによって捨てられるべきです。
Acknowledgments
承認
Robert Bressler, Allen Brown, Robert Metcalfe, and Michael
Padlipsky contributed directly to the establishment of the ideas
presented here. Thanks are due Michael Padlipsky and others for
editorial comments.
ロバートBressler、アレン・ブラウン、ロバートメトカルフェ、およびマイケルPadlipskyは直接ここに提示された考えの確立に貢献しました。 感謝は、編集のコメントのための当然のマイケルPadlipskyと他のものです。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Carl Moberg 1/98 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][カール・モーベリ1/98によるオンラインRFCアーカイブへの]
[Page 10]
[10ページ]
一覧
スポンサーリンク
