Hi Mario,Thanks for clarification. From draft-ietf-calext-jscontact-profiles-00 I interpreted that "localized Card replaces one or more top-level properties entirely" means full replacement. Partial replacement would be fine with a small issue of removing items, as then all what localisation could do is setting null. But I think it's not that wrong at the end.
As a side note then - your code does not seem to have any logic of looking up main object if it's not existing in the localisation. In normal use one would need some logic for this.
In pure context of RDAP the issue is indeed less relevant, as EPP servers have 2 distinct copies of data for each int/loc variant, so rendering a partial diff out of it would be more of a trouble than help, so full replacement variant would be likely the one used anyway.
Kind Regards, Pawel On 30.04.25 12:16, Mario Loffredo wrote:
Il 29/04/2025 16:51, kowa...@denic.de ha scritto:[ML] Properties that don't need to be localized are not required to be included in the localizations property.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.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, MarioKind 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 --regext@ietf.org To unsubscribe send an email toregext-le...@ietf.org-- 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
