multi-level naming
JFC Morfin
jefsey at jefsey.com
Wed Mar 29 11:35:29 CEST 2017
John,
The IETF context has changed on Oct. 1st, 2016. IETF now is the
normative branch of the RFC 6258 ICANN market Global Community. As
such there is a new Catenet normative layer: what is mandatory for
every catenet user.
IMHO Ledger (Class) managers are interested to understand two
different things: what the ICANN/IETF RFC 6852 Global Community
consider as mandatory for everyone and must be discussed along the
RFC 6852 guide lines, and what belongs to the ICANN, XLIBRE, etc.
global community rules. To best protect internetwide cross community
compatibilty (the matter of two appeals of mine) no uniform
constraint should be unilaterally considered (to Be Unilaterally
Global is a BUG). This is why we need an inter-global community governance.
My understanding is that there is a cross community consensus (CCC)
over two domain names ASCII alphadecimal formats :
- the format without "--" in third and fourth position
- the format with "--" in third and fourth position.
In that second format group, the "x" in first and "n" in second position mean :
1) a punycoding of Unicode entries and restitution is supported.
2) no variant oriented algorithm is enforced at the resolvers.
This allows ICANN or XLIBRE to edict any contractual obligation
respecting the second format (in their respective classes). This also
allows non-differentiated registrations of "xn--" domain names as .su
reported they would do.
IMHO a cross community engineering task force should be convened to
discuss catenet layer architectural consensuses.
Best
jfc
More information about the Idna-update
mailing list