> -----Original Message----- > From: regext <regext-boun...@ietf.org> On Behalf Of James Galvin > Sent: Monday, January 18, 2021 9:29 AM > To: REGEXT WG <regext@ietf.org> > Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-loffredo-regext- > rdap-jcard-deprecation-03 > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > This is a formal adoption request for “Using JSContact in Registration Data > Access Protocol (RDAP) JSON Responses”:
While I understand the motivation for this draft, I'm a little worried that it's trying to solve a problem that is no longer a problem for anyone who has completed a jCard implementation. At this point, RDAP implementations with jCard are quite widespread among registries, registrars, and RIRs. Yes, we've heard that jCard can be cumbersome or tedious to implement, but once that work is done, an implementer has something that works. Due to the nature of the problem domain, it is stable and doesn't require maintenance. While an implementation involving jSContact would certainly be more elegant from a technical perspective, I see limited value in developing a specification that would imply re-doing what has already been implemented to produce something that does basically the same thing. There must be some material benefit for implementers (of both servers and then clients) to offset the development and deployment cost of re-implementing the contact representation. Section 2 of the draft describes differences from jCard - are they enough to justify this investment? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
