On 2018-02-05 14:18 -0500, Geoff Huston wrote:
> I thought this was due to some concern over the wording in RFC <mumble>(some
> IDN
> RFC whose number I can’t recall right now!) over a comment that the UC label
> should not contain the starting sequence "<letter> <letter> - -”
RFC5890 point 2.3.1
To facilitate clear description, two new subsets of LDH labels are
created by the introduction of IDNA. These are called Reserved LDH
labels (R-LDH labels) and Non-Reserved LDH labels (NR-LDH labels).
Reserved LDH labels, known as "tagged domain names" in some other
contexts, have the property that they contain "--" in the third and
fourth characters but which otherwise conform to LDH label rules.
Only a subset of the R-LDH labels can be used in IDNA-aware
applications. That subset consists of the class of labels that begin
with the prefix "xn--" (case independent), but otherwise conform to
the rules for LDH labels.
And also:
Labels within the class of R-LDH labels that are not prefixed with
"xn--" are also not valid IDNA labels. To allow for future use of
mechanisms similar to IDNA, those labels MUST NOT be processed as
ordinary LDH labels by IDNA-conforming programs and SHOULD NOT be
mixed with IDNA labels in the same zone.
These distinctions among possible LDH labels are only of significance
for software that is IDNA-aware or for future extensions that use
extensions based on the same "prefix and encoding" model. For
IDNA-aware systems, the valid label types are: A-labels, U-labels,
and NR-LDH labels.
> Is there a broader concern over the use of double hypens in labels in hostname
> contexts in the DNS?
Double hyphens anywhere that is ok, but at position 3 and 4 it will be a
problem for many registries.
ICANN contract with registries, Specification 6 ("Registry
Interoperability and Continuity Specifications") point 1.1 says:
DNS labels may only include hyphens in the
third and fourth position if they represent valid IDNs (as specified
above) in their ASCII encoding (e.g., “xn--ndk061n”).
</quote>
Many ccTLDs have the same restriction.
--
Patrick Mevzek
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
