On Fri, Jun 9, 2023 at 10:03 AM Jasdip Singh <[email protected]> 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" <[email protected] > <mailto:[email protected]>> 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 _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
