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