跳到主要内容

5. CBOR 的未来演进

成功的协议会随时间演进. 新的想法出现, 实现平台改进, 相关协议被开发并演进, 来自应用和协议的新需求被加入. 因此, 促进协议演进是任何协议开发中的一项重要设计考量.

对于将使用 CBOR 的协议, CBOR 提供了一些有用的机制来促进它们的演进. 这方面的最佳实践已为人熟知, 特别是来自基于 JSON 的协议开发中对 JSON 格式的实践. 因此, 这类最佳实践不在本规范的讨论范围之内.

然而, 促进 CBOR 自身的演进则完全在其范围之内. CBOR 的设计既为基于 CBOR 的协议开发提供稳定基础, 又使其自身能够演进.

由于一个成功的协议可能存续数十年, CBOR 需要为数十年的使用和演进而设计. 本节为 CBOR 的演进提供一些指导. 它必然比本文档的其他部分更具主观性. 它也必然是不完备的, 以免变成一本协议开发的教科书.

5.1. 扩展点​

在协议设计中, 演进的机会通常以扩展点的形式被包含进来. 例如, 可能存在一个从一开始就没有被完全分配的代码点空间, 而协议被设计成能够容忍并接纳那些开始使用比最初分配更多代码点的实现.

确定代码点空间的大小可能很困难, 因为所需的范围可能难以预测. 应当设法让代码点空间足够大, 以便它能在协议的预期生命周期内被缓慢填满.

CBOR 有三个主要扩展点:

  • "简单" 空间 (主类型 7 中的值). 在 24 个高效 (以及 224 个效率略低) 的值中, 只分配了很少一部分. 接收到未知简单数据项的实现, 在该值的结构确实简单的前提下, 可能仍能将其作为简单值来处理. 第 7.1 节中的 IANA 注册表是处理该代码点空间可扩展性的恰当方式.

  • "标签" 空间 (主类型 6 中的值). 同样, 该代码点空间只分配了很小一部分, 而空间是充裕的 (尽管靠前的数字比靠后的更高效). 接收到未知标签的实现可以选择直接忽略它, 或者把它当作一个包裹了后续数据项的未知标签来处理. 第 7.2 节中的 IANA 注册表是处理该代码点空间可扩展性的恰当方式.

  • "附加信息" 空间. 接收到未知附加信息值的实现无法继续解析, 因此为这个空间分配代码点是一个重大步骤. 而且剩余的代码点也非常少.

5.2. 管理附加信息空间​

人的心智有时会被吸引去填补一些被感知到的小空隙, 以便让事物变得整齐. 我们预计, 附加信息值代码点空间中剩余的空隙会成为一个吸引新想法的所在, 仅仅因为它们存在于那里.

本规范不通过 IANA 注册表来管理附加信息代码点空间. 相反, 从该空间中进行的分配只能通过更新本规范来完成.

对于 n >= 24 的附加信息值, 附加数据的大小通常为 2**(n-24) 字节. 因此, 附加信息值 28 和 29 应被视为 128 位和 256 位量的候选, 以备将来需要把它们加入协议. 于是, 附加信息值 30 就是唯一可供通用分配的附加信息值, 并且在通过本协议的更新来分配它之前, 应当有一个非常好的理由.