Hi, On 20.08.25 19:06, Andy Newton wrote:
[PK] This was actually my point from the beginning, that EPP streets field (or "name" in JSContact) offers enough of flexibility to put in any address. Likely this is why there never appeared a need for unstructured addresses in EPP, even though it all the mentioned arguments would be same applicable. If the need didn't arise in 20 years, then I don't believe there is a particular problem to fix. CC / postal code are the elements relevant for international post routing, therefore looking through UPU database it is supported by vast majority of economies. We learned quite recently, that even too restrictive on requirement to put in postalCode (it used to be required field in DENIC registration system) didn't prevent people from these economies not having postal code registering domains. These economies apparently are so used to postal code required issue, that they learned to use "00000" placeholder. And of course, even after relaxing the rules on postal code, the change is not reflected upstream, so registrars keep sending "00000".On 20-08-2025 11:00 AM, Mario Loffredo wrote:[ML3] My interpretation of that section is that it warns clients that a postal address could appear in either format in an RDAP response and, therefore, they should be prepared to handle both of them.But I'm pretty sure that clients typically consider the unstructured version only when the structured one isn't available. For an implementer, it's much easier to start with structured data and aggregate/manage it as desired rather than the other way around.I don't know what "typical" is, but my client will display both if both are given... but I have never seen any registry do that.While I think supporting unstructured addresses is an absolute requirement, it does occur to me that even registries that cannot fully support structured addresses do have the country and sometime region in a semi-structured form. Therefore I don't think it is unreasonable to allow unstructured addresses and at least these two fields in a structured form... it isn't great, but it is better than nothing.
It is also my understanding that one of the reasons unstructured addresses area allowed in vCard is that they represent what can be written out on a postal envelope for an economy. (I don't know what JSContact does here). It is one thing to have a postal address in structured form, but if you cannot use it on a postal envelopes that seems to be a bit odd. I think we westerners tend to think that structured addresses are obvious in postal envelope form, but that is not true for many places in Asia where writing direction on both axes is not the same (as ours).
This is true. Some protocols take account of that. OpenID Connect defines "formatted" field - Full mailing address, formatted for display or use on a mailing label.
JSContact definition does not account for this use case however: full: The full address, including street, region, or country. The purpose of this property is to define an address, even if the individual address components are not known.
With this definition one may argue that usage of "full" if individual components are known is not following the intended use of this field.
[1] https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
