Gustavo, Thanks for the additional feedback. The updates based on your prior feedback will be in the next version of the draft. I like your suggested text for the JSONPath Considerations. I look forward to the discussion on the draft at the REGEXT meeting today.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/28/21, 2:53 PM, "Gustavo Lozano" <gustavo.loz...@icann.org> wrote: Thank you Jim, I provide my feedback prefixed with GL-. I think that section 5 (JSONPath Considerations) of the I-D should also be generalized. I also suggest adding some text to guide RDAP extension authors about special JSONPath considerations. For example: RDAP extensions MUST define any special JSONPath considerations required to identify redacted RDAP fields if the methods described in section 5 are insufficient. Regards, Gustavo On 7/14/21, 10:51, "Gould, James" <jgo...@verisign.com> wrote: Gustavo, Thank you for your quick review and feedback. I provide my replies to your feedback embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!o0GbJVtMeAviARQrIBEupbNyMpUHwB0iuziOJsE1Oo0VgCLnNySpyC1r1LAkgMxhPl8AgNQud4M$ > On 7/14/21, 11:50 AM, "regext on behalf of Gustavo Lozano" <regext-boun...@ietf.org on behalf of gustavo.loz...@icann.org> wrote: Thank you, Jim and co-authors, This is needed, and hopefully this I-D could be published as an RFC sooner rather than later. I think that the text explaining the special treatment for jCard should be made generic. Currently, it appears that only jCard uses the position in the array to signal the type of information, but RDAP is extensible, and some extension may be doing or decide to use the same approach as jCard. JG - You are correct that there's an implied assumption that jCard will be the only RDAP case using fixed length arrays, and you're also correct that we can't foresee the forms of RDAP extensions that will be created. I appreciate your suggested language that is more generic. I made some language updates, but making it more generic is an improvement. I'll look for similar jCard specific language in the draft. For example: Original: The Redaction by Removal Method can be done for all RDAP response fields other than the JSON arrays used with jCard [RFC7095] Suggestion: The Redaction by Removal Method can be done for all RDAP response fields other than response fields using the position in an array to signal the type of information (e.g., the JSON arrays used with jCard [RFC7095]). JG - My initial thought was to focus the language on the use of fixed length arrays, but I believe your approach of looking at the resulting redaction expression is better, which is to use a "position in an array". I believe it's best to change "signal the type of information" to "signal the redacted field". The end result is: The Redaction by Removal Method can be done for all RDAP response fields other than response fields using the position in an array to signal the redacted field (e.g., the JSON arrays used with jCard [RFC7095]). GL- agree with the proposed text. Original: The Redaction by Removal Method MUST NOT be used to remove a field from a jCard [RFC7095] fixed array position, which will result in a non-conformant jCard [RFC7095] array definition. Suggestion: The Redaction by Removal Method MUST NOT be used to remove a field from a response field using the position in an array to signal the type of information (e.g., jCard [RFC7095] fixed array position, which removal of an individual data field will result in a non-conformant jCard [RFC7095] array definition). JG - I believe that the jCard reference could be broken out into a separate sentence as in: The Redaction by Removal Method MUST NOT be used to remove a field from a response field using the position in an array to signal the redacted field. For example, removal of an individual data field in jCard [RFC7095] will result in a non-conformant jCard [RFC7095] array definition. GL- agree with the proposed text. Original: The Redaction by Empty Value Method SHOULD be used only when redacting JSON response fields that use jCard [RFC7095] arrays. Suggestion: The Redaction by Empty Value Method SHOULD be used only when redacting JSON response fields that use the position in an array to signal the type of information (e.g., jCard [RFC7095] arrays). JG - Same change for "type of information" to "redacted field", as in: The Redaction by Empty Value Method SHOULD be used only when redacting JSON response fields that use the position in an array to signal the redacted field (e.g., jCard [RFC7095] arrays). GL- agree with the proposed text. Thank you, Gustavo On 7/12/21, 04:03, "regext on behalf of Gould, James" <regext-boun...@ietf.org on behalf of jgould=40verisign....@dmarc.ietf.org> wrote: The "Redacted Fields in the Registration Data Access Protocol (RDAP) Response" draft-gould-regext-rdap-redacted has been published. The goal of the draft is to describe an RDAP extension for explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. Any review and feedback is welcome. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksW5Dv4ypU$ > On 7/12/21, 6:47 AM, "internet-dra...@ietf.org" <internet-dra...@ietf.org> wrote: A new version of I-D, draft-gould-regext-rdap-redacted-00.txt has been successfully submitted by James Gould and posted to the IETF repository. Name: draft-gould-regext-rdap-redacted Revision: 00 Title: Redacted Fields in the Registration Data Access Protocol (RDAP) Response Document date: 2021-07-12 Group: Individual Submission Pages: 24 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-gould-regext-rdap-redacted-00.txt__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksW4DeSFeo$ Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gould-regext-rdap-redacted__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksWx0K7Y6s$ Html: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-gould-regext-rdap-redacted-00.html__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksWVwNhHnw$ Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-gould-regext-rdap-redacted__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksWEbFQTh8$ Abstract: This document describes an RDAP extension for explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. The IETF Secretariat _______________________________________________ regext mailing list regext@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!prnWbdXxUX1mqlw7JN_5NTrvwIvYtF4nCE2oqHHYsM9YfxbK4W2xEfVRcI2s-GOjaksWClMfK30$ _______________________________________________ regext mailing list regext@ietf.org https://urldefense.com/v3/__https://secure-web.cisco.com/1sbQYJ0RklzBQs5RMCovK0UQcaN9tI_4mvkBIWUefxhYjIgNOnEhmlBUSUNYz5fYas6OaXaJdT_mjVPi-GDDFNNO64WPfUB03Y1IEYZAU96OSZIKS5qjaXme4S5HWlJXtBoDHHCt9xMM1kHrGQhp2xW0QeHPHhdAskHxIlI8ZpIjEeZ6uSqPUZVDGQOoCHzzu9rinzE5L6iXprR_pTJikt_DhEFxDP6uS5ZtUB1WlhpHujpVTrKs6OKQdjgT4-o4PL1CF-GSxrqJDJ_GdwnbEGg/https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fregext__;JSUlJSUl!!PtGJab4!o0GbJVtMeAviARQrIBEupbNyMpUHwB0iuziOJsE1Oo0VgCLnNySpyC1r1LAkgMxhPl8A4sqIB4E$ _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
