Update .POST Section

[groundcat]

I am creating this pull request to update the .POST block in the ICANN section.

Starting today, any legal entity engaged in the postal, logistics, or supply chain sectors can register its name in .post, .com.post, .org.post and .edu.post.

Steps taken to verify information from the authoritative source:

1. Started at the IANA page: https://www.iana.org/domains/root/db/post.html and identified the registry website for registration services http://www.upu.int
2. From https://www.upu.int, located registry website https://trust.post
3. From https://trust.post located the policy page https://trust.post/legal/
4. Located "Table 2 – Domain naming conventions and restrictions":

Therefore, adding:

com.post
edu.post
org.post

Other supplemental information from the registrar:

https://www.101domain.com/post.htm

[simon-friedberger]

@groundcat More general discussion point: Should we actually add these? Is it worth checking if these domains are actually in use first?

After all, we are increasing the size of the list, but maybe these are just ideas the registrar had that nobody was ever interested in buying.

[groundcat]

After all, we are increasing the size of the list, but maybe these are just ideas the registrar had that nobody was ever interested in buying.

Good point. I personally doubt that many registrants would choose to purchase third-level .post domains, except for brand protection purposes, also given the price of 129.99 USD per year.

It might end up like the super long list of .aero SLD suffixes in the PSL, which almost no one uses after the registry introduced them, expecting there would be interest. Honestly, .aero has so many entries that many or most of them should probably be removed.

A similar example in the ccTLD space is .jp, which had an overly long list of city- or regional-level second-, third-, and even fourth-level domains. In 2012, JPRS eventually decided to decommission that structure, but the suffixes remain in the PSL and currently many are returning NXDOMAIN.

More general discussion point: Should we actually add these? Is it worth checking if these domains are actually in use first?

This brings us to the question: when registries in the ICANN/IANA section roll out new second-level suffixes (opening up .sld.tld for registration), should we evaluate them in the similar way as addition requests in the private section by assessing their relevance (e.g., user count)? If so, what should be the standard? Do suffixes in the ICANN/IANA section have a higher privilege and a more relaxed relevance threshold compared to the new suffixes proposed for private section domains?

Additionally, for ccTLDs—particularly those of smaller countries with lower populations—I have noticed very low usage of some third-level domains under the SLDs of some of the ccTLDs. However, this low usage would seem reasonable when considering the country's population, along with other geopolitical or registry policy factors.

Therefore, if we need to establish a standard for evaluating such cases, it would likely be best to allow more flexibility compared to the standards applied to private section domains. However, greater flexibility often comes at the cost of reduced neutrality, and I am not entirely sure how to approach this in a feasible and balanced way, honestly.

The points above are more of a general discussion that goes beyond the specific case of the .post gTLD. However, determining whether to include it or not should ideally follow a consistent practice to guide future decisions on similar cases.

[simon-friedberger]

I totally agree and we have had even more fun issues like this in the past: #277 which is listed at https://github.com/publicsuffix/list/wiki/Design-issues.

And actually .post in particular has been discussed before: #270

We circumvented this discussion by requiring that the TLD come to us and at least ask for addition but I definitely appreciate the cleanup work that you are currently doing that's why I thought we should reconsider.

[dnsguru]

I agree. Let the .post administrators direct the PSL on the configuration so it is intentional.

ALSO, in reading the table 2 from 4.9 of the registry documentation where the specify com/edu/org, we failed to include rule 2 which would have added a lot of 2 char subspace entries as well (ie us.post for United States, it.post for Italy, etc) it is not identical 1-1 with ISO 3166

[groundcat]

Upon reviewing #270 (thank you for pointing me to this PR) and the registry policy, I have realized that .post includes not only com.post, edu.post, and org.post but also all {country_code}.post suffixes. This would make the PSL terribly long if all of these were added!

I agree that for such heavily structured TLDs, it is necessary to reconsider. Personally, I would be against adding the country-coded ones (such as ch.post or italy.post, as mentioned in the registry policy) to the PSL at the moment. Perhaps for heavily structured TLDs, we do need to evaluate relevance before selectively deciding which ones to add to the PSL.

Hence, I am going to close this PR for now, not only due to the risk of inflating the PSL to an impracticable length but also because the com.post, edu.post, and org.post suffixes seem to have no visible usage. We can refer back to this if the .post registry decides to submit directly to us, at which point we will reconsider it.

[dnsguru]

As a bit of institutional knowledge, .name, if one followed the registry rules, would contain subdomains for around 200k surnames, as they accept john.smith.name and jane.smith.name as registrations - we opted at the time to allow the registry to request it at such time they intended. Its been 20 years