RFC967 日本語訳
0967 All victims together. M.A. Padlipsky. December 1985. (Format: TXT=4706 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. A. Padlipsky Request for Comments: 967 Mitre Corporation December 1985
A.Padlipskyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 967 斜め継ぎ社の1985年12月
All Victims Together
一緒にすべての犠牲者
STATUS OF THIS MEMO
このメモの状態
This RFC notes a significant omission from the networking literature and proposes to remedy it. Distribution of this memo is unlimited.
このRFCは、ネットワーク文学から重要な省略に注意して、それを治すよう提案します。 このメモの分配は無制限です。
DISCUSSION
議論
An interesting thing happened the other day. Some people were up visiting from IBM Federal Systems Division and, during the course of the conversation, one of them pointed out that they had just as much if not more trouble with the operating system purveyors about making OS "changes" in behalf of networking as anyone else. At the time I just observed that it looked as if we were all victims together and went on to the next point, but further reflection prompts me to offer a few thoughts on the topic to the RFC community:
おもしろいことは先日、起こりました。 何人かの人々がIBMの連邦政府のSystems事業部から訪問しながら、起きていました、そして、会話のコースの間、彼らのひとりは彼らがちょうど同じくらいたくさん他の誰としてのネットワークのためにOS「変化」を作ることに関してましてオペレーティングシステム御用商人の、より多くの苦労をしたと指摘しました。 当時、まるで私たちが一緒に犠牲者であり、次のポイントに進んでいるかのように私は、それが見たのをただ観測しましたが、さらなる反射は、私が話題に関するいくつかの考えをRFC共同体に提供するようにうながします:
o To us, it's axiomatic that networking code is system code when it has to be.
o 私たちにとって、ネットワークコードがそれがそうしなければならないシステム・コードであることは自明です。いてください。
o To Them, it's anathema.
o Themに、それは呪いです。
o We haven't really hit very hard on the point in the literature (although I guess I have made a few strong assertions along those lines, here and there, and it's at least implicit in some of Dave Clark's stuff), unless in my usual slipshod fashion I've just missed seeing it.
o 私たちは本当に文学でポイントでそれほど強く当たりません(私が、それらの線に沿っていくつかの強い主張をあちらこちらしたと推測します、そして、それはデーブ・クラークのいくつかのもので少なくとも暗に示されていますが)、私が、それを見るのを私の普通のだらしないやり方でちょうど逃していない場合。
o It would probably be responsible of us to rectify the omission (assuming there is one) since the literature is supposed to be the way the researchers educate the practioners.
o 文学が研究者が開業医を教育する方法であるべきであるので、省略を正すのはたぶん私たちにおいて責任があるでしょう(1つがあると仮定して)。
o Therefore, I propose a new subseries of RFCs on how the networking code was integrated with various OSs, with an eye toward subsequent publication of the collection in the open literature (RFCs being only semi-open, after all). I'll even volunteer to coordinate, at least to the extent of taking offers from people who are willing to tackle various systems and telling them who else is having a bash at the same one for purposes of possible collaboration--and possibly even merging the results of separate efforts if people just send in things they've already done. (I suppose I even have to offer to do a bit of editing, if people want.)
o したがって、私はネットワークコードが様々なOSsについてどう統合していたかのRFCsの新しい「副-シリーズ」を提案します、開いている文学(結局準開くだけであるRFCs)における収集のその後の公表に向かった目で。 私は、調整するのを買って出さえするつもりです、人々がただ、それらが既にしたことを送るならことによると別々の努力の結果を合併さえして少なくとも様々なシステムに取り組んでも構わないと思っている人々から申し出を取って、可能な共同の目的のために他のだれが同じ1つを試みているかを彼らに言う範囲に。 (人々が望んでいるなら、私は、少しの編集をすると申し出さえしなければならないと思います。)
Padlipsky [Page 1]
Padlipsky[1ページ]
RFC 967 December 1985 All Victims Together
RFC967 1985年12月 一緒にすべての犠牲者
What I'd like to see emerge is a bunch of little essays along the lines of what I attempted to do on Multics in RFC 928, pp.14-21, which would probably be a waste of electrons to reproduce here, but I will if Jon thinks it's worthwhile at some level. With luck, volunteers will emerge to discuss all of the major operating systems currently on the net and most of the minor ones as well, since one of the most interesting philosophical aspects of the exercise is to see just what cuts and pastes get made to any OS if it's networked. My guess is that given more modern systems' tendencies to make adding device drivers more straightforward and to offer interprocess communication primitives at the system level, the likeliest difficulties to encounter would be getting on the process creation path appropriately for Telnet--but that's reasoning ahead of the data. Suffice it to say that each piece should address Host-Host protocol interpreter(s) integration as well as Host-Comm Subnet Processor PI (including device driver, if one), plus something about Telnet and something else about FTP (at least to the extent of whether it's per-user or "monolithic"--on the server side, that is), and, of course, some relevant anatomizing of the OS itself.
現れる見たいと思うものは私がRFC928、たぶんここで再生させる電子の浪費であるだろうpp.14-21のMulticsでするのを試みたことに関する線に沿った多くの小論ですが、ジョンが、それある意味で価値があると考えるなら、私は小論であるつもりです。 運で、ボランティアはまた、現在、ネットの大部分と小さい方のものの大部分で主要なオペレーティングシステムのすべてについて議論するために現れるでしょう、運動の最もおもしろい哲学的な局面の1つがそれがネットワークでつながれるならまさしくどんなきり傷とペーストが何かOSに新調するかを見ることであるので。 私の推測はデバイスドライバを加えるのをより簡単にして、システムレベルでプロセス間通信基関数を提供するより現代のシステムの傾向を考えて、遭遇する中で最もありそうな困難がTelnetのために適切に過程創造経路に乗っているだろうというのにもかかわらずの、それがデータの前の推理であるということです。 それを満足させて、各断片がFTP(すなわち少なくともそれがサーバ側でユーザかそれとも「一枚岩的であるか」に関する範囲に)に関するTelnetと他の何か、およびもちろんOS自体のいくつかの関連解剖に関してHost-Comm Subnet Processor PI(1であるならデバイスドライバを含んでいる)と同様にHost-ホストプロトコルインタプリタ統合、および何かを記述するべきであると言ってください。
The moral, it seems to me, is that we have a chance to strike back at the oppressors by showing them what they should be furnishing with their silly off-the-rack systems if they are going to continue to object to our alterations to make the bloody things fit anywhere near right. It's a little extra effort on our part, but it's probably a worthy goal. Indeed, if anybody from IPTO is watching I suppose I'd even go so far as to suggest a pro tem System Integration Task force if I hadn't already volunteered once in this thing and used up my quota.
教訓が私たちにはそれらが、血だらけのものを右の近くのどこにも合わせないように私たちの変更に反対し続けるなら彼らが自分達の愚かな既製のシステムで何を提供するべきであるかを彼らに示すことによって抑圧者で逆襲する機会があるということであるように思えます。 私たちの部分における少し余分な努力ですが、それはたぶんふさわしい目標です。 本当に、IPTOからのだれかが、Iが、私が臨時aを示しさえすると思うのを見ていて、私が既に持たなかったなら、システム統合課Task軍はこのもので一度買って出て、私の割当てを使いきりました。
Think about it.
それについて考えてください。
EDITOR'S NOTE
編集者注
The editor recalls a session at the 5th Data Communication Symposium (the one at Snowbird) titled "Impact of Networks on Host-System Design and Architecture". (1977)
エディタは「ホストシステム設計と構造のネットワークの影響」と題をつけられた第5Data Communication Symposium(Snowbirdのもの)でセッションを思い出します。 (1977)
Padlipsky [Page 2]
Padlipsky[2ページ]
一覧
スポンサーリンク