Hi all. Reading this CircleId article http://www.circleid.com/posts/domain_registrars_given_a_six_month_deadline_t... one question comes to my mind. Is the implementation of RDAP UA-compliant? I mean, will it be possible to store data in different scripts? Thanks for enlighten me on this topic. Cheers, Roberto
Yes. Part of the design criteria for the protocol. If someone can't do that with RDAP they have gone out of their way to break it. A -- Andrew Sullivan Please excuse my clumbsy thums. On March 7, 2019 06:46:19 Roberto Gaetano <roberto_gaetano@hotmail.com> wrote:
Hi all. Reading this CircleId article http://www.circleid.com/posts/domain_registrars_given_a_six_month_deadline_t... one question comes to my mind. Is the implementation of RDAP UA-compliant? I mean, will it be possible to store data in different scripts? Thanks for enlighten me on this topic. Cheers, Roberto
I would say yes and no Yes it is designed into the protocol and in a perfect world that would mean yes ir is covered. Sometimes the world is not perfect. We should realize that there is a fast cycle on things being put in place and deployed. I agree with Andrew, but would add that I don't think someone would be trying to deliberately break UA if an RDAP implimentation was not solving field data element encoding suddenly. Notwithstanding what Andrew said about it being potentially included, I think assuming RDAP will fix storage of Unicode for UA may not be correct unless explicitly stated by a given implementation. Given the expedited pace of implementation that industry is faced with, for many it is unfortunately a resourcing triage... which means teams may focus upon core operations that are required for compliance and will likely apply the most immediate attention them and to other things later. All hypithetical, but an example might be that If systems that are being updated for RDAP had UA deficiencies (western encoded data field in database might be an example), these may not be being adapted immediately to meet the implementation date. It might even prove to place "compliance by deadline" in jeopardy to modify database field structures. I could see a team, under those circumstances, deferring such a change. Testing and verification of UA may also not be at the front of the list of priorities. I think exposing some of these details helps inform the dialog so that we are not letting people mentally tick the box next to "mission accomplished" on UA just because RDAP came along. Especially when things are happening in expedited timelines. -Jothan On Thu, Mar 7, 2019, 06:49 Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Yes. Part of the design criteria for the protocol. If someone can't do that with RDAP they have gone out of their way to break it.
A -- Andrew Sullivan Please excuse my clumbsy thums.
On March 7, 2019 06:46:19 Roberto Gaetano <roberto_gaetano@hotmail.com> wrote:
Hi all. Reading this CircleId article http://www.circleid.com/posts/domain_registrars_given_a_six_month_deadline_t... one question comes to my mind. Is the implementation of RDAP UA-compliant? I mean, will it be possible to store data in different scripts? Thanks for enlighten me on this topic. Cheers, Roberto
On Mar 7, 2019 06:49, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote: Yes. Part of the design criteria for the protocol. If someone can't do that with RDAP they have gone out of their way to break it. A -- Andrew Sullivan Please excuse my clumbsy thums. On March 7, 2019 06:46:19 Roberto Gaetano <roberto_gaetano@hotmail.com> wrote:
Hi all. Reading this CircleId article http://www.circleid.com/posts/domain_registrars_given_a_six_month_deadline_t... one question comes to my mind. Is the implementation of RDAP UA-compliant? I mean, will it be possible to store data in different scripts? Thanks for enlighten me on this topic. Cheers, Roberto
On Thu, Mar 07, 2019 at 09:17:32AM +0900, Jothan Frakes wrote:
Yes it is designed into the protocol and in a perfect world that would mean yes ir is covered.
That is certainly not what I was suggesting.
We should realize that there is a fast cycle on things being put in place and deployed.
Fast? I'm sorry, but we designed this protocol _years and years_ ago. ICANN did nothing.
Notwithstanding what Andrew said about it being potentially included, I think assuming RDAP will fix storage of Unicode for UA may not be correct unless explicitly stated by a given implementation.
I think the above betrays a misunderstanding of the internationalization support in the wire format. See section 9 of RFC 7480 and section 12.1 of RFC 7483. Regardless of how you store things in the back end, you need to be able to use UTF-8 on the wire. If the point is that maybe your back end can't store everything expressible by UTF-8, then it turns out your repository can't actually store all the stuff you have registered. If on the other hand the problem is that you're storing something from someone _else's_ repository, why are you doing that? Store a referral. A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew, On Mar 7, 2019, at 3:00 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
We should realize that there is a fast cycle on things being put in place and deployed. Fast? I'm sorry, but we designed this protocol _years and years_ ago. ICANN did nothing.
Nothing? The ICANN community put a contractual obligation to deploy RDAP 135 days after the IETF standardized (to Proposed Standard) and it was "commercially reasonable in the context of the overall operation of the registry”. It’s that latter bit which has taken _years and years_ and outside of the control of the ICANN organization. However ICANN (both Organization and community) has not been idle: we’ve deployed the IANA RDAP Bootstrap service, we have funded the development of an RDAP client, we facilitated an RDAP pilot among registries and registers as well as supported the development of an operational profile that will allow the RDAP implementations to work together. Suggesting ICANN has done nothing is IMHO insulting. Regards, -drc
On Thu, Mar 07, 2019 at 06:22:26AM +0000, David Conrad wrote:
Nothing? The ICANN community put a contractual obligation to deploy RDAP 135 days after the IETF standardized (to Proposed Standard) and it was "commercially reasonable in the context of the overall operation of the registry”. It’s that latter bit which has taken _years and years_ and outside of the control of the ICANN organization.
I should have been clearer that the policy-making side of the community, which needed to adopt real policy changes in order to do many of the things that were desirable, froze up in the same way it has since the beginning over every whois discussion. I did not intend in any way to impugn ICANN the organization, which did in my opinion extend itself right to the limits of existing consensus policies in order to inspire RDAP adoption and deployment.
Suggesting ICANN has done nothing is IMHO insulting.
I offer my sincere apologies for any insult I caused. It was inadvertent but that is not an excuse. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew So long as the repository is at least UTF-8 capable, then there shouldn't be a problem with storing these elements. I wonder, however, if Jothan is speaking about using validation checks (what's a valid tld, email, etc.) after receiving the data. Done hastily, that could cause UA issues, although it's got nothing to do with RDAP. Although, I don't see why a data storer does not just take what's given by the source and store with high fidelity. Ram On Thu, Mar 7, 2019, 3:01 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Thu, Mar 07, 2019 at 09:17:32AM +0900, Jothan Frakes wrote:
Yes it is designed into the protocol and in a perfect world that would mean yes ir is covered.
That is certainly not what I was suggesting.
We should realize that there is a fast cycle on things being put in place and deployed.
Fast? I'm sorry, but we designed this protocol _years and years_ ago. ICANN did nothing.
Notwithstanding what Andrew said about it being potentially included, I think assuming RDAP will fix storage of Unicode for UA may not be correct unless explicitly stated by a given implementation.
I think the above betrays a misunderstanding of the internationalization support in the wire format. See section 9 of RFC 7480 and section 12.1 of RFC 7483. Regardless of how you store things in the back end, you need to be able to use UTF-8 on the wire. If the point is that maybe your back end can't store everything expressible by UTF-8, then it turns out your repository can't actually store all the stuff you have registered.
If on the other hand the problem is that you're storing something from someone _else's_ repository, why are you doing that? Store a referral.
A -- Andrew Sullivan ajs@anvilwalrusden.com
Hello All, For many years registration data have been in English ( yes, sometimes poorly transliterated, but still), so I do not think that RDAP implementations of Registries and Registrars will suffer from UA issues, but only due to the ASCII (here I meant the set of characters allowed in RA and RAA 2013 contracts) nature of the data in the platforms (real contractual data of a Registrar is not equal to the restoration data, for many reasons). I do not speak about short implementation time (platforms are already live and punishments for not following SLAs are severe for Registries). One of the biggest issues is RSEP procedures for Registries (the moment a Registry tries to use non ASCII there - rises Compliance issues ). And - even if a Registry implements non ASCII output of it's RDAP - Registrars have to be big enough to spend time and money on something , which is optional for them. Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID m. +7 916 6761580(+whatsapp) skype oldfrogger Current UTC offset: +3.00 (.Moscow)
On 7 Mar 2019, at 12:11, Ram Mohan <rmohan@afilias.info> wrote:
Andrew So long as the repository is at least UTF-8 capable, then there shouldn't be a problem with storing these elements.
I wonder, however, if Jothan is speaking about using validation checks (what's a valid tld, email, etc.) after receiving the data. Done hastily, that could cause UA issues, although it's got nothing to do with RDAP.
Although, I don't see why a data storer does not just take what's given by the source and store with high fidelity.
Ram
On Thu, Mar 7, 2019, 3:01 PM Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote: On Thu, Mar 07, 2019 at 09:17:32AM +0900, Jothan Frakes wrote:
Yes it is designed into the protocol and in a perfect world that would mean yes ir is covered.
That is certainly not what I was suggesting.
We should realize that there is a fast cycle on things being put in place and deployed.
Fast? I'm sorry, but we designed this protocol _years and years_ ago. ICANN did nothing.
Notwithstanding what Andrew said about it being potentially included, I think assuming RDAP will fix storage of Unicode for UA may not be correct unless explicitly stated by a given implementation.
I think the above betrays a misunderstanding of the internationalization support in the wire format. See section 9 of RFC 7480 and section 12.1 of RFC 7483. Regardless of how you store things in the back end, you need to be able to use UTF-8 on the wire. If the point is that maybe your back end can't store everything expressible by UTF-8, then it turns out your repository can't actually store all the stuff you have registered.
If on the other hand the problem is that you're storing something from someone _else's_ repository, why are you doing that? Store a referral.
A -- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>
participants (6)
-
Andrew Sullivan -
David Conrad -
Jothan Frakes -
Maxim Alzoba -
Ram Mohan -
Roberto Gaetano