Roman Danyliw has entered the following ballot position for draft-ietf-regext-rdap-sorting-and-paging-17: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Canonical Reference for JSONPath. Section 2.1/2.3.1 describes field(s) whose syntax is in JSONPath. The shepherd’s note acknowledges that there is no good reference for JSONPath. Nevertheless, the text needs to be clearer on where to turn to for guidance. (1) Section 2.3.1 says: “Such a reference could be expressed by using a JSONPath. The JSONPath in a JSON document [RFC8259] is equivalent to the XPath [W3C.CR-xpath-31-20161213] in a XML document. (2) The JSONPaths are provided according to the Goessner v.0.8.0 specification [GOESSNER-JSON-PATH]. (3) Further documentation about JSONPath operators used in this specification is included in Appendix A. Taking the perspective of the implementer, which of these three resources is canonical for understanding JSONPath: (a) [W3C.CR-xpath-31-20161213] = a reference marked normative that has nothing to do with JSON but suggests equivalence through a few examples. (b) [GOESSNER-JSON-PATH] = a reference marked as informative which is being used to describe the normative mapping between JSONPaths of the RDAP fields in the text, and is the actual description of the JSONPath syntax. The shepherd’s note points out the difficulty of using this as a normative reference (c) Appendix A = self-contained text which describes JSONPath independent of (a) and (c). As an aside, I’m not sure of the completeness of this write-up. Additionally, the IETF is currently considering it’s own version of JSONPath -- https://datatracker.ietf.org/doc/charter-ietf-jsonpath/ IMO, the fig leaf of citing [W3C.CR-xpath-31-20161213] is inappropriate (as in, it isn’t the actual reference) and unnecessary (as in, it’s just there to meet the letter of having a normative reference). I recommend being practical about the need: -- Use language to the effect of saying the “JSONPath used here is a flavor defined in XXX” -- Make “XXX” be Appendix A. -- Bolster Appendix A to say something to the effect of “this version of JSONPath is inspired by [W3C.CR-xpath-31-20161213] (informative reference) and an articulation of what is used in production [GOESSNER-JSON-PATH] (informative reference)”; and where necessary, add more language around the syntax. This approach will also allow for new JSONPath WG to define a variant which is not strictly compatible (if that’s where the work goes). I’m open to an alternative approach. I just want to end up with a single clear reference of where to read about this documents particular JSONPath syntax. ** Section 2.4. Does this specification provide any normative guidance of “cursor” beyond an opaque value constrained by ABNF? The text notes the notion of “offsets”, “limits”, and “keys”, Base64, CSV but these appear to be referenced as examples. However, Appendix B contains normative language around “limit” and “offset”. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the SECDIR review, Rifaat (Shekh-Yusef)! ** Section 2.3.1. The text notes that JSON Pointer is “hard to use”. It wasn’t clear where the mandate to use JSON Pointer came. ** Section 2.4. Please replace thelastdomainofthepage.com with example.* ** Section 2.4 Is there any semantics to read into “&cursor=wJ…” in Figure 5 beyond it being blob conforming to the cursor ABNF? Editorially, the text doesn’t reference it to explain what’s there. ** Section 7. The issue of paging is being framed as primarily a security issue is puzzling. It seems to me that this is about providing a more usable API for the client which has a net benefit of reducing the resources required to serve the comparable information. If DoS is really the concern, the queries can be rate or resource limited by the application or the underlying RDMS (whose underlying capabilities are explained in earlier text as making this process efficient) ** Section 7. Per the third paragraph, what is the security issue? What’s the threat? ** Section 7. Concur with Eric, there appears to be an implicit assumption that returning subsets of a record set is “fast” and so is counting the number of records. IMO, this isn’t a problem if this is a stated assumption. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
