[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