Change:
capitals, as shown here. Readers should also be familiar with the terms and concepts discussed <del> in RFC8428.  Awareness of terminology issues discussed in I- D.bormann-core-media-content-type-format can also be very helpful. </del> <ins> in RFC8428. </ins> 3. When a SenML Record contains a Data Value field ("vd"), the Record MAY also include a Content-Format indication field, using label "ct". <del> The value of this field is a string value, one of: </del> <ins> The value of this field is a Content-Format-Spec, i.e., one of: </ins> a CoAP Content-Format identifier in decimal form with no leading zeros (except for the value "0" itself).  This value represents an unsigned integer in the range of 0-65535, similar to the CoRE Link Format RFC6690 "ct" attribute). <del> or a Content-Format-String I-D.bormann-core-media-content-type- format containing a Content-Type and optionally a Content-Coding (see below). </del> <ins> or a Content-Format-String containing a Content-Type and optionally a Content-Coding (see below). </ins> <del> The CoAP Content-Format identifier 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 CoAP Content-Format identifiers, 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. </del> <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 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. </ins> To indicate that a Content-Coding is used with a Content-Type, the Content-Coding value (e.g., "deflate" RFC7230) is appended to the Content-Type value (media type and parameters, if any), separated by a "@" sign.  For example: "text/plain; charset=utf-8@deflate".  If no "@" sign is present outside the media type parameters, the Content- <del> Coding is not specified and the "identity" Content-Coding is used - </del> <ins> Coding is not specified and the "identity" Content-Coding is used -- </ins> no encoding transformation is employed. 4.

Discussion:
Alexey notes (Archived-At: ): Since data-ct needs almost all of the “normative” ABNF in media-content-type-format, I think the right thing to do would be to fully develop media-content-type-format and make it a normative reference. (Note that media-content-type-format probably needs to be run by httpbis and emailcore [?] soon and when it is nearing WGLC, and there may be surprises there.) This course of action would probably delay data-ct a bit; we might counteract the damage by early registration. Since data-ct only needs an “Expert Review” registration, we could decide to do this when we have processed the reviews that are now incoming.
I didn't do thorough review of the ABNF but otherwise looks good to me Hi all, Sorry for the belated review. I think the document is nearly ready for progression. I have a couple of minor related issues: Terminology Readers should also be familiar with the terms and concepts discussed in [RFC8428]. Awareness of terminology issues discussed in [I-D.bormann-core-media-content-type-format] can also be very It is expired and it is currently not a WG document. At minimum it should be revived. (Or see below) helpful. SenML Content-Format ("ct") Field I wish the document has ABNF for the "ct" field. If you want to use ABNF from draft-bormann-core-media-content-type-format-01, it should be Normative reference. If not, I think you should just cut & paste the ABNF into this document. Best Regards, Alexey