slds aren't handled properly by the 'domain' regexp

[papandreou]

> require('./validation').domain.test('foo.co.uk')
false
> require('./validation').domain.test('foo.uk')
true

[papandreou]

Here's an updated list of "public suffixes": http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1

[Munter]

https://github.com/brinchj/RndPhrase/blob/master/scripts/update-suffixlist.py

[Munter]

Quite a big list. This is going to add considerable weight.

Worth it though.

[mwoc]

This issue happens to be fixed by commit 8db3cf9, though not with the TLD whitelist.

@Munter what's your opinion about closing this issue and instead going with the no-whitelist approach in issue #6?

[Munter]

I think there are uses cases for both. Ideally I think we should expose a light and a full package. Weight doesn't really matter in node the same way as it does in the browser, so both are valuable imo.

[mwoc]

Yeah, in Node it might be useful with a whitelist-based TLD validation anyway, for instance to make sure that a domain could be hosted by a company. In that case the user should probably have influence on the content of the whitelist though, which wouldn't be compatible with how it's done now.

Can you think of any specific use cases where the TLD whitelist can still be purely controlled within the package as it has been done up to now, and is shown in this issue?

New TLDs are added constantly nowadays, so with a whitelist we probably need to release new versions every time a new one is added (whenever https://publicsuffix.org/list/effective_tld_names.dat doesn't give a 304, I guess).
Alternatively, if the whitelist is maintained by the consumer of one-validation, it only has to be updated once that consumer decides to add support for a new TLD.

In the browser the use case for whitelist-based validation is very limited as I see it, especially due to the rate at which new TLDs are added and the use case of being able to send e-mails to TLDs which hit production hours ago.

I think we could offer a generic way of doing plugins in one-validation, and adding the whitelist-based validation based on this issue + the new gTLDs etc. that way. It could of course also be a separate file in the same package, so the users can choose which file to implement.

The main issue is prioritisation. Would it be acceptable if a new version based on #6 is released for now (so without whitelist approach) and that re-implementing the whitelist is postponed until there is time or a strong use case for it?

[Munter]

I'm not aware of any dependents other than purify and npmjs.org doesn't show a lot of downloads. I think it's ok to pull out the tld whitelist. Just be sure to release a new major version when you do.

[mwoc]

Cool thanks, will make sure to do that.