Closed peterthomassen closed 1 month ago
gtldresult.icann.org/applicationstatus/applicationdetails/463 This was in a contention set, and is in 'contracting' phase, but is not yet a root-listed TLD
We designed the automation to go from the JSON file published by ICANN, as it gave a decent lead time before the TLDs would be added to he root zone, which helped reduce the propogation delay issues. IE when the TLD got added, it would exist in the PSL so that their TLD would go to DNS and not Searchengineland
Quoted from https://github.com/publicsuffix/list/pull/2154#issuecomment-2350898381
If I'm interpreting it correctly, it's basically so providers that use the PSL will add support for that TLD before it is officially added to the root zone, so basically it is being added early in order to reduce lag time as much as possible.
Makes sense. Thanks! Also, sorry I had missed the original discussion.
@simon-friedberger Can you please delete the comment posted by @Ahmed-khalil3, it contains a malicious link. I've reported it to bit.ly and GitHub already, however it should be deleted here too.
[ @peterthomassen @simon-friedberger @mozfreddyb @wdhdev @weppos FYI ]
For documentation, I just wanted to provide some background and state that certain undelegated strings were in the PSL intentionally, IF they are furnished as elements within the json file received from ICANN.
( noting that strangely in the case of the TLD that prompted this issue, .merck, that string went through a strange removal/re-insert in the json output )
The listing of TLDs that were not in the root was entirely intentional and by design as a means to mitigate the propogation delay. It was put in place for the 2012 round of TLDs.
On the one hand, there can be delays in propogation of the list into browsers and other apps/systems combined with the lack of authority or control the PSL has to affect those propogation variances.
On the other hand, there was a fairly consistent flow of new TLDs released weekly when the 2012 TLD round started to have TLDs hit the root zone in late 2013 / early 2014.
When we established the process with ICANN to have them provide us with a report or data resource to create automation of the released TLDs and updates, we discovered that waiting until the top level domain would hit the root zone caused a poor user experience for the TLDs and internet users due to the unpredictable delay, and one which we could not do anything to mitigate.
We realized that we might be able to create a buffer timeframe and attempt to get the domain names into the PSL sooner than when they are added to the root zone, and initially thought that using the comprehensive list of applied-for strings was a good idea, but with ICANN's help, we determined that if a TLD had entered into contracting, it was the indicator that it was on a 'root trajectory' and was the most reasonable attribute to base a reliable pre-release list of the top level domain names that would be entering the root zone in advance.
We will likely need to rely on the existing process of json furnished by ICANN as the authority for gTLDs for the 2026 round, and make the same post-contracting list be the method, unless we come up with something stronger in the next few years.
So, yes, a TLD could be in contracting phase and not yet listed in the root zone, but be included in the PSL. And yes, that would be intentional, but be sourced from a trusted authority with a well planned rationale.
https://github.com/publicsuffix/list/pull/2154 adds
merck.
as a public suffix. I noticed that the link given in the entry comment (https://www.iana.org/domains/root/db/merck.html) does not exist.Digging deeper, I saw that this string is not delegated in the root zone.
ICANN's gTLD JSON list says:
This says that the string indeed has no delegation date, and also there does not seem to be a signed contract.
Is it correct that this shows up in the PSL, then?
If not: should be be filtering for
delegationDate
(and perhapsremovalDate
?