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 <nore...@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 > jsonp...@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
