直接因特网消息封装（Direct Internet Message Encapsulation，DIME）

文档选项 未显示需要 JavaScript 的文档选项

级别： 中级

IBM, 作者

2002 年 6 月 01 日

直接因特网消息封装（Direct Internet Message Encapsulation，DIME）是一个轻量级二进制消息格式，可用于把任意类型和大小的一个或多个由应用程序定义的有效负载封装到单个消息构造中。每个有效负载用一个类型、一个长度和一个可选的标识符来描述。同时支持 URI 和 MIME 媒体类型构造作为类型标识符。有效负载的长度是一个整数，指出有效负载有多少个八位元。可选的有效负载标识符是一个 URI，通过它，有效负载之间可以进行交叉引用。DIME 有效负载在生成数据时可能包括嵌套的 DIME 消息或一串串链接在一起的未知长度的记录块。DIME 只是一种消息格式：它不提供连接或逻辑回路（logical circuit）的概念，它也没解决行首问题。

这篇文档的状态

这篇文档是一个因特网草案（Internet-Draft），遵守 RFC2026 中第 10 节的所有规定。

因特网草案是 Internet 工程任务组（Internet Engineering Task Force，IETF）及其分部和工作组的工作文档。注意：其他组也可以将其工作文档作为因特网草案分发。

因特网草案属于草案文档，有效期最长为 6 个月，可以随时被其它文档更新、替换或者废弃。使用因特网草案作为参考材料或不是作为“正在进行中的工作”引用它们的做法是不妥当的。

可以在 http://www.ietf.org/ietf/1id-abstracts.txt 处访问当前因特网草案的列表。

可以在 http://www.ietf.org/shadow.html 处访问因特网草案影像目录（Internet-Draft Shadow Directorie）的列表。

请向“dime@discuss.develop.com”邮件列表发送您的见解，这些邮件列表都被归档在 http://discuss.develop.com/dime.html。

目录

1. 介绍
1.1. 词语约定
1.2. 一致性要求
1.3. 设计目标
1.4. DIME 术语
1.5. 预期用途
2. DIME 机制
2.1. DIME 封装构造
2.1.1. 消息
2.1.2. 记录
2.1.3. 记录块
2.2. DIME 版本号
2.3. DIME 有效负载描述
2.3.1. 有效负载长度
2.3.2. 有效负载类型
2.3.3. 有效负载识别
2.4. DIME 选项
3. DIME 规范
3.1. 数据传输顺序
3.2. 记录布局
3.2.1. 版本
3.2.2. MB（Message Begin，消息开始）
3.2.3. ME（Message End，消息结束）
3.2.4. CF（Chunk Flag，块标志块标志）
3.2.5. TYPE_T
3.2.6. RESRVD
3.2.7. OPTIONS_LENGTH
3.2.8. ID_LENGTH
3.2.9. TYPE_LENGTH
3.2.10. DATA_LENGTH
3.2.11. OPTIONS
3.2.12. ID
3.2.13. TYPE
3.2.14. DATA
3.3. 在 DIME 中使用 URI
4. 国际化注意事项
5. 安全性注意事项
6. IANA 注意事项
6.1. 额外 DIME 选项的定义和注册
6.2. DIME 选项元素类型注册指南
7. 知识产权
8. 致谢
9. 参考资料

回页首

1. 介绍

直接因特网消息封装（DIME）是一个轻量级二进制消息格式，用于把一个或多个由应用程序定义的有效负载封装到单个消息构造中。一条 DIME 消息包含一条或多条 DIME 记录，每条记录可以携带最多 2^32-1 个八位元的任意类型的有效负载。可以将记录链接在一起来支持更大的有效负载。一条 DIME 记录带有三个描述其有效负载的参数：一个有效负载长度、一个有效负载类型和一个可选的有效负载标识符。这些参数的用途如下：

有效负载长度

有效负载长度指出有效负载中八位元的数目（请参阅第 2.3.1 节）。通过在记录的前 12 个八位元中提供有效负载的长度，使高效的记录边界检测成为可能。

有效负载类型

DIME 有效负载类型标识符指出有效负载的类型。DIME 支持 URI [10] 和 MIME 媒体类型构造 [7] 作为类型标识符（请参阅第 2.3.2 节）。通过指出有效负载的类型，就有可能把有效负载分派给适当的用户应用程序。

有效负载标识符

可以以绝对或相对 URI 的形式给有效负载一个可选的标识符（请参阅第 2.3.3 节）。使用标识符使支持 URI 链接技术的有效负载能够与其它有效负载进行交叉引用。

另外，每条记录都包含一个版本号（请参阅第 2.2 节）和一个存放可选数据的槽，这些可选数据以可选元素的形式提供（请参阅 2.4）。

1.1. 词语约定

本文档中的关键字“必须（MUST）”、“绝不可以（MUST NOT）”、“需要的（REQUIRED）”、“将（SHALL）”、“将不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“被推荐的（RECOMMENDED）”、“可以（MAY）”和“可选的（OPTIONAL）”的解释依照 RFC 2119 [9] 中的描述。

1.2. 一致性要求

一个实现如果无法满足这个规范中定义的一个或多个 MUST 或 REQUIRED 级要求，它就不符合 DIME。为解析或生成这个规范定义的 DIME 消息，DIME 实现必须符合 DIME。

1.3. 设计目标

由于现已存在大量的消息封装格式、记录标记协议和多路复用技术，最好是搞清楚 DIME 的设计目标，尤其是要清楚什么东西不在 DIME 的范围内。

DIME 的设计目标是提供高效而简单的消息格式，这种格式可以完成下列工作：

1. 封装任意文档和实体，包括加密的数据、XML 文档、XML 片段、图像数据（如 GIF 和 JPEG 文件）等。

2. 封装刚开始不知道其大小的文档和实体。这个功能可以用于把动态生成的内容或非常大的实体封装成一系列块。

3. 将逻辑上有某种关联的多个文档和实体聚集到单个消息中。例如，DIME 可用于封装一条 SOAP 消息和从该消息引用的一组附件

为实现高效率和简单性，已经把这个规范提供的机制有意限制为只用于这些用途。DIME 还没被设计为一般的消息描述或文档格式（比如 MIME 或 XML）。相反，基于 DIME 的应用程序可以通过将这些格式封装到 DIME 消息中来利用它们。

下面列举了那些不在 DIME 范围之内的内容：

1. DIME 并没有就 DIME 消息内携带的有效负载的类型或这些消息的消息交换模式做任何假设。

2. DIME 并没有以任何方式引入连接的概念或逻辑回路（虚拟的或其它的）的概念。

3. DIME 并不尝试处理线端阻塞问题，当使用面向流的协议（比如 TCP）时可能会发生这种问题。

1.4. DIME 术语

DIME 消息

这个规范定义的基本消息构造。一条 DIME 消息包含一条或多条 DIME 记录（请参阅第 2.1.1 节）。

DIME 记录

一条 DIME 记录包含一个由类型、长度和可选的标识符描述的有效负载（请参阅第 2.1.2 节）。

DIME 记录块

一个已经被标记为包含一个有效负载的一个块，而不是整个有效负载的 DIME 记录（请参阅第 2.1.3 节）。

DIME 版本

一个用于标识 DIME 记录格式的号码（请参阅第 2.2 节）。

DIME 有效负载

用户应用程序定义的 DIME 记录内携带的数据

DIME 分块有效负载

一个已经被划分为多个 DIME 记录块的有效负载。它可以用于携带动态生成的内容或单个 DIME 记录容纳不下的非常大的实体（请参阅第 2.1.3 节）。

DIME 有效负载的长度

以八位元为单位表示的有效负载的大小（请参阅第 2.3.1 节）。

DIME 有效负载的类型

表明有效负载类型的一个标识符。这个规范支持 URI [10] 和 MIME 媒体类型构造 [11] 作为类型标识符（请参阅第 2.3.2 节）。

DIME 有效负载的标识符

一个可选的 URI，用于标识一个有效负载（请参阅第 2.3.3 节）。

DIME 选项

DIME 记录可以以 DIME 选项元素的形式包含零个或多个可选的数据片段。这样可以用于携带关于有效负载的附加信息或以其它某种方式对 DIME 解析器解析 DIME 消息有帮助的信息（请参阅第 2.4 节）。

选项元素

可选的数据片段，可以作为 DIME 选项的一部分在 DIME 记录中携带（请参阅第 2.4 节）。

DIME 用户应用程序

使用 DIME 来封装消息的逻辑的、更高层的应用程序。

DIME 生成器

一个实体或模块，它将用户应用程序定义的有效负载封装到 DIME 消息中。

DIME 解析器

一个实体或模块，它解析 DIME 消息，并将有效负载传递给 DIME 用户应用程序。

1.5. 预期用途

DIME 的预期用途如下：用户应用程序想把一个或多个相关的文档封装到单个 DIME 消息中。例如，这可以是一条带一组附件的 SOAP 消息。DIME 生成器将每个文档作为有效负载或分块有效负载封装在 DIME 记录中，同时指出带有可选标识符的有效负载的类型和长度。然后将 DIME 记录组合在一起形成一条 DIME 消息。DIME 解析器解析 DIME 消息并将有效负载传递给（可能不同的）用户应用程序。

DIME 可以与大多数支持二进制数据交换的协议一起使用，只要 DIME 消息可以被完整地交换即可。使用媒体类型“application/dime”，可以把 DIME 消息作为一个 MIME 实体传送（请参阅第 6 节了解“application/dime”的 IANA 媒体类型注册）。

DIME 记录可以封装任意类型的文档。通过使用媒体类型，比如“message/rfc822”，我们就可能在 DIME 记录中携带 MIME 消息。使用媒体类型“application/dime”可以把 DIME 消息封装到 DIME 记录中（请参阅第 6 节）。

要注意的很重要的一点是：尽管支持 MIME 实体，但在 DIME 中并不假定记录有效负载是 MIME；对于 DIME 消息中携带的有效负载的类型，DIME 并不做任何假设。

DIME 没有提供任何错误处理支持。由 DIME 解析器来确定接收到不符合本规范的格式错误的 DIME 消息（请参阅第 2.2 节了解关于 DIME 版本号的描述）。相关的用户应用程序负责提供它们可能需要的所有附加功能（比如 QoS），这些功能可以作为它们参与的整个系统的一部分。

回页首

2. DIME 机制

这一节描述了 DIME 中使用的机制。第 3 节中定义了这些机制的特定语法。

2.1. DIME 封装构造

2.1.1. 消息

一条 DIME 消息是由一条或多条 DIME 记录组成的。消息中的第一条记录是通过将 MB（Message Begin，消息开始）标记置位来表示的，消息中的最后一条记录是通过将 ME（消息结束）置位来标记的（请参阅第 3.2.1 和 3.2.3 节）。最短的消息长度是只有一条记录，这可以通过置位同一条记录中的 MB 和 ME 标志来标记。注意，要编码一个分块有效负载，至少需要两个记录块（请参阅第 2.1.3 节）。DIME 消息中可以携带的最大 DIME 记录条数不限。

DIME 消息绝不可以交迭；也就是说，绝不可以用 MB 和 ME 标志来嵌套 DIME 消息。通过使用“application/dime”类型在 DIME 记录内携带一条完整的 DIME 消息可以对 DIME 消息进行嵌套（请参阅第 6 节）。

图 1：带一组记录的 DIME 消息示例。消息头在左，尾在右，逻辑记录索引为 t > s > r > 1。在第一条记录中（索引 1）将 MB（消息开始）标志置位，在最后一条记录中（索引 t）将 ME（消息结束）标志置位。

注意：实际的 DIME 记录并不带索引号；记录顺序是由序列化记录的顺序隐式给出的。

2.1.2. 记录

2.1.3. 记录块

分块不是一种用来将多路复用引入到 DIME 中的机制。它是一种在生成端限制出站缓冲需要的机制。它与 HTTP/1.1 [11] 中定义的消息分块机制类似。

一条 DIME 消息可以包含零个或多个分块有效负载。分块有效负载被编码为一个初始记录块，后跟零个或多个中间记录块，最后跟一个终止记录块。每个记录块都是用下列编码规则编码的：

1. 初始记录块是一条 DIME 记录，并置位 CF（块标志）标志（请参阅第 3.2.4 节）。整个分块有效负载的类型必须在 TYPE 字段中指出，不管 DATA_LENGTH 字段的值是零还是非零。ID 字段可以用于携带整个分块有效负载的标识符。DATA_LENGTH 字段指出 DATA 字段中携带的数据的长度（请参阅第 2.3.1 节）。

2. 每个中间记录块都是一条 DIME 记录，并置位 CF 标志，用来指出这个记录块包含相同类型数据的下一个块，并且它的标识符与初始记录块的标识符相同。TYPE_LENGTH 和 ID_LENGTH 字段的值必须为零，TYPE_T 字段的值必须为 0x00（请参阅第 3.2.8 节）。DATA_LENGTH 字段指出 DATA 字段中携带的数据的长度（请参阅第 2.3.1 节）。

3. 终止记录块是一条 DIME 记录，它的 CF 标志被清零，表明这条记录块包含相同类型数据的最后一个块，并且它的标识符与初始记录块的标识符相同。与中间记录块一样，TYPE_LENGTH 和 ID_LENGTH 字段的值必须为零，TYPE_T 字段的值必须为 0x00（请参阅第 3.2.8 节）。DATA_LENGTH 字段指出 DATA 字段中携带的数据的大小（请参阅第 2.3.1 节）。

一个分块有效负载必须整个封装在一条 DIME 消息中。也就是，一个分块有效负载绝不可以跨越多条 DIME 消息。结果，初始记录块和中间记录块都不能将其 ME（消息结束）标志置位。

2.2. DIME 版本号

一条 DIME 记录包含一个版本号，这个版本号表明该记录的格式。当 DIME 消息的格式改变时，DIME 版本号会增加。版本号被认为是“重要的”而不是“次要的”。也就是，在任何两个版本之间，不假设有任何兼容性。

DIME 消息中的所有 DIME 记录（包括记录块）必须是同一版本。在同一条 DIME 消息的不同 DIME 记录中遇到不同 DIME 版本号的 DIME 解析器必须将该消息作为错误的消息废弃。

为解析给定版本的 DIME 记录，DIME 解析器必须与该版本兼容（请参阅第 1.2 节）。一个 DIME 实现绝不可以试图解析或生成该实现不与之兼容的版本的 DIME 记录。一个 DIME 实现可以但不必支持多个 DIME 版本。

这个文档定义了版本 1（0x01）（请参阅第 3.2.1 节）。DIME 的任何新版本都必须作为遵循下列 IETF 共识的标准化 RFC 发布。

2.3. DIME 有效负载描述

每条记录都包含关于它携带的有效负载的信息。这一节介绍描述这些有效负载的机制。

2.3.1. 有效负载长度

2.3.2. 有效负载类型

TYPE_T 字段指出 TYPE 字段值的结构和格式（请参阅第 3.2.5 节）。这个规范支持绝对 URI 和 MIME 媒体类型构造形式的 TYPE 字段值。前者允许值空间的非集中式控制，后者允许 DIME 利用 IANA [3] 维护的早已非常大且成功的媒体类型值空间。

RFC 2048 [8] 中概述了媒体类型的注册过程。不鼓励使用未注册的媒体类型。RFC 2717 [13] 中描述了 URI 模式（scheme）的注册过程。建议只使用 IANA 注册的众所周知的 URI 模式（请参阅 [17] 以获得当前模式列表）。

URI 可以用于 URI 定义的消息类型。携带具有基于 XML 的消息类型的有效负载的记录可以使用根元素的 XML 名称空间标识符作为 TYPE 字段的值。例如，一条 SOAP/1.1 消息可以用以下 URI 来表示：

http://schemas.xmlsoap.org/soap/envelope/

如果一条记录携带一个具有现有的、已注册的媒体类型的有效负载，那么这条记录应该携带这种媒体类型的一个 TYPE 字段值。注意：TYPE 字段指出有效负载的类型；但它却“不”引用包含给定类型实体的 MIME 消息。例如，媒体类型

image/jpeg

指出有效负载是一个 JPEG 图像。类似地，媒体类型

message/http

指出有效负载是一条 HTTP 消息，就象 RFC 2616 [11] 定义的那样。值

application/xml; charset="utf-16"

指出有效负载是一个 XML 文档，就象 RFC 3023 [16] 定义的那样。

2.3.3. 有效负载识别

2.4. DIME 选项

DIME 支持在 DIME 记录中以选项元素的形式携带额外信息。一条 DIME 记录（包括一个记录块）可以带零个或多个这样的选项元素，每个元素都包含关于有效负载的信息或可能会以其它某种方式对 DIME 解析器解析 DIME 消息有帮助的信息。

一个选项元素包含两个参数来描述其内容：类型和长度。这些参数的意义如下：

• 选项元素的类型指出该元素中携带的数据的结构和格式（请参阅第 3.2.11 节）。

• 选项元素的长度以八位元为单位指出该元素中携带的数据的大小（请参阅第 3.2.11 节）。

每个元素的结构和格式都是完全由选项元素类型决定的。这个规范并没有定义任何选项元素类型。DIME 选项元素是由 IANA 控制的集中方式定义的（关于 IANA 指南，请参阅第 6.2 节）

选项元素是按照每 DIME 记录为基础设置的。DIME 生成器可以为同一条 DIME 消息中的不同 DIME 记录生成不同的选项元素。对于 DIME 生成器来说，使不使用选项数据是可选的。

DIME 选项元素类型的定义是互相独立的；支持一种元素类型并不意味着支持其它元素类型。也就是说，能识别出选项元素 5 的 DIME 解析器可能识别不出类型 4 或 6。

遵守这个规范的 DIME 解析器可以但不必支持任何选项元素类型。DIME 解析器应该忽略无法识别的选项元素类型。

回页首

3. DIME 规范

3.1. 数据传输顺序

本文档中描述的 DIME 记录的传输顺序设定到八位元级。对于显示一组八位元的图表，那些八位元的传输顺序是先从左到右，然后再自上而下，正如英文的阅读顺序一样。例如，在图 2 的图表中，按照八位元的编号顺序对它们进行传输。

只要八位元表示的是一个数量，那么图表中最左边的位就是高阶位，或者说是最重要的位。也就是说，标号为 0 的位是最重要的位。

对于 DIME 定义的每个表示数量的多八位元字段，整个字段的最左边的位是最重要的位。这种数量以大尾数法的方式传输，先传最重要的八位元。

3.2. 记录布局

DIME 记录的长度可变，常用格式如图 3 所示。在下面几节中，将更详细地描述各个记录字段。

3.2.1. 版本

3.2.2. MB（消息开始）

3.2.3. ME（消息结束）

3.2.4. CF（块标志）

3.2.5. TYPE_T

必须在分块有效负载所使用的所有中间记录块和终止记录块中使用值 0x00（不变，Unchanged）（请参阅第 2.1.3 节）。它绝不可以用在任何其它记录中。在使用这个值时，TYPE_LENGTH 字段的值必须为零。

值 0x01（媒体类型，media-type）指出 TYPE 字段包含一个值，该值遵守 RFC 2616 [11] 定义的“media-type”BNF 构造（请参阅第2.3.2 节）。

值 0x02（绝对 URI，absoluteURI）指出 TYPE 字段包含一个值，该值遵守 CRF 2396 [10] 定义的“absoluteURI”BNF 构造（请参阅第2.3.2 节）。

值 0x03（未知，Unknown）应该被用来指出有效负载的类型是未知的。这与 MIME [7] 定义的“application/octet-stream”媒体类型相似。在使用这个值时，TYPE_LENGTH 字段的值必须为零。关于实现，“建议”接收这种类型 DIME 记录的 DIME 解析器提供一种机制来存储但不是处理这种有效负载（请参阅第 5 节）。

值 0x04(无，None）指出没有与这个记录相关的类型或有效负载。在使用这个值时，TYPE_LENGTH 和 DATA_LENGTH 字段的值必须为零。只要需要空记录，就可以使用这个 TYPE_T 值，例如，为终止一条 DIME 消息（在该消息中用户应用程序没有定义任何有效负载），就可以使用这个 TYPE_T 值。

TYPE_T 字段没有缺省值。保留的（Reserved）TYPE_T 字段值是供将来使用的，现在绝不可以使用。一个 DIME 解析器如果接收到一条带未知 TYPE_T 字段值的 DIME 记录，那么这个解析器应该把有效负载当作已经用值 0x03（未知）做了标记一样。注意：在这种情况下不要求 TYPE_LENGTH 为零。

3.2.6. RESRVD

3.2.7. OPTIONS_LENGTH

3.2.8. ID_LENGTH

3.2.9. TYPE_LENGTH

3.2.10. DATA_LENGTH

3.2.11. OPTIONS

所有的 DIME 记录都可以有一个非零的 OPTIONS 字段。DIME 解析器在接收到一条 DIME 记录，而该记录的选项元素类型无法识别时应该忽略该元素（请参阅第 6.2 节了解关于新选项元素类型的 IANA 注册指南）。

每个元素的长度不必一定是 4 个八位元的倍数，在元素间没有填充部分。但 OPTIONS 字段的大小必须是 4 个八位元的倍数。如果所有元素的长度之和不是 4 个八位元的倍数，那么生成器必须用全零八位元填充 OPTIONS 字段的值。填充部分不包括在 OPTIONS_LENGTH 字段中（请参阅第 3.2.7 节）。

DIME 生成器绝不可以用超过 3 个的八位元填充 OPTIONS 字段。DIME 解析器必须忽略填充的八位元。

3.2.12. ID

ID 字段的值是一个标识符，以 URI [10] 的形式出现（请参阅第 2.3.3 和 3.3 节）。消息标识符必需的唯一性由生成器来保证。这里的 URI 可以是相对 URI，也可以是绝对 URI；DIME 并不定义基本 URI，这意味着使用相对 URI 的用户应用程序必须提供一个实际的或虚拟的基本 URI（请参阅 [10]）。

除后续的记录块（请参阅第 2.1.3 节）外，所有的记录都可以有非零的 ID 字段。

ID 字段的长度必须是 4 个八位元的倍数。如果有效负载 id 值的长度不是 4 个八位元的倍数，那么生成器必须用全零八位元填充该值。填充部分并不包括在 ID_LENGTH 字段中（请参阅第 3.2.8 节）。

DIME 生成器绝不可以用超过 3 个的八位元填充 ID 字段。DIME 解析器必须忽略填充的八位元。

3.2.13. TYPE

3.2.14. DATA

3.3. 在 DIME 中使用 URI

DIME 使用 URI [10] 作为一些标识符。对于 DIME 来说，URI 只是一条格式化的字符串，它标识名称、位置或 Web 上的其它任何特定资源。

在 URI 中应该尽量避免使用 IP 地址（请参阅 RFC 1900 [5]）。但在 URI 中使用 IP 地址时，应该支持 RFC 2732 [15] 所描述的 URI 中的 Ipv6 地址的文字格式。

本规范并不提供任何适用于 URI 的等价规则，因为这些规则是由个别的 URI 模式和 RFC 2396 [10] 定义的。鉴于许多现行 URI 解析器中的某些 URI 等价规则存在不一致，所以，强烈推荐在进行 URI 匹配时只依赖于 RFC 2396 所定义的最基本的等价规则。

用作 ID 字段和 TYPE 字段中的值的 URI 的大小的最大值被限制为这些字段的最大大小（2^16-1 个八位元）。DIME 解析器和生成器必须能够处理这样大小的 URI。

回页首

4. 国际化注意事项

DIME 中用的标识符（比如 URI 和 MIME 媒体类型构造）提供对国际化的不同程度的支持。强烈推荐在 DIME 中使用这些值时遵循它们的国际化支持的定义和指南。尤其要特别注意下列字段：

• 关于 ID 字段，实现者可以参考 RFC 2718 [14] 了解 URI 的国际化注意事项。

• 关于 TYPE_T 值 0x01（媒体类型），实现者可以参考 RFC 2046 [7] 了解 MIME 媒体类型的国际化注意事项。

• 关于 TYPE_T 值 0x02（绝对 URI），实现者可以参考 RFC 2718 [14] 了解 URI 的国际化注意事项。

由于这个规范没有定义的 ELEMENT_T 值和 TYPE_T 值，实现者可以参考有关这些功能的文档来了解特定的国际化注意事项。

回页首

5. 安全性注意事项

实现者要特别注意任何记录类型的能够导致在接收方的环境中远程执行任何操作的安全性隐患。在接收任何类型的记录之前，应用程序都应该知道与该类型有关的特殊安全性隐患。

媒体类型的安全性注意事项通常是在 RFC 2048 [8] 以及“application/postscript”的上下文中讨论，而“message/external-body”媒体类型的安全性注意事项是在 RFC 2046 [7] 中讨论。

注意：本规范目前并没有定义为 DIME 消息和头信息提供安全性的任何机制。这个规范将来的修订本将解决这一尚未解决的问题。

回页首

6. IANA 注意事项

这个草案描述了一种新媒体类型“application/dime”，第 6.1 节包含了这种媒体类型的注册应用程序，这个应用程序遵守 RFC 2048 [8] 中的指南。

第 6.2 节包含附加的 DIME 选项（请参阅第 2.4 节）的定义及注册指导信息

6.1. 附加的 DIME 选项的定义和注册

媒体类型注册：application/dime

MIME 媒体类型名称：application

MIME 子类型名称：dime

所需参数：无

可选参数：无

编码注意事项：

这种媒体类型可以编码为适用于字符集并具有底层 MIME 传输的功能。对于 7 位传输，8 位或更多位的数据必须以 quoted-printable 或 base64 内容-传输-编码（content-transfer-encoding）的编码方式进行编码。对于纯 8 位传输（例如 8BITMIME [2] ESMTP [4] 或 NNTP [1]），不需要对 8 位数据（比如 UTF-8）进行编码。在 HTTP [11] 上，不管如何编码，都无需使用内容-传输-编码（content-transfer-encoding）

安全性注意事项：请参阅第 5 节

互操作性注意事项：无

已发布的规范：本规范

使用这种媒体类型的应用程序：

选择使用 DIME 作为打包机制，以便把一个或多个由应用程序定义的、任意类型和大小的有效负载封装到单个消息构造中的应用程序。

附加信息：无

幻数（Magic number）：无

文件扩展名：

.dim

.dime

Macintosh 文件类型代码：

DIME

能提供更多信息的人员和电子邮件地址：请参阅第 10 节

预期用途：

COMMON

作者／变化控制器：

DIME 规范是一个单独的因特网草案提议。它不是 IETF 工作组（IETF Working Group） 的产品。IETF 已经改变了对 DIME 规范的控制。

6.2. DIME 选项元素类型的注册指南

DIME 选项元素类型的注册过程遵守 RFC 2434 [11] 中定义的“IETF 共识”指南，在这个过程中通过 IETF 意见处理给 ELEMENT_T 赋值。具体说来，新的赋值是通过 IESG 认可的 RFC 进行。一般情况下，IESG 将从适当人员（例如，一个相关的工作组（如果存在的话））处收集可能的与赋值有关的输入。

下列过程用于确保新的 DIME 选项元素被查看，以保证其技术上的正确性和合适性，并保证在 IANA 为 ELEMENT_T 赋值之前已经完成并发布了它们的描述。

1. 作者对选项元素进行了归档，使 ELEMENT_T 的值仍处于“待定”（To Be Determined，TBD）状态。很重要的一点是解决了选项元素的安全性和国际化方面的问题。强烈建议将该文档作为因特网草案发布。

2. 作者提交了因特网草案以供 IESG 和所有相关的工作组（IETF 或其它组织）检查。

3. 新选项元素的规范由 IESG、IETF 和 2. 中标识的其它相关工作组来检查。如果选项元素被接受，可以包含在 DIME 规范内，那么这个选项的规范就可以作为标准化 RFC 或非标准化 RFC 发布。

4. 在作为 RFC 发布时，IANA 为新的选项元素赋予一个 DIME ELEMENT_T 值。在 IANA 为选项赋予一个 EMENT_T 值之前，该选项将不在已发布的实现中使用。

回页首

7. 知识产权

以下声明复制自 RFC 2026 [6] 的第 10.4 节，描述了 IETF 在涉及本文档的知识产权声明方面的立场。

IETF 不考虑任何关于知识产权或其他权利的有效性或适用范围的问题，这些权利可能被声明为附属于那些实现或使用本文档描述的其它技术，基于此产权声明的许可不是必须的。而且也无须表明为识别此声明做了什么努力。关于标准制定和标准相关的IETF版权声明过程的信息可以在 BCP-11中 找到。可以从 IETF 秘书处得到出版物的有效版权声明的副本和许可证书，还可以使用此详述的制定者和使用者的私人授权，以便得到通用的授权和许可。

IETF 邀请所有感兴趣的组织注意其版权、专利或专利应用、其它专有权利，它们可能需要使用这个标准的技术。请告知 IETF 执行董事会相关的信息。

回页首

8. 致谢

在此特别感谢 Cisco 公司的 Paul H. Gleichauf 和 Krishna Sankar 先生为这个规范所做出的贡献。

关于作者

		IBM has authored this article

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首