Non Alpha Numeric characters in .bit domains

[e234679]

Why not?

It would catch the attention of every day people if they saw

what'smyip?.bit

let's not conflict this idea with internationalize domains

[phelix]

Why not?

It would catch the attention of every day people if they saw

what'smyip?.bit

let's not conflict this idea with internationalize domains

In the end security comes down to correctly reading a domain name. To do so it helps keeping things simple and using only a-z0-9

[mightbemike]

There could be all sorts of compatibility issues as well with everything from ftp to email. On the web, for example, browsers use the question mark to separate the querystring for HTTP GET requests.

Change DNS, leave HTTP alone

[AliceWonder]

Just to add why this wouldn't work - a .bit TLD by itself does not cause any problems with existing filters that validate a domain name.

Adding characters that are not legal means those domains would fail those filter tests.

IDN domain names already often have to be converted to punycode for these filters (e.g. the php built in filters), but that at least works. Allowing characters that are not legal and are not IDN characters would be a disaster.

So that's the why not.

KISS

[indolering]

Just to add why this wouldn't work - a .bit TLD by itself does not cause any problems with existing filters that validate a domain name.

Adding characters that are not legal means those domains would fail those filter tests.

IDN domain names already often have to be converted to punycode for these filters (e.g. the php built in filters), but that at least works. Allowing characters that are not legal and are not IDN characters would be a disaster.

So that's the why not.

KISS

AFAIK we support IDN domains using punycode which is why we use a-z0-9. The issue comes up when you export blockchain records as Zone files for BIND, etc. If we chose to support non-alphanumeric characters then we would at some point have to choose which format is correct and then handle exporting the domains.

That's a lot of extra work and compared to simply converting end user input into punycode. It would also break compatibility with existing namespaces.

[e234679]

good conclusion to come to then, .bit, keep as is, and then maybe some other fun but less compatible TLD in the future to allow all kinds of characters

[biolizard89]

good conclusion to come to then, .bit, keep as is, and then maybe some other fun but less compatible TLD in the future to allow all kinds of characters

Creating a separate TLD just to get a different implementation of a feature that already exists in .bit is completely pointless, and is an invitation to squatters.

[indolering]

good conclusion to come to then, .bit, keep as is, and then maybe some other fun but less compatible TLD in the future to allow all kinds of characters

Non-alphanumeric characters are allowed, they are just encoded via punycode. I do not believe that this is the case for id/ or other namespaces. There are, however issues with spoofing other names using look-a-like characters from different scripts.

[mightbemike]

good conclusion to come to then, .bit, keep as is, and then maybe some other fun but less compatible TLD in the future to allow all kinds of characters

Non-alphanumeric characters are allowed, they are just encoded via punycode. I do not believe that this is the case for id/ or other namespaces. There are, however issues with spoofing other names using look-a-like characters from different scripts.

Browsers need to reject mixed-script domains. That's by design. This was addressed by ICANN working group on IDN in RFC3490 proclaiming mixed script domain names need to be dealt with by the applications. They could have chosen to require something from the registries but chose not to.

Here's one reason why => It is common in some languages with multiple scripts, like Japanese (3 written scripts) to mix them. In that case Katakana is used for tech words, imported words, etc. and when a compound term typically written with an old part in kanji is combined with a suffix in katakana it makes sense.

Another reason is that it can be argued that a lot depends on your font. Using some fonts, l1I.com looks like a string with soem suplicate characters. (lowercase L, digit 1, cap i) so fooling users is not prevented easily. Not a compelling argument granted, but I digress. And it's worth noting ICANN decreed a few years ago that those cutesy little symbol domains were no longer going to be considered valid.

That option of rulemaking by decree and forcing compliance is not available here thankfully!!!

[e234679]

Thanks for the responses. Trying to think outside the box to possibly get everyday people's attention towards other benefits of not being confined to ICANN.