Mario, Sorry for the delay in responding to your feedback. Thanks for the feedback and below are the responses to it.
-- JG [cid:image001.png@01D90BD0.5D9CCAC0] 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/> From: Mario Loffredo <mario.loffr...@iit.cnr.it> Date: Tuesday, November 15, 2022 at 9:05 AM To: James Gould <jgo...@verisign.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Request WGLC for draft-ietf-regext-rdap-redacted Hi James, some comments from my side: 1) With reference to the following sentence in section 3.2: such as "" for a jCard [RFC7095] Text ("text") property or null for non-Text ("text") properties. it seems to me that RFC7095 doesn't include a clear statement in that sense. Some VCard types (i.e. text, uri, language-tag, utc-offset, and all date type variants) are mapped to JSON strings, other VCard types are mapped to other JSON primitive types (i.e number, boolean). Given that, apart from "fn" that is a required "text" property, a JSON string can be either null or empty. For sure, the use of the empty string makes more sense for "text" values, but null value is not clearly prohibited for the other VCard properties mapped to JSON strings. JG – Yes, the other jCard properties may be mapped to a JSON string, but they include additional string format requirements that would not be met with the use of an empty string. The reference to the Text (“text”) property does not apply to the other jCard properties that map to a JSON string, so the redaction is handled with the use of a null value. 2) WIth regard to redaction by replacement method, should the example in Fig.7 be updated as in the following: OLD "redacted": [ { "name": { "type": "Registrant Email" }, "path": "$.entities[?(@.roles[0]=='registrant')].<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')][3]> vcardArray[1][?(@[0]=='email')][3]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')][3]>, "replacementPath": "$.entities[?(@.roles[0]=='registrant')].<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')][3]> vcardArray[1][?(@[0]=='contact-uri')][3]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')][3]>, "pathLang": "jsonpath", "method": "replacementValue", } ] NEW "redacted": [ { "name": { "type": "Registrant Email" }, "path": "$.entities[?(@.roles[0]=='registrant')].<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]> vcardArray[1][?(@[0]=='email')]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]>, "replacementPath": "$.entities[?(@.roles[0]=='registrant')].<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]> vcardArray[1][?(@[0]=='contact-uri')]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]>, "pathLang": "jsonpath", "method": "replacementValue", } ] Based on the example in Fig.6, the "email" property instead of the "email" value is replaced. JG – Yes, I agree that the “email” property instead of the “email” value is replaced. This will be addressed in draft-ietf-regext-rdap-redacted-10. 3) Would rephrase the following sentence in section 4.2 OLD The "redacted" member contains an array of redacted objects with the following child members NEW The "redacted" member contains an array of objects with the following child members The objects in the "redacted" array are not redacted but rather the response fields represented by those objects. JG – This will be updated in draft-ietf-regext-rdap-redacted-10. 4) Wonder if section 6.2 should include an entry for pathLang. JG – Yes, based on the feedback from Pawel Kowalik, the “redacted expression language” type will be added with an initial registration of the “jsonpath” value for the JSON Values Registry. 5) A last feedback about JSONPath Considerations: 5.a) Is it allowed to use wildcard in JSONPath? Think it could be useful especially when the same redaction rule is applied to each result of a search response. For example, if a registry policy consists in redacting all the domain handles, the "redacted" content could simply be: "redacted": [ { "name": { "type": "Registry Domain ID" }, "path": "$.domainSearchResults[*].handle", "pathLang": "jsonpath", "method": "removal", "reason": { "type": "Server policy" } } ] JG – Actually for searches the “redacted” member can be included on a per-object basis, since the redaction may be different per object. Attempting to define crosscutting redaction definitions for all objects included in the search seems like something the server could do, but I don’t believe it should be encouraged. 5.b) I consider this a corner case so feel free to ignore it ;-) The VCard label property (as well as the JSContact fullAddress property) is usually derived from the postal address information. When the postal address is partially redacted, what should be the label value and the related redaction method? If you think it's worth managing this case, I would suggest a conservative solution: the label property should be omitted and the redaction method should be "removal". JG – The rule is if the property can be and is removed due to redaction, then it is omitted, and the redaction method should be “removal”. I’m not sure if this fully answers your feedback, so please let me know with an example if it doesn’t. Hope it could be helpful. Best, Mario Il 10/11/2022 19:38, Gould, James ha scritto: This is a formal request to start the WGLC for draft-ietf-regext-rdap-redacted. There is a normative reference to draft-ietf-jsonpath-base, which has a JSONPath working group November milestone. draft-ietf-jsonpath-base looks stable and can progress in parallel with draft-ietf-regext-rdap-redacted. Thanks, -- JG [cid:image002.png@01D90BD0.5D9CCAC0] 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://secure-web.cisco.com/1jBgmRGLp97BwyI56ZY6E2KnhXLBn_CyaRjxVZ7GqU5nP4VoGbDmOFaSadTLrZ8OaIMWwNr4CLXsVIYNhnH4Z3c6przEWV0581stOfOtCDYyVb1U8iX-OaeglUaY6UIjRbRsoaAcqnx12w7uDgnjrwnhLrtSCH3NQK20VhpKXQbAofvo4jOJsx4cHjD5sxmv-xKgfyjXZgr7oOpxU9z41XgH02hJZZTYbogCf05948JANuWS0T4DojwwmNtmQHoN9UjVqPRqZKAn7gbjnO0xXK3ZDaxx9N9iz65hy3ZqIgQYHxdSLk5KUHbNvQydrwCxd/http%3A%2F%2Fverisigninc.com%2F> _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1QZXPKZg0yOi5FGPtQR9fKFNSa-mIVnC7WC4ALwt1eRfK3-ypZSt6_2xY-hSaVmgzAytTYYHcnL4rCXxWO2UpEtkMlh-OegPiK5nrIShRzg2hBlREYZPS41o1IwIWcM7UZPGQ-FxQBxkkf8fRsG27ZJPh6SN4Npz5Nx0eTyp0BNyD27_AEHQOQGphegY8qsrmx-Wjd9q7Csh129rmKkvKVxpZzed_u_8Pwyn4g4DN11Ns2RGRyh6-ymPx7BK5CxqUGI6OovchjtlylImbPICIi7KiCZMvnjcPCyn_ZDbQbxVQpIu6ikjianxcAM8RpdtD/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> -- Dott. Mario Loffredo Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/139AqdF7WT3CdxSSc0UPSoDgA0gl9_QwVKklekryCslll0JvKfIWV4X16QAKacmsRBjPmY6-F04c28s5zpz2HwT6ki7ON7XQHsnRXipvn3m1NoGxfR9XMNRGTtoSlaoXahD0z-bP-mSUPsraAy5ewotwaYuTsKuafF8T5HN8JqEL4pqYsq1WAdl8WS_bHigbb8mVKIhqTDuRazKzVCpoByy52N_M-Hf8megqz4jAbIU_D7CgzVTQH7GQXldLgfms9L0ugpZtQ0bewrH_9DBeNO0aiY2BRkZ8adIM_8V-TsGl3qCbgdfLzBl6RNTz79GpF/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
