Update of RFC 2606 based on the recent ICANN changes?
nobody at xyzzy.claranet.de
Thu Jul 3 03:00:18 CEST 2008
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,
No TLD is forced to adopt this idea, and many TLDs have their
> 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 / "-"
More information about the Idna-update