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. - 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. - 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" ] 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
