Hi, From: [email protected] <[email protected]> Date: Monday, August 18, 2025 at 5:03 PM To: Mario Loffredo <[email protected]>, Pawel Kowalik <[email protected]>, Jasdip Singh <[email protected]>, [email protected] <[email protected]> Subject: [regext] Re: Fwd: I-D Action: draft-ietf-regext-rdap-jscontact-22.txt
On 18.08.25 14:45, Mario Loffredo wrote: [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. [JS] Glad to see that we won’t be excluding unstructured addresses in RDAP JSContact. Though, not sure about "they NOT be used simultaneously”. Even if structured components are available, unstructured data is typically intended for human-friendly presentation of an address or a name per some economy or culture. IMO, the guidance should be to encourage supplying structured components but not discourage additionally providing unstructured data, be it for an address or a name. PK> I agree. I propose to add SHOULD for components, unless there is no technical mean to provider structured data. 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. PK agree [JS] Per RFC 9553 [1], “country” is country name and “countryCode” its 2-letter code. Should we not keep both? [1] https://www.rfc-editor.org/rfc/rfc9553.html#name-addresses Jasdip
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
