Subject: Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt

From: Antoin Verschuren <[email-masked]>
Date: Mon, 6 Dec 2021 15:29:21 +0100

Hi all,

In addition to the questions from Mario, we still need to discuss the status of this document as discussed during the IETF112 meeting:

"the document doesn’t have designated status; it was adopted without a status (on purpose). We need to think about the implications. Encouraged group to discuss/comment on the list”

Meaning that because jCard is not depreciated with publishing this document, what will the status of this document be? We cannot have 2 standards, so we need to say something about it.

Jim and Antoin

> Op 27 nov. 2021, om 09:04 heeft Mario Loffredo <[email-masked]> het volgende geschreven:
> 
> Hi folks,
> 
> this new version addresses the feedback provided by Jasdip except for the following two points left for WG discussion:
> 
> 1) In the sentence "To aid interoperability, RDAP providers are RECOMMENDED to use as map keys the following string values and labels defined in [RFC5733].", should  "are RECOMMNEDED to" be replaced with "MUST"?
> 
> 2)  Does the portion of the spec for jCard to JSContact transition signaling add significant implementation overhead for RDAP servers and clients? Could an out-of-band (OOB) method have been employed?
> 
> 
> Three more implementations were included.
> 
> Best,
> Mario
> 
> 
> -------- Messaggio Inoltrato --------
> Oggetto:	New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt
> Data:	Fri, 26 Nov 2021 23:53:34 -0800
> Mittente:	[email-masked] <mailto:[email-masked]>
> A:	Gavin Brown <[email-masked]> <mailto:[email-masked]>, Mario Loffredo <[email-masked]> <mailto:[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-regext-rdap-jscontact-04.txt
> has been successfully submitted by Mario Loffredo and posted to the
> IETF repository.
> 
> Name: draft-ietf-regext-rdap-jscontact
> Revision: 04
> Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses
> Document date: 2021-11-26
> Group: regext
> Pages: 22
> URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-04.txt <https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-04.txt>
> Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ <https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/>
> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact <https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact>
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-jscontact-04 <https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-jscontact-04>
> 
> Abstract:
> This document describes an RDAP extension which represents entity
> contact information in JSON responses using JSContact.
> 
> 
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 6 Dec 2021 09:33:48 -0500

> Le 6 déc. 2021 à 09:29, Antoin Verschuren <ietf=[email-masked]> a écrit :
> 
> Hi all,
> 

"We cannot have 2 standards, ». I’m not sure what you really meant, but as is, I disagree. We have two standards for IP: IPv4 and IPv6. At some point in the future, one will be deprecated, but these are two full standards. So I expect that JCard and JSContact will be 2 standards for quite a while (hopefully less time than IPv4 and IPv6…) and those two standards will be used concurrently until one is fully deprecated.  Unless you meant something else.

Marc.

> 
> Jim and Antoin
> 
> 
>> Op 27 nov. 2021, om 09:04 heeft Mario Loffredo <[email-masked] <mailto:[email-masked]>> het volgende geschreven:
>> 
>> Hi folks,
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 7 Dec 2021 09:45:25 +0100

Hi all,

maybe I'm missing something but is there anybody explaining me why we 
can have two standards for the email address in EPP but we cannot have 
two standards for the contact card in RDAP ?

I admit that the reasons supporting the two documents are different but 
their matters appear very similar to me.

Using JSContact inside RDAP is basically an extension.

If we remove stages 3 and 4 of the transition from the document, we 
simply have an RDAP extension that is or isn't implemented  by a server.

This extension can be firstly signaled by the server, then requested by 
the client and consequently returned by the server just as it happens 
for the EAI extension in the EPP context.

Best,

Mario

Il 06/12/2021 15:29, Antoin Verschuren ha scritto:
> Hi all,
>
> In addition to the questions from Mario, we still need to discuss the 
> status of this document as discussed during the IETF112 meeting:
>
> "the document doesn’t have designated status; it was adopted without a 
> status (on purpose). We need to think about the implications. 
> Encouraged group to discuss/comment on the list”
>
> Meaning that because jCard is not depreciated with publishing this 
> document, what will the status of this document be? We cannot have 2 
> standards, so we need to say something about it.
>
> Jim and Antoin
>
>
>> Op 27 nov. 2021, om 09:04 heeft Mario Loffredo 
>> <[email-masked]> het volgende geschreven:
>>
>> Hi folks,
>>
>> this new version addresses the feedback provided by Jasdip except for 
>> the following two points left for WG discussion:
>>
>> 1) In the sentence "To aid interoperability, RDAP providers are 
>> RECOMMENDED to use as map keys the following string values and labels 
>> defined in [RFC5733].", should "are RECOMMNEDED to" be replaced with 
>> "MUST"?
>>
>> 2) Does the portion of the spec for jCard to JSContact transition 
>> signaling add significant implementation overhead for RDAP servers 
>> and clients? Could an out-of-band (OOB) method have been employed?
>>
>>
>> Mittente: 	[email-masked]
>> A: 	Gavin Brown <[email-masked]>, Mario Loffredo 
>> <[email-masked]>
>>
>>
>>
>>
>> URL: 
>> https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-04.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact
>> Diff: 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-jscontact-04
>>
>> Abstract:

-- 
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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 7 Dec 2021 13:35:59 +0000

We can *certainly* do that, Mario. It’s the option I support because there is 
a cost to replace a jCard implementation once it’s been implemented and 
deployed. Make it an optional extension and let server operators decide 
if/when they want to make the change.

I note that this will make life more difficult for client implementors because 
they’ll have to support both formats. “Be liberal in what you accept” applies.

Scott

From: regext <[email-masked]> On Behalf Of Mario Loffredo
Sent: Tuesday, December 7, 2021 3:45 AM
To: Antoin Verschuren <ietf=[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [regext] New Version Notification for 
draft-ietf-regext-rdap-jscontact-04.txt

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.

Hi all,

maybe I'm missing something but is there anybody explaining me why we can have 
two standards for the email address in EPP but we cannot have two standards 
for the contact card in RDAP ?

I admit that the reasons supporting the two documents are different but their 
matters appear very similar to me.

If we remove stages 3 and 4 of the transition from the document, we simply 
have an RDAP extension that is or isn't implemented  by a server.

This extension can be firstly signaled by the server, then requested by the 
client and consequently returned by the server just as it happens for the EAI 
extension in the EPP context.

Best,

Mario

Hi all,

In addition to the questions from Mario, we still need to discuss the status 
of this document as discussed during the IETF112 meeting:

"the document doesn’t have designated status; it was adopted without a status 
(on purpose). We need to think about the implications. Encouraged group to 
discuss/comment on the list”

Meaning that because jCard is not depreciated with publishing this document, 
what will the status of this document be? We cannot have 2 standards, so we 
need to say something about it.

Jim and Antoin

Op 27 nov. 2021, om 09:04 heeft Mario Loffredo <[email-masked] 
<mailto:[email-masked]> > het volgende geschreven:

Hi folks,

this new version addresses the feedback provided by Jasdip except for the 
following two points left for WG discussion:

1) In the sentence "To aid interoperability, RDAP providers are RECOMMENDED to 
use as map keys the following string values and labels defined in [RFC5733].", 
should  "are RECOMMNEDED to" be replaced with "MUST"?

2)  Does the portion of the spec for jCard to JSContact transition signaling 
add significant implementation overhead for RDAP servers and clients? Could an 
out-of-band (OOB) method have been employed?

Best,

Mario

-------- Messaggio Inoltrato -------- 

Oggetto:

New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt

Data:

Fri, 26 Nov 2021 23:53:34 -0800

Mittente:

[email-masked] <mailto:[email-masked]>

A:

Gavin Brown  <mailto:[email-masked]> <[email-masked]>, 
Mario Loffredo  <mailto:[email-masked]> <[email-masked]>

Name: draft-ietf-regext-rdap-jscontact
Revision: 04
Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON 
Responses
Document date: 2021-11-26
Group: regext
Pages: 22
URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-04.txt 
<https://secure-web.cisco.com/14C9FIzXAabWencuKkfeJHEUIspLRA3vKcibCBAn8d6rkSbdYnSlsiivk7_oUmXQiIKRVCeKBoIDfjtlNpBiGfsi1PYLN0guFFNdge8oKVYz6sXAITU-c__KkrKSASh9QNhhFSeMaT6o6kXpXMVVkE-fyj3F3QS3OTDvB4JVlWfq8dGbZRLGThn8FN_LZeLxvQ9ZmV0FqwGDFJ8mXwVlTVQxJtYbbKqrrOg-cHPfsTfHI-tfNGBMYc1oCo-KJEcGIHyTr_xWrRVBt57TP3og1_A/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-jscontact-04.txt>
Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ 
<https://secure-web.cisco.com/1Ru0-ukndBHr35j11l7TbzmcTICx_vW_UQOtspG2s5fWR1GXL52pq0EC23L3tkJmBK5rMBoeqT5l47yNp3xo6Yutj7La8950_hN_dglrdl1Wqg6Y8PZlcu-xEQkAEAwqd76o1XeILDPsEUWg7dW9u64Q4iei9aIGwWTp7cUI9FqbJ2aUAuVdJgV0RPgFJKQThqkbObsmeflT9zKfz5JYvMDgFRzKCpbPao7vM1qgFWyKtM-YRzYVytjeOD8DgVFy8_4N1HWyM_54nYGP3GeATZQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-jscontact%2F>
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact 
<https://secure-web.cisco.com/19TI1J3mToiqQ92UliYRU_hu5X08ToLlRGxwP8aqK3SiGaTvoACCTy9fbITG9yHefpzqE6bHt0SiRSne9fUisRHRTvPoX7pQj4sR_gOGtU2Ai8l5Fr87A-YMhBPSCHKnS0bGvxZacNYJyAQHP0agmTIU4FVEA3YXGF-bq9ou85JQD9lMj6DeUw7hUwPPgOYGbxtxkzia8cOuNqpC0LVoV4BhnmEBBBR_HcThbu-frBham9kJdJzrISQ0RiWb5ToqtRbdxh6ynyhhsCPGeOiGKVw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-jscontact>
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-jscontact-04 
<https://secure-web.cisco.com/1EBi9cZtxmsU5k8EO3QiMXQAVKWxjJRNxRZI2yMoKbE6LJrtOf0rFSk0N1ixGBZqTpwdKgibLHfjsg3vEtYKVY7S38JyvZPiW1NRRHeh7XNV8R2wBHWf6tLdSdboMOrh6QK1Qf4kqltCfG9QO8uNO2fFh9D2LCkn7RRzmucDBpQQ5Jsn0ty53Q0c1d5O0_fq73wytVBuQA-r8BT0-u0ZrSGDn7r6B811efV9mfKLw5YvP7pwOZ5mCbYdEJwgF-I1fVPPnvXTNTRyWHDpR6yExkw/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-rdap-jscontact-04>

Abstract:

The IETF Secretariat

_______________________________________________
regext mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext 
<https://secure-web.cisco.com/1Gi22wRMnaHCD8TuzZKbXz7KGwFyaZmuiSLrDsh5SG3OhkvKtshKQW0FgCMwx4sEMEhVgeXvE0ltyMXpuHg1stdpoHQQxxuJtP6ByYkMyMnTwcFMz_8WuxprOfldERyYwXs_KgqUPzuJQ3PLFPg3x2ZEQBOs82jQ1OeRNUOuDmqhMwDZCw0WaV2QbiIIAxopz5TIko-CWnCSqlMI7zBjWLkSGikhdrnpEVmhR0ZIxl0GHKmQ7y5Rjfgr5gVZ7iIw89StNME_YufpahpysKAQ5zQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

_______________________________________________
regext mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext 
<https://secure-web.cisco.com/1Gi22wRMnaHCD8TuzZKbXz7KGwFyaZmuiSLrDsh5SG3OhkvKtshKQW0FgCMwx4sEMEhVgeXvE0ltyMXpuHg1stdpoHQQxxuJtP6ByYkMyMnTwcFMz_8WuxprOfldERyYwXs_KgqUPzuJQ3PLFPg3x2ZEQBOs82jQ1OeRNUOuDmqhMwDZCw0WaV2QbiIIAxopz5TIko-CWnCSqlMI7zBjWLkSGikhdrnpEVmhR0ZIxl0GHKmQ7y5Rjfgr5gVZ7iIw89StNME_YufpahpysKAQ5zQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

-- 
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 
<http://secure-web.cisco.com/1xQyin4bhu_2NCO534UuTZ2wAiXLyAii222DWNxbt8H36eq74Vruw3nSYaz76oqk9IM7umlZ2jS716DNKq0vRiq99WGsncnuW-vpDMeSsxVxR4WaPxgSNDfSnop03oJ5jpXt0P9XLw_akEbWZQGi11gqLut9wKJFEPUtYkwh5P2P68Hr5WVqoiKMhuqvqRy8pMYoZdf288aX0QloxxoVxG_tbdJbYaVtmr1A0a3dbabDmEKF9PIw9AgTXFHjdQksrrllP41gryxYl2XZVBU8Cxg/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 7 Dec 2021 08:42:12 -0500

> Le 7 déc. 2021 à 08:35, Hollenbeck, Scott <shollenbeck=[email-masked]> a écrit :
> 
> We can *certainly* do that, Mario. It’s the option I support because there is a cost to replace a jCard implementation once it’s been implemented and deployed. Make it an optional extension and let server operators decide if/when they want to make the change.
>  
> I note that this will make life more difficult for client implementors because they’ll have to support both formats.

But the genie is already out of the bottle… I.e. if one have done a client implementation, it has already support for jCard. Adding the JSContact is just more code.  There will be only less work if one is implementing a client in the future after the whole ecosystem had moved to JSContact, therefore no need to implement jCard, which is still a good win, as I guess that many haven’t implemented a client yet since whois is still dominant and RDAP is not yet at the same level.

> “Be liberal in what you accept” applies.

yes.

Marc.

>  
> Scott
>  
> From: regext <[email-masked] <mailto:[email-masked]>> On Behalf Of Mario Loffredo
> To: Antoin Verschuren <ietf=[email-masked] <mailto:ietf=[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Subject: [EXTERNAL] Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt
>  
> 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. 
> 
> Hi all,
> 
> maybe I'm missing something but is there anybody explaining me why we can have two standards for the email address in EPP but we cannot have two standards for the contact card in RDAP ?
> 
> I admit that the reasons supporting the two documents are different but their matters appear very similar to me. 
> 
> If we remove stages 3 and 4 of the transition from the document, we simply have an RDAP extension that is or isn't implemented  by a server.
> 
> This extension can be firstly signaled by the server, then requested by the client and consequently returned by the server just as it happens for the EAI extension in the EPP context. 
> 
>  
> 
> Best,
> 
> Mario
> 
>  
> 
> Gavin Brown <[email-masked]> <mailto:[email-masked]>, Mario Loffredo <[email-masked]> <mailto:[email-masked]>
> 
> 
> 
> URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-04.txt <https://secure-web.cisco.com/14C9FIzXAabWencuKkfeJHEUIspLRA3vKcibCBAn8d6rkSbdYnSlsiivk7_oUmXQiIKRVCeKBoIDfjtlNpBiGfsi1PYLN0guFFNdge8oKVYz6sXAITU-c__KkrKSASh9QNhhFSeMaT6o6kXpXMVVkE-fyj3F3QS3OTDvB4JVlWfq8dGbZRLGThn8FN_LZeLxvQ9ZmV0FqwGDFJ8mXwVlTVQxJtYbbKqrrOg-cHPfsTfHI-tfNGBMYc1oCo-KJEcGIHyTr_xWrRVBt57TP3og1_A/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-jscontact-04.txt>
> Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ <https://secure-web.cisco.com/1Ru0-ukndBHr35j11l7TbzmcTICx_vW_UQOtspG2s5fWR1GXL52pq0EC23L3tkJmBK5rMBoeqT5l47yNp3xo6Yutj7La8950_hN_dglrdl1Wqg6Y8PZlcu-xEQkAEAwqd76o1XeILDPsEUWg7dW9u64Q4iei9aIGwWTp7cUI9FqbJ2aUAuVdJgV0RPgFJKQThqkbObsmeflT9zKfz5JYvMDgFRzKCpbPao7vM1qgFWyKtM-YRzYVytjeOD8DgVFy8_4N1HWyM_54nYGP3GeATZQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-jscontact%2F>
> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact <https://secure-web.cisco.com/19TI1J3mToiqQ92UliYRU_hu5X08ToLlRGxwP8aqK3SiGaTvoACCTy9fbITG9yHefpzqE6bHt0SiRSne9fUisRHRTvPoX7pQj4sR_gOGtU2Ai8l5Fr87A-YMhBPSCHKnS0bGvxZacNYJyAQHP0agmTIU4FVEA3YXGF-bq9ou85JQD9lMj6DeUw7hUwPPgOYGbxtxkzia8cOuNqpC0LVoV4BhnmEBBBR_HcThbu-frBham9kJdJzrISQ0RiWb5ToqtRbdxh6ynyhhsCPGeOiGKVw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-jscontact>
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-jscontact-04 <https://secure-web.cisco.com/1EBi9cZtxmsU5k8EO3QiMXQAVKWxjJRNxRZI2yMoKbE6LJrtOf0rFSk0N1ixGBZqTpwdKgibLHfjsg3vEtYKVY7S38JyvZPiW1NRRHeh7XNV8R2wBHWf6tLdSdboMOrh6QK1Qf4kqltCfG9QO8uNO2fFh9D2LCkn7RRzmucDBpQQ5Jsn0ty53Q0c1d5O0_fq73wytVBuQA-r8BT0-u0ZrSGDn7r6B811efV9mfKLw5YvP7pwOZ5mCbYdEJwgF-I1fVPPnvXTNTRyWHDpR6yExkw/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-rdap-jscontact-04>
> 
> Abstract:
> https://www.ietf.org/mailman/listinfo/regext <https://secure-web.cisco.com/1Gi22wRMnaHCD8TuzZKbXz7KGwFyaZmuiSLrDsh5SG3OhkvKtshKQW0FgCMwx4sEMEhVgeXvE0ltyMXpuHg1stdpoHQQxxuJtP6ByYkMyMnTwcFMz_8WuxprOfldERyYwXs_KgqUPzuJQ3PLFPg3x2ZEQBOs82jQ1OeRNUOuDmqhMwDZCw0WaV2QbiIIAxopz5TIko-CWnCSqlMI7zBjWLkSGikhdrnpEVmhR0ZIxl0GHKmQ7y5Rjfgr5gVZ7iIw89StNME_YufpahpysKAQ5zQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>  
> 
> 
> https://www.ietf.org/mailman/listinfo/regext <https://secure-web.cisco.com/1Gi22wRMnaHCD8TuzZKbXz7KGwFyaZmuiSLrDsh5SG3OhkvKtshKQW0FgCMwx4sEMEhVgeXvE0ltyMXpuHg1stdpoHQQxxuJtP6ByYkMyMnTwcFMz_8WuxprOfldERyYwXs_KgqUPzuJQ3PLFPg3x2ZEQBOs82jQ1OeRNUOuDmqhMwDZCw0WaV2QbiIIAxopz5TIko-CWnCSqlMI7zBjWLkSGikhdrnpEVmhR0ZIxl0GHKmQ7y5Rjfgr5gVZ7iIw89StNME_YufpahpysKAQ5zQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
> -- 
> Dr. Mario Loffredo
> Web: http://www.iit.cnr.it/mario.loffredo <http://secure-web.cisco.com/1xQyin4bhu_2NCO534UuTZ2wAiXLyAii222DWNxbt8H36eq74Vruw3nSYaz76oqk9IM7umlZ2jS716DNKq0vRiq99WGsncnuW-vpDMeSsxVxR4WaPxgSNDfSnop03oJ5jpXt0P9XLw_akEbWZQGi11gqLut9wKJFEPUtYkwh5P2P68Hr5WVqoiKMhuqvqRy8pMYoZdf288aX0QloxxoVxG_tbdJbYaVtmr1A0a3dbabDmEKF9PIw9AgTXFHjdQksrrllP41gryxYl2XZVBU8Cxg/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>_______________________________________________
> regext mailing list
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 8 Dec 2021 10:55:26 +0100

Il 07/12/2021 14:42, Marc Blanchet ha scritto:
>
>> Le 7 déc. 2021 à 08:35, Hollenbeck, Scott 
>> <shollenbeck=[email-masked]> a écrit :
>>
>> We can **certainly** do that, Mario. It’s the option I support 
>> because there is a cost to replace a jCard implementation once it’s 
>> been implemented and deployed. Make it an optional extension and let 
>> server operators decide if/when they want to make the change.
>> I note that this will make life more difficult for client 
>> implementors because they’ll have to support both formats.
>
> But the genie is already out of the bottle… I.e. if one have done a 
> client implementation, it has already support for jCard. Adding the 
> JSContact is just more code.  There will be only less work if one is 
> implementing a client in the future after the whole ecosystem had 
> moved to JSContact, therefore no need to implement jCard, which is 
> still a good win, as I guess that many haven’t implemented a client 
> yet since whois is still dominant and RDAP is not yet at the same level.

+1

Every extension requires an implementation effort and every transition 
process from the old to the new requires a period where both coexist.

If we hadn't been aware of that, we wouldn't have started the process to 
replace Whois with RDAP. And, like Marc pointed out, this process is 
still at the beginning  and we still don't imagine when it will really 
be completed.

In addition to that, I wonder why some members are so worried about the 
implementation effort done in this case in comparison to other 
extensions that completed the reviewing process.

For example, why haven't we been so concerned about the implementation 
effort required to client and servers in order to implement the EPP 
Login Security extension and the consequent period where clients and 
servers should deal with both the password formats ? And what about the 
implementation effort done to replace custom solutions already existing 
with new standard solutions?

Honestly, it seems to me that the implementation effort required in this 
case is lower than the one required by other extensions.

I believe that the main point is if we (intended as most of us) finally 
agree that the benefits from implementing an extension far outweigh the 
required efforts and we have evidence that

the new will be significantly better than the old (and it seems to me we 
have it in this case).

But, at the same time, we are not sure that the majority of EPP or RDAP 
operators will implement it. That's it.

That being said, IMO, the status of this document should remain 
"Standard Track".

Best,

Mario

>> *From:*regext <[email-masked]>*On Behalf Of*Mario Loffredo
>> *Sent:*Tuesday, December 7, 2021 3:45 AM
>> *To:*Antoin Verschuren <ietf=[email-masked]>;[email-masked]
>> *Subject:*[EXTERNAL] Re: [regext] New Version Notification for 
>> *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.
>>
>> Hi all,
>>
>> can have two standards for the email address in EPP but we cannot 
>> have two standards for the contact card in RDAP ?
>>
>> I admit that the reasons supporting the two documents are different 
>> but their matters appear very similar to me.
>>
>> This extension can be firstly signaled by the server, then requested 
>> by the client and consequently returned by the server just as it 
>> happens for the EAI extension in the EPP context.
>>
>> Best,
>>
>> Mario
>>
>>     In addition to the questions from Mario, we still need to discuss
>>     the status of this document as discussed during the IETF112 meeting:
>>     "the document doesn’t have designated status; it was adopted
>>     without a status (on purpose). We need to think about the
>>     implications. Encouraged group to discuss/comment on the list”
>>     Meaning that because jCard is not depreciated with publishing
>>     this document, what will the status of this document be? We
>>     cannot have 2 standards, so we need to say something about it.
>>     Jim and Antoin
>>
>>
>>         this new version addresses the feedback provided by Jasdip
>>         except for the following two points left for WG discussion:
>>         1) In the sentence "To aid interoperability, RDAP providers
>>         are RECOMMENDED to use as map keys the following string
>>         values and labels defined in [RFC5733].", should  "are
>>         RECOMMNEDED to" be replaced with "MUST"?
>>         2)  Does the portion of the spec for jCard to JSContact
>>         transition signaling add significant implementation overhead
>>         for RDAP servers and clients? Could an out-of-band (OOB)
>>         method have been employed?
>>         *Oggetto:*
>>         *Data:*
>>         *Mittente:*
>>         [email-masked]
>>         *A:*
>>         Gavin Brown<[email-masked]>
>>         <mailto:[email-masked]>, Mario
>>         Loffredo<[email-masked]>
>>         <mailto:[email-masked]>
>>
>>
>>
>>
>>         URL:https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-04.txt
>>         Status:https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
>>         Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact
>>         Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-jscontact-04
>> Web:http://www.iit.cnr.it/mario.loffredo  <http://secure-web.cisco.com/1xQyin4bhu_2NCO534UuTZ2wAiXLyAii222DWNxbt8H36eq74Vruw3nSYaz76oqk9IM7umlZ2jS716DNKq0vRiq99WGsncnuW-vpDMeSsxVxR4WaPxgSNDfSnop03oJ5jpXt0P9XLw_akEbWZQGi11gqLut9wKJFEPUtYkwh5P2P68Hr5WVqoiKMhuqvqRy8pMYoZdf288aX0QloxxoVxG_tbdJbYaVtmr1A0a3dbabDmEKF9PIw9AgTXFHjdQksrrllP41gryxYl2XZVBU8Cxg/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>

---

From: Gavin Brown <[email-masked]>
Date: Wed, 8 Dec 2021 10:31:09 +0000

On 8 Dec 2021, at 09:55, Mario Loffredo <[email-masked]> wrote:
> Every extension requires an implementation effort and every transition process from the old to the new requires a period where both coexist. 
> 
> If we hadn't been aware of that, we wouldn't have started the process to replace Whois with RDAP. And, like Marc pointed out, this process is still at the beginning  and we still don't imagine when it will really be completed.
> 
> In addition to that, I wonder why some members are so worried about the implementation effort done in this case in comparison to other extensions that completed the reviewing process.

Speaking as a client implementer, the amount of work required to update my RDAP client to support JSContact was minimal - which speaks to how much easier JSContact is to work with than jCard. You can see every change required in https://client.rdap.org here:

https://gitlab.centralnic.com/centralnic/rdap-web-client/-/compare/ba4fd514...c9deae03

Getting JSContact working in the CentralNic RDAP server took a bit more work, but I see it as being worthwhile if it makes life easier for client implementers.

We are still in the early days of RDAP, and the amount of RDAP code that exists now is much smaller than the amount of RDAP code still to be written. If we can make a modest change now that makes that future code smaller and easier to write and maintain, we should do so.

(full disclosure: I am a co-author on this draft).

G.

> 
> For example, why haven't we been so concerned about the implementation effort required to client and servers in order to implement the EPP Login Security extension and the consequent period where clients and servers should deal with both the password formats ? And what about the implementation effort done to replace custom solutions already existing with new standard solutions?
> 
> Honestly, it seems to me that the implementation effort required in this case is lower than the one required by other extensions.
> 
> I believe that the main point is if we (intended as most of us) finally agree that the benefits from implementing an extension far outweigh the required efforts and we have evidence that 
> 
> the new will be significantly better than the old (and it seems to me we have it in this case).
> 
> But, at the same time, we are not sure that the majority of EPP or RDAP operators will implement it. That's it.
> 
> 
> 
> 
> That being said, IMO, the status of this document should remain "Standard Track".

+1

>>> Gavin Brown <[email-masked]>, Mario Loffredo <[email-masked]>
>>> 
>>> 
>>> 
>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: http://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR.

https://www.centralnic.com