"Forbidden host code point" should be defined without U+0025

[GPHemsley]

The term "forbidden host code point" is used exactly twice within this spec, and in one case it excludes U+0025 (%):

If asciiDomain contains a forbidden host code point, validation error, return failure.

If input contains a forbidden host code point excluding U+0025 (%), validation error, return failure.

I think it is easier for implementations to add to a definition rather than take away from it, so I propose removing U+0025 from the definition and special-casing it where it is included:

If asciiDomain contains a forbidden host code point or U+0025 (%), validation error, return failure.

If input contains a forbidden host code point, validation error, return failure.

Or else creating a second definition that relates to the existing one.

[annevk]

It's also used in https://url.spec.whatwg.org/#valid-opaque-host-string now and I think that indeed argues for changing this as it's a bit ambiguous (to me).

[alwinb]

Something similar happens with URL-path-segment strings which uses the phrase:

zero or more URL units excluding U+002F (/) and U+003F (?), that together are not a single-dot path segment or a double-dot path segment.

What do you think about rephrasing things to use sets of allowed codepoints for each of username, password, opaque-host, path-segment, query, and fragment instead?

[annevk]

That might be reasonable, though I'd rather approach it in small incremental steps as each of those has the potential for regressions.