Original text:
types of values, from numbers to text strings and arbitrary binary data values.  In order to facilitate processing of binary data values, this document specifies a pair of new SenML fields for <del> indicating the Content-Format of those binary data values, i.e., their Internet media type including parameters as well as any Content-Coding applied. </del>  1. out-of-band knowledge of the application.  However, this context may not always be easily available to entities processing the SenML pack. To facilitate automatic interpretation it is useful to be able to <del> indicate an Internet media type and content-coding right in the SenML Record.  The CoAP Content-Format (RFC7252) provides this information in the form of a single unsigned integer; enclosing a Content-Format number (in this case number 60 as defined for content-type application/cbor in RFC8949) in the Record is illustrated in ex-2. All registered CoAP Content-Format numbers are listed in the IANA.core-parameters IANA.core-parameters as specified by RFC7252. </del>  In this example SenML Record, the data value contains a string "foo" and a number 42 encoded in a CBOR RFC8949 array.  Since the example MAY also include a Content-Format indication field, using label "ct". The value of this field is a Content-Format-Spec, i.e., one of: <del> a CoAP Content-Format identifier in decimal form with no leading zeros (except for the value "0" itself).  This value represents an </del>  unsigned integer in the range of 0-65535, similar to the CoRE Link Format RFC6690 "ct" attribute). or a Content-Format-String containing a Content-Type and <del> optionally a Content-Coding (see below). </del>  The syntax of this field is formally defined in abnf. The CoAP Content-Format number provides a simple and efficient way to indicate the type of the data.  Since some Internet media types and their content coding and parameter alternatives do not have assigned <del> CoAP Content-Format numbers, using Content-Type and Content-Coding is also allowed.  Both methods use a string value in the "ct" field to keep its data type consistent across uses.  When the "ct" field contains only digits, it is interpreted as a CoAP Content-Format identifier. To indicate that a Content-Coding is used with a Content-Type, the Content-Coding value is appended to the Content-Type value (media type and parameters, if any), separated by a "@" sign.  For example (using a Content-Coding value of "deflate" as defined in RFC7230): </del>  If no "@" sign is present after the media type and parameters, then <del> no Content-Coding has been specified, and the "identity" Content- Coding is used -- no encoding transformation is employed. </del>  4. The following examples are valid values for the "ct" and "bct" fields (explanation/comments in parentheses): <del> "60" (CoAP Content-Format for "application/cbor") </del>  <del> "0" (CoAP Content-Format for "text/plain" with parameter </del>  "charset=utf-8") "application/json" (JSON Content-Type - equivalent to "50" CoAP <del> Content-Format identifier) </del>  "application/json@deflate" (JSON Content-Type with "deflate" as <del> Content-Coding - equivalent to "11050" CoAP Content-Format identifier) </del>  "text/csv" (Comma-Separated Values (CSV) RFC4180 Content-Type) "text/csv;header=present@gzip" (CSV with header row, using "gzip" <del> as Content-Coding) </del>  6.

Reviewer comments:
Address Ben Kaduk's DISCUSS by allowing multiple content codings. Use the opportunity to also address Christer Holmberg's comment that Ben offered some sympathy to -- but staying with the (now lower case) term "content format".
On 2020-08-19, at 04:29, Jim Schaad wrote: (Archived-At: ) Right, this would be what you easily get if you do a “naïve” resolution of “bct" base fields. (However, Section 4 says that you only copy them to records with “vd” fields.) I think that it would be good to do the same thing with “naïve” resolution, i.e., ignore “ct” if there is no “vd”. But I don’t have a strong opinion. Section 3 says: When a SenML Record contains a Data Value field ("vd"), the Record MAY also include a Content-Format indication field. In logic, it simply doesn’t say anything about records without “vd”. In English, it does seem to imply that the MAY does not apply to them. (But then it doesn’t say what is supposed to happen.)
I believe this is now covered by the text in Section 4. For the most part it looks good. However, I am not sure that I understand what the correct behavior for {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","vs":"7.1","ct":"0"} {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1,"ct":"0"} Should the ct be ignored if the value is not "vd"? If it is present but does not make sense what should happen? Jim

Revised text:
types of values, from numbers to text strings and arbitrary binary data values.  In order to facilitate processing of binary data values, this document specifies a pair of new SenML fields for  <ins> indicating the content format of those binary data values, i.e., their Internet media type including parameters as well as any content codings applied. </ins> 1. out-of-band knowledge of the application.  However, this context may not always be easily available to entities processing the SenML pack. To facilitate automatic interpretation it is useful to be able to  <ins> indicate an Internet media type and, optionally, content codings right in the SenML Record. The CoAP Content-Format (RFC7252) provides this information in the form of a single unsigned integer; enclosing a Content-Format number (in this case number 60 as defined for content-type application/cbor in RFC8949) in the Record is illustrated in ex-2.  All registered CoAP Content-Format numbers are listed in the IANA.core-parameters IANA.core-parameters as specified by RFC7252.  Note that, at the time of writing, the structure of this registry only provides for zero or one content codings; nothing in the present document needs to change if the registry is extended to allow sequences of content codings. </ins> In this example SenML Record, the data value contains a string "foo" and a number 42 encoded in a CBOR RFC8949 array.  Since the example MAY also include a Content-Format indication field, using label "ct". The value of this field is a Content-Format-Spec, i.e., one of:  <ins> a CoAP Content-Format number in decimal form with no leading zeros (except for the value "0" itself).  This value represents an </ins> unsigned integer in the range of 0-65535, similar to the CoRE Link Format RFC6690 "ct" attribute). or a Content-Format-String containing a Content-Type and  <ins> optionally zero or more content codings (see below). </ins> The syntax of this field is formally defined in abnf. The CoAP Content-Format number provides a simple and efficient way to indicate the type of the data.  Since some Internet media types and their content coding and parameter alternatives do not have assigned  <ins> CoAP Content-Format numbers, using Content-Type and zero or more content codings is also allowed.  Both methods use a string value in the "ct" field to keep its data type consistent across uses.  When the "ct" field contains only digits, it is interpreted as a CoAP Content-Format number. To indicate that one or more content codings are used with a Content- Type, each of the content coding values is appended to the Content- Type value (media type and parameters, if any), separated by a "@" sign, in the order of the content codings were applied (the same order as in RFC7231).  For example (using a content coding value of "deflate" as defined in RFC7230): </ins> If no "@" sign is present after the media type and parameters, then  <ins> no content coding has been specified, and the "identity" content coding is used -- no encoding transformation is employed. </ins> 4. The following examples are valid values for the "ct" and "bct" fields (explanation/comments in parentheses):  <ins> "60" (CoAP Content-Format number for "application/cbor") </ins>  <ins> "0" (CoAP Content-Format number for "text/plain" with parameter </ins> "charset=utf-8") "application/json" (JSON Content-Type - equivalent to "50" CoAP  <ins> Content-Format number) </ins> "application/json@deflate" (JSON Content-Type with "deflate" as  <ins> content coding - equivalent to "11050" CoAP Content-Format number) "application/json@deflate@aes128gcm" (JSON Content-Type with "deflate" followed by "aes128gcm" as content codings) </ins> "text/csv" (Comma-Separated Values (CSV) RFC4180 Content-Type) "text/csv;header=present@gzip" (CSV with header row, using "gzip"  <ins> as content coding) </ins> 6.