12.3 CoAP内容格式注册(CoAP Cotent-Formats Registry)
互联网媒体类型被定义成一个字符串,例如“application/xml”[RFC2046]。为了最小化使用这些媒体类型表示格式所带来的payload开销,这篇文档为互联网媒体类型子集定义了一个sub-registry,这些子集在CoAP中使用,并且每个都分配好,和content-coding合并,有数字标识。这个sub-registry的名字是“CoAP Content-Formats”,在“CoRE Parameters”表里面。
每次进入到sub-registry必须包含这些IANA注册过的媒体类型,用于定义CoAP中的媒体类型数字的范围是0-65535,cotent-coding和这些定义相关,一个文档参考描述了payload和媒体类型的表达语义。
CoAP不包括用分离的方式来转移content-encoding信息和请求或响应,因为content-encoding每一个标识符也是特定的。如果多种content-encodings和媒体类型一起使用,然后每一个分离的content-format标识符将会被注册。相似的,其他参数和互联网媒体类型关联,比如level,也能被定义为CoAP Content-Format条目。
初始化进入这个sub-registry如下:
65000~65535之间所包含的标识符是预留用于实验。他们不是给赞助商使用,也禁止用于操作部署。256~9999之间的标识符预留是用于未来IETF规格(IETF Review or IESG Approval)。所有其他标识符都尚未安排。
由于一个字节标识符的命名空间非常小,IANA政策对于sub-registry未来额外的定义在0~255范围,是“Expert Review”描述在[RFC5226]。IANA政策对于额外的定义在1000-64999包含了“First Come First Served”,描述在[RFC5226]。总结在下表中。
在M2M的应用中,不希望这些常用的媒体类型,比如text/plain,application/xml或者application/octet-stream在实际应用中长期有效。推荐M2M的应用中使用CoAP请求新的互联网媒体类型,这些媒体类型来自于IANA表明的语义,该语义信息规定了如何创建和理解一个payload。举个例子,一个智能的payload携带的一个XML,可能请求一个更特定的类型,比如application/se+xml或者application/se-exi。
最后更新于
这有帮助吗?