Re: [regext] Thoughts on the fundamental premise of JSContact

[Mario Loffredo <[e-mail]>]

Hi Andy,

please find my comments below.

Il 09/06/2023 17:41, Andrew Newton ha scritto:
> On Fri, Jun 9, 2023 at 10:03 AM Jasdip Singh <[e-mail]> wrote:
>> Hello Mario,
>>
>> Your answer made my day! :) I'm still LOL about your "it wouldn't be short-sighted but completely blind" point. Yah, good to think this through before we as a WG take the next step. I recall one of the laws of simplicity [1]: law 9 which says that some things can never be made simple. May be, JSContact falls into that category. Trusting that the CalExt WG thought through about not unnecessarily introducing implementation complexity for JSContact.
>>
>> Regards,
>> Jasdip
>>
>> [1] http://lawsofsimplicity.com/
> TBH, it was the JSContact patchobject that made me re-examine this
> space. I don't know the requirements for CalExt, but the necessity to
> implement a JSON patching framework to parse postal addresses seems to
> me to be beyond what is reasonable for RDAP.

[ML] CalExt adopted the same approach in designing JSCalendar.

Anyway, the reason supporting the use of patchObject is simple: it is a 
more reusable and extensible approach than replicating in many objects 
the information needed to build language-dependent alternatives.

vCard  makes use of the LANGUAGE and ALTID parameters to build 
language-dependent alternatives. The two parameters are jointly allowed 
for about ten properties.

In designing JSContact, instead of replicating that information in each 
of the ten JSContact counterparts of those vCard properties, we opted 
for defining a single point in the spec containing all the 
localizations. So doing, language based alternatives of a contact can 
always be built in the same way. This a big vantage especially for 
client applications which can provide a better user experience by 
enabling the language selection.

For example, suppose you have a contact card whose default language is 
Japanese but an English version is provided as well.

If you want to display the Japanese version, you just need to ignore the 
localizations. If you want do display the English vertsion, take the 
contact card, apply the patches (no matter if you are patching a 
standard property or an extension), display the resulting contact card.

To be noted that extensions which can be localized don't need to include 
information to build language-dependent alternatives.

On server side,  you need to put the localized object and the 
corresponding localization in two different places but the steps to be 
done are, even in this case, always the same: construct the default 
language version of an object, put it into the right place of the card, 
construct the localization and put it as a generic object into the 
localizations map.

On both sides, you need to know JSONPointer concepts and leverage the 
capabilities of a JSONPointer library.

The implementation in jscontact-tools took to me very short time and 
frankly I'm not a great Java programmer.

Hope now it's more clear why we have used PatchObject.

Finally, consider that CalExt members usually join other forums like 
CalConnect where people are highly experienced with iCalendar and vCard.


With regard to RDAP, honestlty can't evaluate the average number of 
contact properties that might be provided in other languages but the 
example in Fig.15 of RFC 9083 includes 7 properties that could be 
potentially localized: fn, n, org, title, role and two adr intances (one 
structured and one unstructured). If we consider the contact information 
defined by RFC 5733, the minimal set of properties that can be localized 
includes: fn, org and adr.


> James has also pointed
> out several times that the JSContact UID may not be a good fit for
> RDAP.

[ML] JSContact uid takes the same role as jCard fn. Both of them are 
required. Depending on which format a server uses to represent JSContact 
uid, it can be redacted by either the replacementValue or the emptyValue 
method while jCard fn can be redacted only by emptyValue method.

Therefore, after the discussion we have had, don't see why it could be 
an issue.

Neither it looked an issue for you, if I remember well.

>> On 6/9/23, 5:02 AM, "Mario Loffredo" <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> Hi Jasdip,
>>
>> Il 08/06/2023 15:39, Jasdip Singh ha scritto:
>>> True, we could define an entity object class that serves the DNR and RIR purposes with a simpler JSON, just like we chose to define domain, IP network, and autonomous system number object classes that are specific to these registries' business. However, before abandoning the JSContact effort, one question to ask would be: Would it be short-sighted in precluding future user cases for entities in other registries (say, RDAP use for space related registration data)?
>>>
>>> Jasdip
> This is a good question to ask? What if a space registry needs to use
> RDAP? Let's say they need star-dates, celestial orbital planes, and
> jump-gate coordinates.
> Does JSContact currently support star-dates, celestial orbital planes,
> and jump-gate coordinates? It probably does not, and therefore they
> would have to extend JSContact.
> So if they can extend JSContact, why can't they just write an
> extension for RDAP itself. In the end, that would be simpler IMHO.
[ML] If reasons supporting JSContact in RDAP exist, they are not 
celestial but absolutely terrestrial.
> It is also possible that we define a SimpleContact and fail to account
> for something a registry is doing today.
> If that happens, that registry can still use jCard. As Marc has
> pointed out, jCard will be with us for some time to come.
> Or they too can create an RDAP extension.
> That said, I have high confidence we can create a SimpleContact that
> addresses 99% of what is needed given the gTLD space is well-defined,
> many of the ccTLDs are similar to gTLDs (many of them run gTLDs these
> days), and the RIR space is also defined.

[ML] Think that your conclusions need no more words from my side. 
Personally I see no solid reasons to replace JSContact with another 
fully object-oriented representation based on your arguments. But I can 
be bias.

I expect that shortly the chairs will formally ask the WG members to 
manifest their support to rdap-jscontact. Whatever happens, I'll respect 
the WG decision.

Anyway, if a new representation based on a JSON transliteration of 
RFC5733 were preferred,  IMHO it would be fair that Gavin was the 
leading author.


Best,

Mario


P.S.

Lesson learned: considering that I'm almost sixty, perhaps I'm not so 
bad as a Java programmer :-)

>> [ML] Would like to answer your question trying at the same time to recap
>> the reasons why 3 years ago we didn't bring on Gavin's proposal about "a
>> straight mapping of RFC5733 contact objects into JSON".
>>
>> I remember that at ROW 2019 George Michaelson from APNIC gave a
>> presentation
>> (https://regiops.net/wp-content/uploads/2019/05/ROW8-RDAPPanel-In-defence-of-jCard%E2%80%99s-goals-George-Michaelson.pdf <https://regiops.net/wp-content/uploads/2019/05/ROW8-RDAPPanel-In-defence-of-jCard%E2%80%99s-goals-George-Michaelson.pdf>)
>> about which requirements a contact representation aiming to replace
>> jCard was supposed to meet according to his experience.
>>
>> In that circumstance, it was clear to everyone that the EPP contact
>> representation was pretty unfit to handle non-western registry data in
>> general.
>>
>> Think that hopefully all of those requirements are matched by JSContact
>> (e.g. we have recently updated the spec to better model non-western
>> addresses but the work is still ongoing).
>>
>> Tom and George, can you please say your word on this matter ?
>>
>> Definitively, I believe that embracing the proposal of a contact data
>> format based on RFC 5733 would be a huge step backwards in facing this
>> problem.
> The idea is not to solely base it on RFC 5733. We know that won't
> work. The idea is to find a simpler solution that can be mapped into
> plain structures much the same way the rest of RDAP works.
>
> And thanks to Tom and George, we do have a good idea of the needs that
> EPP doesn't provide:
> https://datatracker.ietf.org/doc/html/draft-harrison-regext-rdap-jcard-profile-00
>
> -andy
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web: http://www.iit.cnr.it/mario.loffredo