I strongly object to this. This document describes a specific way to extract information from a json object. The use case is another standard that needs to do that. That document needs a reference to a specific way to extract the information which will be implemented interoperably by many entities. There isn’t any way to claim that the specific way to extract the data isn’t a standard. That has nothing to do with json parsers. Surely, we may some day have to update the jsonpath spec. The corresponding xpath spec (for which these is a standard, albeit not an IETF standard) has changed some. But it would change slowly, because we need interoperable implementations. You might have made an argument that IETF is the wrong body (I don’t agree), but to say that this isn’t a standard is, in my opinion, just flat wrong. Further, the use of a media type to hold a jsonpath expression is entirely appropriate, and the creation of a registry to hold extensions is common in standards like this (or even, if we had to, a non-standards-track RFC). Brian > On Aug 10, 2023, at 2:18 PM, Linda Dunbar via Datatracker <noreply@xxxxxxxx> 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. > However, like any software programs, errors can be encountered at run time even > after careful review. > > 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. 2. Like SQL, this document specified > syntax may change as more ways being developed by implementers to parse the > JSON objects. 3. It is not clear why IANA registration is needed. > > Minor issues: > > Nits/editorial comments: > > Thanks, Linda Dunbar > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
