IETF conflict review for draft-ucarion-json-type-definition
conflict-review-ucarion-json-type-definition-00

The following approval message was sent
From: The IESG
To: draft-ucarion-json-type-definition@ietf.org,
    rfc-ise@rfc-editor.org,
    Adrian Farrel
Cc: The IESG ,
    iana@iana.org,
    IETF-Announce
Subject: Results of IETF-conflict review for draft-ucarion-json-type-definition-03

The IESG has completed a review of draft-ucarion-json-type-definition-03
consistent with RFC5742.

The IESG has no problem with the publication of 'JSON Type Definition'
as an Experimental RFC.

The IESG has concluded that there is no conflict between this document and
IETF work.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-ucarion-json-type-definition/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-ucarion-json-type-definition/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
I have some fairly boring comments on the bits of the document that
I read with much attention to detail.

Section 1

  JTD is intentionally designed as a rather minimal schema language.
  Thus, although JTD can describe JSON, it is not able to describe its
  own structure: this document uses Concise Data Definition Language
  (CDDL) [RFC8610] to describe JTD's syntax.  By keeping the

In the Abstract we said that "JTD schemas [are] JSON documents".  The
claim here that JTD can describe JSON, combined with the one from the
abstract, seem to combine and lead a reader to conclude that JTD can
describe JTD schemas; perhaps the intent here is to note only that "JTD
can describe some categories of JSON" (but not all)?

  The principle of clear correspondence to common programming languages
  is why JTD does not support, for example, a data type for numbers up
  to 2**53-1.

nit: s/numbers/integers/

Section 1.1

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in
  BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
  capitals, as shown here.  These words may also appear in this
  document in lower case as plain English words, absent their normative
  meanings.

In the IETF stream we like the boilerplate just as it appears in RFC
8714, but as this is not the IETF stream you are free to do as you wish.

  The term "instance", when it appears in this document, refers to a
  JSON value being validated against a JTD schema.

Can this "value" range from an entire document to a single field?

Section 1.2

This is really nicely written; thank you!

Section 2.3

  Users SHOULD NOT expect metadata members to be understood by other
  parties.  As a result, if consistent validation with other parties is
  a requirement, users SHOULD NOT use metadata members to affect how
  schema validation, as described in Section 3, works.

Since the SHOULD NOT is already conditional on "consistent validation
with other parties is a requirement", perhaps MUST NOT makes more sense.

[Ballot comment]
There is work brewing on a JSON schema definition, coming from 3GPP.  I don't know the timeframe for forming a working group (I'm trying to get a better sense of that now), and it's not clear whether or not this proposal would fit into what they want to do.  The author is now aware of this and plans to watch for that working group and to participate, and the ISE is aware of it as well.

In any case, there isn't a reason for that brewing work to block publication of JTD (this document).  The ISE, the author, and I will work together on this to decide what the best way is for this to go forward -- likely through Independent stream publication, but possibly waiting to see whether such a working group could be a good fit instead.