Update of RFC 2606 based on the recent ICANN changes?

[Frank Ellermann]

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