Hi Pawel,
gain my responses inline prefixed with ML3.
Il 12/08/2025 08:24, Pawel Kowalik ha scritto:
Hi Mario, Jasdip,
On 25.07.25 16:11, Mario Loffredo wrote:
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.
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.
[ML3] I think that a reasonable compromise could be removing the
unstructured address and, at the same time, omitting to specify the
structured address components as I proposed in
https://mailarchive.ietf.org/arch/msg/regext/ypO-0Dnz3A3HgQRkzEXwY8W-LfY/
Does it work for you ?
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.
PK2> the text must be clear whether: a) keys are only temporary for a
single response (i.e. can vary between 2 responses of the same
object), there is no gap in numbering; -> likely not fully compliant
with JSContact RFC b) keys are stable for a period of time when the
object is not changed (i.e. as long as no of e-mails got added,
deleted or updated, the keys are stable. There is no gap in numbering*
; c) keys are always stable, there can be gaps in numbering.
* if redaction is considered, there might be gaps created anyway
[ML3] Option b) works for me
Best,
Mario
Kind Regards,
Pawel
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
--
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]
