RFC101 对1971年2月17日伊利诺斯州的Urbana的网络工作组会议的注释

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