Original text:
The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary <del> data values.  In order to simplify processing of the data values this document proposes to specify a new SenML field for indicating the Content-Format of the data. </del>  1. <del> The Sensor Measurement Lists (SenML) media type RFC8428 can be used </del>  to send various kinds of data.  In the example given in ex-1, a temperature value, an indication whether a lock is open, and a data value (with SenML field "vd") read from an NFC reader is sent in a not always be easily available to entities processing the SenML pack. To facilitate automatic interpretation it is useful to be able to indicate an Internet media type and content-coding right in the SenML <del> Record.  The CoAP Content-Format (Section 12.3 in RFC7252) provides just this information; enclosing a Content-Format number (in this case number 60 as defined for content-type application/cbor in RFC7049) in the Record is illustrated in ex-2.  All registered CoAP Content-Formats are listed in the Content-Formats subregistry of the CoRE Parameters registry IANA.core-parameters. In this example SenML Record the data value contains a string "foo" and a number 42 encoded in a CBOR RFC7049 array.  Since the example </del>  above uses the JSON format of SenML, the data value containing the <del> binary CBOR value is base64-encoded.  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor. </del>  2. 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>  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>  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>  <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>  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>  no encoding transformation is employed. 4. for the Content-Format Field (label "ct") within its range.  The range of the base field includes the Record containing it, up to (but not including) the next Record containing a "bct" field, if any, or <del> up to the end of the pack otherwise.  Resolution (Section 4.6 of RFC8428) of this base field is performed by adding its value with the label "ct" to all Records in this range that carry a "vd" field but do not already contain a Content-Format ("ct") field. </del>  5. 6.  The indication of a media type in the data does not exempt a consuming application from properly checking its inputs.  Also, the ability for an attacker to supply crafted SenML data that specify "decompression bombs", compressed data that is crafted to decompress to extremely large data items. <del> 7. </del>  (Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification and remove this note.) IANA is requested to assign new labels in the "SenML Labels" <del> subregistry of the SenML registry IANA.senml (as defined in RFC8428) </del>  for the Content-Format indication as per tbl-senml-reg:

Reviewer comments:
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

Revised text:
The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary  <ins> data values.  In order to simplify processing of the data values, this document proposes to specify a new SenML field for indicating the Content-Format of the data. </ins> 1.  <ins> The Sensor Measurement Lists (SenML) media types RFC8428 can be used </ins> to send various kinds of data.  In the example given in ex-1, a temperature value, an indication whether a lock is open, and a data value (with SenML field "vd") read from an NFC reader is sent in a not always be easily available to entities processing the SenML pack. To facilitate automatic interpretation it is useful to be able to indicate an Internet media type and content-coding right in the SenML  <ins> Record.  The CoAP Content-Format (RFC7252) provides just this information; 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-Formats are listed in the Content-Formats IANA.core-parameters of the CoRE Parameters registry IANA.core-parameters. 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 </ins> above uses the JSON format of SenML, the data value containing the  <ins> binary CBOR value is base64-encoded (RFC4648).  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor. </ins> 2. capitals, as shown here. Readers should also be familiar with the terms and concepts discussed  <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".  <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).  <ins> or a Content-Format-String containing a Content-Type and optionally a Content-Coding (see below). </ins>  <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-  <ins> Coding is not specified and the "identity" Content-Coding is used -- </ins> no encoding transformation is employed. 4. for the Content-Format Field (label "ct") within its range.  The range of the base field includes the Record containing it, up to (but not including) the next Record containing a "bct" field, if any, or  <ins> up to the end of the pack otherwise.  Resolution (RFC8428) of this base field is performed by adding its value with the label "ct" to all Records in this range that carry a "vd" field but do not already contain a Content-Format ("ct") field. </ins> 5. 6. <ins> This specification provides a formal definition of the syntax of Content-Format-Spec strings using ABNF notation RFC5234, which contains three new rules and a number of rules collected and adapted from various RFCs RFC7231 RFC6838 RFC5234 RFC8866. 7. </ins> The indication of a media type in the data does not exempt a consuming application from properly checking its inputs.  Also, the ability for an attacker to supply crafted SenML data that specify "decompression bombs", compressed data that is crafted to decompress to extremely large data items.  <ins> 8. </ins> (Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification and remove this note.) IANA is requested to assign new labels in the "SenML Labels"  <ins> IANA.senml of the SenML registry IANA.senml (as defined in RFC8428) </ins> for the Content-Format indication as per tbl-senml-reg: