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

[Andrew Newton <[e-mail]>]

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. James has also pointed
out several times that the JSContact UID may not be a good fit for
RDAP.

>
> 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.

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] 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