Hi Mario, Pawel, Please find below my comments, marked [JS2].
Thanks, Jasdip From: Pawel Kowalik <[email protected]> Date: Tuesday, August 12, 2025 at 2:25 AM To: Mario Loffredo <[email protected]>, Jasdip Singh <[email protected]>, [email protected] <[email protected]> Subject: Re: [regext] Re: Fwd: I-D Action: draft-ietf-regext-rdap-jscontact-22.txt <snip> From: Pawel Kowalik <[email protected]><mailto:[email protected]> Date: Thursday, July 24, 2025 at 6:09 PM To: Mario Loffredo <[email protected]><mailto:[email protected]>, Pawel Kowalik <[email protected]><mailto:[email protected]>, [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: [regext] Re: Fwd: I-D Action: draft-ietf-regext-rdap-jscontact-22.txt 1) Some fields in the profile seems duplicated to other fields and I am not convinced we need them at all: components Name -> we have full Name … full Address -> we have components of Address [ML] Viceversa, here in the following examples where the postal address is represented only as an unstructured text. https://rdap.arin.net/registry/ip/199.0.0.0 (again) https://rdap.apnic.net/ip/133.0.0.0 https://rdap.db.ripe.net/ip/193.0.0.25 In these cases, I assumed that either only the unstructured postal address was available or mayve RIRs share the policy to display the full address (@Tom, @Jasdip you can shed a light here). The above cases made me think that both formats should be allowed. PK> OK, this would be a friction for the clients to support both, so unless RIRs say they also have structured data we can't do any better. Thanks for clarification. [JS] The RIRs are expected to align with the NRO RDAP Profile [1]. As for the name and address fields from jCard, per section 5.1.1 of this profile, “fn”, “n”, and “adr” may be returned. For ARIN’s RDAP service, the unstructured “adr” is constructed from structured address data (street, city, state, zip, and country) from the database. The RDAP JSContact draft says: “The JSContact "name" property MUST include the "full" member and MAY include the "components" array to specify the name components of an individual.” “The JSContact "Address" type MUST include at least one between the "full", "components" and "countryCode" members.” Looks like RDAP JSContact allows for unstructured names and addresses and their structured components. That seems flexible enough for various server operators (DNRs, RIRs, etc.) but not sure if it would be more complex interoperability-wise for the clients. [1] https://bitbucket.org/nroecg/nro-rdap-profile/raw/0ede2b21a9103409b7d4c9c8a1894eb230b77dcd/nro-rdap-profile.txt [ML] Yes, JSContact is very flexible in this regard. It's good to know that the structured name must be considered. Regarding the full address, based on your answer, it seems redundant, although the current RDAP responses provided by RIR servers suggest otherwise. [JS2] AFAIK, no, the full address is not presently redundant vis-a-vis the RIRs’ jCard implementations. :) The unstructured address leaves room for postal address implementations whose postal address scheme doesn't match the current structure of either jCard or JSContact. [JS2] That’s a good point. Since there are 200+ economies globally and RDAP being an Internet Standard, afraid if we banish unstructured addresses, there could be some economies left out from using RDAP if their postal addresses don’t map to the structured address components RDAP JSContact profile offers. So my final opinion is to keep it. [JS2] Agreed, keep both structured and unstructured addresses. PK2> Following rfc1958 3.2, I would suggest to remove unstructured address. If there would be opinions appearing with good arguments to add it (and as I read Jasdip's response, these are not RIRs), we can always do it with a clear use case at hand. Otherwise we have a clear advantage for the client implementation that they can rely on the structured data being used - which is much better for them. [JS2] Yes, following the RFC 1958 section 3.2 advice is laudable but not if it ends up excluding a real-world use case where structured address components don’t work for some economies. Relatedly, Andy shared that general RDAP clients already support both structured and unstructured ways for jCard.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
