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

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.

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.