ENS Name Normalization

One question I have about the underscore is, has anyone actually come forward and asked for it to be included ??

If not then it shows that it is not needed in my view

I’m guessing someone has come forward and asked for $ to be added

100%

1 Like

This sounds very non-sensical to me.

I don’t see any issue on introducing the “_”
just like I don’t see any issue with $ and other currency symbols. Once decided it can be “locked” and that fear of never ending ASCII would stop.

I might be being cynical but it sounds like you might own some “-” hyphen ENS and want to protect yourself from the “_” version.

You are right with one things. Just the point of the iceberg know about ENS. And I can guarantee it unlike Web 2. This wont be as brand centred, quite the opposite in fact.

2 Likes

Underscores are permitted in DNS names - they are just prohibited by registrars for registration. The normalisation function needs to support a superset of valid DNS characters, so underscores need to be included.

1 Like

In my first post I think it was in this thread, I said I own hyphenated names

No need to guess, it’s further up the discussion

I’ve been fully open

REPLY TO NICK BELOW AS CAN"T POST AGAIN

Still not seen a single TLD with a underscore, I’ve seen subdomains, but never a TLD

They were also phased out being used in subdomains

I know this is web3 and not web2, but your argument falls flat

DNS has already gone though this process and phased out the underscore as they realised it was a mistake

First off, I’m assuming you mean domain names vs subdomains (as TLDs would be .com, .net, .org, .eth and so on)

I looked into this a while ago and the convention of not using underscores in domain names is from an incredibly outdated specification hailing from 1987 that was last updated in 1997 (the last spec is from 1998 but is about URI’s):

Summary: HostNamingRules < CF < TWiki


The TLDR is that it was decided that domain names should follow ARPANET hostname rules to prevent incompatibility with legacy software like telnet and mail before operating systems other than Plan9 conformed to unicode.

ENS doesn’t have to make those same considerations because it doesn’t support legacy software regardless. I haven’t seen any up to date specification that disallows underscores for any reason beyond this, let alone a reason that matters to ENS or modern software.

These same specifications also contains many antiquated rules restricting the length of names, internationalized names, all unicode and many more things we wouldn’t want to restrict ourselves to.

From 2020:

From 2019:

https://www.entrust.com/blog/2019/01/removal-of-underscores-from-domain-names/

https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/

Those articles aren’t about which characters are valid in domain names, they are about rules for the issuance of SSL certificates by centralized Certificate Authorities.

ENS names aren’t required to point to a website, or to use SSL certificates, and self-issued certificates aren’t bound by those rules.

Totally agree ENS names are different, BUT it shows that underscores were used and revoked in the past in DNS to to the same reason why I am talking about not issuing the underscore in ENS

It’s history repeating itself, but as ENS is decentralised it can’t be revoked like on DNS, if it’s allowed it’s here to stay

No it doesn’t. Underscores not being allowed in domain names doesn’t have anything to do with those articles, it had to do with very old considerations for ARPANET hostnames. You can read about it in my comment here:

As I have been saying, used in sub-domains only, but not in the main domain name

They have also been revoked as they are a confusable, which is what I have also been saying for ENS

So why follow the same path when it’s already happened in DNS and they changed it

It obviously doesn’t work…

I am really not interested in litigating this further, and it’s a massive distraction from the normalisation function as a whole.

Underscores are permitted in DNS and will be permitted in the new normalisation function. End of debate.

5 Likes

Underscore is for file path word separation only imo.

im just gonna bump this one post up and pretend I didn’t reply before reading @nick.eth 's recent post.

1 Like

Thought the DAO decided and not one single person??

Why are you not addressing the concerns of the people you are meant to be serving instead of dictating to them?

Raffy has already said this about mapping it:

Why not introduce it to allow DNS integration, but map it to the hyphen

This gives the best of both worlds, which is what Raffy was proposing

Just now what you are proposing in my view is a rug pull on anyone who has registered an ENS name with a hyphen in it

Coca-Cola.eth included along with all the others

1 Like

Glad to see “_” is likely going to happen.

As it should.

2 Likes

Hello @raffy! Is there a new version of the Resolver over at: ENS Resolver ?

Thank you.

Edit: found my answer in the repo. package, thanks!

I forsee the mistake of sending money to a hyphenated name when it’s meant to be underscored and vica versa, 100%.

can you see people confusing “i” / “l” ?
Because the above looks an order of magnitude more confusable than “_” / “-” to me.

Its even more obvious in context

alllna / allina
hello-world / hello_world

2 Likes

They are distinguishable by physical location on a mapped keyboard.

( i ) and ( l ) are seperate keystrokes.

( i ) or ( I ) is mapped the physical keycap ( i ) or ( I ) on most standard keyboard layouts
whereas the ( i ) keystroke will produce ( i ) or ( I ) and not ( l ) or ( L)

( l ) or ( L ) is mapped the physical keycap ( l ) or ( L ) on most standard keyboard layouts
whereas the ( l ) keystroke will produce ( l ) or ( L ) and not ( I ) or ( i )

( - ) and ( _ ) is mapped the physical keycap to the right of { [ 9 ][ ‘)’ ] } and to the left of { [ + ][=] }
which can produce both ( - ) and ( _ ), which is same keycap

I will be pushing an update very soon. The current repo is behind and contains lot of experimental stuff. The next update should 100% match ens-norm-ref-impl.js but be ~20KB.

3 Likes