摘要

  • RFC 910 记录了 1984 年 7 月的多媒体邮件会议。BBN 报告说，Diamond 的初版已在 Jericho 工作站上完成，可交换包含文字、图形、图像、语音和电子表格／图表的复合文档。
  • Diamond 的表格对象把模型与数据一起传递。功能完整的收件程序可更改数据、检验另一种结果；简化程序则可跳过公式，只显示单元格数值。会议还讨论了怎样让同一份文档适应不同屏幕和打印机。

设想一间办公室：报表刚送到，图表上的线条漂亮得像专门为汇报而长。有人指着一格数值问：“要是这项成本翻倍呢？”纸面上的曲线回答不了。可若邮件送来的是整套计算模型，收件人便能改掉那一格，看图线当场改口。1984 年，这种“把追问的工具随报表一起寄出去”的念头，已经坐上了互联网邮件研究者的会议桌。

Harry Forsdick 的 RFC 910 是 7 月 23 至 24 日 BBN 会议的记录。BBN、ISI、SRI 和 Linkabit 都带来了进展。BBN 的 Diamond 初版已在 Jericho 工作站运行，可处理文字、图形、图像、语音和电子表格／图表。ISI 正在 Xerox 1108 上开发用户界面，TOPS-20 上的消息处理模块已基本完成，并增加了与普通 SMTP 邮件之间的转换。SRI 则介绍了 Sun 工作站上的邮件管理、结构编辑和传输模块，当时支持文字、语音和图形。桌面上摆的不是一套整齐划一的成品，而是几种准备互相通信的系统。

Diamond 电子表格的关键，在于它寄的不只是计算结果。对象里有数字、标签、日期和公式，连同这些元素之间的模型一并传输。收件人的程序若懂它，就能代入别的数据，看原表格暗示的结论怎样变化。同一对象可以画成表格、折线图、散点图、柱形图或饼图，加上分隔线还像一份漂亮的商业报表。外表是报表，里面装着可继续追问的机关。

会议也给简化阅读器留了位置。它可以忽略公式，只把单元格数值摆出来。这样一来，同一封邮件在强弱不同的软件上会呈现不同深度：有的收件人能动手试算，有的至少能读出表格。记录还担心，不认识 Diamond 表格的其他实现收到它时，程序可能直接进调试器。这说的是兼容性风险，而不是现场发生过的事故。会议因此同意让系统接收未知媒介类型，必要时略过内容。收件人本领参差，消息得先活着抵达。

表格能否在不同机器上“保持意思”，又把问题引到版面。小窗口、位图显示器和纸张打印机各有尺寸、分辨率、字体。与会者想记录作者对分组、标题、重点和对象关系的意图，却把最终布局留给收件端决定。把文字解释固定在图旁边，是作者的愿望；在另一台机器上怎样摆得清楚，是阅读程序的工作。会议把这项表示方法列为待完成任务，并给出了期限。

这些实验有更早的技术底座。Jon Postel 的 RFC 759 描述互联网消息协议和消息处理模块；RFC 767 描述多媒体文档的结构格式。到 1984 年，研究者面对的是实现之间的摩擦：图形格式先用谁的、不同工作站怎样互通、复杂邮件如何转换成只含文字的 SMTP 邮件。他们决定暂用 Diamond 的图形表示，取名 MMGraphics1，同时继续寻找更普遍的标准。

会议纪要里的日程表同样说明当时走到哪一步。新版多媒体语法打算在 1984 年 10 月 1 日前切换完成；下一轮包含文字、图形、图像和语音的实验安排在 1985 年 1 月。BBN 预计下一年 ADDCOMPE 测试平台会有 100 至 200 名用户，那是预测人数。Diamond 表格是会上报告的实现；让各处的程序稳定收发它，还得靠后续协调。

发送者可以挑出最好看的曲线；模型一旦随信到达，收件人就能把它请回证人席，换一组数据再问一次。图表终于要为自己的前提负责了。1984 年的邮件实验，已经在琢磨怎样把一个足以改变结论的“如果”，塞进信封。