[core] Artart last call review of draft-ietf-core-senml-data-ct-04

Bron Gondwana via Datatracker <noreply@ietf.org> Wed, 25 August 2021 13:30 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF023A0879; Wed, 25 Aug 2021 06:30:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Bron Gondwana via Datatracker <noreply@ietf.org>
To: <art@ietf.org>
Cc: core@ietf.org, draft-ietf-core-senml-data-ct.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162989820511.22802.13018106629607951033@ietfa.amsl.com>
Reply-To: Bron Gondwana <brong@fastmailteam.com>
Date: Wed, 25 Aug 2021 06:30:05 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/WR6F3Kfosgn6PUdFbCQdGYky-G8>
Subject: [core] Artart last call review of draft-ietf-core-senml-data-ct-04
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2021 13:30:14 -0000

Reviewer: Bron Gondwana
Review result: Ready with Nits

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.