Hi Jasdip,
thanks for your comments.
Please find my own inline prefixed with [ML].
Il 25/07/2025 14:22, Jasdip Singh ha scritto:
Hi Mario, Pawel,
Please see my comments below.
Thanks,
Jasdip
*From: *Pawel Kowalik <[email protected]>
*Date: *Thursday, July 24, 2025 at 6:09 PM
*To: *Mario Loffredo <[email protected]>,
Pawel Kowalik <[email protected]>, [email protected]
<[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.
The unstructured address leaves room for postal address implementations
whose postal address scheme doesn't match the current structure of
either jCard or JSContact.
So my final opinion is to keep it.
3) 3.1.12. Map Keys
[JS] The interesting discussion between you and Pawel raised one point
for me. :) Say, an entity has “email”, email-1”, and “email-2” keys to
start with. If “email-1” value were to be deleted at some point, in
the subsequent responses, would the “email-2” value then become the
“email-1” value, or would both “email-1” and “email-2” keys still be
returned with an empty value for “email-1”?
[ML2] The former, i.e. the keys are not bound to the values. After all,
this is exactly what happens with the standard RDAP properties.
In this case, the use of numbers as keys or in the keys could confuse
the implementer, but I think that a clarifying text could suffice.
Keeping the history of changes should be material for a specific RDAP
extension like the one Tom proposed some time ago.
Best,
Mario
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
