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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf