[Last-Call] Artart last call review of draft-ietf-httpapi-yaml-mediatypes-04

Barry Leiba via Datatracker <noreply@ietf.org> Tue, 28 March 2023 07:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC274C1522D9; Tue, 28 Mar 2023 00:41:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-httpapi-yaml-mediatypes.all@ietf.org, httpapi@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <167998930475.11274.11780573331917973954@ietfa.amsl.com>
Reply-To: Barry Leiba <barryleiba@computer.org>
Date: Tue, 28 Mar 2023 00:41:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/AxhIgzk2KPhu7lenX9p2q428uGM>
Subject: [Last-Call] Artart last call review of draft-ietf-httpapi-yaml-mediatypes-04
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2023 07:41:44 -0000

Reviewer: Barry Leiba
Review result: Ready with Nits

Thanks for this.  I have a few comments, but they're all very minor:

— Section 1.2.1

   If multiple nodes would match a fragment identifier, the first such
   match is selected.

I don’t know what “first” means here — alphabetically first, sequentially first
in a set, something else?  Is this clear enough for someone who actually uses
YAML, or can/should it be clarified?

— Section 2.1 —

   Optional parameters:  N/A; unrecognized parameters should be ignored

Maybe “unrecognized parameters are ignored” ?

— Section 2.2 —

   The suffix +yaml MAY be used with any media type whose representation
   follows that established for application/yaml.

This strikes me as a “may”, not a “MAY”.

   Fragment identifier considerations:  Differently from application/
      yaml, there is no fragment identification syntax defined for
      +yaml.

“Differently from” isn’t proper English here.  I think you want “Unlike”.

— Section 3.5 —

   Implementers need to consider that the YAML version and supported
   features (e.g. merge keys) can impact on the generation of the
   representation graph (see Figure 9).

The phrase “impact on” is non-standard English; please consider “affect”
instead.

— Section 4.2 —

   YAML documents are rooted, connected, directed graphs and can contain
   reference cycles, so they can't be treated as simple trees (see
   Section 3.2.1 of [YAML]).  An implementation that attempts to do that
   can infinite-loop traversing the YAML representation graph at some
   point, for example:

I find the antecedent to “do that” to be unclear, and using “infinite-loop” as
a verb seems odd.  I suggest this:

NEW
An implementation that treats them as simple trees risks going into an
infinite loop while traversing the YAML representation graph.  This
can happen:
END

— Section 5 —

   IANA has updated the "Media Types" registry at
   https://www.iana.org/assignments/media-types
   (https://www.iana.org/assignments/media-types) with the registration
   information provided below.

I presume the duplication of the URI is an artifact of the markup.  But IANA
has not, in fact, made these updates yet (I looked).  I suggest “IANA is asked
to update…”, and the RFC Editor will change this when they have confirmed that
IANA has taken the requested actions.  (This situation occurs twice in Section
5.)

--
Barry