摘要

  • Jon Postel 在 RFC 807 记录了 1982 年 1 月 12 日的多媒体邮件会议。若收件机器缺少呈现某类数据的设备，例如 LPC 声码器，与会者倾向于告诉用户：这里有一类数据，机器无法呈现，并说出它的类型。
  • 会议同意用 CCITT T.4 编码交换黑白位图。最初实验打算以文件方式发送完整 RFC 759 文档，文字采用 RFC 767 段落格式。先发指针、让接收端选择所需片段的协商方案，连同中继和媒体交错问题，留待继续研究。

一封邮件带着一段话、一张图和一段声音。文字看得见，图能显示，声音的数据也到了，接收电脑却没有能把它放出来的设备。1982 年 1 月，多家实验室的人在南加州大学信息科学研究所讨论多媒体邮件，面对的正是这类窘境。Jon Postel 在次月发表的 RFC 807 记下他们的回答：告诉用户确实有数据，说明它属于什么类型，并承认这台机器呈现不了。开头的邮件是示意；处理原则来自会议记录。

这群人手里的设备像一次硬件展销会。CMU 使用 PERQ、传真和 LPC 声码器；ISI 用 TOPS20，也开始试 PERQ，并有 Rapicom 450 传真机。MIT 的 Apollo 还在等网络接口。COMSAT 做传真编码，BBN 研究分发与隐私，UCL 清理、缩放和裁切位图，SRI 做带安全功能的邮件和图文工作站。共享一个文件格式很难让七处实验室凭空长出相同的扬声器、屏幕和存储。

因此，能传输不等于能给人看或听。会议用缺少 LPC 声码器举例：收件系统可以拿到语音数据，却无法把声音交给用户。与会者的普遍意见是如实报告“有些数据在这里，我无法呈现，它的类型是某某”。他们还提出两个待研究问题：究竟允许多少种标准形式，各媒体在内存、CPU 和呈现时间上的成本如何影响选择。诚实提示是眼前可做的事；其他账还没算完。

图像方面有一个共同决定：黑白位图交换采用 CCITT T.4 编码。这能让分处不同机器的实验互相读懂一部分图像数据。会议计划在实验中使用修订后的 COMSAT 图像数据格式，既能装原始位图，也能装 CCITT 编码。共通编码解决的是字节怎么解释；接收端有没有合适设备，仍要由接收端自己回答。

有人提出更精巧的设计：发件人先发各段内容的指针，收件系统只请求自己能处理的部分。这听起来节省传输，碰到中继邮件就复杂了；文字、图片、声音若细密交错，请求边界又该划在哪里？附件、指针、交叉引用也难在一次会议里定妥。于是首轮实验采用一句非常工程化的决定：先把整份文档发过去。最重要的事是让各站点真的能交换一次，而非先用概念图把复杂性擦掉。

这次实验有明确材料。各站点可用手头任何文件传输方法，传递一份完整的 RFC 759 文档。文字按 RFC 767 段落格式写，位图放进修订的 COMSAT 格式，采用原始位图或 CCITT 编码。会议把传真与文字文档交换演示交给所有站点，计划在 1982 年 4 月 19 至 20 日展示。记录给出了任务和期限，没有给出演示已完成的结果。更新 RFC 759、RFC 767，以及比较国家标准局的邮件格式，也列入行动表。

留下的工作清单很长：各团队先发展自己的多媒体编辑方法，日后比较；位图的旋转、缩放和剪贴要交流算法；邮箱标识、控制信息、存储与传输成本、与旧式纯文字邮件的衔接，都要继续研究。会议没有把本地实验的差异伪装成一套已经齐备的统一产品。

在这些大问题中，最有力的一句倒是给收件人的小提示。数据抵达机器、机器识别其类型、机器把它呈现给人，是三件事。第三件做不到，就把第二件说清楚。这封 1982 年的多媒体邮件也许还不能开口，至少不该装作里面根本没有声音。