RFC469 日本語訳
0469 Network mail meeting summary. M.D. Kudlick. March 1973. (Format: TXT=17774 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
NWG/RFC#469 Michael D. Kudlick MDK (SRI-ARC) NIC 14798 8-MAR-73
NWG/RFC#469マイケルD.Kudlick MDK(様アーク)NIC14798 8 3月の73
Network Mail Meeting Summary
ネットワークメールミーティング概要
Introduction
序論
The purpose of this RFC is to briefly summarize, from the NIC's viewpoint, the principal conclusions reached at the Network Mail Meeting held Friday, February 23 1973, at SRI-ARC.
このRFCの目的はNICの観点から1973年2月23日金曜日に持たれていたNetworkメールMeetingで達した主要な結論を簡潔にまとめることです、SRI-ARCで。
Please refer to RFC #475 (NIC 14919) for Abhay Bhushan's
comprehensive summary of the issues discussed at the meeting.
Abhay Bhushanのミーティングで議論した問題の包括的な概要についてRFC#475(NIC14919)を参照してください。
There is no major disagreement between the present RFC and RFC
#475.
現在のRFCとRFC#475とのどんな主要な不一致もありません。
RFC #453 (NIC 14317) contains background information on the
meeting.
RFC#453(NIC14317)はミーティングに関する基礎的な情報を含んでいます。
RFC #479 (NIC 14948) describes what the NIC would like to see
included in the File Transfer Protocol for Network Mail purposes,
and also describes briefly how the NIC would use the information.
RFC#479(NIC14948)は、Networkメール目的のためにFile Transferプロトコルに含まれているNICが見たがっているものについて説明して、また、簡潔にNICがどう情報を使用するだろうかを説明します。
The present RFC is organized as follows:
現在のRFCは以下の通り組織化されます:
Conclusions
Discussion
Attendees
結論議論出席者
Conclusions
結論
Additional FTP mail requirements were decided upon. These would be implemented as a new mail command, with the following subcommands:
追加FTPメール要件は決められました。 これらは新しいメールコマンドとして以下のサブコマンドで実行されるでしょう:
TO
to
This field is explicitly allowed to contain multiple
addressees, with a standard syntax: user@host.
この分野は標準の構文で明らかに複数の受け取り人を含むことができます: user@host 。
FROM
from
This field provides a return-address for notification of
undeliverable mail, as well as a clearcut identification of the
sender for the recipient's information..
この分野は「非-提出物」メールの通知に返送先を提供します、受取人の情報のための送付者の明確な識別と同様に。
[Page 1]
NIC 14798 MDK 8-MAR-73 17:24 14798
[1ページ]NIC14798MDK8 3月の73 17: 24 14798
AUTHOR
作者
This field denotes the author of the mail. There may be
multiple authors
この分野はメールの作者を指示します。 複数の作者がいるかもしれません。
TITLE
The "title" (i.e. subject) of the mail is to be terminated by
period carriage return.
TITLEメールの(すなわち、対象)が終えられることになっている「タイトル」期間の復帰。
ACKNOWLEDEGMENT success / failure (time out) / normal
ACKNOWLEDEGMENTの成功/故障(タイムアウト)/標準
For use by the intermediate host, probably the NIC in most
cases, to tell the sender what happened to his attempt to send
mail. (Note: "normal" wasn't defined.)
多くの場合、中間的ホスト、たぶんNICを使用して、何がたまたま彼の試みにメールを送ったか送付者に言ってください。 (注意: 「標準」は定義されませんでした。)
RECORDED jnumber / null
RECORDED jnumber/ヌル
Note: "jnumber" is the pre-assigned accession number (NIC
number), to be used when known.
以下に注意してください。 "jnumber"は、知られていると使用されているためにはあらかじめ割り当てられた受入番号(NIC番号)です。
The "RECORDED" subcommand provides for the option of having the
mail recorded. Information given with this subcommand would be
recognized at the NIC. Options are:
「記録された」サブコマンドはメールを記録させるオプションに備えます。 このサブコマンドで与えられた情報はNICで認識されるでしょう。 オプションは以下の通りです。
to be recorded (in NIC journal) only,
to be recorded and distributed,
to be distributed only.
記録されて分配されています。記録される、(NICジャーナルで)単に、分配されてください、そして、単に。
This field would also be used to inform the recipient that the
mail has been recorded.
また、この分野は、メールが記録されたことを受取人に知らせるのに使用されるでしょう。
(In retrospect, it may be preferable to have a separate
command to inform the recipient of this fact, but no
decision on this was made at the 23-Feb-73 meeting.)
(追憶では、この事実を受取人に知らせる別々のコマンドを持っているのが望ましいかもしれませんが、1973年2月23日のミーティングでこの決定を全くしませんでした。)
TYPE long / urgent / ordinary
TYPEの長いか緊急の/普通です。
This allows the recipient site to take whatever action it
thinks appropriate in storing the mail.
これは、メールを格納しながらそれが適切であると考えるどんな動作も中に入れるために被移植部を許容します。
TEXT / FILE / CITATION
テキスト/ファイル/引用
TEXT
テキスト
This field is for the text of the mail message.
この分野はメール・メッセージのテキストのためのものです。
[Page 2]
NIC 14798 MDK 8-MAR-73 17:24 14798
[2ページ]NIC14798MDK8 3月の73 17: 24 14798
FILE
ファイル
The purpose of the field is unclear to me. Does it contain a
machine readable pointer to the file that the sender wishes the
recipient to read?
私にとって、分野の目的は不明瞭です。 それは送付者が、受取人に読んで欲しいファイルにマシンの読み込み可能なポインタを含んでいますか?
CITATION
引用
This field is a person-readable pointer to the file that the
sender wishes the recipient to read. When the citation command
is used, no mail is sent other than the citation.
この分野は送付者が、受取人に読んで欲しいファイルへの人の読み込み可能なポインタです。 引用命令が使用されているとき、引用以外に、メールを全く送りません。
Discussion
議論
Introduction
序論
The key aspects in the solution are:
解決策の特徴は以下の通りです。
1) It is based on FTP.
1) それはFTPに基づいています。
2) It uses the NIC without requiring direct use of NLS.
2) NLSのダイレクト使用を必要としないで、それはNICを使用します。
3) There is a mechanism for uniformity in the use of
user identifications.
3) 一様性のためのメカニズムがユーザ登録名の使用であります。
4) There is a mechanism for recording the mail for
later reference.
4) 後の参照のためのメールを記録するためのメカニズムがあります。
These issues are covered in the discussion that follows.
これらの問題は続く議論でカバーされています。
New FTP Mail Subcommands
新しいFTPメールサブコマンド
TO
to
Addressee Format
受け取り人形式
The standard form of the address is: user@host
アドレスの標準形式は以下の通りです。 user@host
"User" may be an individual's last name; or it may be whatever
other identification the recipient has chosen AND has made
known to the rest of the network.
「ユーザ」は個人の姓であるかもしれません。 または、それは受取人が選んで、ネットワークの残りに明らかにしたどんな他の識別であるかもしれません。
If the intended host doesn't recognize the intended
recipient's identification, then it sends back an
"undeliverable" mail message to the sender's host. It is up
to the individual to keep the NIC informed of his wherabouts
[sic]; otherwise, he may not get his mail on time.
意図しているホストが意図している受取人の識別を認めないなら、それは"「非-提出物」"メール・メッセージを送付者のホストに返送します。 彼のwherabouts[原文のまま]についてNICを知らせ続けるのが個人まで達しています。 さもなければ、彼はメールを定刻にしないかもしれません。
[Page 3]
NIC 14798 MDK 8-MAR-73 17:24 14798
[3ページ]NIC14798MDK8 3月の73 17: 24 14798
NIC Role
NICの役割
The NIC need have no role at all for mail sent from point A to
point B, whenever that mail is not to be recorded at the NIC.
NICには、役割がBを指すためにポイントAから送られたメールのために全くある必要はありません、NICに記録されないそのメールがことであるときはいつも。
For mail that is to be recorded at the NIC, the RECORDED
subcommand is to be used.
RECORDEDサブコマンドはNICに記録されることになっているメールに関しては使用されていることです。
Also, when the sender does not know the standard address of the
recipients, he may use the NIC to obtain this information.
また、送付者が受取人の標準のアドレスを知らないとき、彼は、この情報を得るのにNICを使用するかもしれません。
Idents and Addresses
Identsとアドレス
The NIC will modify its identification files to include the
"user@host" standard address for each individual.
NICは、各個人のための" user@host "標準のアドレスを含むように識別ファイルを変更するでしょう。
Sites may ask the NIC to translate from NIC Ident, or from a
user's last name, to the standard address. A query facility
will be made available at the NIC to do the translation on
request. The translation service will also be available for
"group idents".
サイトは、NIC Identか、ユーザの姓から標準のアドレスまで翻訳するようにNICに頼むかもしれません。 要求に応じて翻訳をするために質問施設をNICで利用可能にするでしょう。 また、翻訳サービスは「グループidents」に利用可能になるでしょう。
This service would be FTP-like, in term of the prootocol
[sic] it accepts, but would not be within FTP itself. A
different server process would handle Ident translation
requests.
このサービスは、FTPのそれが受け入れるprootocol[原文のまま]の用語でようでしょうが、FTP自体の中にないでしょう。 異なったサーバの過程はIdent翻訳依頼を扱うでしょう。
Translation will also be done at the NIC when the NIC is
used as an intermediate point on the delivery route.
また、配達ルートの中間的ポイントとしてNICを使用するとき、NICに翻訳をするでしょう。
The NIC could be an intermediate point for recording the
mail as a NIC journal item, and for forwarding the mail
to its ultimate destinations. During this process, the
NIC would translate from NIC idents to standard
addresses.
NICは、NICジャーナルの品目としてメールを記録して、メールを最終仕向地に転送するための中間的ポイントであるかもしれません。 この過程の間、NICはNIC identsから標準のアドレスまで翻訳するでしょう。
In the NIC ident files, provision already exists to specify
hardcopy or on-line delivery of recorded (NIC Journal) mail.
NIC identファイルでは、支給が、記録された(NIC Journal)メールのハードコピーかオンライン配送を指定するために既に存在しています。
This provision will be extended to include a "network"
attribute, which means "deliver the mail to the host of this
person".
この支給は、「ネットワーク」属性を含むように広げられるでしょう。(属性は「この人のホストに郵便を配達します。」と意味します)。
The network attribute may be qualified by restricting all
mail to be kept at the sender, with only a notification
message actually mailed.
送付者に保管されるすべてのメールを制限することによって、ネットワーク属性は資格があるかもしれません、実際に通知メッセージだけを郵送して。
[Page 4]
NIC 14798 MDK 8-MAR-73 17:24 14798
[4ページ]NIC14798MDK8 3月の73 17: 24 14798
Notification would be in the form of a citation giving "to",
"from", "title", "date of submission", and "location of
mail".
通知が「タイトル」を“to"、“from"に与える引用のフォーム、「服従の日付」、および「メールの位置」にあるでしょう。
TIP Users
チップユーザ
To enable TIP users to have access to the mail system, both for
sending and receiving mail, it was suggested that some hosts
will have to be the "home" site for these users (but no more
than one "home" site per user).
TIPユーザがメールを送って、受け取るメールシステムに近づく手段を持っているのを可能にするために、何人かのホストがこれらのユーザ(しかし、1ユーザあたり1つ未満の「家」サイト)のために「家」サイトにならなければならないと示唆されました。
That is, an account that allows a TIP user to send and receive
mail will have to be established at such a host.
すなわち、TIPユーザがメールを送って、受け取るアカウントは、そのようなホストで確立されなければならないでしょう。
For the present, any TIP user can use the SRI-ARC system for
his mail requirements.
当分、どんなTIPユーザも彼のメール要件のSRI-ARCシステムを使用できます。
An alternate solution, that TIP's be equipped with a hardcopy
device that is continuously available for printing mail, was
discarded in favor of the above approach.
代替策、そのTIPは絶え間なく印刷メールに利用可能であり、上のアプローチを支持して捨てられたハードコピー装置を備えていました。
FROM
from
The "FROM" command in FTP, identifies the sender in "standard
address" form.
送付者は、「標準のアドレス」フォームで“FROM"がFTPで命令するのを特定します。
This will allow "undeliverable" mail notices to be sent back to
the originator.
これは、"「非-提出物」"メール通知が創始者に送り返されるのを許容するでしょう。
The default condition is that the sender's host must retain
the mail until it is "delivered" to the recipient's host.
デフォルト条件はそれが受取人のホストに「渡される」まで送付者のホストがメールを保有しなければならないということです。
"Delivered" means that the recipient's host has accepted
the mail. It does NOT mean that the recipient has READ
the mail.
受取人のホストが受け入れた手段にメールを「渡しました」。 それは、受取人がREADを持っていることを意味しません。メール。
Alternatively, the sender may designate that an intermediate
host store the mail. Then the intermediate host has the
responsibility of storing the mail until it is "delivered"
to all intended recipients.
あるいはまた、送付者は指定するかもしれません。中間的ホストはメールを格納します。 そして、中間的ホストには、それがすべての意図している受取人に「渡される」までメールを格納する責任があります。
The "ACKNOWLEDGEMENT" command will allow an optional, positive
acknowledgement to be given to the originator of the mail (the
"FROM" addressee), stating that the mail was delivered.
「承認」コマンドは、任意の、そして、積極的な承認はメール(“FROM"受け取り人)を創始者に与えられているのを許容するでしょう、メールが配達されたと述べて。
[Page 5]
NIC 14798 MDK 8-MAR-73 17:24 14798
[5ページ]NIC14798MDK8 3月の73 17: 24 14798
AUTHOR
作者
The AUTHOR may be several persons. For recorded documents the
authors appear separately in the index of authors, to facilitate
searching for mail when an author is known, but the title and
location of the mail are unknown.
AUTHORは数人の人々であるかもしれません。 記録されたドキュメントに関しては、作者は、作者が知られていますが、メールのタイトルと位置が未知であるときに、メールを検索するのを容易にするために別々に作者のインデックスに載っています。
TITLE
タイトル
The TITLE field is especially useful for recorded mail, since
indexes on key words in the title can be produced relatively
easily, and facilitate searching for mail.
TITLE分野は特に記録されたメールの役に立ちます、タイトルのキーワードに関するインデックスが、比較的容易に生産されて、メールを検索するのを容易にすることができるので。
For this reason, the title should be a succinct indicator of the
contents.
この理由で、タイトルはコンテンツの簡潔なインディケータであるべきです。
ACKNOWLEDGEMENT
承認
Acknowledgement of failure to deliver should be given to the
sender.
配送しないことの承認を送付者に与えるべきです。
An optional, positive acknowledgement of successful delivery to
the recipient's sitename will be given on request of sender
(like U.S. CERTIFIED mail).
要求に応じて、受取人のsitenameへのうまくいっている配送の任意の、そして、積極的な承認に送付者(U.S. CERTIFIEDメールのような)を与えるでしょう。
No acknowledgement that the recipient actually saw the mail
will be given (comparable to not having U.S. REGISTERED mail).
受取人が実際にメールを見たという承認を全く与えないでしょう(U.S. REGISTEREDメールを持っていないのに匹敵する)。
RECORDED
記録されます。
The concept of "recorded" mail is that a permanent record of the
mail is kept centrally, to allow future references and re-readings
of the mail to be made.
「記録された」メールの概念はメールの永久的な記録がメールの後学と再読書をするのを許容するために中心でつけられるということです。
For example, in the NIC Journal system, a record is kept of all
the items entered into the Journal. From this record, author,
title-word, and NIC number indexes are produced to allow for
references and re-readings.
例えば、NIC Journalシステムでは、記録はJournalに入れられたすべての商品についてつけられます。 この記録から、作者、タイトル単語、およびNIC数のインデックスは、参照と再読書を考慮するために製作されます。
The key to retrieval of recorded Journal items is the use of an
accession number (the NIC number). This essentially removes
the possibility of duplicate filenames being used.
記録されたJournalの品目の検索のキーは受入番号(NIC番号)の使用です。 これは本質的には使用される写しファイル名の可能性を取り除きます。
The basic aspect of recorded mail which was discussed at the mail
meeting is the assignment of an "accession" number.
メールミーティングで議論した記録されたメールの基本的な局面は「就任」番号の課題です。
[Page 6]
NIC 14798 MDK 8-MAR-73 17:24 14798
[6ページ]NIC14798MDK8 3月の73 17: 24 14798
It was decided to get the accession numbers from the NIC on an
as-needed basis, without pre-assignment and without local
assignment of numbers.
それがNICからの受入番号に乗るために決められた、必要に応じて、基礎、プレ課題なしで数のローカルの課題なしで。
This subject may be reviewed in the future. Local assignment
may be desirable to prevent the NIC from becoming a bottleneck
in the mail process.
この対象は将来、見直されるかもしれません。 NICがメールの過程によるボトルネックになるのを防ぐのにおいてローカルの課題は望ましいかもしれません。
It was pointed out that local assignment of numbers would be
un-ambiguous if the numbers included some information such as
sitename, date, and time.
数のローカルの課題が不-数がsitenameや、日付や、時間などの何らかの情報を含んでいるかどうかあいまいであると指摘されました。
One other problem exits [sic], namely "where is the recorded
document?".
他の1つの問題がすなわち、[原文のまま]、「どこに、記録されたドキュメントがありますか?」を出ます。
Initially the document should be in the NIC, but ultimately it
could be anywhere on the Network, provided only that there is a
central mechanism for indexing and cataloging all the recorded
documents.
初めは、ドキュメントがNICにあるはずですが、結局、それはNetworkでどこでもあるかもしれなくて、それだけをそこに提供しているのは、すべての記録されたドキュメントに索引をつけて、カタログに載せるための主要なメカニズムです。
The pathname to the recorded document would then include
filename and sitename.
そして、記録されたドキュメントへのパス名はファイル名とsitenameを含んでいるでしょう。
TYPE
タイプ
The TYPE subcommand was a result of a discussion on the
problems of large mail files, and the associated
question of who would pay for the processing and storing
of these files.
TYPEサブコマンドは、大きいメールファイルの問題についての議論の結果と、だれがこれらのファイルの処理と格納の代価を払うだろうかに関する関連問題でした。
The main decisions made were:
された主な決定は以下の通りでした。
a) The processing, transmittal, and storage costs of
sending mail should be borne at the sender's host.
a) 送付メールの処理、譲渡、および格納コストは送付者のホストで負担されるべきです。
b) The processing and storage costs of receiving
mail should be borne at the recipient's host
initially, as a default.
b) メールを受け取る処理と格納コストは初めは、デフォルトとして受取人のホストで負担されるべきです。
Information to enable the recipient host to make an
intelligent decision about where to store the incoming
mail are passed along via the TYPE command.
受取人ホストが入って来るメールをどこに格納するかに関する知的な決定をするのを可能にする情報はTYPEコマンドで伝えられます。
The recipient host will have the local option of
providing either of the following services:
受取人ホストには、以下のサービスのどちらかを提供する地方選択権があるでしょう:
[Page 7]
NIC 14798 MDK 8-MAR-73 17:24 14798
[7ページ]NIC14798MDK8 3月の73 17: 24 14798
a) free use of system to send mail;
b) free use of system to receive mail, i.e. login
not required for delivery over the Network. (A
possible alternative is use of a "mail" account,
or use of the recipient's account, for processing
and storage of the incoming mail.
a) システムの使用を解放して、メールを送ってください。 b) システムの使用を解放して、メールを受け取ってください、すなわち、ログインはNetworkの上の配送に必要ではありません。 (可能な選択肢は、「メール」アカウントの使用、または受取人のアカウントの使用です、入って来るメールの処理と格納に。
TEXT / FILE / CITATION
テキスト/ファイル/引用
TEXT
テキスト
This field is for the text of the mail message.
この分野はメール・メッセージのテキストのためのものです。
FILE
ファイル
The purpose of this field is unclear to me. Does it contain a
machine readable pointer to the file that the sender wishes the
recipient to read?
私にとって、この分野の目的は不明瞭です。 それは送付者が、受取人に読んで欲しいファイルにマシンの読み込み可能なポインタを含んでいますか?
CITATION
引用
The citation is a person-readable pointer to the file that the
sender wishes the recipient to read.
引用は送付者が、受取人に読んで欲しいファイルへの人の読み込み可能なポインタです。
An alternative to sending entire messages or files over the
Network is to use the "CITATION" mechanism. With this, the
sender sends a short message (the citation) saying, in effect,
"please read file X at site Y".
全体のメッセージかファイルをNetworkの上に送ることへの代替手段は「引用」メカニズムを使用することです。 これと共に、「サイトYでファイルXを読んでください。」と、事実上、送付者は短いメッセージ(引用)に言わせます。
This alternative would be especially useful for
この代替手段は特に役に立つでしょう。
a) mail that is distributed with group idents (to all
liaisons, for example), and
そしてa) グループidents(例えばすべての連絡に)で配布されるメール。
b) "long" files (size not defined) that the recipient may
not be immediately interested in.
b) 受取人がすぐに興味を持たないかもしれない「長い」ファイル(定義されなかったサイズ)。
However no method of enforcing use of this alternative was
discussed. It will be up to the recipients to devise a
scheme satisfactory to them.
しかしながら、この代替手段の使用を実施する方法について全く議論しませんでした。 彼らにとって、満足できる計画について工夫するのは、受取人次第でしょう。
Other General Discussion
他の一般議論
Bob Kahn placed on the floor the following question (I paraphrase):
ボブ・カーンは以下の質問(I言い換え)を床に置きました:
Can't the design of a mail system be made to include alternative
sources of data and alternative modes of operation, unless
exclusion of these alternatives can be quantitatively defended?
量的にこれらの代替手段の除外を防御できないならデータと代替の運転モードの代替仕入先を含んでいるのをメールシステムの設計をすることができませんか?
[Page 8]
NIC 14798 MDK 8-MAR-73 17:24 14798
[8ページ]NIC14798MDK8 3月の73 17: 24 14798
Particular aspects of this question are:
この質問の特定の局面は以下の通りです。
1) What is the desirability and difficulty of admitting different
data sources into the mail system?
1) 願わしさであることとメールシステムを異なったデータ送信端末を認めるという困難?
What are the "boundaries" that divide permitted from prohibited
data sources?
分割される「境界」は禁止されたデータ送信端末から何に受入れられますか?
What is the quantitative distinction between deferred and
realtime mail?
延期されるのとリアルタイムでメールの量的な区別は何ですか?
Will the design we come up with allow such things as
私たちが思いつくデザインはそのようなものを許容するでしょう。
a) handling a calendar that reflects the known and
anticipated whereabouts of people so that meetings can be
scheduled sensibly?
a) 分別よくミーティングを予定できるように人々の知られていて予期された居場所を反映するカレンダーを扱いますか?
b) formatting the mail contents for later query and other
information handling?
後の質問のためにメールコンテンツをフォーマットするb)と他の情報取り扱い?
2) Whatever primitives we implement, can't they be designed so as
not to preclude things like Tenex "linking"?
2) 私たちがどういった基関数を実行しても、それらは、「リンクTenex」のようなものを排除しないように設計されるはずがありませんか?
This requires two-way data communication paths.
これは両用データ通信路を必要とします。
How do we specify and get the attention of a "sink" for the
data stream?
私たちは、どのようにデータ・ストリームのための「流し台」の注意を指定して、得ますか?
e.g., for interprocess communication, and for Tenex-type
"linking".
例えば、プロセス間通信、および「リンクTenex-タイプ」のために。
The general reaction to this discussion was one of perspective:
この議論への一般的な反応が1であった、見解について:
In the scheme of things that could be considered "point-to-point
communication", mailbox-type of communication is not the most
general kind.
「二地点間コミュニケーション」であると考えることができたものの計画では、コミュニケーションのメールボックスタイプは最も一般的な種類ではありません。
AKB listed several types of communication problems:
AKBはいくつかのタイプの意思疎通の問題を記載しました:
program-program communication
people-people real-time communication, e.g.
Tenex-type "links"
computer teleconferencing
mailbox communication: cataloging, storage
protocols: host-host, telnet, file transfer
コミュニケーション人々人々瞬時通信をプログラムでプログラムしてください、そして、例えば、Tenex-タイプはコンピュータ電子会議メールボックスコミュニケーションを「リンクします」: カタログに載せる格納プロトコル: ホスト兼ホスト、telnet、ファイル転送
[Page 9]
NIC 14798 MDK 8-MAR-73 17:24 14798
[9ページ]NIC14798MDK8 3月の73 17: 24 14798
A design for a mailbox-type system won't be required to encompass
the problems of, say, a computer teleconferencing system, which
has attributes (real-time, video, very large volume of data to be
transferred, to name some) that are not attributes of a mail box
system.
メールボックスタイプシステムのためのデザインは、たとえば、メールボックスシステムの属性でない属性(いくつかを命名するために移されるべきリアルタイムで、ビデオの、そして、非常に大きいデータ量)を持っているコンピュータ電子会議システムの問題を包含するのに必要でないでしょう。
Attendees at the Network Mail Meeting 2/23/73 at SRI-ARC
2/23/73の様アークにおけるネットワークメールミーティングにおける出席者
Nancy Mimno BBN
ACB Alan Bomberger AMES-67
AKB Abhay Bhushan MIT-DMOG
AWH Wayne Hathaway AMES-67
CHI Charles Irby SRI-ARC
DHC Dave Crocker UCLA-NMC
JBP Jon Postel UCLA-NMC
JDH Dave Hopper SRI-ARC
JEW Jim White SRI-ARC
LPD Peter Deutsch PARC-MAXC
MCK Mark Krilanovich UCSB-MOD75
MDK Mike Kudlick SRI-ARC
REK2 Bob Kahn ARPA
RKK Rajendra Kanodia MIT-MULTICS
RST Ray Tomlinson BBN-TENEX
ナンシーMimno BBN ACBアランBombergerエームズ-67AKB Abhay Bhushan MIT-DMOG AWHウェインハザウェイエームズ-67キーチャールズイルビー様アークDHCデーヴ医者UCLA-NMC JBPジョンポステルUCLA-NMC JDHデーヴホッパー様アークJEWジムホワイト様アークLPDピータードイツ語PARC-MAXC MCKマークKrilanovich UCSB-MOD75 MDKマイクKudlick様アークREK2ボブカーンアルパRKK Rajendra Kanodia MIT-MULTICS RSTレイトムリンスンBBN-TENEX
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Joseph Marshall 9/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ジョゼフ・マーシャル9/97によるオンラインRFCアーカイブへの]
[Page 10]
[10ページ]
一覧
スポンサーリンク
