Il 07/12/2021 14:42, Marc Blanchet ha scritto:
Le 7 déc. 2021 à 08:35, Hollenbeck, Scott
<shollenbeck=40verisign....@dmarc.ietf.org> 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
“Be liberal in what you accept” applies.
yes.
Marc.
Scott
*From:*regext <regext-boun...@ietf.org>*On Behalf Of*Mario Loffredo
*Sent:*Tuesday, December 7, 2021 3:45 AM
*To:*Antoin Verschuren <ietf=40antoin...@dmarc.ietf.org>;regext@ietf.org
*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.
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
<mario.loffr...@iit.cnr.it> 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:*
internet-dra...@ietf.org
*A:*
Gavin Brown<gavin.br...@centralnic.com>
<mailto:gavin.br...@centralnic.com>, Mario
Loffredo<mario.loffr...@iit.cnr.it>
<mailto:mario.loffr...@iit.cnr.it>
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://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:
This document describes an RDAP extension which represents entity
contact information in JSON responses using JSContact.
The IETF Secretariat
_______________________________________________
regext mailing list
regext@ietf.org
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
regext@ietf.org
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>
_______________________________________________
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
