725530 - How does the public suffix list test data determine local is not a true TLD

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Jason Wieland]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.44 Safari/535.11

Steps to reproduce:

I'm running the official test suite from Public Suffix website: http://publicsuffix.org/list/test.txt



Actual results:

All rules pass on my implementation but these 3:

# Listed, but non-Internet, TLD.
checkPublicSuffix('example.local', NULL);
checkPublicSuffix('b.example.local', NULL);
checkPublicSuffix('a.b.example.local', NULL);

The issue is according to the effective TLD names local shows up as a valid TLD.  See http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat#1842



Expected results:

Looking at the comment in the test file
'# Listed, but non-Internet, TLD'
It seems to indicate that there is a way to know if its a non-Internet TLD?  By looking at the effective TLD list how do we know which ones are 'non-internet'?

Comment 1

[Gervase Markham [:gerv]]

There is no programmatic way to know.

We plan to sort the list into (terminology for the two groups is subject to change):

- ICANN registrar-controlled Public Suffixes (e.g. co.uk)
- Privately-controlled Public Suffixes (e.g. appspot.com)

However, .local is an odd case. I'm not sure what we'll do with that...

Gerv

Comment 2

[Jason Wieland]

Since there is no programmatic way to know, I would recommend taking .local out of the test file for now, until you build a new rule for intranet based TLDs.  

I like the idea of distinguishing out official ICANN registrar suffixes and pseudo-private suffixes.

Comment 3

[Gervase Markham [:gerv]]

Sending        list/test.txt
Transmitting file data .
Committed revision 101854.

Gerv