引言
以下摘要转录自我在 1970 年秋季联合计算机会议期间于休斯顿参加的三次网络会议上所做的笔记。尽管我力求客观, 但这些笔记难免带有对会议的偏见。这一部分是由于我对某些主题的专注, 以及可能对各种讨论的误解。虽然我努力准确地复述与会者的发言, 但其中一些的含义可能已被曲解。
周一会议的出席者
Dick Benjamin MITRE
Jack Bouknight UI-CAC
Al Cocanower MIRUT
Steve Crocker UCLA
Dough Engelbart SRI
Richard Greenblatt MIT-MAC
Eric Harslem RAND
Frank Heart BBN
Allen Joseph ORNL (Oak Ridge)
Peggy Karp MITRE
William B. Kehl UCLA
Bob Long SDC
Jim Madden UI-CAC
Bob Metcalfe MIT-MAC
Edwin Meyer MIT-MAC
Ari Ollikainen UCLA
Tom O'Sullivan Raytheon
Jon Postel UCLA
Chris Reeve MIT-MAC
Tjaart Schipper UCAL-CCN
Michael S. Sher UI-CAC
Bob Sundberg Harvard
Hal van Zoeren CMU
Albert Vezza MIT-MAC
Alfred H. Vorhaus MITRE
Clark Weissman SDC
网络会议
1970 年 11 月 16 日星期一晚上 8:05
Crocker: 并非所有人都到了, 所以我们先聊着, 等更多人来。大家都对我通知里的议程满意吗?
Meyer: 我们应该谈谈记录器协议。与实验相对, 网络的实际运行使用取决于它的实现。
大家互相做了介绍。
Crocker: 我有一个议程, 但想听听大家对议题的建议。
- 我将作开场发言。
- 我将列出关注的议题。
- Englebart 将谈谈网络信息中心
- 我将回顾各站点的状态。
开场发言
- ARPA 不会为供应的咖啡和点心付钱, 所以请大家凑点钱帮我付账。
- 我将以正式身份全职投入网络协调工作。我的目标是: (a) 提高网络的可用性。 (b) 建立协议层次, (c) ?
重要领域
- 某个站点或站点联盟应准备一种方法, 以便检验一个站点的 NCP。
- NCP 协议的重新设计。有些问题可以解决得更好: (a) 差错控制, (b) 流量控制, (c) 过载 —— 丢失网络状态, (d) 协议的简化和重新分层。
- Telnet 系统的控制台交互, 即记录器协议。如何进入系统, 以及遇到麻烦时如何获得帮助。
- 各主机的文档。网络信息中心参与其中。也许可以给每个站点配一台传真设备。
- 更复杂的控制台, 特别是图形控制台, 要接入网络。应有一个工作组来制定并拟定处理复杂控制台的格式。一月将在科罗拉多或犹他举行一次图形会议。入场费是写一份提案。我预计最多 30 人。我会挑选一小部分人来制定规范。
- 计费 —— 1971 年下半年会有更多站点加入, 在那里计费很重要。(他们想发账单。) Larry Roberts 说会有一种银行式的系统, 账单在各方之间传递。两类站点: 计费站点, 以及免费但访问受限的研究站点。我看不出有什么根本性问题。当一个研究站点与一个计费站点通信时会怎样? 我认为这是可行的。
- 测量 —— 网络是一个工具, 但它也是一个比仿真软件包更好的模型。各方都想做测量。这可以通过在 NCP 里保存统计数据来支持。把 NCP 扩充以纳入这些内容如何?
Long: 把计费和测量放进 NCP 会占用空间。新增内容要保持最少。
Weissman: 各种系统的预定可用时间怎么办?
Crocker: 这必须与每个单独的系统协调
?: 当一个系统宕机时, 连接会怎样?
Crocker: 图形提案怎么办? 我会自己写一篇论文作为提案。它以 DEC 340 为模型。Modes 假定 scope 系统有内存。输出和输入都纳入标准制定。我希望由工作组制定出一个像样的协议。
Crocker: 文档方面怎么办?
Meyer: 关于如何使用其他系统的文档是必需的。只有这样才能推动网络的实际运行使用。
--: 在每个站点把文档放到线上怎么样, 或者至少放摘要。
Crocker: 哪些站点有在线文档? (MIT 和 Harvard) 各站点对把文档保存在别人的系统上怎么看?
Crocker: 重新设计协议怎么样?
Harslem: 我们已经登录进 UCSB 系统, 正在协同调试。
Harslem: 我们对取消标记和填充（按 RFC 67）印象深刻。
Crocker: 我们和各站点讨论过这个。大多数人似乎接受了, 但有一些保留意见。对基本协议的修改怎么办。我想 Meyer 有话要说。
Meyer: Project MAC 的立场是, 在目前这个阶段, 除了关键性修复之外, 我们反对作改动。花在改动上的时间, 就是不会花在开发其他必要而有趣的协议和系统上的时间。而且我们 Multics 这边创建和安装改动的前置周期很长。
Weissman: 我倾向于把改动一次性放入, 比如每隔 6 个月一次。而不是零零碎碎地改。
O'Sullivan: 现有系统和新系统不能同时工作吗?
Crocker: 如果改动涉及 IMP, 那不行, 因为所有 IMP 都希望运行同一套系统。
Meyer: M.I.T. 的感觉是, 要想成功, 网络迫切需要投入实际运行使用。如果再过去一年而没有重大的实际运行使用, 它可能就泡汤了。
--: 而文档对于推动实际运行使用至关重要。
Engelbart: 也许我们应该把图形推迟几个月, 以免耽误打字机。打字机很重要。
--: 但那样对 DOD 的人来说足够有说服力吗?
Engelbart: 但如果两年后发现它是个烂摊子……
--: 但这两个开发组（打字机和图形）之间有交流吗?
Vezza 和 Engelbart: 有。
Crocker: 我们多听听这方面的内容。
Harslem: 我们希望能访问文件。
Crocker: 那么图形方面的工作也许会分散打字机开发的精力。这个小组的共识是不是我们不该开图形会议?
Vezza: 新来的人应该做图形, 而不是已经定型的人。禁止现有人员参加这个会议。
Meyer: 那会非常令人沮丧。
Benjamin: 为什么不征集立场文件（但不开会）。
Weissman: 字符传输比图形传输容易。图形需要更多实验。开发图形协议的前置周期比打字机长得多。
Vezza: 我同意。
Crocker: 接下来几天还会有更多会议, 来处理如何通过网络完成有用工作的问题。
中间休息
晚上 9:15
Crocker: Engelbart 将谈谈网络信息中心。
Engelbart: NIC 是作为一种临时性的东西发展起来的, 没有 ARPA 的具体指示。当时设想了哪些东西? (1) 复杂的查询系统, (2) 关于各站点系统的基本信息。每个人都对自己站点文档的状况感到非常没底。大家都同意: 需要更好的文档。我们认为自己提供以下服务: 1) 收集硬拷贝材料; 2) 对这些材料的目录和索引进行在线查询; 3) 提供对这些材料的访问。我们决定走硬拷贝而不是在线, 也许是缩微胶片。
Engelbart: 原本要用 940 来做文档系统, 随着使用量增长可以扩展。我们正从 940 换成 10X, 以便更好地扩展服务能力。容量大幅提升。这耽误了其他方面的工作。是一场有意的赌博。我们担心能否起步。我们缺少资金来增加二级存储, 有兴趣用其他主机做三级存储。在 940 上实现协议的成本相对于潜在收益太高, 所以放弃了。到一月我们的 940 要运走时, 能上线的站点寥寥无几。
Engelbart: 我们创建了一个 Network Dialogue System。这是一个人工代理组成的网络。每个站点有: a) 技术通信代理（秘书）和 b) 技术联络人。我们鼓励代理与我们通话, 并设置了 “Enterprise” 电话号码, 让他们可以免费通话。
Engelbart: 我们首先给每个代理寄出一小套资料, 一套不断增长的网络参考信息集合。每个站点要培训一个人（代理）来处理这套文档, 并在需要时检索信息或联系另一个站点的技术联络人。这涉及一种公开的对话, 记录来回传递的文档。这是一种 “human IMP” 网络, 结构如下:
________________________________
| |
| ________________ |
| | local | | one
| | reference | | <== site ____________
| | material | | ( )
| -----------------| | ( )
| | => (____________)
| | || \\
| | || Other sites
| | || \\
| ________ | || ____________
| local =====> | |================ ( )
| users | agent |=====|===============( )
| =====> |________| | (____________)
| |
|________________________________|
- 主集合拥有全部材料。
- 每个本地集合拥有被认为最有用的一部分。
--: 限制对文档的访问怎么样?
Engelbart: 在这个系统里所有文件都是公开文件。
Vezza: 你可以发一份私密备忘录, 而不是用 NIC 服务。
Engelbart: 主集合包含书籍和其他文档。在线编目。硬拷贝的东西可以复制。对于通过价值检验的信息, 该服务负责存储、编目、建立索引并提供对文档的访问。我们将支持多种不同的终端。我们准备在硬拷贝条目上走很长一段时间, 但可以有偿提供从硬拷贝到在线的转录服务。
Weissman: 给各站点分发 OCR Selectric 字球怎么样?
--: NIC 是收下送来的东西, 还是主动去搜寻?
Engelbart: 大致是送到我们手里的那些。1971 年春季会有一个系统, 让代理把条目插入目录。所进行的对话将决定数据库往哪个方向增长。我们相当肯定, 最终 SRI 将不得不收费, 因为许多不在主站点的潜在用户会来争取有限的资源。
--: 你们 10X 的 NCP 怎么办。
Engelbart: 如果 BBN 的 NCP 在 1971 年 2 月前准备好, 我们就用它。
Crocker: 人们怎么获得访问?
Engelbart: 每个站点都注册了。任何通过站点账号进入的人都有相应的访问权。在饱和之前我们不担心计费。我们希望鼓励使用代理系统, 来创建并使用各站点资源的调查。某个子小组应该讨论一下这个。
Crocker: 人们什么时候能开会讨论这个? (明天上午)
Engelbart: 我们有很好的设施来开发邮件列表、私人书目、人员档案, 但这取决于网络方面的人有没有兴趣。
Engelbart: 已经在 MIT、UCLA、RAND、UI、Utah 等站点设了代理。相当大比例的站点
Vezza: 许多站点寄东西用三等、四等邮件。太费时间了。
Crocker: 站点状态报告。ILLIAC IV 要到 1971 年年中才能运行, 上网络更晚 (72?)。其他可能的站点: RADC、AWS、NCAR。目前已上线: UCSB、RAND。即将上线 (1971 年 1 月): MIT BBN、Harvard、UCLA、Utah、LL、SDC。年底前有一部分, 其余在一月。
Heart: 明天要装入一套全新的 IMP 系统（重大改动）。还有一些站点在考虑加入。网络将大幅增长, 超出目前已接入的规模。我们也对站点资源信息感兴趣。没有长期兴趣, 但我们会把信息写在纸上以帮助 ARPA。
Crocker: 很多人在打哈欠了。会议日程怎么办? 在 FJCC 期间开? 开 1 天还是 2 天? 东西海岸同时开两个会议怎么样?
会议结束
网络会议
1970 年 11 月 17 日星期二上午 9:15
Crocker: Engelbart 会讲得更详细些。之后可能会讨论记录器协议和文件传输。
Engelbart: 基本的东西是一批文档, 配一份描述它的目录。条目包含很多数据项, 包括在哪里能找到它。添加和更新条目的技术。我们现在就在做, 但想把这项能力提供给其他站点, 部分原因是我们无法判定什么有价值。(展示了 3 种打印输出。) 1) 目录清单, 按集合内的顺序索引和 NIC 索引排列。用于库存控制, 查明里面有什么。2) 压缩成一行。3) 按作者排序 —— 每个条目一行。我们将有相应的流程, 让未受过训练的用户也能管理一个集合。
Meyer: 这些系统是怎么实现的?
Engelbart: 我们在 940 上有一个编译程序的编译程序。我们的子系统用专门的高级语言编写。我们正把这些移到 10X 上。
Heart: 粗略估计 10X 能支持多少人?
Engelbart: 也许 100-1000 个集合。
--: 也许人们可以自己提供 DEC 磁带作为额外存储。
Engelbart: 可以, 但需要现场操作员。访问慢。我们没有钱买更多存储, 但在考虑把文件送到 UCSB。我们对在线数据提供在线查询。无论我们是否存储, 都愿意操心数据管理。
Crocker: 请描述一下各个子系统。(接下来由 Engelbart 描述。)
Heart: 有人试过通过网络使用它吗?
Engelbart: 没有。940 上没有 NCP。决定不把它装进一个即将淘汰的系统里。最大的卡点是 10X 什么时候有 NCP。Bobrow 在开发, 但进度在往后拖。
Heart: 谁会是早期接入它 (SRI) 的人?
UI: Illinois 一开始只能访问 SRI。
Postel, UCLA: 我们打算用它。
Heart: 如果有人把接入 Engelbart 的系统当作目标, 那会是一项不小的任务。
MITRE: 我们要从 BBN 的 10X 使用其他系统。
Engelbart: 我们正设法把必要的子系统独立出来, 方便人们使用。文件按层次组织, 随着年头会逐渐充实。文档用路径名引用。(接下来讨论系统。)
Crocker: 怎么进入系统? (Engelbart 描述了进入 TOdas 的序列。)
Crocker: 怎么在系统上注册?
Engelbart: 最终按个人条目注册, 但目前每个站点只有一个用户 id。
Meyer: 我认为我们忽视了打字机接口中未解决的问题。比如进入 TOdas 的序列, 用户输入一两个字符, 系统就打出某个关键字的其余字符, 从 Multics 这样的半双工系统使用会很令人沮丧。我们的系统在输入换行之前不会识别一行输入。
Various: 讨论 1/2 duplex 通信。引出了以下区别: a) 系统回显输入的全双工系统, 与输入在本地打字的 1/2 duplex 系统; b) 每输入一个字符就被识别的系统, 与只有在 EOL 字符之后才识别整行的系统。
Crocker: Multics 不是网络上唯一一个半双工、面向行的系统吗?
Meyer: 我无法相信。IBM 系统不也是这样运作的吗?
Engelbart: 我们的系统 (SRI) 可以有一个 1/2 duplex 接口。是 Multics 的硬件强制了这个限制吗?
Meyer: 是的, 输入输出控制器。*
* Multics IO 控制器的打字机适配器是 1/2 duplex, 但可以接受 “new line” 字符以外的 break 字符。
Engelbart: 每个系统都应该有一个预处理器来与其他系统通信。我们要把一个图形接口接入网络。
Meyer: 你怎么看这些接口? 它们是遵循某种网络标准, 还是每个系统各自构造一个到你的接口?
Engelbart: 标准网络协议。
Crocker: 我们接着谈别的。
O'Sullivan: 你们 (CMU) 10X 系统上的 2741 怎么办。你们有严重的接口问题吗? (CMU 的 2741 经过一个软件包转换成 TTY 37。没有严重困难。)
Various: 简要讨论 Multics 如何处理输入。
Sundberg, HARVARD: 我们的 10X 可以接受面向字符的输入, 但我们更高层的子系统更喜欢面向行的输入。
--: 一次一个字符地通过网络传输消息, 效率如何?
Crocker: 输出比输入多, 而且是打包传输的, 所以输入的低效可以忽略不计。
Engelbart: 我们计划在我们的系统上开几个不同的端口。如果每个系统都有一个 NIC 模块; 它就能与我们通信而不必登录。我们更倾向于批处理式的系统, 站点把成批的编辑请求 spool 出去, 取回结果, 然后释放端口。按行传输打字机的问题可以用类似 spooled-up 请求的方式来处理。我们鼓励 spool, 但也会支持交互式用户。我们能支持的批处理比交互式用户更多。
* Multics IO 控制器的打字机适配器是 1/2 duplex, 但可以接受 “new line” 字符以外的 break 字符。
Vezza: 大家觉得全双工和 1/2 duplex 的问题是个问题吗? 让所有人都回去了解一下这个。M.I.T. 有两套相距 20 英尺的全双工和 1/2 duplex 系统, 在这方面能帮上忙。
O'Sullivan: 似乎有 2 个问题: (1) 回显（全双工）对 1/2 duplex。(2) 单字符传输对整行传输。
Crocker: 两个定义: 服务主机 —— 提供计算; 使用主机 —— 寄生性的, 管理用户的终端。这把网络使用看作本地用户与外地服务器之间的链路。
Vezza: 如果某些全双工系统回显的不是输入的内容, 那么 1/2 duplex 与全双工的互连怎么办。
Crocker: 两种相互独立的可能。我们画个图:
| "2741" | "33, 35, 37" |
| hard wire | 2 separate |
| local echo | lines all |
| computer does | printed |
| not echo | |
____________|_________________|___________________|
Process | hard | X |
each | | |
character | | |
____________|_________________|___________________|
Process | X | easy |
only after | | |
EOL | | |
____________|_________________|___________________|
Crocker: 我认为实际上只有两种可能（用 X 标出）。
Postel: 那回显是在低到无法删除的层次上进行的系统呢。
Crocker: 如果是那样, 就跟不回显一样。
Van Zoeren: 我们的系统以为我们有的是全双工 TTY, 但我们的 2741 是通过一个软件转换盒接上去的。
Meyer: 当不回显的系统通过网络接到回显的系统上时会怎样? 我输入我的输入行, 然后回显的系统用我的输入回应, 然后是一些输出。我的系统无法过滤这些, 因为没有办法区分回显和输出。
Crocker: 这未必是坏事。我向 SRI 输入命令缩写; 然后下一行输出就是输入命令的展开形式。
Meyer: 我们的目标应该是制定一个通用协议, 而不是一堆蹩脚的方案, 用来实现特定主机对之间的通信。
Long, SDC: 我们更愿意接收通过网络送来的整行。
Crocker: 我们把研究中心和服务中心区分开。只有服务中心才关心半双工接口。(图上左下角的 X。) 这些包括 SRI、BBN、Multics。
O'Sullivan: 研究中心呢?
Crocker: 它们可以呼叫服务中心, 但它们自己可能很难用。
Illinois: 那么 ILLIAC IV 将不得不做成半双工。
Postel: 我认为半双工、面向行的协议（比全双工、面向字符的协议）要弱。
Sundberg: Harvard 两种都行, 但更喜欢面向行的系统。
Engelbart: 图形终端更难接入网络, 因为输入不标准。
Harslem: 你是把那些键当成功能键而不是输入键了。
Engelbart: 我担心的是那些想用图形的人。
O'Sullivan: 我们还没有谈到应该建立什么样的协议这个问题。
Crocker: 那不是什么困难的技术问题。我们稍后会谈到并作出决定。
Meyer: 我没有被授权作任何决定。我要回去向 MAC 小组汇报。
Crocker: 好的。那么, 提出一项提案, 通过正常机制来接受。中间休息
Crocker: 我将提出如何处理打了 X 的方框, 忽略 hard 和 ease 的方框:
Line-Oriented Input —— 8 bit ascii, 包括 End of Line 字符:
n, C1,...,Cn;
Cn=EOL
120>n>>_1 n is the character count in an 8-bit field.
字符计数放在行之前, 以便让软件系统获得与硬件系统相同的效率, 计算机不必扫描 EOL。
Vezza: 你不是能从 IMP 消息中得到长度信息吗?
Crocker: 我的理念是 IMP 消息边界应当完全不可见。
Long: 我反对把打字机消息拆成两个分开的块。
Crocker: 你反对的是哪一点, 1) 行从消息边界开始, 还是 2) 消息不从行边界开始?
Long: 两者都是。
Engelbart: 每台主机都应编写一个接口来处理最常见的终端类型。
Crocker: 官方协议不允许 IMP 消息边界具有任何意义。
Engelbart: 我不想操心 IMP 消息边界。网络应当是不可见的（在这个层次上）。
Vezza, Long: 我们让步, 我们同意。
Meyer: 我想修改这个限制。行包中的最后一个字符不必是 EOL (比如当输出不前进到新行时), 但 EOL 不能出现在包的中间。
Van Zoeren: 我不喜欢这个限制。
Meyer: 计数告诉我们任何 EOL 都在末尾, 我们不必扫描。
Crocker: EOL 就是告诉系统采取行动的那个字符。
Harslem: 我们的系统有 46 个功能键, 不只是一个 EOL。
Crocker: 如果 C, E {breakset}; i=n 怎么样。这更复杂, 因为必须传输一个 breakset。我稍后会提出这个。这样如何: 面向消息的 (1/2 duplex) 连接
在用户主机与服务器主机之间, 用于控制台交互。本地回显, 服务器不回显。这是针对面向行的服务系统的。这些是 Multics 约定的轻微推广。
Meyer: 我确信除 Multics 之外的其他系统也在用它。它没有你想象的那么糟。
Engelbart: 上层管理者应该知道它很糟。
Meyer: 这不清楚。还有效率问题。
Van Zoeren: 我不想非要用这种方式传输文件。
Crocker: 这是用于控制台的, 不是文件传输。
Engelbart: 我们需要一个统一的数据传输方案。
O'Sullivan: （就控制台而言）我们要设计一种办法, 告诉一个系统它的中断应该在哪里被模拟。
Crocker: 有一个关于磁带和文件数据传输的一般性问题。
O'Sullivan: 但我们有实现打字机通信这个具体问题。
Engelbart: 但我们需要的是一种通过网络发送东西的通用方式（这样它就是不可见的）, 并让主机按自己的意愿解释它。
Meyer: 网络应该只有一个控制台接口, 而不是每个站点好几个。
Crocker: 这个问题也许被夸大了。
Engelbart, Meyer, O'Sullivan: 讨论支持特定终端类型的问题。
Engelbart: 我会画一张系统对终端类型的图。系统与它接受的终端的交叉点用一个点标出。网络通信问题就是找到一种本地主机上有、且目标主机也支持的终端。
_____|_____|_____|_____|_____
| | | |
systems_____|_____|_____._____|_____
| | | |
_____|_____._____|_____|_____
| | | |
_____|_____|_____|_____|_____
| | | |
terminals
Crocker: 有一个子系统对输入作出反应的一般性问题。我们建议输入应作为一个完整消息发送, 或按 8-bit 的倍数发送。
Vezza: 我们是不是限制得太多了?
Meyer: 为什么一定要用 8-bit 的倍数?
Crocker, Engelbart: 好吧, 把那个扔掉。
第二次会议结束
网络会议
1970 年 11 月 18 日星期三晚上 8:20
(以下笔记做了大幅压缩, 只试图呈现本次会议讨论的主要议题。)
Crocker: 我们在 SJCC 再开会, 事先多做些组织工作。我们每隔 2-3 个月开几次为期一天的会议。关于下一层协议我们有很多好的讨论。让一个子小组把它弄清楚。
(Harslem 自愿重新起草 RFC 66 中提出的记录器协议。Meyer 将修订 RFC 46 中的提案。)
Meyer: 我们回去, 讨论这些问题, 写提案。之后我们开一次公开会议来决定一份正式提案。
Crocker: 小组更好, 也许我会挑一个子集。
Vezza: 这里的事情确实还没有定下来。重大提案应该在开会前就形成书面材料。我们无法规定一个小组该做什么。它并不比个人有更多的权威。
(MITRE 的 Karp 自愿编制一份网络文档的书目, 也许在一月之前。)
(谁实现了记录器协议? UCSB 和 UCLA mod 91 已经实现或正在计划。SDC 可能在 21/1 之前有, 觉得它别扭, 愿意改。)
(讨论文件传输。Crocker 提出, 未来的协议改动可能会给一个连接附加一个字节大小, 如 8、32、36 bits。)
(关于控制链路, 除 ECO、ERP、ERR 命令外, 一切都以 8-bit 字节传输。没有人反对修改协议, 使它们也必须是 8-bit 字节的倍数。)
(讨论如何指明文件的结束。事先传输比特计数, 还是在末尾发送 EOR 字符? 有人建议我们要的是一个全局方案, 来解决发送任意长度消息这个一般性问题, 而不只是文件传输。)
(讨论 “transaction units” 或记录大小。最优的事务单元大小是多少? IMP 消息边界是不可见的（凭协议规定）, 与这个讨论无关。有人提到 Multics 的块大小。最接近的是页面大小, 1024 字。)
(如何指明文件结束。Engelbart 说先发数据包, 再发 EOF 包。Crocker 建议关闭连接 (CLS) 可以充当 EOF。Vezza 建议用 IMP 消息边界来确定结束。如果不足一个完整的 IMP 消息, 这就是文件的最后一部分。Meyer 建议使用两个连接, 数据通道和控制通道, 所有控制消息如文件名、比特长度等都通过它传递。)
(讨论不同情形: 有时要整个文件, 有时要文件的一部分, 有时要任意分块的整个文件。)
Meyer: 何不推迟这个, 先谈最要紧的打字机通信。
Vezza: Engelbart 想要一个干净的通用方案。
Crocker: 如果我们现在搞一个临时方案, 可能会妨碍以后实现通用方案。
(Crocker 提出一种格式, 用于传输由固定大小 8-26 bits 字节组成的任意长度记录文件。一条记录小于 10^5 字节。每条记录以一个计数字节开头。)
1 2 n 1 2 m
|----------------------------------------------------|
| n | | | | | m | | | | |
|----------------------------------------------------|
<------- record -----------> <-------- record ------->
O'Sullivan: 这个模型适用于具有字符和图形模式的终端吗?
(讨论键盘传输与文件传输之间的差异。不确定一个全局方案能否同时适用于两者。)
(谁想通过网络传送文件? Multics 和 6-10, RAND 到 UCLA, MITRE 用 BBN。)
Crocker: 我们回去想想这个, 以后再提出方案。
(Harslem 提出一种带操作码的数据传输格式。每条记录由以下组成: <opcode> <length> <data>。提供了发送多种状态信息的机会。)
(讨论数据和控制信息是混合发送还是在分开的连接上发送。数据被污染的问题, 对同步和竞争问题。有人声称同步问题很容易克服。)
(有人建议我们对这个领域其实了解不多。我们应该回去动手写。)
中间休息
Crocker: 在能登录其他系统之前, 必须先做什么?
Meyer: 3 个问题: 1) 如何建立连接, 2) 字符集是什么, 3) 传输模式是什么（与全双工和 1/2 duplex 问题有关）。
(讨论把标准协议朝向服务系统, 这些系统一般是面向行的和 1/2 duplex 的。任何提供服务的系统都要有一个 1/2 duplex 接口。)
(讨论记录器协议是否可能或可取地允许在一个 IMP 消息中传输不完整的行。接受不完整的行效率较低, 发送整行是合理的。有人指出 NCP 协议不允许 IMP 消息边界具有任何意义, 所以系统必须准备好接受跨越 IMP 消息边界的行。不过, 最好还是发送完整的行。)
(讨论面向行的协议是否应该变通, 以便接受来自全双工系统的单字符传输。看来我们正在提出的协议是要让任何系统都能使用面向行的系统。要从其他系统使用面向字符的系统则更困难, 需要单独的协议。)
Heart: 我赞成马上出一个方案。
Postel: 一旦有东西装了进去, 就很难改它了。
Crocker: 我认为这些会议的结果会比我们预想的更重要。我更关心长期影响, 而不是开始日期。
Van Zoeren: 如果我们不决定它, 别人就会用糟糕的方式决定它。
注: 本 RFC 由 Gottfried Janik 于 2/98 转成机读形式, 以便录入在线 RFC 存档。