[governance] ICANN declined Bulgarian IDN fast-track

JFC Morfin jefsey at jefsey.com
Sun May 30 12:28:28 EDT 2010


At 16:59 30/05/2010, Avri Doria wrote:
>Hi,
>Yes, while the technical and policy rules forbid mixing scripts 
>except in some special  cases within a single label (demarcated by 
>the dots) mixing scripts at different levels is ok as long as these 
>are also not mixed labels (caveats for special exceptions) - though 
>there are some who would try to limit that, i do not see how they 
>could be successful as that cat is well out of the bag already

Dear Avri,

could you please quote the reference of such technical and policy rules?

To my knowledge at this architectural stage there is _no_  technical 
rule that may legitimate _any_ policy rule. There are services 
operated under local applications of the IDNA2003 technology.

That technology has been identified as inadequate (RFC 4690) and a 
new architecture (IDNA2008) has been approved by the IESG that met 
the consensual support of ICANN, Unicode, IUCG, etc. as being 
appropriate and final. This architecture is based upon the agreement 
that it is "usable"; however the consensual documentation a minima of 
this usability did not pass the AD filter for good reasons, including 
reasons documented by the IAB. As I documented it in my last post: 
this work is ahead. It takes time and to get that time and necessary 
indications I use, as documented a long ago, an appeal procedure to 
protect all of us from the too nimble ICANN.

Forbiding mixing scripts [what is technically a script in IDNA2008?] 
is (1) technically impossible (2) politically only dependent from the 
current level zone manager decision.

Why is that? Because the internet architecture is documented by RFC 
1958, RFC 3439 and now IDNA2008 in applying to the IDN diversity 
Internet multiplication concepts that were not used up-to-now. This 
dramatically extends the Internet Users capabilities. This is in an 
off-the-shelves manner because this does not call for the change of a 
single bit, and because - in the DNS case - the change is transparent 
to usage. That change is the capacity for an ML-DNS (multi-layer DNS) 
to service applications. This is just a free capacity. However, that 
capacity is open to everyone, and everyone will have to use it at 
some stage, in order to build and enforce technical and policy rules 
at presentation, class, externet, TLD etc. levels. The first impact 
of this capacity is to remove the need of a single ICANN for users. 
However, it does not remove the interest of a leaner IANA, and the 
importance of IANA related Support Organizations.

For years we try to avoid the mess this may lead to, if not 
coordinated. Initiative should have come from ICANN, at least to 
protect themselves (they started doing it with ICP-3, but stopped). 
Then from Govs (as IAB called for in RFC 1958). Then from industry 
(but they tried to use it to control the network through the IANA - 
RFC 4646). So, we tried do three things:

- to prevent the industry's control on linguistic architecture. The 
control is delayed (RFC 4646 consensus).
- to make sure the IDNA2008 backbone of the IDN general support will 
be adequate. This is achieved.
- prepare but _not_ document the way for the Internet Users to use it 
and to experiment it before however our means are extremely limited. 
However, our calendar follows the IETF/IESG/IAB calendar because we 
needed the IESG and now the IAB positions on the issue, in order to 
make sure every other possibility has been checked. Then to release, 
test, document, organize and deploy.

Rod Beckstrom's bullish political introduction of FAST TRACK 
conflicts with that calendar. It will necessarily lead to conflicts 
among and between Users and ICANN, probably initially ruled by 
industry (that depends on the date ML-DNS is operationnaly supported).

Now, please understand that out Internet Users' priorities are not 
these of industry nor ICANN. We want things to work well, in a 
coordinated resolution order (because cheaper). Therefore we have our 
different set of piorities from ICANN, business, govs and industry. 
Also, please understand that once we get them developped, tested and 
used they will probably be here to stay. so we have time with us.

Now, I consider that everyone has been reasonably informed in the 
community. I will focus on IAB and on software development.
Cheers.
jfc




____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance

Translate this email: http://translate.google.com/translate_t



More information about the Governance mailing list