Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-12.txt

[Jasdip Singh <[e-mail]>]

Hello James,

I'm fine with all the changes you propose. Thanks for the explanations.

Jasdip

On 6/26/23, 3:17 PM, "Gould, James" <[e-mail] <mailto:[e-mail]>> wrote:

Section 1:

"The redacted JSON fields will either be removed or have empty values in the RDAP response." ... Isn't that incomplete, now that we have partial value and replacement methods as well?

JG - Yes, you are correct that this sentence is now incomplete. How about the following:

"The redacted JSON fields will either be removed, have empty values, have partial values, or be replaced in the RDAP response."

Section 3:

"The redaction of RDAP fields fall into the three categories defined in the following sub-sections." ... Should it not be four categories now?

JG - Yes, you are correct there are four categories, so it should read "The redaction of RDAP fields fall into the four categories defined in the following sub-sections." 

Section 3.1:

"The Redaction by Removal Method is when the RDAP field is removed from the RDAP response, which is the preferred method." ... Why is it preferred? It just happens to be for optional fields’ redaction, no? As-is, it seems to connote: prefer redacting optional fields. Perhaps "default method" is a better phrase than "preferred method".

JG - I believe the preferred language was based on comparison to the empty value method, but it is the default (and most common) redaction method. We can replace ", which is the preferred method" with ", which is the default method" to correctly reflect it as the default method instead of the preferred method. The sentence would be "The Redaction by Removal Method is when the RDAP field is removed from the RDAP response, which is the default method". This will match what is indicated for the "method" member in section 4.2. 

Section 3.2:

"The Redaction by Empty Value Method is when a redacted field is not removed, but its value is set to an empty value, such as "" for a jCard [RFC7095] Text ("text") property or null for a non-Text property." ... Found "null for a non-Text property" to be a bit confusing given a string JSON type can also be set to null, AFAIK.


JG - That same language was brought up my Mario with my response in the mail message https://mailarchive.ietf.org/arch/msg/regext/-TpQ9tS_PN5d9IqMcg4Ke6-ZNq4/. The <https://mailarchive.ietf.org/arch/msg/regext/-TpQ9tS_PN5d9IqMcg4Ke6-ZNq4/.&nbsp;&nbsp;The> empty string can be used for redaction of a jCard Text ("text") property, but the other jCard types that are mapped to JSON strings include additional format requirements that would not be met with an empty string, which is the reason why null is used for non-Text ("text") properties. I believe it's important to clarify what to do for redaction with Text and non-Text jCard properties. A jCard Text ("text") property is redacted using an empty string. 

"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" … Why just that? Why not for a required field that needs to be emptied (instead of a non-empty replacement) for redaction?

JG - We added the Redaction by Empty Value Method specifically to address the issues of redaction with jCard. The SHOULD reflects the intent of the redaction method and it's not defined as a MUST to cover corner cases such as an RDAP member that needs to be redacted being defined as required. I hope that future RDAP extensions don't overuse required members causing an issue for redaction. 

Section 4.2:

"The "redacted" member is included as a member of the object class in a lookup response, such as the object classes defined in [RFC9083], and as a member of the object instances in a search response, such as the object instances defined in [RFC9083]." ... Found the "object class" and "object instance" use a bit confusing here. Would it be better to say: "The "redacted" member is included as a member of the object instance in a lookup response, for the object classes defined in [RFC9083], and as a member of the array of object instances in a search response."?

JG - Yes, that sounds better. The second sentence would then read ""The "redacted" member is included as a member of the object instance in a lookup response, for the object classes defined in [RFC9083], and as a member of the array of object instances in a search response.".

"name" ... Is it a REQUIRED member of a child object of the "redacted" array? Is so, good to mark it as REQUIRED given we mark other fields as OPTIONAL.

JG - The members are required by default, but there is no problem being explicit for the "name" member with "REQUIRED logical name for the redacted field....". The change will be made.

"pathLang" … Knowing JSONPath is the only query expression lang mentioned in this draft, wonder if some folks would ask why JSONPointer [1] was not chosen as a pathLang, or if it could be a pathLang? Do we want to provide any guidance/clarification via-a-vis JSONPointer?

JG - We looked at JSONPointer early on, but it didn't provide the needed features for redaction. I believe it's best to define the chosen and in this case the default JSON path expression language with extensibility to support other expression languages without providing clarification of why another expression language wasn't chosen. 

"method" ... "The default value is "removal" when not provided." ... Why not always provide "method" (read: no default) in order to avoid confusion vis-a-vis other fields in a child object of the "redacted" array? Apparently there is not much space optimization to be gained by not setting this field. If so, we can do away with the "which is the preferred method" phrase in section 3.1.

JG - The space savings depends on the number of redacted members. The removal method will be the most common redaction method, so there is no need to specify it for every redacted member.