Hi Mario, From: Mario Loffredo <[email protected]> Date: Wednesday, August 20, 2025 at 3:30 AM To: Jasdip Singh <[email protected]>, [email protected] <[email protected]>, Mario Loffredo <[email protected]>, [email protected] <[email protected]> Subject: [regext] Re: Fwd: I-D Action: draft-ietf-regext-rdap-jscontact-22.txt
<snip> 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. [ML2] Clients don't need to get the unstructured format if they can get the structured one and present the address as they want, instead of how servers chose. It could happen, perhaps it is unlikely but we cannot completely rule it out, that there could be inconsistencies between the two formats if both were presented. [JS2] That’s an interesting point -- whether a client should honor the unstructured address’ presentation when provided from the server side or not. RFC 9083 discusses structured versus unstructured addresses [2] but not sufficiently to help with our discussion point. [2] https://www.rfc-editor.org/rfc/rfc9083.html#name-structured-vs-unstructured- 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 [ML2] I believe it's always better to manage a code rather than its decoding. Furthermore, RFC5733 uses the country code rather than the country name. Therefore, I imagine that RDAP servers using registration data based on the EPP data model derive the country name from the country code to comply with the jCard format and this is also the reason why the vCard CC parameter was introduced by RFC8605. The JSContact format does not require this conversion. [JS2] This makes sense. Come to think of it, even RDAP’s IP Network and Autonomous System Number object classes have the “country” member as a 2-character country code. Considering the EPP data model, the name will be presented primarily in the unstructured format, while the postal address will be presented in the structured format. Jasdip
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
