Change:
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> <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 <del> optionally a Content-Coding (see below). </del> <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 <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> <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 <del> no Content-Coding has been specified, and the "identity" Content- Coding is used -- no encoding transformation is employed. </del> <ins> no content coding has been specified, and the "identity" content coding is used -- no encoding transformation is employed. </ins> 4.

Discussion:
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