Interesting point, Scott. Adopting JSContact (and deprecating jCard eventually)
seems a tradeoff between ease-of-implementation for future servers/clients and
diminishing returns for the current servers/clients. Should the latter
(diminishing returns) prevent the former (easy-of-implementation)? It may help
to gauge what other protocols have done in the past when presented with such a
trade-off.
Jasdip
On 1/29/21, 8:16 AM, "regext on behalf of Hollenbeck, Scott"
<regext-boun...@ietf.org on behalf of
shollenbeck=40verisign....@dmarc.ietf.org> wrote:
> -----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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
