Hi,
the document has a twofold goal:
- introducing an alternative to jcard as an extension
- defining a deprecation process through which the extension can replace
jcard progressively
The document doesn't state that replacing jcard with jscontact is an
absolute must but it provides the means to make it possible.
Whether and when the transition procedure will be fully completed will
depend on the general consensus among RDAP implementers that jscontact
is a much more efficient representation of contact information than
jcard and, consequently, is worthy to be implemented.
Usually, when we propose an EPP or RDAP extension, we are not sure that
it will be widely adopted. We simply admit that an inefficiency or a
lack of functionality exists and we agree on a solution that can
represent a valid guidance for all the implementers. Ultimately, only
the implementers evaluate our proposals as worthy to be adopted.
Therefore, in my opinion, the main questions are: do we agree that jcard
is inefficient? do we agree that the solution proposed for fixing such
inefficiency can become a guidance for all the RDAP implementers?
Finally, I would like to say that I have released an open-source Java
library supporting the burden of those who are willing to implement the
proposal. At least in this case and for java developers, the
implementation effort wouldn't be so strong :-)
Best,
Mario
Il 29/01/2021 15:11, Jasdip Singh ha scritto:
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
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
