James Seng wrote:
if the "character" is defined more broadly to cover "U-label"
character, then I would have strong objections.
+1 And fortunately it's not our job to figure out what a term
like "IDN ccTLD" actually means, where that might be important.
I remember it is a standing "tradition" that labels may not
be a single ascii character.
IIRC "SC SLDs" were recently permitted. In this acronym soup
that's "single character second-level domains" affecting TLDs
with a contract not permitting such beasts. ASCII characters,
[0-9A-Za-z].
No TLD is forced to adopt this idea, and many TLDs have their
own rules.
But is there any technical reason we should forbid it? (e.g.
6.cn have not kill any kittens yet)
It is certainly an obstacle for *simple* definitions of what
constitutes "confusingly similar" or "typo resistent". But I
guess there is no *simple* definition also covering typos in
IDN A-labels, so maybe that point is moot.
Unrelated: The "2606" thread on the general list so far was
about many interesting topics, notably about <toplabel>s, but
not about the 2606bis draft.
For the 3920bis-06 draft I sent this comment to the author:
You claim to import <idnlabel> from RFC 3490, but there is
no <idnlabel> in RFC 3490. Besides you don't want only
"xn--" labels, you want <ldh-label> not limited to "xn--".
How about this, based on latest RFC 1123 toplabel erratum:
| domain = fqdn / address-literal
| fqdn = *(ldhlabel ".") toplabel
| ldhlabel = letdig [*61(ldh) letdig]
| toplabel = ALPHA *61(ldh) letdig
| letdig = ALPHA / DIGIT
| ldh = ALPHA / DIGIT / "-"
Frank
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf