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.

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

IDNA: possibly use "domain to Unicode" in "valid domain"? #317

Closed
domenic opened this issue Jun 1, 2017 · 2 comments
Closed

IDNA: possibly use "domain to Unicode" in "valid domain"? #317

domenic opened this issue Jun 1, 2017 · 2 comments
Labels
clarification Standard could be clearer

Comments

@domenic
Copy link
Member

domenic commented Jun 1, 2017

In #309 @rmisev noted that the extra flags were not set in the "valid domain" algorithm's call to ToUnicode. I pushed a fixup that adds them. But maybe it would be better to deduplicate the calls to ToUnicode, similar to what is already done for the calls to ToASCII.

This is not obviously straightforward since I am not sure who uses "domain to Unicode", and I'm not sure why it doesn't return failure on errors.

domenic pushed a commit that referenced this issue Jun 1, 2017
Tests: web-platform-tests/wpt#5976.

Fixes #53 and fixes #267 by no longer breaking on hyphens in the 3rd and
4th position of a domain label. This is known to break YouTube:
r3---sn-2gb7ln7k.googlevideo.com. This is fixed by setting the proposed
CheckHyphens flag to false.

Fixes #110 by clarifying that BIDI and CONTEXTJ checks are to be done
by setting the proposed CheckBidi and CheckJoiners flags to true.

Follow-up #313 is filed to remove the proposed bits once Unicode is
updated. #317 also tracks a potential cleanup.
@annevk
Copy link
Member

annevk commented Jun 22, 2017

We don't have any users of "domain to Unicode" in the platform currently (after I removed origin to Unicode). #288 proposes to change that, but some at Chrome voiced concerns.

@annevk annevk added clarification Standard could be clearer and removed non-normative labels Apr 26, 2020
@annevk
Copy link
Member

annevk commented Dec 9, 2022

I ended up doing this in 0895123. The one call we have now is from the i18n address bar considerations, which seems okay.

@annevk annevk closed this as completed Dec 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Standard could be clearer
Development

No branches or pull requests

2 participants