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 <http://verisigninc.com/> 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]). 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. 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). 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://secure-web.cisco.com/1sbQYJ0RklzBQs5RMCovK0UQcaN9tI_4mvkBIWUefxhYjIgNOnEhmlBUSUNYz5fYas6OaXaJdT_mjVPi-GDDFNNO64WPfUB03Y1IEYZAU96OSZIKS5qjaXme4S5HWlJXtBoDHHCt9xMM1kHrGQhp2xW0QeHPHhdAskHxIlI8ZpIjEeZ6uSqPUZVDGQOoCHzzu9rinzE5L6iXprR_pTJikt_DhEFxDP6uS5ZtUB1WlhpHujpVTrKs6OKQdjgT4-o4PL1CF-GSxrqJDJ_GdwnbEGg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
