Re: [Gen-art] Genart last call review of draft-ietf-jsonpath-base-17

["Murray S. Kucherawy" <[e-mail]>]

I'm also quite puzzled by this review.

On Thu, Aug 10, 2023 at 11:18 AM Linda Dunbar via Datatracker <
[e-mail]> wrote:

> Major issues:
> The major issue is that this document should not be “Standard Track”
> because:
> 1.      Existing parsers for JSON data don’t need to change to comply with
> the
> syntax specified in this document.


I don't understand this claim.  If I'm parsing it correctly, since this
document doesn't demand changes to JSON parsers, this is not worthy of
standardization.  Is that correct?

JSON is a syntax used to describe (serialize) a certain class of objects.
Those objects are trees whose nodes are numbers, strings, nulls, booleans,
lists of nodes, or key-value pairs of nodes.  This specification presents a
syntax for describing a path to follow from the root of such a tree to a
node in that tree and returning what's there.  It is appropriate for
standardization so that producers and consumers of JSON paths can agree on
what exactly they mean and how they are to be interpreted.

If we used something else to serialize the tree, rather than JSON, we would
still have trees we want to walk through to get values.  I would argue that
JSONpath would still be valuable -- though by some other name, probably --
even if JSON didn't exist.  So I don't understand the assertion being made
here.


> 2.      Like SQL, this document specified
> syntax may change as more ways being developed by implementers to parse the
> JSON objects.


I'm unclear on this as well.  The presence of possible future syntaxes, or
changes to this one, doesn't render this unworthy of standardization,
especially given the well-established nature of this work and its need for
interoperability outside of private environments.


> 3.      It is not clear why IANA registration is needed.
>

>From the abstract of RFC 8126:

   Many protocols make use of points of extensibility that use constants
   to identify various protocol parameters.  To ensure that the values
   in these fields do not have conflicting uses and to promote
   interoperability, their allocations are often coordinated by a
   central record keeper.

Seems like a bullseye to me.

-MSK