RFC585 日本語訳

Network Working Group                                         D. Crocker
Request for Comments: 585                                       UCLA-NMC
Category: Users                                                N. Neigus
NIC: 18259                                                       BBN-NET
                                                              J. Feinler
                                                                 SRI-ARC
                                                                J. Iseli
                                                               MITRE-TIP
                                                                6-Nov-73

コメントを求めるワーキンググループD.医者要求をネットワークでつないでください: 585UCLA-NMCカテゴリ: ユーザN.Neigus NIC: 18259 BBN-ネットJ.Feinler様アークJ.Iseli斜め継ぎチップ1973年11月6日

              Arpanet Users Interest Working Group Meeting

Arpanetユーザ関心ワーキンググループミーティング

   A new group, the Arpanet Users Interest Working Group (USING) is the
   outgrowth of a meeting held in Boston on May 22-23, 1973.  The
   meeting, cochaired by Dave Crocker, UCLA-NMC, and Nancy Neigus, BBN,
   followed BBN's Resource Sharing Workshop.

新しいグループ、Arpanet Users Interest作業部会(USING)は1973年5月22日〜23日にボストンで行われた会合の派生物です。 デーヴ・クロッカー、UCLA-NMCとナンシーNeigus、BBNによるミーティングであって、共同議長を務めるのはBBNのResource Sharing Workshopに続きました。

PURPOSE

目的

   The USING meeting was seen by the members as a forum for Network
   Users to air complaints, exchange information, voice desires, and
   present concrete proposals for the design and implementation of
   user-oriented Network capabilities.

Network Usersが利用者志向Network能力の設計と実装のための苦情、交換情報、声の願望、および現在の具体的な提案を放送するように、USINGミーティングはフォーラムがメンバーによって見られました。

   The group will devote itself to lobbying on behalf of user interests,
   to promoting and facilitating resource sharing, to improving user
   interfaces (support), and to studies of standardization.  The
   ultimate goal will be provide users identification of, and
   facilitated access to, whatever resources on the Network they might
   wish to use.

グループはユーザ関心を代表した運動にそれ自体をささげるでしょう、ユーザインタフェース(サポート)を改良することと、そして、標準化の研究にリソース・シェアリングを促進して、容易にするのに。 究極の目標はそれらが使用したがっているかもしれないNetworkでいかなるリソースにもユーザ識別を提供して、アクセスを容易にするためにことになるでしょう。

   Neigus, Crocker, and Iseli of MITRE were selected to define the
   objectives and goals of USING in more detail, and they will present
   their discussion in a later publication.

MITREのNeigus、クロッカー、およびIseliはさらに詳細にUSINGの目的と目標を定義するのに選ばれました、そして、それらは後の刊行物における彼らの議論を提示するでしょう。

ATTENDEES

出席者

      Dave Crocker, UCLA-NMC, Co-Chairperson
      Nancy Neigus, BBN, Co-Chairperson
      Ken Bowles, UCSD-CC
      Frank Brignoli, NSRDC
      Jim Calvin, CASE-10
      Jake Feinler, NIC
      Wayne Hathaway, NASA-AMES
      Jean Iseli, MITRE
      Mike Kudlick, NIC
      Mike Padlipsky, MIT-MULTICS

デーヴ・クロッカー、UCLA-NMC、共同理事長ナンシーNeigus(BBN、共同理事長のケン・ボウルズ)はフランクBrignoliをUCSD CCします、NSRDCジム・カルヴァン、ケース-10ジェークFeinler、NICウェインハザウェイ、NASA-エームズジーンIseli、斜め継ぎマイクKudlick、NICマイクPadlipsky、MIT-MULTICS

Crocker, et al.                  Users                          [Page 1]

RFC 585               USING Working Group Meeting          November 1973

クロッカー、他 ミーティング1973年11月に作業部会を使用するユーザ[1ページ]RFC585

      Lee Richardson, USC-ISI
      Ron Stoughton, UCSB
      Jim White, NIC
      Steve Wolf, UCLA-CCN
      Joe Wyatt, Harvard

リー・リチャードソン、USC-ISIロンストートン、UCSBジム・ホワイト、NIC Steve Wolf、UCLA-CCNジョー・ワイアット、ハーバード

CATEGORIES OF CONCERN

関心のカテゴリ

   The meeting began by attempting to create a relatively complete list
   of topics directly relevant to users.  The intention was to then
   discuss some of these categories in detail.  The categories of
   concern to users are listed here along with a brief outline of the
   discussion and recommendations associated with each category.  Not
   all topics were discussed fully due to time limitations.  It was
   acknowledged that some of the recommendations were quite extensive,
   but that they should be mentioned even though their implementation
   would be far off.

aを作成するのを試みることによってミーティングが始まった、比較的、直接ユーザに関連している話題に関する全リスト。 意志はそして、詳細にこれらのカテゴリのいくつかについて議論することでした。 ユーザにとって、重要なカテゴリは各カテゴリに関連している議論と推薦の簡潔なアウトラインと共にここに記載されています。 期間制限のためすべての話題について完全に議論したというわけではありません。 それらの実装は遠く離れているでしょうが、推薦のいくつかがかなり大規模でしたが、それらが言及されるべきであると認められました。

   1. Online and Offline Documentation, Information Sharing, and
      Consulting

1. オンラインの、そして、オフラインのドキュメンテーション、情報共有、およびコンサルティング

      a. There is a general need to upgrade the quality, technical
         accuracy, timeliness, dissemination, and format of both online
         and offline documentation.

a。 オンラインの、そして、オフラインの両方のドキュメンテーションの品質、技術的な精度、タイムリー、普及、および形式をアップグレードさせる一般的な必要があります。

      b. Documentation should avoid "buzz" words (jargon), and should
         follow easily understood syntax conventions, abbreviation
         standards, reference citation rules, etc.  However, there
         probably cannot be a standard format for writing documentation.

b。 ドキュメンテーションは、「騒音」単語(専門用語)を避けるべきであり、容易に理解されている構文コンベンション、略語規格、参照引用規則などに続くべきです。 しかしながら、たぶん、ドキュメンテーションを書くための標準書式があるはずがありません。

      c. Offline documentation should be well indexed, should contain a
         good table-of-contents, and should be written in an easily
         browsable format.  Online documentation should be presented in
         a browse mode with well-labeled categories of information as
         well as a keyword search capability.

c。 オフラインドキュメンテーションは、よく索引をつけられるべきであり、良い目次を含むべきであり、容易に「まゆ-可能」な形式で書かれているべきです。 オンラインドキュメンテーションはキーワード探索能力と同様に情報のよくラベルされたカテゴリでブラウズのモードで提示されるべきです。

      d. Documentation should be identified with date/author/version
         information, particularly in large online documents, so that it
         is easier to keep the most current version of a document and to
         query the author, in the event of problems with the
         documentation.

d。 ドキュメンテーションは日付/作者/バージョン情報と同一視されるべきです、特に大きいオンラインドキュメントで、ドキュメントの最新版を保って、作者について質問するのが、より簡単であるように、ドキュメンテーションに関する問題の場合。

      e. Network news needs to be gathered and intelligently distributed
         to users (Network PR).

e。 集められた、知的にユーザ(ネットワークPR)に分配されるべきネットニュースの必要性。

      f. Users need several levels and styles of access to
         documentation, whether online or offline, based upon their
         experience, interests, and preferences.

f。 ユーザはドキュメンテーションへのアクセスのいくつかのレベルとスタイルを必要とします、オンラインである、またはオフラインであることにかかわらず、彼らの経験、関心、および好みに基づきます。

Crocker, et al.                  Users                          [Page 2]

RFC 585               USING Working Group Meeting          November 1973

クロッカー、他 ミーティング1973年11月に作業部会を使用するユーザ[2ページ]RFC585

      g. Each server site should also provide some degree of information
         variety in online "help" mechanisms, tailored to fit the needs
         and experience of different user types.

g。 また、それぞれのサーバサイトは必要性に合うように合わせたオンライン「助け」メカニズムと異なったユーザタイプの経験にいくらかの情報のバラエティーを供給するべきです。

         In addition, entering "Help" from the EXEC level of a system
         should direct a user to ALL procedural-type information.

さらに、システムのEXECレベルから「ヘルプ」に入ると、ユーザはすべての手続き上のタイプ情報に向けられるべきです。

      h. New users should be carefully introduced to the Network by way
         of a New Users Packet (NUP).  Since the MITRE-TIP group is the
         official contact for new users, they should design such a
         packet and incorporate suggestions from USING.

h。 New Users Packet(NUP)を通して慎重に新しいユーザにNetworkを紹介するべきです。 MITRE-TIPグループが新しいユーザに関する公的な接触であるので、彼らは、そのようなパケットを設計して、USINGから提案を取り入れるべきです。

         This packet should eventually contain, among other things:

このパケットは結局、以下を特に含むはずです。

            a definition of, and introduction to the Network

Networkへの定義、および紹介

            a list of sites

サイトのリスト

            step-by-step scenarios for accessing functional documents an
            related online items

機能的にアクセスするための段階的なシナリオは関連するオンライン項目を記録します。

            a definition of who can get on the Network

だれがNetworkに乗ることができるかに関する定義

            some quick-reference charts showing a list of Network
            services available to new users

新しいユーザにとって利用可能にNetworkサービスのリストを見せているいくつかのクイックリファレンスチャート

            and an introduction to Network groups, including USING, as
            well as the names of Network consultants, assistants, and
            the like.

そして、USING、およびNetworkコンサルタント、アシスタント、および同様のものの名前を含んでいて、Networkへの紹介は分類されます。

      i. Information-accessing mechanisms should be provided for users,
         including interactive tutorials, user scenarios, and other
         training mechanisms.

i。 対話的なチュートリアル、ユーザシナリオ、および他のトレーニングメカニズムを含むユーザに情報にアクセスするメカニズムを提供するべきです。

      j. A Network-wide "who, what, where and when" information system
         should be implemented. (This was nicknamed the Network Yellow
         Pages.)  Discussion of support for such a system focused on
         obtaining some form of central funding.

j。 広さのNetwork、「だれ、何、」 情報システムがあるはずである時間と場所に実装されるか。 (これはNetworkイエローページと愛称で呼ばれました。) そのようなシステムのサポートの議論は、何らかのフォームの中央の基金を得るのは焦点を合わせました。

      k. The concept of `Regional Agents' for collecting information for
         the Resource Notebook was discussed.

k。 Resource Notebookのための情報集めのための'地方のエージェント'の概念について議論しました。

         Several felt that what was really needed was a `rebirth' of the
         original concept of Technical Liaison as the person who
         provides information to the NIC and technical assistance to
         users.

数個が、本当に必要であったものがNICへの情報とユーザへの技術支援を提供する人としてTechnical Liaisonのオリジナルの概念の'再生'であると感じました。

Crocker, et al.                  Users                          [Page 3]

RFC 585               USING Working Group Meeting          November 1973

クロッカー、他 ミーティング1973年11月に作業部会を使用するユーザ[3ページ]RFC585

         There was concern voiced about the number of people collecting
         information and the redundancy of the requests received by
         sites.

人々情報集めの数とサイトによって受け取られた要求の冗長に関して声に出された関心がありました。

         There was also concern about what incentives there are (or
         should be or can be) for Liaisons to perform their tasks
         adequately by providing truly up-to-date and complete
         information (carrot vs. stick).

Liaisonsが本当に最新の、そして、完全な情報(にんじん対棒)を提供することによって彼らのタスクを適切に実行するようにどんな誘因があるかに関する(または、あるべきであるか、またはあることができます)心配もありました。

      l. Server Sites should provide a variety of consulting services to
         supplement `help' and general information services.
         Consultants could represent the whole Network, a group of
         sites, a single site, general areas such as software, or
         specific applications processes.  This could fit into the
         workings of the Network Servers Group.

l。 サーバSitesは、'助け'と一般情報サービスを補うためにさまざまなコンサルタント業務を提供するはずです。 コンサルタントは全体のNetworkを表すことができました、サイトのグループ、ただ一つのサイト、ソフトウェアの、または、特定のアプリケーションプロセスなどの一般的な領域。 これはNetwork Servers Groupの作業に収まるかもしれません。

   2. Standardization for the User

2. ユーザのための標準化

      a. If they so desire, users should only have to learn one
         Executive (command) language, rather than 20.  Rather than have
         every site change its interface to the user, it was suggested
         that there be a Network Common Command Language Protocol which
         is translated to/from the host's own Executive command
         language.

a。 彼らがそう望んでいるなら、ユーザは20よりむしろ1Executive(コマンド)の言語を学ぶべきであるだけでよいです。 そこに、いてください。むしろ、それがあらゆるサイトにインタフェースをユーザに変えさせるより示された、それ、ホストの自己のExecutiveコマンド言語からの/に翻訳されるNetwork Common Command Languageプロトコル。

         As with FTP and RJE, a human user should be able to type in CCL
         Protocol directly, though many sites may want to allow a local
         user to type in their local Executive language, and then they
         will translate it into CCLP, for the foreign host.

FTPとRJEなら、人間のユーザは直接CCLプロトコルをタイプできるべきです、多くのサイトが、地元のユーザが地元のExecutive言語をタイプするのを許容したがっているかもしれません、そして、次に、それをCCLPに翻訳するでしょうが、異種宿主のために。

         Any Network Common Command Language should be compatible with
         batch systems as well as with interactive systems, and should
         provide an effective means for batch job submission and
         control.

どんなNetwork Common Command Languageもバッチシステムと対話的なシステムと互換性があるべきであり、バッチジョブ依頼とコントロールに効果的な手段を提供するはずです。

         Bowles, Hathaway, and Stoughton volunteered to outline specs
         for Network command language that would be compatible with
         ideas suggested by Padlipsky and discussed at the meeting.

ボウルズ、ハザウェイ、およびストートンは、Padlipskyによって勧められて、ミーティングで議論する考えと互換性があるNetworkコマンド言語のための仕様を概説するのを買って出ました。

      b. One of the functions to included in a Common Command Language
         is a simple editor, which Padlipsky has outlined.  The editor
         should be easy for users to learn as well as for servers to
         implement or interface to their own editors.

b。 含まれていることへのCommon Command Languageでの機能の1つは純真なエディタです。(Padlipskyはそのエディタについて概説しました)。 サーバに、エディタはそれら自身のエディタにユーザが学んで、実装するか、または連結するのが簡単であるはずです。

Crocker, et al.                  Users                          [Page 4]

RFC 585               USING Working Group Meeting          November 1973

クロッカー、他 ミーティング1973年11月に作業部会を使用するユーザ[4ページ]RFC585

   3. Status/Measurement of Site Performance

3. サイトパフォーマンスの状態/測定

      a. A variety of performance measures, for the individual sites,
         needs to be derived, acquired, maintained, and made available
         to users.

a。 さまざまな性能測定が、個々のサイトに引き出されて、取得されて、維持されて、ユーザにとって利用可能に作られている必要があります。

         This could include some attempt to measure average "response
         time", relative costs (relative to type of task, that is),
         availability/reliability, etc.

これは平均した「応答時間」を測定する何らかの試み、相対的なコスト(タスクのタイプに比例してすなわち)、有用性/信頼性などを含むかもしれません。

      b. Mechanisms are needed for software certification and for
         measuring and verifying the accuracy and/or reliability of
         systems, hardware, protocols, applications software, etc.

b。 メカニズムがシステム、ハードウェア、プロトコル、アプリケーションソフトウェアなどの精度、そして/または、信頼性をソフトウェア証明と測定して、確かめるのに必要です。

   4. User Feedback Mechanisms

4. ユーザフィードバック・メカニズム

      a. There is a need for a uniform Network gripe/suggestion
         mechanism.  This should cover several types of gripes,
         including program bugs and service complaints.

a。 一定のNetwork不平/提案メカニズムの必要があります。 これはプログラムバグとサービス苦情を含むいくつかのタイプの不平をカバーするべきです。

      b. Each user registering a complaint deserves immediate
         acknowledgement and some indication of what, if any, action
         will be taken.

b。 行動をいくらか取るなら、苦情を示す各ユーザが即座の承認と何のいくつかのしるしに値するか。

      c. The NIC should set up Network ident groups for Principal
         Investigators, Liaisons, Station Agents, Accounts
         Administrators, Consultants, etc., so that users can easily
         direct their comments, inquiries and mail to these groups.

c。 NICは主任研究者(Liaisons)駅のエージェント(Accounts Administrators)ConsultantsなどのためにNetwork identグループを設立するはずです、ユーザが容易に彼らのコメント、問い合せ、およびメールをこれらのグループに向けることができるように。

      d. A Network Servers Group should be started, to coordinate the
         activities (to the extent possible) of the servers (a Server's
         Cartel?).  It would also provide a focus for user complaints
         and suggestions.

d。 Network Servers Groupは、サーバ(ServerのCartel?)の活動(可能な範囲内で)を調整するために始動されるべきです。 また、それはユーザ苦情と提案に焦点を提供するでしょう。

         (The group was originally dubbed the "Tobacco Institute".  The
         Tobacco Institute acts as a representative for the disparate
         Tobacco companies, and attempts to convince the public that
         smoking is good for them.)

グループは元々、「タバコ研究所」と呼ばれました。(Tobacco Instituteは、異種のTobacco会社の代表として務めて、それらに、喫煙が良いと公衆に納得させるのを試みます。)

         The point of the Servers Group -- rather than trying to
         convince the Network public that servers are good for them --
         would be for servers to help each other with common tasks (such
         as documentation) that are too big for each to handle alone.

Servers Groupのそれらに、サーバが良いとNetwork公衆に納得させようとするよりむしろ先はサーバがそれぞれが単独で扱うことができないくらい大きい共通タスク(ドキュメンテーションなどの)で互いを助けるだろうことです。

            This eventually works in the users interest, because the
            servers (in the Network free-market economy) are dependent
            upon the users for their livelihood.

これは結局ユーザ利益のためで働いています、彼らの暮らしにおいて、サーバ(Network自由市場経済における)がユーザに依存しているので。

Crocker, et al.                  Users                          [Page 5]

RFC 585               USING Working Group Meeting          November 1973

クロッカー、他 ミーティング1973年11月に作業部会を使用するユーザ[5ページ]RFC585

         There should be cooperation between the Server Group and USING,
         but the groups would NOT be comprised of the same people.  They
         are on opposite sides of the product.

Server GroupとUSINGとの協力があるべきですが、グループは同じ人々から成らないでしょう。 彼らは製品の反対側にいます。

      e. Station Agents should supply users with information of a
         clerical nature such as names, phone numbers, titles,
         documentations, etc.  To be able to do this, the Agents must
         first HAVE this information.

e。 駅のエージェントは事務員の本質の情報をもっている名前、電話番号、タイトル、文書化などのユーザを供給するべきです。 これができるために、エージェントが最初にそうしなければならない、HAVE、この情報。

   5. Messages to Users

5. ユーザへのメッセージ

      a. Messages to users, such as error messages or diagnostics,
         should be simple, clear, and meaningful to users.

a。 エラーメッセージか病気の特徴などのユーザへのメッセージは、簡単で、明確で、ユーザにとって、重要であるはずです。

      b. The user should have the ability to control notifications given
         to him, by being able to queue messages or refuse them.

b。 ユーザには、彼に与えられた通知を制御する能力があるべきです、メッセージを列に並ばせるか、またはそれらを拒否できることによって。

      c. Users should be able to suppress diagnostics or to specify
         abbreviated or expanded versions.

c。 ユーザが病気の特徴を抑圧できるべきであるか、または指定するのは、バージョンを簡略化したか、広げました。

   6. Tailoring of Resources for Users

6. ユーザへのリソースの仕立屋

      a. Interfaces to users should support different levels of user
         proficiency, without being a burden to the more proficient
         user.

a。 ユーザへのインタフェースは負担であるのなしで異なったレベルのユーザ上達をより堪能なユーザにサポートするべきです。

         That is, a new user needs more prompting, etc.  A more
         experienced user does not need and DOES NOT WANT such
         prompting.  So the capabilities of the interface, which are not
         needed by a specific user, should be transparent.

すなわち、新しいユーザは、より多くのうながすことなどを必要とします。 より経験豊富なユーザは、うながしながら、必要性とどんなDOES NOT WANTにもそのようなものをしません。 それで、インタフェースの能力(特定のユーザによって必要とされない)は透明であるべきです。

      b. A method for work flow management that permits a user to set up
         a sequence of computer tasks that are contingent upon one
         another is needed.  The user should be able to describe this
         sequence interactively and then be able to detach and continue
         with other work while the sequence of tasks is being carried
         out.

b。 ユーザがお互い次第であるコンピュータのタスクの系列をセットアップすることを許可するワークフロー経営者側のためのメソッドが必要です。 タスクの系列が行われている間、ユーザは、他の仕事をインタラクティブにこの系列について説明して、取り外して、次に、続行できるべきです。

   7. Personal Information Management System

7. 個人情報管理システム

      a. Users need a system for managing all types of machine-based
         contacts such as mail, links, journal items, etc.

a。 ユーザはすべてのタイプのメールなどのマシンベースの接触、リンク、ジャーナル項目などを管理するシステムを必要とします。

         Such a system should `log' what has been received and allow the
         user to keep a copy, if desired.

望まれているなら、そのようなシステムは、受け取られたものを'登録し'て、ユーザがコピーをとっておくのを許容するはずです。

         It should also provide the user with options for organizing his
         personal information.

また、それは彼の個人情報を組織化するためのオプションをユーザに提供するべきです。

Crocker, et al.                  Users                          [Page 6]

RFC 585               USING Working Group Meeting          November 1973

クロッカー、他 ミーティング1973年11月に作業部会を使用するユーザ[6ページ]RFC585

      b. A personal `calendar' or reminder system would be handy,
         especially if it allowed one to look ahead to coming events as
         well as to check events for the current day or week.

b。 個人的な'カレンダー'か思い出させるものシステムが手頃でしょう、特に次のイベントを予測して、現在の日か週のためのイベントをチェックするために1つを許容したなら。

      c. A `return to sender' feature is needed in the Network-wide mail
         address system.

c。 '送付者へのリターン'特徴がNetwork全体の郵便の宛先システムで必要です。

      d. (Discussion of the current work on the Mail Protocol indicated
         that some of these ideas are already being considered)

d。 (プロトコルが示したメールについてのこれらの考えのいくつかが既に考えられている執筆中の作品の議論)

   8. Uniform Accounting Procedures and Online Status of Accounts

8. アカウントの一定の会計手順とオンライン状態

      a. This topic was covered in detail by sections of the Resource
         Sharing Workshop.  It is mentioned here only because it is a
         problem of real concern to users.

a。 この話題はResource Sharing Workshopのセクションで詳細にカバーされていました。 それは、単にユーザへの本当の関心の問題であるのでここに言及されます。

   9. Trial Usage and Browsing

9. トライアル用法とブラウジング

      a. Ideally, users should be allowed some `free' sampling of
         systems and features available at each site.  Practically, this
         presents problems of space allocation, accounting, consulting,
         etc.  Although none of these problems are easy to solve
         equitably, an attempt should still be made to provide some free
         usage to everyone.
      b. Several types of trial usage should be considered, such as for
         those who will make an immediate commitment and those who wish
         merely to sample, without making any commitment.

a。 理想的に、各サイトで利用可能なシステムと特徴のいくつかの'自由な'標本抽出がユーザに許容されるべきです。 実際に、これはスペース割当て、会計、コンサルティングなどの問題を提示します。 これらの問題のどれかは公正に解決しにくいのですが、何らかの無料の用法を皆に提供するのをまだ試みをしているべきです。. b。 いくつかのタイプのトライアル使用法は考えられるべきです、即座の公約をする人や作成なしでどんな委任も単に抽出したがっている人などのように。

   10.  Prelogon Facilities

10. Prelogon施設

      a. Some facilities should be available as prelogon facilities, so
         that any user can access them whether or not he has an account,
         directory, etc., at a given site.  Some sites will not be able
         to support many of these functions, so a required set must be
         kept to a minimum.

a。 いくつかの施設が前ログオン施設として利用可能であるべきです、彼にアカウント、ディレクトリなどがあるか否かに関係なく、どんなユーザもそれらにアクセスできるように、与えられたサイトで。 いくつかのサイトがこれらの機能の多くをサポートできないので、必要なセットを最小限に維持しなければなりません。

   11.  Remote User Facilitation

11. リモート・ユーザー簡易化

      a. Users not only need help with actual use of systems from a
         remote site, but they also need facilitation of administrative
         tasks.  Station Agents should be able to handle most of these
         problems or transfer the user to the proper person.  System
         access requirements, account and billing problems, and document
         acquisition need particular attention.

a。 ユーザはリモートサイトからシステムの実際の使用による助けを必要とするだけではありませんが、また、彼らは管理業務の簡易化を必要とします。 駅のエージェントは、これらの問題の大部分を扱うべきであるか、またはユーザを適任者に移すことができるべきです。 システムアクセス要件、アカウント、支払い問題、およびドキュメント獲得は特別の注意を必要とします。

Crocker, et al.                  Users                          [Page 7]

RFC 585               USING Working Group Meeting          November 1973

クロッカー、他 ミーティング1973年11月に作業部会を使用するユーザ[7ページ]RFC585

      b. There should be a simple mechanism for users to acquire/update
         information in functional documents such as the Resource Note-
         book and in files such as identification files.  Publications
         or files of this sort should combine the collective input of
         all the users.

b。 Resource Noteの本などの機能的なドキュメントと識別ファイルなどのファイルにはユーザが情報を取得するか、またはアップデートするのが、簡単であるメカニズムがあるはずです。 この種類の刊行物かファイルがすべてのユーザの集合的な入力を結合するはずです。

   12.  Transportability of Resources and Information

12. リソースと情報のTransportability

      a. Users should be able to easily transfer information, such as
         files, memos, mail, online documentation, (programs?!?) etc.,
         from one site to another.

a。 ユーザは容易に情報を移すことができるべきです、ファイル、メモ、メール、(プログラム?)オンラインドキュメンテーションなどのように、1つのサイトから別のサイトまで。

   13.  Network Utilities

13. ネットワークユーティリティ

      a. Should distributed data banks and similar features be
         considered Network utilities that can be used by all?

a。 分散データ銀行と同様の特徴はすべてで使用できるNetworkユーティリティであると考えられるべきですか?

         The idea of "Network Utilities" was recognized as an
         interesting one by the group, but there was little agreement as
         to what constitutes Network utilities or how they should be
         supported.

「ネットワークユーティリティ」の考えはおもしろいものとしてグループによって認識されましたが、何がNetworkユーティリティを構成するべきであるか、そして、またはそれらがどのようにサポートされるべきであるかに関して協定がほとんどありませんでした。

CURRENT PLANS

現在のプラン

   1. Neigus, Crocker, and Iseli will draft the scope, objectives,
      goals, and priorities of USING and will submit their
      recommendations for approval by the members.

1. Neigus、クロッカー、およびIseliはUSINGの範囲、目的、目標、およびプライオリティを作成して、メンバーによる承認のために彼らの推薦を提出するでしょう。

   2. MITRE will design a New User's Packet incorporating ideas from
      USING.

2. MITREはUSINGからNew UserのPacket盛込み考えを設計するでしょう。

   3. Bowles, Hathaway, and Stoughton will write preliminary specs for a
      Network Common Command Language Protocol.  All members should
      suggest a list of commands for consideration.

3. ボウルズ、ハザウェイ、およびストートンはNetwork Common Command Languageプロトコルのための予備の仕様を書くでしょう。 すべてのメンバーが考慮のためのコマンドのリストを勧めるべきです。

   4. Padlipsky will produce specifications for a simple, standard
      editor (NETED) which could easily be implemented by server hosts.

4. Padlipskyはサーバー・ホストが容易に実装することができた簡単で、標準のエディタ(NETED)に仕様を作り出すでしょう。

   5. A general Users Group (NIC ident = USERS) will be formed, to allow
      any interested person to monitor user-oriented activities,
      especially those of USING.  Anyone interested in being in USERS
      should contact Dave Crocker (DHC).

5. 一般的なUsers Group(NIC identはUSERSと等しい)はどんな関心がある人も利用者志向活動をモニターするのを許容するために形成されるでしょう、特にUSINGのもの。 USERSにいたがっていただれでもデーヴ・クロッカー(DHC)に連絡するべきです。

Crocker, et al.                  Users                          [Page 8]

RFC 585               USING Working Group Meeting          November 1973

クロッカー、他 ミーティング1973年11月に作業部会を使用するユーザ[8ページ]RFC585

   6. Activities of the group will be reported in the ARPAnet News, and
      a user's forum column will be made available for user's comments.

6. ARPAnet Newsでグループの活動を報告するでしょう、そして、ユーザのフォーラムコラムをユーザのコメントに利用可能にするでしょう。

   7. The group will meet again in the Fall of 1973 at the Network
      Information Center in Menlo Park, California.

7. グループはメンローパーク(カリフォルニア)のNetworkインフォメーション・センターで1973年のFallで再会するでしょう。

          [ This RFC was put into machine readable form for entry ]
              [ into the online RFC archives by Via Genie 3/00 ]

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

Crocker, et al.                  Users                          [Page 9]

クロッカー、他 ユーザ[9ページ]