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
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.
[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
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
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
--
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
