组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：邵毅（epl&nbsp;&nbsp;&nbsp;shaoyi@163.net）<br />
译文发布时间：2001-10-11<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Richard&nbsp;W.&nbsp;Watson<br />
Request&nbsp;for&nbsp;Comments:&nbsp;101&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SRI-ARC<br />
NIC:&nbsp;5762&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;February&nbsp;23,&nbsp;1971<br />
<br />
1971年2月17日伊利诺斯州Urbana<br />
网络工作组会议注释<br />
(RFC0101---Notes&nbsp;on&nbsp;the&nbsp;Network&nbsp;Working&nbsp;Group&nbsp;Meeting&nbsp;)<br />
目录<br />
周三晚上，二月十七日	1<br />
周四上午，二月十八日	4<br />
周四下午，二月十八日	6<br />
周四晚上，二月十八日	7<br />
周五上午，二月十九日	8<br />
<br />
周三晚上，二月十七日<br />
Mike&nbsp;Sher首先欢迎大家来到Urbana，然后简要地指出“ILLIAC第四”计划有望<br />
于当年夏天开始运作。“ILLIAC第四”计划被分成两个子计划：其中一个着眼于基础系<br />
统的软硬件，另一个则与应用有关。它们的IMP还未与其PDP-11相连。<br />
Steve&nbsp;Crocker要求会议就相关问题进行讨论，这些问题在本文的后续部分给出。<br />
来自Mitre的Peggy&nbsp;Karp一直致力于旧RFC文档的总结归纳工作。她给出了一个<br />
大约30个条目的清单，并对其目前的状态加以归纳。她的这一工作有望于二月底左右<br />
完成。（见RFC#100，NIC5761。）大家建议一些人就那些旧RFC文档应被取缔来撰写<br />
一个RFC文件。人们还建议网络信息中心（NIC）在组织硬拷贝材料所需场所方面提<br />
供帮助。<br />
接下来是关于网络使用经验方面的简要讨论。John&nbsp;Melvin（SRI-ARC）把SRI的<br />
经验总结为使用尤它PDP-10来帮助SRI从一个XDS&nbsp;940向PDP-10转变。在1970<br />
年四月至五月间，很明显SRI在朝PDP-10方向发展，以使自己有能力和可靠性来履<br />
行自己作为网络信息中心的任务。他们在那之前有一些与Utah相连的经验，因此试图<br />
使用Utah&nbsp;10来辅助其转变过程也是合乎逻辑的。<br />
网络的使用从六月份开始。由于SRI大量地使用了高级语言，因此首要任务是编<br />
译器对编译器的信息树。在940上生成用于PDP-10的源代码，然后将二进制文<br />
件传送到Utah调试运行，并在可能的地方更改源代码，添加补丁，进而生成新的<br />
源代码和二进制文件。<br />
运行信息树的同时，一种新的用于在线系统（NLS）编程的高级语言（称做L-10）<br />
也被按照相同方式实现。L-10运行的时候，NLS的核心设备无关部分被重写并调<br />
试。在转变过程中，NLS被完全重组。<br />
在SRI和Utah末端，人们编写了一个允许三个用户与Utah相连的控制程序。这<br />
个控制程序作为一个用户进程运行，允许字符输入以及文件传输。这一计划运行<br />
平稳，并于七月至十二月间完成了大量有用的工作。这期间，有一些人员每天工<br />
作4至5个小时。语音链接在当试图确定问题所在以及重新组合的工作可能出现<br />
错误的时候使用。有时持续两周没有任何错误。SRI拥有一个作为T/S进程运行<br />
的IMP诊断界面。<br />
通常来说，回应在SRI端被处理。Utah端使用的是DDT。往返字符四秒的延迟<br />
并不罕见，而且在某些地方还出现过延迟8或10秒的情况。由于每个终端的实现<br />
涉及多进程，并且每一进程都是预定的，因此会产生这些延迟。Utah在下午两点<br />
时负载沉重，而SRI则喜欢在晚上和周末运转。<br />
当SRI&nbsp;PDP-10于十二月出现的时候，网络的使用被减慢。<br />
用户会喜欢一个更加恒定的反应时间，而不是很大的变动。这样，尽管这一时间<br />
很慢，用户的工作习惯也可以去适应它。<br />
Gerry&nbsp;Cole报告了在SRI-Utah工作过程中所采用的一些措施的结果。SRI还提供<br />
一些措施帮助UCLA解释获得的数据。Gerry写了一篇文章归纳这些来自SDC的统计<br />
数据。<br />
Gerry请求当人们打算使用网络的时候通知他，以使他可以收集统计数据。UCLA<br />
最终将采用一个用于扫描网络的程序。但如果人们通知他何时他们将使用网络，<br />
则测量有意义信息以及解释来自某类应用方面知识的数据的工作将变得容易。<br />
Bob&nbsp;Kahn指出，BBN对全局信息流的统计非常感兴趣。他们想通过此来确定网络<br />
的配置是否恰当。Gerry说UCLA对网络模型研究的统计数据有兴趣。对于这种功能，<br />
远程控制采用诸如IMP设计特征使用的方法。<br />
来自UCSB的Jim&nbsp;White说UCSB和RAND已经开始在RAND气候研究工作中<br />
试验网络。UCSB的NCP过去的三到四周里所有白天都是激活的。一篇编号为NIC5480<br />
的描述该应用的文档可在NIC文集中找到。UCSB还将他们的NCP用于本地进程间通<br />
信实验。RAND在使用UCSB&nbsp;360-75的远程工作入口设施。他们用UCSB来检查他们<br />
的NCP。现在，UCSB在正常的使用时间内都运行其NCP。他们发现了他们的硬件于<br />
其IMP接口的一些错误。UCSB和RAND的软件看上去都运行良好。被来回传送的典<br />
型工作只是一些源语句的测试任务。UCSB的NCP大约有39K，运行于一个60K字节<br />
的分区。用户通过汇编语言、FORTRAN或PL/I调用来访问它。<br />
Steve&nbsp;Crocker回过头来讨论会议的议程以及NWG的长期组织结构。Steve感觉<br />
到由于开放的会议对于发现问题，一般性讨论和教育等非常有益，但规模太大以至于不<br />
能够准备各种各样主题的详细描述，因此需要建立针对各异主题的工作委员会。<br />
下列为需求工作的主题：<br />
1．	图形学<br />
2．	数据传输语言<br />
3．	主机----主机协议（长期研究）<br />
4．	主机----主机协议（短期维护及修改）<br />
5．	记数<br />
6．	日志协议<br />
7．	打印机连接协议<br />
8．	文档<br />
9．	数据管理<br />
关于第一个主题，MIT的Al&nbsp;Vezza正在组织一个计划与四月25日至27日召开的，<br />
可以容纳31人的图形学方面的NWG会议。希望参加会议的人需要为他的单位准备一<br />
个工作报告。Al给出三类问题：<br />
1）	两个主机，每个都有计算和图形设备，并希望使用对方的某些特殊设备<br />
2）	一个具有图形设备而不具备数据处理设备的主机，希望使用第二个主机的<br />
计算能力<br />
3）	一个具有图形终端，但无图形处理和计算能力的结点，希望从其它结点处<br />
得到图形和计算能力<br />
关于第二个主题，来自RAND的John&nbsp;Heafner指出RAND希望提供如RFC83所<br />
描述的数据重配置服务。以下还有关于这一主题更多的讨论。<br />
关于第三个主题，来自CMU的A.&nbsp;N.&nbsp;Habermann手下专门组成了一个工作组研究<br />
主机----主机协议。到三月底以来，他们一直在准备一篇论述他们观点的文章。这个工<br />
作组由如下人员组成：<br />
A.&nbsp;N.&nbsp;Habermann,&nbsp;CMU<br />
G.&nbsp;B.&nbsp;Hansen,&nbsp;CMU<br />
W.&nbsp;Wulf,&nbsp;CMU<br />
R.&nbsp;Chen,&nbsp;CMU<br />
R.&nbsp;Kalin,&nbsp;Lincoln&nbsp;Lab<br />
欢迎关于该主题的建议。<br />
关于第四个主题，人们建立了一个小组来评测当前的协议，并对其进行必要的修改。<br />
这个工作组将采用保守的工作方法，只做解决已知问题的必要更改，而将所谓美学更改<br />
（esthetic&nbsp;changes）保留到以后。<br />
关于其它问题的讨论将被放到最后。<br />
两个对网络感兴趣并旁听会议的人简要地发言。<br />
加拿大政府计算机交流专门小组的C.&nbsp;D.&nbsp;(Terry)&nbsp;Shepard对其工作组的目标进行<br />
了概述。这些目标包括：<br />
1）	建立一个计划以连接各种加拿大的计算机，建立一个网络<br />
2）	针对加拿大的需求开发这样一个网络<br />
3）	观察这一网络的收益在加拿大的分布情况<br />
4）	防止对加拿大计算技术的控制完全依赖于外国资源<br />
5）	观察加拿大拥有的关键计算机设施<br />
接下来，来自IBM的Doug&nbsp;McKay简要地描述了IBM两年前开展的一个网络计划。<br />
基础网络已经完成，并已具备一些用户。网络被频繁地用于程序升级时的文件往返传输。<br />
IBM试图将网络看成一个多处理器机器。他们试图处理IBM中所有的异构系统，如<br />
360's，370's，CP'67，91，44，以及一个NYU&nbsp;CDC&nbsp;6600。<br />
有另外一个使用一台91从远程工作入口连接TSS系统的项目。IBM使用一个用<br />
于控制和信息流分布的中央机器来掌握集中的控制视角。他们对此方案并不是十分的满<br />
意，并且正在朝类似于ARPA网络的更加集中的方案发展。目前，IBM有大约14个人<br />
在从事该项目。<br />
周四上午，二月十八日<br />
周四的上午，人们分开在不同的地点开始报告他们的工作状况。来自BBN的Alex&nbsp;<br />
McKenzie在当天稍晚时间准备了一张状况表，由周四晚间的会议代表填写。BBN与<br />
NIC计划准备一个在各地点保留信息并保持更新的程序。<br />
状况<br />
BBN，TENEX计划：在TENEX与NCP合作的最终阶段。试图建立一个与Utah<br />
的连接，但发现了一些错误。NCP将网络视为一个文件，一种与其它类型文件整和的<br />
方式。NCP引入了一个传统界面。他们希望可在月底实现NCP在SRI的TENEX系统<br />
中的合并。<br />
BBN，网络组：报告了他们工作的三个领域：<br />
1．	改善现有网络<br />
2．	基于IMP316版本的工作以及作为一个终端接口处理器（TIMP）的工作<br />
3．	记数<br />
当前，共有15个IMP与网络相连。一个新的，做了较小改动的软件系统将于三月<br />
份完成。<br />
TIMP使用316系统。尽管存在一个硬件设计方案，他们仍需定义软件环境。一个<br />
TIMP可以解决直至64个不同速度同步与异步的终端。第一台机器将于九月份到达<br />
MITRE。<br />
BBN强调三个产品：一个516IMP，一个316IMP和一个316TIMP。316IMP比<br />
516IMP价格便宜，并且可以与一个主机相连。BBN目前并不打算将316IMP换成<br />
516IMP。这两者都是插头可插接的。<br />
SDC：还处于他们NCP的调试阶段，计划四至六周完成。也许八周后，他们的<br />
T/S就可供网络使用了。他们的T/S是一个运行ADEPT系统的360/65机器。<br />
西部储备大学的CASE：IMP已经连接有近一个月，但还没有NCP。他们计划采<br />
用哈佛大学使用的NCP。CASE有一个PDP-10/50系统，有望于两至三个月内完成。<br />
哈佛大学：哈佛大学有一个PDP-1以及一个PDP-10与IMP相连。PDP-10的NCP<br />
处于最后的调试阶段。PDP-1用来刷新显示，PDP-10用于语言研究以及供学生使用。<br />
计划于一至两个月内完成。<br />
SRI-ARC：SRI处于从XDS&nbsp;940向PDP-10转换的最后阶段。他们计划采用BBN<br />
的TENEX&nbsp;NCP。该计划有望于三至四周内完成。<br />
MIT动态建模----PDP-10：他们希望一个NCP能够在三月内投入运行。<br />
MIT的MULTICS：他们已经与IMP相连，再有四个星期，他们的NCP就可以进<br />
入最终的调试阶段。由于MULTICS是一个服务器，他们并不具有无限的访问能力，并<br />
且必须在休息时间里退出。他们计划在三至四周内为网络提供正常的服务。<br />
UTAH：PDP-10/50极有可能最终运行TENEX。他们的NCP已经由一种高级语言<br />
编写并与BBN一同调试。他们已完成与自身的连接与登陆。一个调试后的版本将于月<br />
内产生。<br />
林肯实验室，TX-2：他们正在测试IMP接口以期发现林肯系统硬件中的问题。目<br />
前为止除了消息标识错误外，并没有数据错误。他们的具有日志系统的NCP有望于四<br />
月15日完成。据称，他们将以实验测试为目的，在不被暴露于网络传输的前提下开放<br />
其IMP。BBN称有一种方法可以响应自身而不向网络公开。<br />
林肯实验室，360/97：正在运行CP/CMS。IMP接口已于上月完成。NCP与日志<br />
服务器都在工作。他们计划在四月份建立NCP作为一个正常服务。与他们进行实验的<br />
请求不久就可以实现。<br />
UCSB：从去年十月份以来就已经拥有其NCP。NCP作为一个独立的批任务运行。<br />
他们计划向他们的在线系统提供服务。他们正计划在正常基础上全天运行。同时也存在<br />
一些先前提及的接口问题。<br />
RAND：360/65。他们的NCP是一个用户进程，并且可以驻留。该进程需要8K<br />
字节，并且不需要日志。<br />
UCLA，Sigma-7：他们的NCP正处于最终调试阶段。他们计划于三月一日建立起<br />
NCP，日志服务以及打印连接程序。<br />
美洲电脑有限公司（CCA）：其刚开始创建一个供10至12位激光存储的结点。在<br />
前端，他们采用PDP-10。他们正在为数据操作开发语言。其存储器也将与<br />
B-6500-ILLIAC&nbsp;IV相连。他们正考虑将数据压缩作为其语言的一部分，以减少使用网<br />
络50千位线缆时的问题。其目前的工作重点是安全及保密措施。最初的重点是文件共<br />
享。其安装已于1972年规划完毕。<br />
以下计划在会议上没有代表发言，Steve&nbsp;Crocker汇报了他们的状况。<br />
CMU：PDP-10/50：IMP已经连接，计划采用哈佛大学的NCP。<br />
SRI-AI计划：PDP10。计划运行TENEX。<br />
斯坦福AI计划：尚未连接，计划今年夏天进行。<br />
上述是对目前状况的回顾。Steve&nbsp;Croker接下来说，旧的NWG邮件列表将不再使<br />
用，将采用一个由NIC（5731）维护的列表，或者NIC也可以通过向大家的站点代理<br />
发送信息的方式来进行发布工作。如果你的站点代理或是联络人员有变动，请立刻通知<br />
NIC。<br />
主机----主机日志协议讨论：来自Multics的Tom&nbsp;Skinner首先发言。他指出，他们<br />
至少需要一个过度性质的协议以使网络开始工作。他们提交了RFC98号文件<br />
（NIC5744），文件中包括了他们周三的观点。SRI-ARC也有一个相类似的文件，RFC97<br />
号文件（NIC5740），也于周三晚上提交。Mutics则给出了RFC80号文件（NIC5608）<br />
的修订后的日志协议。<br />
RFC66号文件与RFC80号文件相比较的一些相对优势的讨论也在会上给出。80<br />
号文件协议有一些潜在的问题，这是由于“工作必须在首次接触时建立”这一假<br />
设的原因。<br />
讨论的结果是在对RFC66号文件进行“建立连接之后下达命令”这一修正的基础<br />
上接受其日志协议。<br />
现在看来，似乎有必要建立一个官方文档来修正给出的日志描述。<br />
Tom还建议与日志服务的首次通信占8位域的7位ASCII码。人们就第八位是否<br />
为0或1进行了有些讨论，最终认为第八位应设为0。<br />
接下来，Steve列出了主机----主机协议中存在的一些问题。<br />
1）	响应<br />
2）	消息类型<br />
3）	中断<br />
4）	标记与填充<br />
5）	接口建立过程中半双工与全双工通讯的比较<br />
考虑到要进行如下选择：<br />
a）	闲置<br />
b）	将头与数据分成两个信息<br />
c）	将消息定为72位长度的倍数<br />
考虑到中断（INS，INR），有一个与消息传递有关的同步问题。即，一个消息可被<br />
发送，然后发出一个中断。中断可能在消息之前到达，也可能在消息中间到达。因此需<br />
要一些在数据流中标明哪里是中断的方法。<br />
会议任命一个小分组来考虑上述主机----主机问题。简言之，他们将给出一个对主<br />
机----主机协议进行修订的RFC文档，然后收集意见和建议，并提交一个官方的修订版。<br />
对此有建议或意见的人应与委员会联系。委员会还与站点相连。委员会由以下人员组成：<br />
S.&nbsp;Crocker,&nbsp;UCLA&nbsp;（主席）<br />
R.&nbsp;Tomlinson,&nbsp;BBN<br />
T.&nbsp;Barkalow,&nbsp;Lincon实验室<br />
G.&nbsp;Grossman,&nbsp;illinois大学<br />
J.&nbsp;White,&nbsp;UCSB<br />
R.&nbsp;Bressler,&nbsp;MIT,&nbsp;MAC计划<br />
接下来，会议的讨论转回网络打印的访问问题。该问题在RFC97号文件（NIC5740）<br />
中被提及。其中的一些是：<br />
a）	字符集<br />
b）	行尾标识<br />
c）	中断<br />
d）	消息格式<br />
e）	半双工，全双工<br />
这些问题被提交到一个打印连接协议委员会寻求解决方案。这个委员会由以下人员<br />
组成：<br />
Tom&nbsp;O'Sullivan,&nbsp;Raytheon&nbsp;（主席）<br />
Ed&nbsp;Meyer,&nbsp;MIT-MAC<br />
John&nbsp;Melvin,&nbsp;SRI-ARC<br />
Bob&nbsp;Long,&nbsp;SDC<br />
Bob&nbsp;Metcalfe,&nbsp;Harvard<br />
Wil&nbsp;Crowther,&nbsp;BBN<br />
这个委员会将在一个星期内提供一个过度协议，并在未来几周内提供一个长期协<br />
议。<br />
周四下午，二月十八日<br />
周四下午有ILLINOIS大学就ILLIAC第四计划做报告，此外还有关于Plato计划的<br />
演示。去年十一月份关于向ILLIAC第四处理器进行传输的线路的初步测试并未发现记<br />
时问题。ILLIAC第四系统的硬件和软件都将最终建立。该系统将被放置在California<br />
的NASA&nbsp;Ames研究中心。从ILLINOIS大学到网络的连接将由一个具有CRTs存储器、<br />
2400波特字符CRTs、以及附加输入设备的PDP-11实现。它将同时安装一台Gould&nbsp;<br />
Clevie打印机和DEC磁带机以及小碟片机。大学的B6500也将与网络相连。<br />
周四晚上，二月十八日<br />
起初的议题是有关网络信息中心的状况和规划的讨论。来自SRI的Dick&nbsp;Watson<br />
回顾了当前由站点代理和网络联系人员组成的离线系统。站点代理的功能是辅助NIC<br />
服务的使用。网络联系人员的作用是作为来自其他站点的人员提出的关于其站点技术问<br />
题的联系点，此外，他还要监视是否适当的人物可以查阅站点接受到的文档和信息。如<br />
果网络要营造一种社区的感觉，那么人们就需要清楚他们的所作所为，并从不同的站点<br />
进行考虑。因此，鼓励人们向NIC提交报告，备忘录，笔记，以及一些对大家感兴趣<br />
问题的讨论的记录。从正式报告到非正式手稿都可向NIC提交。为了鼓励人们提交最<br />
初的想法和观点，NIC给出了一个问题，即：是否应该为文档的不同类冠以标题，以助<br />
于分辨正式与非正式通信的级别。<br />
看上去似乎这样的安排并不必要。其次提出的问题是有关隐私及安全性的。一些<br />
人认为如果信笺或是谈话的记录被收录到NIC文集中，可能其中的一些会包含个<br />
人隐私。人们询问NIC是否其会在收录之前检查涉及此类通信的所有方面。Dick<br />
认为既然有NIC资源的存在，那么涉及到的各方面在向NIC提交之前首先给予许<br />
可或许会更好一些。<br />
NIC将提供的最初的在线服务是对一个SRI-ARC在线系统（NLS）打字版本的访<br />
问。向人们提供消息服务，访问NIC的目录以及可能的站点状况文档，以及网络<br />
工作人员等等。今后还将提供服务来辅助站点社区中站点代理的工作。在一次主<br />
要的调查会议上，似乎人们对使得NIC得到一套关于ARPA计划的报告和工作文<br />
档有相当大的兴趣。为了解决如此庞大集合的存储处理，微缩胶片看上去非常重<br />
要。使用微缩胶片有很多问题，如只允许单个或有限数目的读者，以及需要硬拷<br />
贝设备等等。NIC将调查这些问题，并开始用微缩胶卷材料来进行实验。<br />
NIC正在用一个IMLAC终端进行NLS的远程访问试验。人们对NLC的图形访问<br />
产生了很大的兴趣。NIC则认为图形访问并不是一个当前优先级非常高的需求，<br />
但仍会尽快向站点提供编程资源以期进行图形访问的试验。<br />
Steve&nbsp;Crocker提出了人们如何从不同的站点获取访问权限并学习使用服务设施<br />
的问题。关于用户在网络上的服务设施需要包含或附加于用户文档的哪些附加信<br />
息等问题也做了讨论。并提出了硬拷贝应包括何种材料，在线信息都有哪些等问<br />
题。NIC将对这些问题进行研究，并生成一套处理用户操作的推荐步骤，以及网<br />
络访问使能所需的信息列表。<br />
Dick&nbsp;Watson指出，尽管NIC提供的服务只能运行更慢的终端以及单层图形界面，<br />
NIC的用户可能还是会认为使用拥有上下多层图形界面的，以每秒30个字符运行<br />
的打字终端是最佳选择。RFC97号文件（NIC5740）描述了一个与NIC相连的最<br />
初协议。由于一个产生标准打字连接协议的委员会的成立，RFC97号文件协议将<br />
被改动以满足由该委员会建议的一个过渡协议。近期，与这个过渡协议一同还要<br />
提交一个新的RFC文档。自从这次会议以后，打字连接协议委员会决定不提交这<br />
个过渡协议。<br />
会议转移到站点之间文件传输方面，讨论了在文件传输过程中通过文件名传输而不<br />
需要用户登陆每个站点的方式。ILLINOIS大学的Gary&nbsp;Grossman将就这一题目提交一<br />
个初始的RFC文档。<br />
周五上午，二月十九日<br />
与网络相关的数据管理方面有一些问题在会上讨论。会议提及了下列各方面以及其<br />
负责人：<br />
数据机10~12位存储<br />
数据管理语言<br />
形式机<br />
ILLIAC&nbsp;IV信息管理系统<br />
过渡文件系统<br />
文件传输协议<br />
数据机有美国电脑有限公司负责，但要求与ILLIAC&nbsp;IV信息管理系统及网络和在数<br />
据管理语言方面的工作密切协调。<br />
数据管理语言的工作由ILLINOIS大学的J.&nbsp;Madden，哈佛大学的Bob&nbsp;Metcalfe，<br />
RAND的J.&nbsp;Heafner，UCSB的Jim&nbsp;White以及IBM的Doug&nbsp;McKay负责。<br />
John&nbsp;Heafner说他打算实施他关于形式机的计划（RFC83号文件（NIC5609）<br />
UCSB，Multics）。林肯实验室也宣称他们对此感兴趣。一些站点，如UCLA，SRI，<br />
RAND，ILLINOIS大学，Raytheon，MITRE表示对在一至三个月内在UCSB&nbsp;360/75<br />
磁盘阵列上保存文件有很大兴趣。Jim&nbsp;White说他将在接下来的四到六个星期内建立一<br />
个系统以使网络用户可以在UCSB保存文档。<br />
主机间文件按名称传递的问题再次被ILLINOIS大学的G.&nbsp;Grossman提出。他说<br />
他将通过生成RFC的方式开始一个有关这一题目对话。<br />
有人提出了接口数目中用户名及用户ID含义的问题。目前为止，接口数目并无结<br />
构可言，但是一些人认为记数、文件传输、进程中通信等一些结构是有价值的。一个由<br />
RAND的J.&nbsp;Heafner，MIT-Multics的E.&nbsp;Meyer和ILLINOIS大学的G.&nbsp;Grossman组成<br />
的委员会将提出一个RFC文件来讨论接口数目结构的另一提议。<br />
UCLA指出，它希望得到链接数目的实验范围内的一个链接数目，以用于网络的测<br />
试实验。链接号223被指定给这个功能。（链接223是后来发现并被指定的，被选的连<br />
接实际上是191号，见RFC104号文件（NIC5768））。<br />
由于网络上的机器或系统会提供服务功能，因此提出了记数的问题。当前的服务设<br />
施主要是UCLA的360/91，UCSB的360/75，SRI的NIC，MIT的Multics，ILLIAC&nbsp;IV，<br />
林肯实验室的360/67，以及数据机。高级主机----主机协议研究委员会正着手于记数问<br />
题。他们简要地提及了网络带宽问题。BBN的Bob&nbsp;Kahn说他将提交一篇文章以开始<br />
一个关于记数主题的讨论。<br />
接下来提出了关于处理管理进程的问题，如从外部系统获取记数数目等。Dick&nbsp;<br />
Watson说他将就这一问题进行研究并看NIC在其解决方案上是否可能给予帮助。<br />
最后考虑的是NWG会议的频率以及如何利用的问题。大家一致认为NWG会议是<br />
一个非常有用的会议，但是一些待讨论的特定题目的准备工作应该提前完成。希望在会<br />
议上提交主题的人应该尽可能在下次会议开始一个月之前分发介绍性质的资料。Peggy&nbsp;<br />
Karp将负责NWG在春季会议的房间问题。她不久就会发出预订请求。<br />
<br />
<br />
[这一RFC文档由Kelly&nbsp;Tardif，Viagie于1999年10月]<br />
[编为机器可读的形式以便录入RFC在线档案]<br />
RFC0101---Notes&nbsp;on&nbsp;the&nbsp;Network&nbsp;Working&nbsp;Group&nbsp;Meeting&nbsp;<br />
对1971年2月17日伊利诺斯州的Urbana的网络工作组会议的注释<br />
<br />
<br />
8<br />
RFC文档中文翻译计划<br />