Hi James,
please find my comments below prefixed by [ML].
-------- Messaggio Inoltrato --------
Oggetto: Re: [regext] New Version Notification for
draft-gould-regext-rdap-redacted-00.txt
Data: Wed, 14 Jul 2021 14:06:47 +0000
Mittente: Gould, James <[email protected]>
A: [email protected] <[email protected]>,
[email protected] <[email protected]>
CC: [email protected] <[email protected]>
Mario,
Thank you for your review and feedback. I provide replies to your
feedback embedded below.
--
JG
James Gould
Fellow Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 7/14/21, 3:58 AM, "Mario Loffredo" <[email protected]> wrote:
Hi all,
Il 12/07/2021 13:26, Gould, James ha scritto:
> Marc,
>
> Thank you for the quick review and feedback. Below are responses to your
early comments:
>
> - would be good to include specific text about jscontact, so when we
switch to it, this document does not need rev.
>
> Agreed, that was thought about while drafting, but we initially left it
out. I'm confident that the extension will work with JSContact, but some text
would help for clarity.
I guess it will work even better than with jCard! JSContact is more
object-oriented than jCard and the json path expressions are simpler since
maps are mostly used to represent collections (e.g.
"$.entities[?(@.roles[0]=='registrant')].jscard.phones.voice.phone" instead of
"$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[1].type=='voice')]")
JG - Yes, JSContact is much easier to express via JSONPath, since there is no
dependency on the use of JSON arrays.
Here in the following a first feedback from my side about the document:
- if, as it seems, the "name" property is unique in the "redacted" array, I would prefer to define
"redacted" as a map where the "name" value is the map key. In theory, every RDAP information can be
redacted but, in practice, the number of RDAP properties usually redacted is limited. If the possible "name"
values were standardized, il would be easier for RDAP clients implementers to check and pick a property inside the
collection of redacted properties.
JG - Agreed, it would be ideal for the "name" property to unique and easy to key off of by the client. The JSONPath expression
provides the technical reference, while the "name" property can represent the logical reference. We didn't want to go down the
IANA registry route in draft-gould-regext-rdap-redacted, but if we add a RDAP JSON Values type for the redaction reason, we could also add
an RDAP JSON Values type of the redaction name. The question would be whether all "name" property values would need to be
registered in the RDAP JSON Values registry. If that is not the case, then we would need change the "name" member to be a JSON
object with the "description" and "type" members used for registered and unregistered values in RFC 9083.
- another possible pre-defined value for "pathLang" might be
"jsonpointer" as an alternative syntax to indentify a value within a JSON doc.
JG - I don't believe JSON Pointer will work for RDAP based on the need for the
conditional expressions (e.g., "$.entities[?(@.roles[0]=='registrant')]"). Do
you see a way that JSON Pointer could be used for RDAP? I would only add it if it will
work for RDAP.
[ML] - I think it depends on whether the "jsonpath" is meant as a way to
identify a generic RDAP response field or a specific field in the
current RDAP response. Surely, unlike JSONPointer, JSONPath allows to
select a field nested in an array regardless of the position. Therefore,
it is able to represent multiple cases through the same
respresentations. However, an RDAP profile might use conventions (e.g.
the registrant is always the first entity in the array of entities
associated to a domain) making the use of JSONPath filters redundant. In
additon, there are cases where JSONPointer can be used
straightforwardly: for example, a entity lookup response using JSContact
:-) . Anyway, I agree with you that JSONPath fits better than JSONPointer.
- it seems to me that the document assumes that the role used to identify the
redacted entity within the array of entities should be in the first position of
"roles" array. Maybe such assumption should be added somewhere in the
document.
JG - That is the convention, but if there are multiple roles, the server could choose to use a different role value
reference. There is the option for a contact to serve multiple roles ("registrant", "
administrative", "technical", "billing"), but it's unclear whether that is actually used. If
the multi-role contact is redacted by role, then it will add complexity from a redaction perspective, but it can be
done. In the end, I believe this will come down to a implementation consideration item.
[ML] - Generally, an entity is redacted without regard to the role but based on
other conditions: whether the entity represents an individual or not, whether
the entity have expressed the explicit consent for publishing or not. At least
for ccTLDs, it is normal that an entity is both the registrant and the
amministrative contact linked to a domain.
- there is a typo in the json path expression of "Registrant Street"
JG - What typo do you see in the JSON Path expression of "Registrant Street". I tested the
"Registrant Street" JSONPath expression
"$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='adr')][3][:3]" against the
unredacted RDAP response, with the result being:
[
"",
"Suite 1235",
"4321 Rue Somewhere"
]
[ML] - Understood. You considered both extended address and post office box as
street components. I have always considered the street information made up only
by the third ADR component beacuse RFC6350 recommends not to use the first two
components to increase interoperability (see below). That being said, I admit
that your JSONPath is able to cover any street representation.
Unlike the use in RFC8977, a JSONPath expression is allowed to select an
array of values in order to communicate that all the values are redacted.
"Experience with vCard 3 has shown that the first two components
(post office box and extended address) are plagued with many
interoperability issues. To ensure maximal interoperability,
their values SHOULD be empty." (RFC6350 section 6.3.1)
[ML] - Another feedback about implementing this extension in search responses.
Provided that this is not the .it case where searches are allowed only to users
legitimated to see the full contact information, I wonder how RDAP servers
permiiting searches more or less publicly might implement it.
Returning the list of all the redacted JSON values included in the
response seems to me inefficient. On the other hand, relying on the JSONPath
capability to select a result set, it would be wrong to use a single generic
JSONPath expression
(e.g. use
"$.domainSearchResults[*].entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]"
to communicate that the emails of all domains' registrants are redacted) because, in
general, the same property in different results could be either redacted or unredacted.
Do you think the document should address this topic and how?
Best,
Mario
>
> - I really would like to have an IANA registry for the « reason »
property. Because this would be potentially displayed to the user, and
to avoid having all variations of the same reason in different words. A
registry of reserved words would also facilitate translation in multiple
languages.
>
> We had a desire to stay away from needing to setup an IANA registry
for redaction. I view the reason property as not a good candidate for an
IANA registry, since it's meant to be a human readable informational
value that includes normative language not to be used as a client
processing dependency. This is a good discussion item.
>
> Thanks,
>
-- Dr. 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://secure-web.cisco.com/1F-PFooJyrWLg51lyW_I49Zvwy3moYXof6OwGqaZON9_0DcwS-s4HC3KttHlW4-GTU-3j7eTkRexCFzAuK9qR5TFk1Va8rwSoh15OdINxFIShnToELNciLpmFWsMNghBtzhTGEfz81tSFv-8jpnVkIF56EAcX0m47l_U0xLdYxjWxvkBykLE6XGyZkw-IHz_8LfdHOV6Ja-dDltW2jsD7CdSMhuy3B4g2ihEL5ekGFFizXUM5jM8rQrdTICQAhGxBqTHe6CwiveYGEUunTsQJxA/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
