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

Hi Linda

Thanks for your review. Detailed responses inline.

As for the need for a standard, I think the WG Charter makes that clear:

"JSONPath was originally described by Stefan Goessner [...] but has never
had an official specification of any kind, and the 39+
implementations, while mostly compatible, differ in certain behaviors."

Regards,
Glyn

On Thu, 10 Aug 2023 at 19:19, Linda Dunbar via Datatracker <noreply@ietf.org>
wrote:

> Reviewer: Linda Dunbar
> Review result: Not Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>
> Document: draft-ietf-jsonpath-base-17
> Reviewer: Linda Dunbar
> Review Date: 2023-08-10
> IETF LC End Date: 2023-08-09
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> The document specifies a method to parse the JSON objects to get values and
> specifies the syntax to retrieve a list of values. The document reads well.
>

Actually, the document does not specify how JSON documents are parsed, in
the sense of producing a syntax tree from a JSON document.

> However, like any software programs, errors can be encountered at run time
> even
> after careful review.
>

Section 2.1 of the document acknowledges that run time errors can occur,
e.g. because of resource depletion. As for bugs in implementations: those
need not concern the specification.

>
> 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 point. JSONPath is query support strictly layered
on top of JSON parsing.

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

I don't understand this point either as it addresses JSON parsing rather
than a query layer.

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

Because, as we have seen in the WG, the five function extensions defined by
the document will need to be augmented. It is normal in such situations to
use IANA registration.

>
> Minor issues:
>
> Nits/editorial comments:
>
> Thanks, Linda Dunbar
>
>
> --
> JSONpath mailing list
> JSONpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath
>