They are: TLD English Meaning Approval Date xn--ngbc5azd (شبكة.) Web or Network July 13, 2013 xn--80asehdb (онлайн) Online July 14, 2013 xn--80aswg (сайт) Web site July 14, 2013 xn--unup4y (.游戏) Game July 14, 2013 lighting August 27, 2013 estate August 27, 2013 bike August 27, 2013 xn--vhquv (企业) Company/firm/enterprise August 27, 2013 holdings August 27, 2013 equipment August 27, 2013 clothing August 27, 2013 voyage August 27, 2013 guru August 27, 2013 ventures August 27, 2013 singles August 27, 2013 camera August 27, 2013 None of them have told us about any sub-structure, but Chrome (at least) likes to have all TLDs in the list regardless. Gerv
Gerv- The first four are contracted, but not in the zone yet / delegated. There is, until contract and delegation of the TLD, a number of intervening factors that might merit some thought... for example, the opportunity for the TLD to not be delegated is present should they withdraw their application or not pass the application process. Also applicant contention (two companies+, one string) could be still in the process of sorting out... so the "official" request from the registry operator may be ambiguous in some cases. What is the policy to be used for which are and are not included in PSL, and when? -Jothan
This list comes from the notifications on the gTLD mailing list: https://mm.icann.org/mailman/listinfo/gtldnotification Each of those represents a signed contract between ICANN and a specific applicant. So I think applicant contention is sorted out, and a withdrawal is unlikely. My proposal is that we use the appearance of a TLD on this mailing list as a trigger to add it to the PSL. (CAs are using it as a trigger to contact customers who have clashing certs.) As a data source, it has the advantage of simplicity, completeness and (I think) timeliness. It also allows updated PSLs to get some distribution before the domain goes live. If you don't think we should do this, what data source or event do you think we should trigger on? Gerv
Also: tattoo August 30, 2013 Gerv
Your proposal sounds solid. So it shall be done.
Just a suggestion... for managing the additions that are going to come in 'thundering herds' over the next 18-24 months - there are many updates on the way. To mitigate the diffs becoming unwieldy, could I recommend that it is time to split the gTLDs from the ccTLDs as individual sections within the ICANN region. There will be approximately 1400 new gTLDs coming in, the majority of which are going to be flat, while the ccTLDs have much variety and nuance. If these are separated and remain distinct, I suspect the diffs / update process will work smoother.
I have had a submission from CoreNIC which indicates that the two new Russian TLDs are flat. Gerv
Weppos: can you prepare a patch here? I also seem to remember that there was a proposal to separate out CCTLDs from gTLDs. I can't remember where that was made. If that's going to happen, it should be a separate, previous patch. I'm not sure whether or not it would improve maintenance. Gerv
Assignee: nobody → weppos
I don't recall about the proposal. I personally suggest to start using the same list, we always have time to split it in a second step. Do you agree?
weppos: happy to wait and see, as you say. Could you prepare a patch for the TLDs in the Google Doc Jothan created? These emails seem to be coming through thick and fast. Perhaps we should establish a 2-week rhythm, or something like that? Gerv
@Gerv I have no access to the docs. Can you share it with me? My gmail account is easy to guess ;). -- Simone
@simone I have a PM to you so I can ensure you have access to the Google spreadsheet. @simone, @gerv, et al contributors I know I have suggested a few ideas on how to structure PSL for best addressing the thundering herd of new gTLD entries that are coming. Ignore those. Now that I see how these are coming in, and the pace that ICANN is contracting, I'd like to suggest that these new gTLDs have a section to themselves which we order by arrival of the email announcements from ICANN, and that we do this for the duration of the contracting phase, until we have the majority of them (say 1200ish). After the majority have arrived, we can then better organize them, but it will allow us more agility in the interim if we do by arrival. This will keep the DIFF process clean and be simpler to track so that nothing is accidentally overlooked. -Jothan
Simone or Gerv can you make a unified diff of this and add it to the PSL
Simone: are you able to take this on? I think we need to get into the habit of adding these on a regular basis. Gerv
I'm looking into that. As far as I read, we decided to go with a separate file?
A separate file? I'm not sure where you got that idea. The PSL is one file. Do you mean a separate section? Yes, I think we should go with that, and see how we get on. We can always merge in later if it seems advantageous. Gerv
I generated a patch. Gerv, let me know if the section header looks fine for you or you want to use a different label.
New patch, the previous one contained an invalid quote.
Comment on attachment 813047 [details] [diff] [review] GTLDS.patch > // ===END PRIVATE DOMAINS=== >+// ===BEGIN NEW gTLD DOMAINS=== We can't do this; people will expect the new domains to be in the "ICANN DOMAINS" section. We should add them in a block, as you have done, but add them at the bottom of that section, not in a new section. >+// kim : 2013-09-24 Afilias Limited >+kim Can we remove the double space, and separate with a comma? Other than that, great. Gerv
Attachment #813047 - Flags: review?(gerv) → review-
OK, I'll update the patch ASAP.
I updated the patch with the following changes: 1. I moved the group inside the existing ICANN group 2. I replaced the double space with a new format. The double space was the result of the formula printing a separator when no punycode exists. In this case, I moved the punycode/unicode at the beginning followed by : as we're doing for the other existing IDN TLDs. 3. I updated the list to the latest released gTLD.
Comment on attachment 817182 [details] [diff] [review] GTLDS.patch >+// ===BEGIN NEW gTLD DOMAINS=== I'm not sure we need this. Who would want to distinguish between these and the other ICANN domains? Also, it's dangerous to label anything "New" - see http://en.wikipedia.org/wiki/New_College,_Oxford (founded 1379). >+// xn--q9jyb4c : 2013-09-17 Charleston Road Registry >+xn--q9jyb4c This one seems to be in punycode form... >+// xn--fiQ64b : 2013-10-14 CITIC Group Corporation >+ä¸ä¿¡" Stray closing quote here? >+// ===END NEW gTLD DOMAINS=== Don't forget to remove this one too. Gerv
Attachment #817182 - Flags: review?(gerv) → review-
> I'm not sure we need this. It means you don't want to use a custom group anymore? You said > We should add them in a block, as you have done, but add them at the bottom of that section, not in a new section. Please let me know what is the name of the group you want to use, and I'll use it.
Sorry I wasn't clear. By "in a block", I merely meant "not scattered throughout the file". I don't think the block needs delimiters. Gerv
Comment on attachment 817201 [details] [diff] [review] GTLDS.patch r=gerv. Gerv
Attachment #817201 - Flags: review?(gerv) → review+
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.