== Tasks to do ==
Sort out a contact email address # Decide on how to prevent email forgeries (Gerv recommends "pinging" each registry that sends an email and get them to confirm that they actually send it)
# Send the email to all TLD registries
# Monitor the email address regularly and manage changes
# Make the effective TLD list file available to other browser manufacturers
== Name ==
order to prevent the effective TLD list being seen as an authoritative database of effective TLDs, it will be called the Public Suffix List. Internally, however, the list and the service which uses it will continue to be known as the effective TLD list and effective TLD service respectively.
== Email address ==
The email address for submissions has not
as of yet been decided.
== Email address monitoring ==
The email address must be monitored
daily for emails, and submissions, after being verified as originating from the registry, must be integrated with the master list as soon as possible in order to be included in the next browser update and be available to as many users as possible.
== Email to registries ==
By design, web browsers set cookies for websites with very little checking to see whether the website in question is allowed to set that cookie. Therefore, there is the possibility that a website may set a cookie at a higher level than itself (e. g., example. co.uk could set a cookie for . co. uk). Since the domain the cookie is being set for matches at least part of the domain name where the request originates from, the browser sets it.
As you can see, this is a major breach of privacy since such cookies will be sent to sites that they should not be sent to. Since there is no algorithmic method of working out which level domains are allowed to be registered (and hence cookies set) at for each top-level domain, a list must be compiled with this information to be used by the browser when determining whether a cookie may be set or not. Mozilla has devised the Public Suffix List as a solution to this problem.
This is where your registry comes in. Since compiling the Public Suffix List of every single top-level domain and its associated rules for domain registrations on a large scale would be a very long-winded, tedious and error-prone task, your registry can help by compiling a smaller list pertaining to your own top-level domain. These smaller lists can then easily be combined to provide a definitive list.
The format of the Public Suffix List is very simple. It basically defines one rule on each line, ignoring comments preceded by two forward slashes (//). Each rule states the lowest level at which a cookie may be set. Each rule starts with a dot, and a wildcard (*) can be used in place of a subdomain. An exclamation mark (!) at the start of a rule marks an exception to a previous wildcard rule.
Here is an example list:
<pre> .com // This is a comment .co.uk *.tokyo.jp !metro.tokyo.jp </pre> The first line says that cookies may be set for any domain below .com. This line also has a comment, which will be ignored. The second line says that cookies may be set below .co.uk, and also implies that cookies may not be set directly below . uk. The third line says that cookies may be set for any domain below subdomains of .tokyo.jp. Therefore, for example, a cookie may be set for site.city.tokyo.jp but not for city.tokyo.jp or state.tokyo.jp. The last line is an exception to the line above, and says that cookies may be set for metro.tokyo.jp. The compiled list (and any subsequent updates) should be sent to [INSERT EMAIL ADDRESS HERE]. They will then be integrated with the master list. Compiling your registry's section of the list should not take too much time and will help immensely with privacy protection for browser users. The list only needs to be updated when registration rules change, and so is very low maintenance. Your participation in this program will be greatly appreciated.
Thanking you in advance,