Il 29/04/2025 16:51, [email protected] ha scritto:
Hi Mario,
This is very straightforward. My concern is in the data consistency
and redundancy.
You have a very nice example, where just postOfficeBox and countryCode
are not localised.
And even in this example if the localisation would set different
countryCode the dataset would be inconsistent, maybe leaving even room
to some misuse.
If the dataset would contain much more properties which are not being
localised - tel/fax/email/vatid etc. then there will be a lot of
redundant data where the implementation would either need to decide to
close eyes and just trust they have the same content or implement some
consistency check and error handling. All not nice.
Putting all trust in implementers of object creators (RDAP servers in
this case) will render errors IMHO.
In the context of RDAP redaction would be more complicated as for each
object there would be more paths to cover - at least as long as
JSONPath is in use. However still easier or even possible compared to
the original patch objects.
[ML] Properties that don't need to be localized are not required to be
included in the localizations property.
I just updated the test by including the phones property that must not
be localized per what is defined in rdap-jscontact doc,
In theory, you could even localize only the nested properties that can
be language-dependent and ignore the others. Looking at the example in
the test, you could exclude the country code and P.O. information from
the localizations property.
The choice to localize the entire address reflects the way int/loc
addresses are represented in EPP.
Honestly, the JSContact localizations property looks to me more similar
to the EPP PostalInfo element than a data structure providing int/loc
versions for each of the nested elements.
Additionally, please consider that not only text values can be localized
in JSContact. For example, you might provide an audio/video message in
different languages.
Therefore, to provide language-dependent variants along with the main
information and keep the flexibility of the current proposal for
localizations, we should implement a "LocalizedObject" type more than a
"LocalizedString" type (quoting the text in a previous Robert's post).
Best,
Mario
Kind Regards,
Pawel
On 29.04.25 12:40, Mario Loffredo wrote:
Hi,
just made a simple project on GitHub
(https://github.com/mario-loffredo/TestJSContactProfile) to
demonstrate how it would be easy to implement the JSContact profile
for RDAP.
The test at
https://github.com/mario-loffredo/TestJSContactProfile/blob/master/src/test/java/testJSContactProfileForRDAP/LocalizationsTest.java
is executed on the JSContact card reported in Figure 1 of
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/.
The uid property has been removed. As for localizations, I think the
solution described in the JSContact profile document is the best way
to go, as it preserves the efficiency and flexibility of the original
proposal and, at the same time, allows implementers to handle
localizations without having to deal with JSONPointer.The test
project demonstrates that, using basic Java features (and I imagine
that the same features are available in all programming languages
as well), an implementer can deserialize a JSContact card including
the "localizations" property into a simple data structure.
Any feedback is appreciated.
Best,
Mario
--
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 [email protected]
To unsubscribe send an email [email protected]
--
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 -- [email protected]
To unsubscribe send an email to [email protected]
