-
Notifications
You must be signed in to change notification settings - Fork 150
IDNA: avoid defining valid domain string in terms of the parser #245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Maybe I'm wrong but aren't valid domains defined in the RFCs below? The first one saying: <domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit> The second one somehow saying that we can start a domain with a figure. |
It's not entirely wrong, but those definitions don't account for IDNA and also don't seem to account for ASCII code points that happen to work in practice, such as |
Hi, a DNS guy here. Allow me to describe this from DNS perspective:
Indeed that is wrong in a subtle way. This quote comes from section The real limits of the DNS protocol are made clear here:
We could argue URL should be concerned only with host names (as opposed to domains) and then the quote might more fitting, but that ignores IDNA completely. RFC5890 defines stricter subset of permissible names in ASCII encoding... I'm happy to discuss further if there's interest! |
Uh oh!
There was an error while loading. Please reload this page.
This is basically something we need to raise again with the IDNA folks as their document does not really address it. This used to be tracked by https://www.w3.org/Bugs/Public/show_bug.cgi?id=25334.
As part of fixing this we should make it clear they are at least ASCII case-insensitive.
The text was updated successfully, but these errors were encountered: