== Data collection ==
Maintaining an up-to-date list of all top-level domains and policies is clearly a vast task, and therefore each registry will be asked to maintain their own section of the database and email any changes regularly to the effective TLD list maintenance team, who will then merge it with the master database.
Once fine details have been sorted out, registries Registries for all top-level domains will be contacted by email (possibly via an ICANN mailing list) that will inform them of the intentions of the effective TLD list, how to participate and formats for data files.
== Tasks to do ==
# Make the website for registries
# Sort out a contact email address
# Decide on how to prevent email forgery forgeries (Gerv recommends "pinging" each registry that sends an email and get them to confirm that they actually send it)# Define Send the file format for the effective TLD list (copy from [http://wiki.mozilla.org/Gecko:Effective_TLD_Service#The_domain_file])# Author an email and send it to all TLD registries
# Monitor the email address regularly and manage changes
# Make the effective TLD list file available to other browser manufacturers
== Names Name ==
In 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.
== Content of email Email address ==
* What 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 == Dear Registry, 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. * Format 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 submit records 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 trivial examples a wildcard (*) can be used in place of a subdomain. An exclamation mark (there !) at the start of a rule marks an exception to a previous wildcard rule. Here is an example list: .com // This is a comment.co.uk*.tokyo.jp!metro.tokyo.jp The first line says that cookies may be set for any domain below .com. This line also has a website with examples 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 we can link 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 from the emailline above, and says that cookies may be set for metro.tokyo.jp. The compiled list (and any subsequent updates)should be sent to [EMAIL ADDRESS HERE]. They will then be integrated with the master list. * Email address Compiling your registry's section of the list should not take too much time and will help immensely with privacy protection for submissionsbrowser 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, The Mozilla Public Suffix List Team
== Links ==
* [http://my.opera.com/yngve/blog/show.dml/267415 How to make sure the cookies don't burn your fingers? - Implementer's notes - by Yngve Nysaeter Pettersen]
--[[User:Rubena|Rubena]] 1314:0838, 14 February 6 March 2007 (PST)
