Skip to content
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.

Sign up for GitHub

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

Jump to bottom

IDNA: avoid defining valid domain string in terms of the parser #245

Open
annevk opened this issue Feb 10, 2017 · 2 comments
Open

IDNA: avoid defining valid domain string in terms of the parser #245

annevk opened this issue Feb 10, 2017 · 2 comments
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. topic: idna topic: validation Pertaining to the rules for URL writing and validity (as opposed to parsing)

Comments

@annevk
Copy link
Member

annevk commented Feb 10, 2017 •
edited

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.
@karlcow karlcow mentioned this issue Oct 18, 2018
Closed
@himorin himorin mentioned this issue Nov 12, 2019
Open
@annevk annevk added i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. topic: model For issues with the abstract-but-normative bits topic: validation Pertaining to the rules for URL writing and validity (as opposed to parsing) and removed topic: model For issues with the abstract-but-normative bits labels May 4, 2020
@annevk annevk mentioned this issue May 5, 2020
Closed
@cmcaine cmcaine mentioned this issue Aug 9, 2021
Open
3 tasks
@whatwg whatwg deleted a comment Nov 20, 2022
@whatwg whatwg deleted a comment from Boody6343 Nov 21, 2022
@dubzzz
Copy link

dubzzz commented Sep 6, 2023

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.

@annevk
Copy link
Member Author

annevk commented Sep 6, 2023

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 _. What we want is a definition that does account for that, for which, when the host parser defined in the URL standard is applied to it, the output is not failure.

@annevk annevk mentioned this issue Oct 4, 2023
Open
@zacknewman zacknewman mentioned this issue Apr 21, 2024
Open
@tomchristie tomchristie mentioned this issue May 8, 2024
Merged
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. topic: idna topic: validation Pertaining to the rules for URL writing and validity (as opposed to parsing)
Milestone
No milestone
Development

No branches or pull requests
2 participants
@annevk @dubzzz