Re: [regext] Request WGLC for draft-ietf-regext-rdap-redacted

[Mario Loffredo <[e-mail]>]

Il 12/12/2022 14:17, Gould, James ha scritto:
>
> Mario,
>
> Thank you for clarification around the vCard specific example of the 
> partial redaction of the formatted text properties “LABEL” and “FN”.  
> I don’t believe any of the existing redaction methods cover this case 
> of a partial redaction of a formatted text property value.  I realize 
> this is a corner case, but to fully address it in RDAP, we may need to 
> add a new redaction method to draft-ietf-regext-rdap-redacted.  The 
> redaction method could be “Redaction by Partial Value Method” with the 
> “method” member value of “partialValue”.  This would signal to the 
> client that the formatted text property value has been partially 
> redacted.  The concrete case are the “LABEL” and “FN” vCard 
> properties, but other formatted text properties could be defined in 
> the future.
>
> Thoughts on adding a new redaction method for covering this corner case?
>
I'm OK with it. A new redaction method is surely  much better than my 
conservative proposal.

Mario

> -- 
>
> JG
>
>
>
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *Mario Loffredo <[e-mail]>
> *Date: *Saturday, December 10, 2022 at 3:31 AM
> *To: *James Gould <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] Request WGLC for 
> draft-ietf-regext-rdap-redacted
>
> Hi James,
>
> please find my comments below.
>
> Il 09/12/2022 19:15, Gould, James ha scritto:
>
>     Mario,
>
>     Sorry for the delay in responding to your feedback.  Thanks for
>     the feedback and below are the responses to it.
>
>     -- 
>
>     JG
>
>
>
>
>     *James Gould
>     *Fellow Engineer
>     [e-mail]
>     <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>     703-948-3271
>     12061 Bluemont Way
>     Reston, VA 20190
>
>     Verisign.com
>     <http://secure-web.cisco.com/10wmXnAxec1RRrOtGTl4db_iLXMUtPfYFQrLzw-IA2PHbfNc9ze5KbXK3eWCAxJSio1lPtr_6pKioWeYvtLLrnVmZPkJWjQzok4esvmclUfrfkyRBCyDoJt_ryHsKxqZnXSbirKJywEyxB25w9OZqILiskden6igDu3eWZ8GZbgLoDDPJFLJVheJMYKuASxkT76O1U0JGRZ0wh5gYU7PxQ9YOsffUD0yMTCKG3C_S6kW9V15m-UfLxS6qupeP2j7qkhOOudeo--y4d2AzM-KUXiu-EqrQCbjBAN1DGuZ41tA/http%3A%2F%2Fverisigninc.com%2F>
>
>     *From: *Mario Loffredo <[e-mail]>
>     <mailto:[e-mail]>
>     *Date: *Tuesday, November 15, 2022 at 9:05 AM
>     *To: *James Gould <[e-mail]>
>     <mailto:[e-mail]>, "[e-mail]"
>     <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>     *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.
>
> [ML]  As I wrote in my previous mail, maybe it's not worth addressing 
> this case. In general, it is connected with the redaction of vCard 
> elements, namely the FN property and the LABEL parameter of the ADR 
> property, that are generated by formatting their structured 
> counterparts. If the structured components get partially redacted by 
> the emptyValue redaction method, what redaction method should I use to 
> redact the formatted versions?
>
> Here in the following an example clarifying my question.
>
> Before redaction:
>
>           [
>                     "adr",
>                     {"label": "Suite 1236\n4321 Rue Somewhere\nQuebec\QC\G1V 2M2\Canada"},
>                     "text",
>                     [
>                       "",
>                       "Suite 1236",
>                       "4321 Rue Somewhere",
>                       "Quebec",
>                       "QC",
>                       "G1V 2M2",
>                       "Canada"
>                     ]
>                   ]
>
> After redaction:
>
> 1)
>           [
>                     "adr",
>                     {"label": "QC\nCanada"},
>                     "text",
>                     [
>                       "",
>                       "",
>                       "",
>                       "",
>                       "QC",
>                       "",
>                       "Canada"
>                     ]
>                   ]
> 2)
>   
>           [
>                     "adr",
>                     {},
>                     "text",
>                     [
>                       "",
>                       "",
>                       "",
>                       "",
>                       "QC",
>                       "",
>                       "Canada"
>                     ]
>                   ]
>   
>
> Since the specification doesn't allow the server to signal that a 
> value has been partially redacted, and I don't see the need to  add 
> another redaction method only for this corner case, my proposal was 
> simply the following: "those properties that are generated from other 
> properties that can be partially redacted must be redacted by using 
> the removal method" (Solution 2)
>
> Best,
>
> Mario
>
>     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
>
>
>
>
>         *James Gould
>         *Fellow Engineer
>         [e-mail]
>         <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>         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
>
>         [e-mail]
>
>         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: [phone]
>
>     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
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/regext  <https://secure-web.cisco.com/1rA9AMtjPXivn2GGQB-ID4QUpd0YAumPZdCk9bomUeA-FW0jgWKt4BP-iZUjN9ZK5RHa3mQ0cgZR2CXGzCn7h5draw6tDsnn1tSB77lEpcrBTek47xmL8JcWRW7nrXcYWxlUJzXRAQbEPjV-zA4CToN9bL-qxyTxiM86Qdl2yf0VHGU9I7jvK8JrtFVS-STzmXEIFF8EaHSM31W6KF8L2VL4rQ4ZGnDL1tI2DNqDdq8GKQjafxSL34HzNHpWSllgqbY7K6JSCJ6773fZIRMhrDaF5f-HmjwipuKwciva27i0/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: [phone]
> Web:http://www.iit.cnr.it/mario.loffredo  <http://secure-web.cisco.com/1Bl4tTWy6j96jLMQhvvpHAXNQ41oOlRskA5D53vZW-T6wL5phoY08mwHjoDtV7zFoXdlnARj7naYERSK3D1qW0xpd-s6AvJpc0cJ_SoIHX3iNlY-fO3_aB3ZnKwQ65nXXA7jCf0fUrGBdv98Qds0-Y14vwcKUTItJm97dg7egfABvUs7UEhDs1G_C1kNZM-5r7UzETiZxK5ob6tjf5_rSghdo7CrPwb334_rKFyPKsj7HGu2tNYK7iKhzdbMAJXxYdGfnJMRecJSzF646MoK8g1sAcpiQmU0lbVf_fwxvhLo/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo