RFC231 日本語訳

Network Working Group                     J. Heafner - Rand
Request for Comments  231                 E. Harslem - Rand
NIC 7648                                  21 September 1971

ネットワークワーキンググループJ.Heafner--コメント231E.Harslemを求める底ならし革要求--底ならし革NIC7648 1971年9月21日

                        SERVICE CENTER STANDARDS
                        ------------------------
                    FOR REMOTE USAGE--A USER'S VIEW
                    -------------------------------

サービスセンター規格------------------------ リモート用法のために--、ユーザの視点-------------------------------

INTRODUCTION
------------

序論------------

     This note is a statement of our views on service cen- ter
standards.  It is an input to the service center panel discussion of
the October Network meeting.  Some areas are identified for
consideration in intra-network standardiza- tion.  We do not describe
a methodology for analyzing com- puter systems; however, such analysis
may be appropriate for solving the problems.  We also do not enumerate
the spectrum of services that may be required.  We merely enu- merate
areas where commonality of appearance and function can be of immediate
value to a network user.

この注意はサービスcen- ter規格に関する私たちの意見の声明です。 それは10月のNetworkミーティングのサービスセンター公開討論会への入力です。 いくつかの領域がイントラネットワークstandardiza- tionでの考慮のために特定されます。 私たちはcom- puterシステムを分析するために方法論について説明しません。 しかしながら、問題を解決するのに、そのような分析は適切であるかもしれません。また、私たちは必要であるかもしれないサービスのスペクトルを列挙しません。 私たち、単に外観と機能の共通点にはネットワーク利用者には即座の価値があることができるenu- merate領域。

CAVEAT
------

警告------

     It is assumed that service centers will conform to official
network standard protocols.  This is essential for service centers
since the effects of their practices are generally more wide-spread
and are crucial to the effectiveness of minimal hosts such as TIPs.

サービスセンターが公式のネットワークに標準のプロトコルを従わせると思われます。 それらの習慣の効果が一般に、より広範囲であり、TIPsなどの最小量のホストの有効性に重要であるので、サービスセンターに、これは不可欠です。

JUSTIFICATION
-------------

正当化-------------

     The generation of network standards for service centers is of
value to a very important class of people--the ultimate user
community.  We have such a community at Rand that is composed of
research scientists and their support programmers.  Certainly such
users exist elsewhere, and a goal of the net- work must be to
encourage their use.  In the past, these researchers have relied
solely on programmers to buffer them from computer detail.
Standardization of services is cer- tainly a great value in expanding
the community of users and eliminating the buffer.

サービスセンターのネットワーク規格の世代には、非常に重要なクラスの人々には価値があります--究極のユーザーコミュニティ。 私たちは研究専門の科学者と彼らのサポートプログラマで構成されるRandにそのような共同体を持っています。 確かに、そのようなユーザはほかの場所に存在します、そして、ネットの仕事の目標は彼らの使用を奨励することでなければなりません。 過去に、これらの研究者は、コンピュータの詳細から彼らをバッファリングするように唯一プログラマに頼りました。 サービスの標準化はユーザの共同体を広げて、バッファを排除することにおいてcer- tainlyのaかなりの価値です。

     Additionally, standards will be of benefit to those persons
responsible for implementation of resource access programs.  Instances
and areas of standardization are cited below to support both of these
statements.

さらに、規格はリソースアクセスプログラムの実装に責任があるそれらの人々に有益です。標準化のインスタンスと領域は、これらの声明の両方をサポートするために以下で引用されます。

                                                                [Page 1]

AREAS FOR STANDARDIZATION
-------------------------

[1ページ] 標準化のための領域-------------------------

     Each host installation has its own standards for pro- gramming
and operational procedures.  From a network point of view, we are only
interested in standards affecting external performance--primarily
required operations and documentation of procedures.  Intra-network
standards should allow a user to plan his network use effectively to
improve the performance of his tasks and take advantage of savings in
both time and money.

それぞれのホストインストールには、それ自身の親grammingの規格と操作手順があります。 ネットワーク観点から、私たちは外部の性能に影響する規格に興味を持っているだけです--主として、手順の操作とドキュメンテーションを必要とします。 イントラネットワーク規格で、ユーザは、彼のタスクの性能を向上させて、時間とお金の両方で貯蓄を利用するために有効に彼のネットワーク使用を計画できるべきです。

Remote Job Entry
----------------

リモートジョブエントリ----------------

     One immediately apparent area for standardization is in the
access to network resources.  For example, there are two remote job
entry (RJE) facilities on the network at present with two different
data protocols.  The UCSB facility was developed early to provide
timely access to their resources.  The UCLA facility was developed
after the Telnet and Data Transfer protocols and takes advantage of
them.  If these two services appeared alike to the user and to the
using process, two significant advantages would be obtained.  First,
the using system would need only one module to access both facilities.
And secondly, a user could select either facility on a dynamic basis
using the conditions influencing him at any given moment without any
additional knowledge of the specific site.

標準化のための1つのすぐに見かけの領域がネットワーク資源へのアクセス中です。 例えば、2リモートジョブエントリ(RJE)施設が現在のところ2つの異なったデータプロトコルと共にネットワークにあります。 UCSB施設は、それらのリソースへのタイムリーなアクセスを提供するために早く見いだされました。 UCLA施設は、TelnetとData Transferプロトコルの後に開発されて、それらを利用します。 これらの2つのサービスが同じくユーザと、そして、使用プロセスに現れるなら、2つの重要な利点を得るでしょうに。 まず最初に、使用システムは、両方の施設にアクセスするために1つのモジュールだけを必要とするでしょう。 そして、第二に、ユーザは、いつなんどきでも特定のサイトに関する少しも追加知識なしで彼に影響を及ぼす状態を使用することでダイナミックベースのどちらの施設も選択できるでしょう。

Login Procedures and Subsystem Access
-------------------------------------

ログイン手順とサブシステムアクセス-------------------------------------

     A more global example of common access to resources is the login
procedure to remote systems.  All systems require basically the same
information--password, identification, account number.  Yet the
formats are syntactically inconsis- tent.  An extension to the logger
generally exists at these sites in the form of a "line scanner" for
the network.  In general, this module also performs other
transformational functions.  It would certainly be reasonable for this
module to translate a network standard login into whatever format was
required at the site.  Perhaps to a lesser extent, a similar approach
could be taken to constructing a uniform access to subsystems from the
supervisor.  In like fashion, a network standard interrupt could be
translated into the escape (e.g., control C) of the serving host to
return from a subsystem.

リソースへの一般的なアクセスの、よりグローバルな例はリモートシステムへのログイン手順です。すべてのシステムが基本的に同じ情報を必要とします--パスワード、識別は数を説明します。 しかし、形式はシンタクス上、inconsisがテント生活をするということです。 一般に、きこりへの拡大はネットワークのための「系列スキャナ」の形にこれらのサイトに存在しています。 一般に、また、このモジュールは他の変形機能を実行します。 確かに、このモジュールがサイトで必要であったどんな形式にもネットワークの標準のログインを翻訳するのは、妥当でしょう。 恐らくある程度、監督からサブシステムへの一定のアクセスを構成するのに同様のアプローチを取ることができました。 同様に、サブシステムから戻るために給仕のホストのエスケープ(例えば、コントロールC)にネットワークの標準の中断を翻訳できました。

Charging Algorithms and Accounting Protocol
-------------------------------------------

アルゴリズムと会計プロトコルを請求します。-------------------------------------------

     To accurately forecast costs, a normalized formula for machine

マシンのために正確にコスト、正常にされた公式を予測するために

                                                                [Page 2]

time estimation is needed.  Technically, an accounting protocol is
easily added at the subnet and/or NCP levels--the relevant information
is the same for all nodes, thus the Net charges are readily determined
by any node.  More difficult is the prediction and comparison of host
charges.  Like the login procedure example, each host uses the same
ingredients, namely storage, I/O, connect time, and CPU resources
expended.  Again, like the login procedure the information is handled
slightly dif- ferently in each case such that estimations are
difficult.  For example, some charge algorithms represent I/O as
counts of I/O transactions where others clock I/O time.  Without
significantly perturbing anyone's local accounting proce- dures, it is
desirable to normalize the charge components as a step toward
reasonable cost comparisons and forecast- ing.

[2ページ] 時間見積りが必要です。 技術的に、会計プロトコルはサブネット、そして/または、NCPレベルで容易に加えられます--すべてのノードに、関連情報が同じである、その結果、ネット充電はどんなノードでも容易に決定します。 より難しいのは、ホスト充電の予測と比較です。 ログイン手順の例のように、各ホストはリソースが費やした同じ成分、すなわち、ストレージ、入出力、接続時間、およびCPUを使用します。 一方、ログイン手順のように、情報はわずかに扱われて、それぞれのdif- ferentlyが見積りが難しいようなものをケースに入れるということです。 例えば、他のものが入出力時間の時間を計るところにいくつかの充電アルゴリズムが入出力トランザクションのカウントとして入出力を表します。 だれの地方の会計proce- duresをもかなり混乱させないで、ステップとして合理的な原価比較と予測ingに向かって充電コンポーネントを正常にするのは望ましいです。

Off-Line Services
-----------------                             .

オフラインサービス----------------- .

     Procedures need to be established for off-line services where
they are offered as a service or are an integral part of a service.
Such services are graphic hardcopy, large quantities of printer
output, tape or disc facilities, etc.  How are such items transmitted?
What guarantees or state- ments should be made about turnaround times?
How should they be specified--in terms of invocation and communication
with operations staffs?

手順は、オフラインサービスのためにそれらがサービスとして提供するか、サービスの不可欠の部分であるところに設立される必要があります。 そのようなサービスは、大量のグラフィックハードコピーやプリンタ出力やテープやディスク施設ですなど。 そのような項目はどのように伝えられますか? mentsがそうするべきであるすべての保証か状態がターンアラウンドタイムに関して作られていますか? それらはどのように指定されるべきですか?--操作スタッフとの実施とコミュニケーションに関して?

Job Scheduling, Priorities and Status Information
-------------------------------------------------

ジョブスケジューリング、プライオリティ、および状態情報-------------------------------------------------

     Extrapolating from the above rather static cost com- parisons
that a normalized formula allows, envision a small but useful process,
i.e., a throughput query service, that allows the user to dynamically
determine the most cost ef- fective location for a job.  (Such a
service is technically reasonable since some systems now offer status
data such as a core map and job queues display.) Imagine the user's
situation.  "Let's see, I need these numbers by 4:00 and I'm willing
to pay a slight dollar premium to get them; the job will run on any
Tenex machine, where should I run it?" The user would like to query
Tenex systems, providing as input the requirements of his program, and
get answers like probable turn-around time and cost vectors for dif-
ferent priorities.  (Incidentally, our non-programmer users are
familiar with their job parameters (time, core space, etc.) since this
information is normally part of the out- put stream.)

むしろ静電気が正常にされた公式が許容するcomパリソンかかった上記で推定して、小さい、しかし、役に立つプロセス、すなわち、ユーザが、大部分が仕事のためのef- fective位置かかるとダイナミックに決心できるスループット質問サービスを思い描いてください。 (いくつかのシステムが現在コア地図やジョブキューディスプレイなどの状態データを提供するので、そのようなサービスは技術的に手頃です。) ユーザの状況を想像してください。 「見よう、それらを得るためにわずかなドルプレミアムを支払います」。 「仕事は何かTenexマシンで動いて、私はそれをどこに実行するべきですか?」 彼のプログラムの要件を入力して、dif- ferentプライオリティのためにありえそうなターンアラウンドタイムと費用ベクトルのような答えを得るとき提供して、ユーザはTenexシステムについて質問したがっています。 (ところで、私たちの非プログラマのユーザはこの情報が通常出ているかかっているストリームの一部であるので、彼らの仕事のパラメタ(時間、コアスペースなど)に詳しいです。)

     Most of the necessary elements for such a service are readily
available in systems with which we are concerned.  The query service
would be a utility for users.  This is the kind of a problem we should
address concerning services vis-a-vis exporting Network concepts.

そのようなサービスのための必要な要素の大部分は私たちが関するシステムで容易に利用可能です。 質問サービスはユーザへのユーティリティでしょう。 これはNetworkに概念をエクスポートすることと向かいあって私たちがサービスに関して訴えるべきであるその問題の種類です。

                                                                [Page 3]

Other Areas
-----------

[3ページ] 他の領域-----------

     In addition to the above items, the user community could
immediately benefit from standards in: documentation formats and
distribution, operating schedules, the extent and availability of
consulting services, data transmission and storage facilities,
techniques for communication with operations staffs, and abnormal
procedures such as system or program failures.

上の項目に加えて、ユーザーコミュニティはすぐに、以下で規格の利益を得ることができました。 システムかプログラム障害などのドキュメンテーション形式、分配、スケジュールを操作する、コンサルタント業務、データ伝送、および貯蔵場所の範囲と有用性、操作スタッフとのコミュニケーションのためのテクニック、および異常な手順。

     Some of the above items should be described in a standard format
rather than the services themselves being standardized across the
network.  For example, schedules obviously vary in different time
zones and each system has a different magnitude and policy for on-line
storage capabilities.

数個の上の項目がネットワークの向こう側に標準化されるサービス自体よりむしろ標準書式で説明されるべきです。 例えば、スケジュールは異なった時間帯において明らかに異なります、そして、各システムには、オンラインストレージ能力のための異なった大きさと方針があります。

     To some extent these items are covered in the Resource Notebook.
It should either be expanded to become a service center standards
notebook or a separate item to fulfill that function should be
created.  For example, a site might have resources that it wished to
offer on a limited or special arrangement basis to the network
community and should be included as such in the Resource Notebook.
However, that site might not wish to or have the staff to conform to
network service center standards.  Hence, the service center notebook
would describe standards for a much more rigor- ously conforming
community.

ある程度これらの項目はResource Notebookでカバーされています。 サービスセンターになるように広げられて、その機能を実現させる規格ノートか別々の項目が作成されるべきであるということであるべきです。 例えば、サイトは、それが制限されたか特別なアレンジメントベースでネットワーク共同体に提供したがっていたリソースを持っているかもしれなくて、Resource Notebookにそういうものとして含まれるべきです。 しかしながら、そのサイトには、ネットワーク・サービスセンター規格に従うために、スタッフは、願っていないか、いないかもしれません。 したがって、サービスセンターノートは、共同体をouslyに従わせながら、さらに多く厳格の規格について説明するでしょう。

SUMMARY
-------

概要-------

     The theme of this note is that without classifying ser- vices and
analyzing operations at service nodes, there are a number of areas
that can be standardized to some extent throughout the network.  What
is needed is a manual of service center standards and a collection of
documentation on services.  Perhaps the latter is the Resource
Notebook.

この注意のテーマはser悪を分類して、サービスノードで操作を分析しないで、ネットワーク中である程度標準化できる多くの領域があるということです。 必要であるものは、サービスセンター規格のマニュアルとサービスのときにドキュメンテーションの収集です。 恐らく、後者はResource Notebookです。

     Service centers who intend to attract a significant network user
community should be prepared to adopt a psychol- ogy appropriate to
the market-oriented requirements for providing service.  In the
network at large, with our re- search orientation, personnel tend to
have a different approach to computing than that required by a service
bureau.

重要なネットワークユーザーコミュニティを引き付けるつもりであるサービスセンターはサービスを提供するための市場指向の要件に適切なpsychol- ogyを採用するように準備されるべきです。 私たちの再検索オリエンテーションによる全体のネットワークでは、人員は、サービス・ビューロによって必要とされたそれよりコンピューティングに異なるアプローチを持っている傾向があります。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                   12/96   ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの方向。 12/96 ]

                                                                [Page 4]

[4ページ]