Skip to main content

Last Call Review of draft-ietf-core-senml-data-ct-04
review-ietf-core-senml-data-ct-04-artart-lc-gondwana-2021-08-25-00

Request Review of draft-ietf-core-senml-data-ct
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2021-09-06
Requested 2021-08-23
Authors Ari Keränen , Carsten Bormann
I-D last updated 2021-08-25
Completed reviews Artart Last Call review of -04 by Bron Gondwana (diff)
Genart Last Call review of -04 by Christer Holmberg (diff)
Assignment Reviewer Bron Gondwana
State Completed
Request Last Call review on draft-ietf-core-senml-data-ct by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/IrTMlRnHlRAN9OD_gx6EJXzU_14
Reviewed revision 04 (document currently at 07)
Result Ready w/nits
Completed 2021-08-25
review-ietf-core-senml-data-ct-04-artart-lc-gondwana-2021-08-25-00
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.