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
