Hi Pawel, Jasdip and Andy,
again my comments below.
Il 16/08/2025 11:47, Pawel Kowalik ha scritto:
Hi,
My feedback with PK3>
On 15.08.25 22:39, Jasdip Singh wrote:
<snip PK3>
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.
PK3> I believe the benefit of enforcing a single, structured format
outweighs the perceived risk of exclusion. While no data model is a
perfect representation of reality, a standardised one brings necessary
order and predictability. The risk of exclusion is minimal; the
proposed structured fields are quite flexible. The country code is
universal, and for the handful of jurisdictions without postal codes
(e.g., Hong Kong), that field can simply be omitted. More importantly,
the street component within the structured address can serve as the
"catch-all" for any address lines that don't fit other fields. RFC5733
address data model seems to be a good middle ground of enforcing
structure. By mandating a single structured representation, we place
the responsibility of mapping data correctly on the server, which is
in a much better position to handle its own data than every client is.
This eliminates ambiguity and simplifies client implementation
significantly.
Also in terms of redaction, the unstructured field is all-or-nothing -
partial redaction would be impossible, or would imply server making a
structure out of data to redact the right parts.
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.
PK3> see above
Relatedly, Andy shared that general RDAP clients already support both
structured and unstructured ways for jCard.
PK2> The fact that some general clients support both formats is a
reflection of the existing jCard standard, not a stated requirement
for automated processing in RDAP. For clients that perform automated
data processing, structured data is vastly more useful and reliable.
Given the heavy redaction of PII in RDAP, the utility of a purely
unstructured address for these clients is questionable at best. We
should optimise for the most valuable data format IMHO.
[ML] I think a reasonable compromise is to allow both formats, but we
could require that they NOT be used simultaneously. This could avoid
confusion for clients. The same could apply to the full name and name
components.
Regarding JSContact address components, I think that we should only
allow "name", "locality", "region" and "postcode". The "country"
component is redundant because countryCode is already allowed.
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]
