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.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
