undefined | Better HN

0 pointscls598y ago0 comments

But also, the folks at medium made that assumption long after RFC 2606 had established a "right answer" for which tld to use when testing.

0 comments

gruez8y ago

i think i wasn't being clear with my initial comment. it's a "fair assumption" in the same way that it's a fair assumption that emails can be validated with the regex

    [a-zA-Z0-9\.]+@[a-zA-Z0-9]+\.[a-zA-Z0-9]+

sure, it breaks for gmail aliases (with +), isn't RFC compliant, and the proper regex is a google search away, but it's understandable why that was chosen. same with .dev domains. yeah, you probably should have looked for a reserved tld, but why do that when .dev already didn't exist, and it didn't look like icann was going to delegate that any time soon?

kijeda8y ago

These don't strike me as comparable scenarios.

In the case of .dev, it didn't even appear in the weeds of usage when the DNS root servers were measured for traffic to identify potential new TLDs usage conflicts in the real world (e.g. https://www.icann.org/en/system/files/files/name-collision-0... p22). Even if .dev were in significant usage, that traffic was not reaching the domain name system. The complaint seems to be fundamentally to be about the pre-loaded configuration of Chrome, not the DNS.

In the case of your regex, it would breaks millions of production domains in used today and fail in a wide variety of scenarios. It is only understandable in the context of someone who hasn't done any cursory research into the topic.

j / k navigate · click thread line to collapse