RFC451 日本語訳

Network Working Group                                  M.A. Padlipsky
Request for Comments # 451                             MIT-Multics
NIC # 14135                                            February 22, 1973

ネットワークワーキンググループM.A.Padlipskyは1973年2月22日にコメント#451MIT-Multics NICのために#14135、を要求します。

          Tentative Proposal for a Unified User Level Protocol

ユーザの統一されたレベルプロトコルのための試案

Now that proposals for expansions to the Telnet Protocol are in vogue
again (RFC's 426 and 435, for example), I'd like to promote some
discussion of a particular favorite of my own.  Please note that this is
presented as a tentative proposal: it's an attempt to consider the
desirability of a new approach, not a rigorous specification.  To begin
somewhat obliquely, for some time I've felt that we (the NWG) have
fallen into a trap in regard to the Initial Connection Protocol.  The
point is that even though the ICP gives us the ability to define a
"family" of ICPlets by varying the contact socket, there's no compelling
reason why we should do so.  That we have done so in the FTP and RJEP I
view as unfortunate--but also undesirable and unnecessary.

テルネット・プロトコルへの拡張のための提案が再び(例えば、RFCの426と435)流行しているので、私自身の特定のお気に入りの何らかの議論を促進したいと思います。 これは試案として提示されます: それは厳密な仕様ではなく、新しいアプローチの願わしさを考える試みです。 いくらか斜めに、そして、しばらく始まるように、私たち(NWG)がInitial Connectionプロトコルに関する罠になったのを感じました。 ポイントはICPが接触ソケットを変えることによってICPletsの「ファミリー」を定義する能力を私たちに与えますが、私たちがそうするべきであるやむにやまれない理由が全くないということです。 私たちは私が不幸ですが、望ましくなくも不要であるとして見なすFTPとRJEPでそうしました。

To take the "undesirable" aspects first, consider the following: If we
continue to define a new contact socket for every new "user level"
protocol we come up with, we'll continue to need another new mechanism
(process, procedure, or patch) to respond to requests for connection for
each new protocol.  By Occam's Razor (or the principle of economy of
mechanism, if you prefer), this is a bad thing.  Irrespective of the
relative difficulty of implementing such mechanisms on the various
Hosts, to implement them at all leads to a kind of conceptual clutter.
Further, a different kind of confusion is introduced by the notion which
some of our number seem to be entertaining, that the "later" user level
protocols such as FTP are somehow still another level of abstraction up
from Telnet.  So it seems to me that we could spare ourselves a lot of
bother, both practical and theoretical, if we could avoid spawning
contact sockets needlessly.

最初に「望ましくありません、な」局面を取るには、以下を考えてください: 私たちが思いつくあらゆる新しい「ユーザレベル」プロトコルのために新しい接触ソケットを定義し続けていると、私たちは、それぞれの新しいプロトコルのための接続を求める要求に応じるためにずっと別の新しいメカニズムを必要とするでしょう(プロセス、手順、またはパッチ)。 Occamのレイザー、(または、メカニズムの経済の原則、よければ)、これは悪いものです。 様々なHostsでそのようなメカニズムを実装するという相対的な困難において関係ありません、彼らを全く実装するのは一種の概念的な散乱に通じます。 さらに、FTPなどのユーザの「後」のレベルプロトコルがどうにかTelnetから上がっている抽象化のまだ別のレベルであるという私たちの番号のいくつかがいだいているように思える概念で異種の混乱を導入します。 それで、私たちが実際的なものと同様に理論上の多くの面倒から自分達を開放できたように思えます、私たちが、不必要に接触ソケットを量産するのを避けることができるなら。

Turning to the "unnecessary" aspects, I think that even if the case
against the current approach isn't completely convincing the case for a
particular alternative might be.  So to show that the multiple contact
socket ICP is unnecessary, I'll try to show that what I call the
"unified user level protocol" (UULP) is better.  The first thing to
notice is that all the "later" protocols "speak Telnet".  This is
sensible: Telnet works, by and large.  Why not make use of it?  Right.
But why not make even more use of it?  In view of the fact that FTP,
RJEP, and even the initiating part of the Network Graphics Protocol, are
really just ways of letting a user say to a Server "I don't know what
you call it on your system, but please perform the whatever function
(push or pull a file, start or stop a batch job, funnel some of my
output through the Network Virtual Graphics Terminal module) for me now,

「不要な」局面に変わって、私は、現在のアプローチに対するケースに完全に説得力があるというわけではなくても特定の代替手段のためのケースがそうであると思います。 それで、複数の接触ソケットICPが不要であることを示すために、私は、私が「ユーザの統一されたレベルプロトコル」(UULP)と呼ぶことが、より良いのを示そうとするでしょう。 気付く最初のものはすべての「後」のプロトコルが「Telnetを話す」ということです。 これは分別があります: telnetは概して働いています。 なぜそれを利用しませんか? 正しい。 しかし、なぜそれのさらに多くの使用をしませんか? 事実から見たそのFTP、RJEP、およびNetwork Graphicsプロトコルの開始部分さえ本当にただユーザ言いたい事をServerにさせる方法である、「私がシステムでいわゆるそれを知りませんが、働いてください、私のための現在のいかなる機能(ファイルを押すか、引きます、始まるか、バッチ・ジョブを止めてください、そして、またはNetwork Virtual Graphics Terminalモジュールによる私の出力のいくつかを注ぐ)、も」

Padlipsky                                                       [Page 1]

RFC 451           Unified User Level Protocol Proposal     February 1973

Padlipsky[1ページ]RFC451はプロトコル提案1973年2月にユーザレベルを統一しました。

why not simply put hooks in Telnet to indicate that a Network Generic
Function is wanted instead of a Host-specific one at a given point in
time?  Then everybody can come in through Telnet in ways that are
already known (and usually debugged and optimized) and fan out to other
services through a single mechanism, where that single mechanism can be
whatever is most appropriate to a particular Host.  This view has the
additional virtue of keeping the Host "Answering Service"-equivalent
processes out of the act when new protocols come along -- where by
Answering Service, I mean that process which manages logins in general
for a given Host.  This process is, of course, a particularly sensitive
one on those systems which worry about accounting and security.

なぜNetwork Generic Functionが時間内に与えられたポイントのHost特有のものの代わりに欲しいのを示すためにTelnetにフックを絶対に入れませんか? 次に、みんなは、Telnetを通って既に知られていて、(通常、デバッグされていて最適化される)である方法で入って、ただ一つのメカニズムを通して他のサービスに四方八方に広がることができます。そこでは、そのただ一つのメカニズムが特定のHostに最も適切なことなら何でもであることができます。 この視点には、新しいプロトコルがやって来るとき私がAnswering Serviceで与えられたHostのために一般に、ログインを管理するそのプロセスを言っているところに行為からHost「回答サービス」が同等なプロセスであることを保つ追加美徳があります。 このプロセスはもちろん会計とセキュリティを心配するそれらのシステムの上の特に敏感なものです。

That's all probably a bit vague.  Perhaps some idea of how I think the
UULP would work will cast some light on what I think it is.  What's
needed is a way of letting the Server know that it's being given a
generic command (I decline to call it a Network Virtual command, but I'm
afraid that might be what I mean) like "STOR" or "RETR" rather than a
local command like "who" or "sys".  What could be simpler than defining
a Telnet Control Code (TCC) for "Network Generic Function Follows"?  So
if the Server Telnet receives a command line beginning with the NGF TCC
(say, 277 octal), it just feeds the line to the appropriate process or
procedure (depending on the structure of its operating system).  This
approach also offers a handy way of communicating back the fact that a
particular protocol or piece thereof isn't available: define a TCC for
"Unimplemented Generic Function".  This feels a lot cleaner than having
a close on socket 3 mean anything from "no FTP Server exists here" to
"the FTP Server happens to be busy."

それはたぶん少しすべてあいまいです。 恐らく私が、UULPが働いているとどう思うかに関する何らかの考えが私が、思うそれが何であるかのいくらかの光を投げかけるでしょう。 必要であるものはServerに「だれ」や"sys"のようなローカルのコマンドよりむしろ"STOR"や"RETR"のようにジェネリックコマンド(残念ながら、私は、それをNetwork Virtualコマンドと呼ぶのを断りますが、それは私が言っていることであるかもしれない)がそれに与えられているのを知らせるか方法です。 何が「ネットワークジェネリック機能は続く」ように、Telnet Control Code(TCC)を定義するより簡単であるかもしれませんか? それで、Server TelnetがNGF TCC(たとえば、277 8進)と共に始まるコマンドラインを受けるなら、それはただ適切なプロセスか手順に系列を提供します(オペレーティングシステムの構造によって)。 また、このアプローチはそれの特定のプロトコルか断片が利用可能でないという事実を伝え返す便利な方法を提供します: 「Unimplementedジェネリック機能」のためにTCCを定義してください。 これはソケット3の上の閉鎖に「どんなFTP Serverもここに存在していないこと」から「FTP Serverはたまたま忙しくなる」までの何でも意味させるよりはるかにきれいであると感じられます。

Notice that the UULP automatically provides the answer to such
objections as the one Braden raises in RFC 430, that "there is no
mechanism within the FTP for _changing_ a password.  A user shouldn't
have to use a different protocol ... to merely change his password".
With the UULP, any system which has a password changing ability would
have it available for all user level protocols because all of its
abilities are made available by the generic login.  This seems clearly
superior to having to retrofit afterthought after afterthought to the
various user level protocols as we come to realize that life is more
convenient when we get away from the view that each protocol lives in
its own island universe.  I understand that one of the main motivations
for going the multiple contact socket route was to avoid syntactic (and
semantic) conflicts between the protocol and the particular Host's
"normal" command processor; however, locking ourselves in to special
command processors exclusively is awfully procrustean.  So instead of
cutting off the limbs to fit the bed, why not use the UULP to expand the
bed.

UULPが自動的にブレーデンがRFC430で上げるもののような反論の答えを提供して、「_パスワードを変える_のためのFTPの中にメカニズムが全くないこと」に注意してください。 「ユーザは単に彼のパスワードを変えるのに異なったプロトコルを…使用する必要はないはずです。」 UULPと共に、能力を変えるパスワードを持っているどんなシステムでもそれは、ジェネリックログインで性能のすべてを利用可能にするので、すべてのユーザレベルプロトコルに利用可能になるでしょう。 これは私たちがその寿命がわかるようになるので、私たちが各プロトコルがそれ自身の島宇宙の中に住んでいるという意見から逃げるとき、ユーザの様々なレベルプロトコルへの結果論が便利によりなった後に結果論を改装しなければならないために明確に優れているように見えます。 私は、複数の連絡ソケットルートがあった行くことに関する主な動機の1つがプロトコルと特定のHostの「正常な」コマンドプロセサとの構文の、そして、(意味)の闘争を避けるのを理解しています。 しかしながら、排他的に特別なコマンドプロセサに自分達を閉じ込めるのはとても寝台です。 それで、ベッドに合うように手足を切り落とすことの代わりに、なぜベッドを広げるのにUULPを使用しませんか?

Padlipsky                                                       [Page 2]

RFC 451           Unified User Level Protocol Proposal     February 1973

Padlipsky[2ページ]RFC451はプロトコル提案1973年2月にユーザレベルを統一しました。

Although this is a tentative proposal and not meant to be a detailed
design spec, one elaboration suggests itself which might make the
general idea more attractive: For ease of implementation on some
systems, it would probably be a good idea to define additional TCC's for
"Begin User Protocol".  That is, the user side starts the FTP by sending
the "Begin FTP" Telnet Control Code, waits for the Server to send either
the same code or the one for "Unimplemented Generic Function", and then
proceeds (or not) to send STOR's and RETR's and the like.  (It could
also follow the "I will"/"I won't" style discipline of RFC 435 if we
like.) Probably each line is preceded by the Network Generic Function
TCC so that systems which don't pass input off to some other process can
still distinguish between input to the system command processor and
input to the procedure(s) which perform(s) the protocol in question,
although perhaps it would be preferable to have an "End Protocol" TCC.

これが試案であり、詳細なデザイン仕様であることは意味されないで、概念をより魅力的にするかもしれない1個の労作が連想されます: いくつかのシステムの上の実装の容易さのために、「ユーザプロトコルを始めてください」のために追加TCCのものを定義するのは、たぶん名案でしょう。 すなわち、ユーザ側は、「FTPを始めてください」というTelnet Control Codeを送ることによってFTPを始めて、Serverが同じコードかもののどちらかを「Unimplementedジェネリック機能」に行かせるのを待っていて、次に、STOR、RETR、および同様のものを送る(or not)を続かせます。 (また、私たちが好きであるなら「私はそうするつもりです」という「私はそうしないつもりです」/がRFC435の規律を流行に合わせるということになることができました。) たぶん各系列はある他のプロセスに入力を行われさせないシステムがまだ(s) 問題のプロトコルを実行する手順へのシステムコマンドプロセサと入力に見分けることができるように、入力をNetwork Generic Function TCCによって先行されています、「終わりのプロトコル」TCCを持っているのが恐らく望ましいでしょうが。

Now, I'm the first to admit that what makes sense to me, on my system,
may not make sense on somebody else's.  But it does seem plausible to me
that the unified user level protocol I've sketched here ought to be no
harder to implement than the multiple contact socket (MCS) ICP is.  And
the advantages of the UULP over the MCS ICP in terms of ease of
extension and (at least in my mind, if not in this paper) clarity make
it seem worthwhile to consider further.  So rather than try to refine it
here, let me simply ask for comments both on the general notion and on
the necessary iteration of the design from sketch to spec.  (The Multics
scenario in ICCC booklet shows how to get "mail" to me, for those who
don't feel like RFCing or phoning.)

現在、私は私のシステムの上で私に理解できることが他の誰かのところで理解できないかもしれないことを1番目に認めます。 しかし、私がここにスケッチしたユーザの統一されたレベルプロトコルは実装するのが複数の接触ソケット(MCS)ICPほど困難であるべきでないことが私にとってもっともらしく思えます。 そして、拡大と(少なくとも私の心、またはこの紙の)明快の容易さに関するMCS ICPの上のUULPの利点はそれをさらに考えるために価値があるように見せます。 それで、むしろ、一般的な概念とデザインの必要な繰り返しのときにここでそれを精製しようとするより単にスケッチから仕様まで発言を求めさせてください。 (ICCC小冊子のMulticsシナリオは、どのように「メール」を私に届けるかを示します、RFCingか電話が欲しくない人のために。)

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社9/99]

Padlipsky                                                       [Page 3]

Padlipsky[3ページ]