问题是 HTML 与电子邮件不兼容。这就是我创建邮件标记语言的原因。
HTML 是为使用 HTTP 协议而创建的,因为这两种技术几乎是由同一个人在同一时间发明的。不同之处在于 HTTP 是从服务器到客户端的单会话单向传输。这永远不会改变,因为 HTML 文档始终源自服务器,被发送到请求的客户端,并且一旦传输完成,客户端和服务器之间的连接就会断开。
电子邮件不会以这种方式运行。在电子邮件中,通信起源于客户端,发送到一个或多个电子邮件服务,然后终止于远程客户端。然而,最大的区别是文档不会像通过 HTTP 的文档传输那样随着单个传输实例的终结而死亡。在 SMTP 中发送的文档可以回复、转发或复制给多个未请求的用户。在考虑电子邮件线程时,这一差异是深刻的。
问题在于 SMTP 和 HTTP 是不同的,如前两段所示。由于 SMTP 和 HTTP 用于创建标头数据的格式化方法完全不同,这种差异更加复杂。HTML 的标头数据旨在与 HTTP 传输的标头兼容,并且不符合 SMTP 传输。HTML 标头也不考虑电子邮件线程的复杂性。
当电子邮件软件破坏 HTML 文档以添加满足该软件的一致性要求所需的格式更改并将标题数据直接写入文档时,问题就得到了例证。当 HTML 电子邮件成为电子邮件线程时,这个例子变得非常明显。由于 HTML 标头数据无法解释电子邮件线程的复杂性,因此无法从样式表中提供相关的表示定义,这些定义在文档传输后仍然存在。每次将 HTML 文档或具有 HTML 格式的文档从一个电子邮件软件发送到另一个电子邮件软件时,该文档都会损坏,并且每个电子邮件软件设备都会损坏先前的损坏。电子邮件处理软件可能是指电子邮件客户端,它肯定会损坏文档,也可能是电子邮件服务器,
该问题的解决方案是创建一个直接识别电子邮件标题数据要求的标记语言约定。这些要求在 RFC 5321 中针对 SMTP 协议和 RFC 5322 中针对客户端处理进行了定义。正确扩展此解决方案以解决电子邮件线程复杂性的唯一方法是为多代理 DOM 提供约定。
由于技术不准确以及术语多代理 DOM 与此处未提及的发明特性的性质之间的差异,即使在编辑之前,也删除了段落。
编辑:多代理 DOM 应用一定程度的层次结构,这可能不是表示电子邮件线程所必需的。