Good Evening,
+1 on the transition thoughts, thanks Marc for delving a bit deeper on this topic. Just wanted to make one comment/clarification on one of Andy's questions: "Are there any registries willing to step up and say they'll deploy RDAP if we move to JSContact? Just wanted to add clarity to “registries” and suggest supplementing “RDAP servers “ as there will also be thousands of Registrar RDAP servers instances as well. As for GoDaddy, we look forward to migrating our server and clients to a more appropriate contact structure. I can’t speak to Andy’s “holdout question” but I would like to also say I believe migrating will lessen the long term maintenance (e.g. new clients writing/debugging to your server, handling of unique data scenarios into these arrays of arrays) by going with a more simplified/precise structure. Just some additional food for thought. Thanks Roger -----Original Message----- From: regext <[email protected]> On Behalf Of Andrew Newton Sent: Thursday, July 25, 2019 4:43 PM To: Marc Blanchet <[email protected]> Cc: regext <[email protected]> Subject: Re: [regext] on jcard and jscontact migration Notice: This email is from an external sender. Thanks for describing that. I think that makes sense, and if we have to transition this plan seems like the way to go. Given that there are many registries and clients whom have already implemented jCard, does moving to JSContact mean hold-outs will implement RDAP? In other words, who is NOT doing RDAP because of jCard? Are there any registries willing to step up and say they'll deploy RDAP if we move to JSContact? -andy On Thu, Jul 25, 2019 at 4:21 PM Marc Blanchet <[email protected]<mailto:[email protected]>> wrote: > > There has been discussion on replacement of jcard. One of the > considerations in the equation is how to handle the migration. Some > people have (appropriatly) expressed concerns about this issue of > migration. While I’m not yet sure if we need to deprecate jcard, I > would like to suggest a way to manage the migration if we ever > consider the new format: > - define in RDAP RESPONSE another property additional to vcardarray, > at the same place as vcardarray appears. Say « jscontact » > - have servers to send both (for quite a long time). This is more work > from the server side, but I think it is not that bad. > - clients not able to read the new format will just ignore it and will > continue to parse the jcard. > - clients that are updated and prefer the new format just parse the > new format and ignore the jcard. > - wait a while. at some point in time, deprecate jcard. > > My point here is that there is a smooth path to the new format, which > has some costs, but it is doable and not that complicated. > > Regards, Marc. > > _______________________________________________ > regext mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
