Hi,
JSContact definition primarily distinguishes between postal addresses
whose components are known and those whose components are unknown.
However, no specification constraint explicitly prohibits the joint use
of the full and components members to match the case of semi-structured
addresses.
Regarding how JSContact handles the formatted address for display or use
on a mailing label, once the address components are known, a formatted
string can be derived using the following properties:
- Address.components (obviously)
- Address.isOrdered: The indicator if the address components in the
components property are ordered.
- Address.defaultSeparator: The default separator to insert between
address component values when concatenating all address component values
to a single String.
- AddressComponent.separator: a formatting separator between two ordered
address non-separator components. The value property of the component
includes the verbatim separator, for example, a hyphen character or even
an empty string. This value has higher precedence than
Address.defaultSeparator
The same approach was used for handling name information.
That said, the rdap-jscontact can specify additional constraints to
those defined by JSContact to match the RDAP use cases and make the RDAP
responses' contents more consistent.
Since the vast majority of RDAP servers are operated by DNRs that adopt
the EPP contact data model (that's what I meant by "typically"), I
imagine the prohibition of using the components and full members
together would be largely respected. The few remaining RDAP operators -
hopefully very few - that store only the unstructured addresses would
use the full member as a last resort..
In conclusion, in an effort to finalize this discussion, here are in the
following the alternatives about handling the unstructured and
structured versions of the postal address and name information:
1) Allow both the unstructured and structured versions to be set. This
would allow for semi-structured versions to be handled and the full
member to be used as a formatted string depending on server policy (but
i wonder if they corresponds to practical RDAP responses) .
2) Require that the unstructured and structured versions not be used
together.
2.1) Add the JSContact properties designed to handle the formatting
of structured version. I'm unclear on whether this is appropriate.
In any case, I would limit the name components to given name and surname
and the address components to street name (name in JSContact), city
(locality in JSContact), region and postcode.
Please let me know your preference on this matter.
Best,
Mario
Il 21/08/2025 08:20, Pawel Kowalik ha scritto:
Hi,
On 20.08.25 19:06, Andy Newton wrote:
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.
[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".
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
--
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 -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
