CBOR Tags for CoAP Content Formats

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 December 2021.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

[RFC8949] defines a number of CBOR Tags for common items.¶

Often, there is a need to identify a media type (or content type, i.e., media type optionally used with parameters) for a byte string in a CBOR data item.¶

[RFC7252] defines the concept of a Content-Format, which is a short 16-bit unsigned integer that identifies a specific content type, optionally together with a content encoding.¶

This short specification allocates tag numbers 1668546560 (0x63740000) to 1668612095 (0x6374FFFF) for the tagging of representations of specific content formats. The tag content tagged with tag number NNNN (in above range) is a byte string that is to be interpreted as a representation of the content format NNNN-1668546560.¶

2. Examples

[IANA.core-parameters] defines content formats that can be used as examples:¶

• Content-Format 432 stands for media type application/td+json (no parameters). The corresponding tag number is 1668546992 (i.e., 1668546560+432).¶

  So the following CDDL snippet can be used to identify application/td+json representations:¶

  td-json = #6.1668546992(bstr)
  

  ¶

  Note that a byte string is used as the type of the tag content, as a media type representation in general can be any byte string.¶

• Content-Format 11050 stands for media type application/json in deflate encoding.¶

  The corresponding tag number is 1668557610 (i.e., 1668546560+11050).¶

  So the following CDDL snippet can be used to identify application/json representations compressed in deflate encoding:¶

  json-deflate = #6.1668546992(bstr)
  

  ¶

  The byte string as the type for the tag content is appropriate here as the compressed form is an instance of a general byte string.¶

3. IANA Considerations

IANA is requested to allocate the tag numbers 1668546560 (0x63740000) to 1668612095 (0x6374FFFF) as follows:¶

Data Item: byte string
Semantics: representation of content-format (RFC7252) NNNN-1668546560

Acknowledgements

Michael Richardson prompted us to finally write this up.¶

Author's Address