**Session Date/Time:** 18 Oct 2022 08:00

# [JSONPATH](../wg/jsonpath.html)

## Summary

This interim meeting focused on two main areas: progressing the I-JSONPATH (draft-ietf-jsonpath-iregexp) document to Working Group Last Call (WGLC), and reviewing open issues for the main JSONPath base draft (draft-ietf-jsonpath-base). Key decisions included launching the WGLC for I-JSONPATH and deferring the JSONPath branding discussion. Several issues for the main draft were addressed, with action items assigned for pull requests and further review.

## Key Discussion Points

*   **Agenda Setting:** The proposed agenda to address the I-JSONPATH draft first, followed by outstanding issues on the main draft, was adopted.
*   **I-JSONPATH (draft-ietf-jsonpath-iregexp):**
    *   Version 02 has been posted, incorporating changes from the shepherd review.
    *   The document is deemed ready for Working Group Last Call (WGLC). It is expected that feedback during WGLC will likely lead to an 03 version.
    *   The I-JSONPATH specification was noted as potentially useful for JSON Schema, which currently uses ECMAScript 262 for regular expressions, leading to compatibility issues in some language environments. A proposal to migrate JSON Schema to I-JSONPATH was mentioned.
    *   **Decision:** The working group will proceed with launching a Working Group Last Call for the `draft-ietf-jsonpath-iregexp` document.
*   **Main Draft (draft-ietf-jsonpath-base):**
    *   The current authoritative version is 07. A brief discussion clarified the relationship between the editor's draft in the repository and the officially submitted Internet-Draft, noting minor formatting differences due to template settings.
    *   **Open Issues Review:**
        *   **Issue 227 (JSONPath Branding Proposal):** Discussion centered on whether a logo should be keyboardable, its placement (external to the RFC, likely repo README or WG website), and general IETF practices for logos (e.g., QUIC). The general sentiment was that while building a community is important, the immediate focus should be on the technical specification.
            *   **Decision:** Defer this issue to be revisited "after base done" and close it for now to focus on the spec.
        *   **Issue 265 (Order of Results):** The current spec is considered correct regarding result order. It was suggested to add an editorial note advising implementers that applications relying on the exact sequence of results might be less interoperable.
            *   **Decision:** An editorial note will be added to the spec regarding interoperability for clients relying on the exact sequence of results.
        *   **Issues 260 and 252:** These issues are addressed by in-flight Pull Requests (PRs) assigned to Glenn. They are nearing merge, and no further discussion was required at this time.
        *   **Issue 195 (Non-singular Paths in Filter Expressions):**
            *   Carsten expressed support for allowing non-singular paths in existence tests within filter expressions (e.g., `$.foo[?(@.bar)]`).
            *   A potential counter-argument was noted: it could introduce user confusion if some path contexts within filter expressions require singular paths while others permit non-singular ones.
            *   There was a sense of those present that allowing non-singular paths in existence tests is a useful feature and does not constitute an egregious departure from current field support.
            *   **Decision:** The WG will proceed with allowing non-singular paths in filter expressions for existence tests. The spec language must explicitly call out the difference in behavior for users regarding singular vs. non-singular path requirements in different contexts.
        *   **Issue 203 (and related 160, 154, 194) (Extension Points):** These issues, all related to extension points, are assigned to Carsten, who is preparing a full proposal following recent merges. Discussion will resume once the proposal is ready. The general consensus is that the function syntax in filter expressions is the likely direction.
        *   **Issue 151 (Administrative issue):** This issue will be deferred until the base draft is complete.
*   **Post-Merge Review:** Participants were encouraged to re-read the entire document after the recent large merge to ensure no unintended changes or regressions.
*   **Tooling/Links:** A brief discussion on build warnings and ensuring internal links are correct and robust was held, with a note that current issues seem resolved.

## Decisions and Action Items

*   **Decision:** Launch Working Group Last Call (WGLC) for `draft-ietf-jsonpath-iregexp`.
    *   **Action Item:** James (Shepherd) to initiate the WGLC after this call.
*   **Decision:** Issue 227 (JSONPath Branding Proposal) is deferred and closed for now, with focus remaining on the technical spec.
*   **Decision:** An editorial change will be made to add a note about interoperability for clients relying on the exact sequence of results (Issue 265).
*   **Action Item:** Glenn to create a Pull Request (PR) to incorporate the change allowing non-singular paths in existence tests within filter expressions, including explicit language about the different path type requirements (Issue 195).
*   **Action Item:** Glenn to add test cases for non-singular paths in filter expressions to the comparison project (Issue 195).
*   **Action Item:** Carsten to complete and submit a proposal for extension points in the main draft, building on the consensus around function syntax primarily within filter expressions (Issue 203 and related).
*   **Action Item:** All active participants to conduct a full review of the document following recent large merges to identify any issues.

## Next Steps

*   Complete and merge outstanding Pull Requests for issues 260 and 252.
*   Submit the extension point proposal.
*   Hold a subsequent interim meeting, potentially in late November (avoiding the week of Nov 21st for Thanksgiving), to discuss the extension point proposal.
*   Continue general document review in preparation for eventual WGLC for the main draft.