Markdown Version | Session Recording

Session Date/Time: 18 Jan 2022 10:00

JSONPATH

Summary

This interim meeting focused on reducing the number of open issues for the JSONPath base document and addressing key technical points to prepare for Working Group Last Call (WGLC). Significant progress was reported on issue closure, leaving a more manageable set of tasks. Key discussions included the handling of absent values in comparisons, the adoption of a modest regular expression subset via a separate document, the importance of examples, security considerations, and the treatment of duplicates in result node lists. The working group also discussed the timeline for WGLC and future meetings.

Key Discussion Points

• Issue Management:
  • The editor (Carsten Bormann) reported closing 25 issues, reducing the open count to 12. Many closed issues were marked for "revisit after base" as they pertain to features not in the core document.
  • Greg asked for issues, particularly those marked "revisit after base," to remain open to preserve discussion history. The editor stated that this approach confuses current work and that labels suffice for tracking.
  • A sense of those present indicated a preference for closing issues deemed not critical to the base document, to be reopened once the base document is stable.
• Absent Equals Absent (absent=absent):
  • Discussion centered on whether two non-existent (absent) values should compare as equal (like undefined == undefined in some contexts) or not equal (like NaN != NaN in IEEE 754 arithmetic).
  • Arguments for absent=absent being true (undefined style): aligns with common programming language behavior for null/undefined comparisons, useful for handling default values in JSON where properties might be omitted.
  • Arguments for absent=absent being false (NaN style): avoids counter-intuitive outcomes where non-existent items are considered equal.
  • A poll of the room indicated a leaning towards the "undefined" style (i.e., absent=absent is true).
  • The need for clear examples illustrating this behavior was emphasized.
• Regular Expressions:
  • The working group acknowledged the lack of consensus among implementations for a specific regex flavor, necessitating a WG decision.
  • A proposal was made to define a "modest subset" of regular expressions, aiming for maximum interoperability.
  • There was a strong leaning towards developing this subset in a separate document (IRegex), which could also be used by other IETF working groups (e.g., JSON Schema).
  • Discussion on IRegex content included Unicode character classes (\p) and the decision to be explicit about supported features, favoring interoperability over complexity.
  • The embedding syntax for regex within JSONPath (standard string vs. /.../ slashes) was raised as an open issue, with a preference for standard string syntax to avoid "false interoperability."
• Examples:
  • There was a strong call for more comprehensive examples in an appendix, demonstrating the behavior of various JSONPath expressions, particularly for nuanced cases like absent=absent and duplicate results.
  • Working group members were encouraged to contribute examples via GitHub issues, specifying the JSON document, JSONPath expression, and expected result.
• JSON Pointer Comparison:
  • The document needs a section clarifying the differences between JSONPath and JSON Pointer. This is important due to common confusion between the two.
• Web of Things Requirements (Issue 55):
  • A year-old review from the W3C Web of Things project was discussed. The requirements seemed largely orthogonal to JSONPath's core functionality (e.g., embedding JSONPath in URLs). It was decided to seek a refresh of their review at WGLC.
• Security Considerations:
  • Initial thoughts for this section included denial of service attacks (maliciously crafted, deeply nested, or large JSONPath expressions) and regular expression vulnerabilities.
  • It was suggested that implementations should be explicitly allowed to impose limits (e.g., nesting depth, total path size), and that such limits should ideally be detectable at "parse time" (e.g., well-formedness checks) to avoid runtime failures.
• Duplicates in Node Lists:
  • The current document implicitly allows duplicates in result node lists (using "node list" rather than "node set").
  • Arguments were made for:
    • Explicitly stating that duplicates are not removed (minimalism, user intent).
    • Having an option or explicit syntax for duplicate removal (like SELECT DISTINCT in SQL).
    • Implementers optimizing internally (e.g., memoization) without changing the specified output.
  • The sense of the group leaned towards minimalism: not automatically removing duplicates in the base specification, but emphasizing the need for examples to make this behavior clear.
• "Union" Terminology (Issue 21):
  • The term "union" in the context of selectors ([a, b]) was identified as potentially confusing due to its set theory implications.
  • A replacement term, "list selector" or "selector list," was discussed, with a preference for "list selector" as it aligns with the document's structure of defining types of selectors.
• ABNF Auto-check:
  • An issue proposing an automatic commit check for ABNF validation was deemed a "won't fix" due to minimal perceived value and not wanting to waste time on it.

Decisions and Action Items

• Issue Management: Issues marked "revisit after base" will be formally reopened when the JSONPath base document is handed off to the IESG.
• Absent Equals Absent: The working group will proceed with the understanding that comparing two absent values (empty node lists) results in true, similar to undefined == undefined behavior. This will be confirmed on the mailing list.
• Examples: Add specific examples to the document's example section illustrating the absent=absent behavior.
• Regular Expressions:
  • The working group confirms the path forward to define a modest subset of regular expressions in a separate iregex document.
  • ACTION: Chairs to initiate a formal call for adoption of draft-bormann-jsonpath-iregex-02 (or the latest version) as a JSONPATH working group document.
  • ACTION: Discuss specifics of iregex content (e.g., Unicode \p support, embedding syntax) on the mailing list.
• Examples:
  • ACTION: Working group members are requested to contribute JSONPath examples (JSON document, JSONPath expression, expected result) by opening GitHub issues. Emphasis on examples for absent=absent and duplicate handling.
• JSON Pointer Comparison: Add text to the document explaining the differences and relationship between JSONPath and JSON Pointer.
• Web of Things Requirements (Issue 55): Revisit and seek refreshed review from the W3C Web of Things project at the Working Group Last Call stage.
• Security Considerations:
  • ACTION: Write a security considerations section covering denial of service risks (deep nesting, large paths, regex), implementation limits (detectable at parse time), and handling of unique characters (e.g., null characters).
• Duplicates in Node Lists: The document will explicitly state that duplicate nodes are not removed by default, aligning with a "minimalist" approach.
  • ACTION: Add examples to the document to clearly illustrate scenarios where duplicate nodes can appear in results.
• "Union" Terminology (Issue 21):
  • ACTION: Carsten Bormann to propose a Pull Request (PR) to rename "union" to "list selector" (or similar preferred term) within the document.
• ABNF Auto-check: Close the issue related to ABNF commit checks as "won't fix."
• Working Group Last Call (WGLC): Aim for WGLC for both the JSONPath and iregex documents by early February.

Next Steps

1. Draft Adoption: Chairs to issue a formal Call for Adoption for the iregex document.
2. Document Updates: The editors and contributors will work on the action items listed above, including adding examples, clarifying JSON Pointer differences, writing the security considerations section, and updating terminology.
3. WGLC Preparation: Once outstanding action items are addressed and integrated into the drafts, the working group will prepare for Working Group Last Call, aiming for early February. Both JSONPath and iregex drafts are expected to enter WGLC simultaneously.
4. Next Interim Meeting:
   • ACTION: Chairs to send out a poll to determine the best date for an interim meeting in late February / early March (before the IETF 113 draft submission deadline on March 7th) to discuss the WGLC status and any emerging issues.
   • It is anticipated that IETF 113 in Vienna (March) will be largely an online affair for the working group, and an interim meeting prior is preferred.