This is a last-call review as part of the ARTART review team, of the document draft-ietf-core-senml-data-ct-04.

This document describes an extension to RFC 8428 (SenML) to indicate the media type and content-coding.

It is mostly easy to understand, however there is a missing reference to one registry, and some phrases that may be confusing.

The missing registry is here: http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding (I found it by following normative references, however other similarly registered data fields in this document link to their registries, and could likewise be found by following references)

The document specifies `Content-Coding` as:

   Content-Coding:  a registered name for an encoding transformation
      that has been or can be applied to a representation.  Confusingly,
      in HTTP the Content-Coding is then given in a header field called
      "Content-Encoding"; we *never* use this term (except when we are
      in error).

I found this quite confusing, and it also comes across as very snarky and suggesting infighting.  I suggest removing the "except when we are in error" entirely.

I also found "has been or can be" is also confusing.  In the context of this document, I understood Content-Coding in a `ct` field to mean that said coding HAS BEEN applied to the value in `vd`, however this wording makes me question that assumption.

Maybe something like this is sufficient?

Content-Coding: a name registered in [IANA.content-coding] as specified by [RFC7230].  Confusingly, in HTTP the Content-Coding is found in a field called "Content-Encoding", however "Content-Coding" is the correct term.

The other confusing section was this in section 3:

  If no "@" sign is present outside the media type parameters, the Content-Coding is not specified and the "identity" Content-Coding is used --  no encoding transformation is employed.

"If no @ sign is present outside" is a really clunky turn of phrase that left me more confused than the examples!  I assume this construction was used because theoretically an '@' sign could be present inside the media-type, or inside a parameter, if correctly quoted.  I would suggest at least changing "present outside" to after, or trailing, or something.

Maybe this?

If no "@" sign is present after the media-type parameters, then no Content-Coding has been specified, and the "identity" Content-Coding is used -- no encoding transformation is employed.


Other than those two slightly confusing bits, great document - I enjoyed reading it and the intentions, purpose and use of this document are clear.