Just for the record,..
I favor the publication of this document with a minimum of
further fuss.
I read and studied this document before the first I-D was
published, participated in discussion of it on the IDNABIS WG
list and again on the APPSAWG list. In each case, essentially
the same arguments were repeated and the same conclusion
reached. While the consensus is definitely rough, we are
putting a tremendous amount of of review cycles and energy into
a document whose essence is "we have agreed to do nothing". We
rarely publish documentation of a decision to do nothing in the
RFC Series. Instead, we simply do nothing and move on.
john
_Background and Reprise (in case needed or wanted)_
The argument for doing something --that this document makes and
describes the wrong decision-- is rooted in a set of decisions
the IDNABIS WG made (also with rough, rather than perfect,
consensus) a rather long time ago. One of the key differences
between IDNA2003 and IDNA2008 was the decision to try to be
independent of Unicode versions rather than tied to a specific
one. That decision, in turn, required that the IDNA properties
of characters -- whether they are Protocol-VALID in IDNs,
DISALLOWED, or valid only in particular contexts -- became a
matter of rules that, in turn, utilize the values of selected
Unicode properties. If Unicode never changed the properties for
a particular character once it was allocated (and avoided
introducing new characters that required contextual evaluation),
the rule-set would never need to be changed and we would never
have to debate, and write, documents keyed to those property
changes: new versions of Unicode would add new characters but
not change the IDNA properties of previously-assigned ones.
The world is not that perfect: Unicode does change properties of
already-assigned characters. It is rare (how rare depends a bit
on perspective), but it does happen. The reason is typically to
correct errors made in earlier property assignments, but other
reasons are possible (or one could have a
philosophically-interesting, but otherwise useless, debate about
how far the concept of "error" can extend). IDNA2008 recognized
that such changes might occur and might be disruptive, so
provided for a special "exception" rule that could be used to
list characters that needed special treatment because of changes
in Unicode properties.
The WG discussed the question of how to fill the table
associated with that rule in, a discussion that included the
realization that having the having the table become large would
simply create a new, and hard-to-explain, Unicode-version
dependence. One option was to populate it automatically: if
Unicode made changes, the table would be filled in to preserve
the behavior at the time the character was first allocated or
that appeared in Unicode 5.2, whichever came later, whatever
that was. Another was to turn the decision-making over to the
Unicode consortium, which might have resulted in either that
same rule or a rule that treated changes from DISALLOWED to
PVALID differently from changes from PVALID to DISALLOWED. The
WG rejected both of those ideas as well as the idea that some
changes were inherently more attractive than others.
Instead, the WG concluded that Unicode changes of character
properties that affected IDNA needed to be evaluated in the IETF
on a case-by-case basis as to whether they were important enough
to justify an addition to that exceptions table or whether the
balance fell on the side of keeping the table small (and IDNA
reflecting as short and obvious an exception list as possible).
In this particular instance, rough consensus has been reached in
multiple groups that it is better to keep the rules (including
that exception table stable and compact than to change the rules
in the interest of preserving the character classification
associated with Unicode 5.2. Had the characters involved been
less obscure, or more obviously used in domain names for other
than demonstrations and equivalent purposes, perhaps the
decision would have been different (or, if they were less
obscure, perhaps Unicode either would not have made the mistake
in the first place or would have decided to not correct it).
But wanting to consider the tradeoffs and balance between those
alternatives, probably with a slight bias toward not making
changes in the rules,a is precisely why the WG decided that
Unicode property changes needed to be considered by the IETF and
on a case-by-case basis.
There is no perfect answer to the tradeoff involved unless
Unicode never makes an error and concludes that a correction is
needed. Because no perfect answer exists, it is possible to
reopen the issue, bring up variations on the same old arguments,
and debate them endlessly. In that case, we've done that at
least twice, and, depending on how one counts, probably several
more times. We've decided. Let's get the document published
rather than seeing how many words and person-hours we can devote
to saying "we considered the issue and decided to do nothing".
john
--On Monday, 23 May, 2011 15:19 -0700 The IESG
<iesg-secretary@xxxxxxxx> wrote:
>
> The IESG has received a request from the Applications Area
> Working Group WG (appsawg) to consider the following document:
> - 'The Unicode code points and IDNA - Unicode 6.0'
> <draft-faltstrom-5892bis-04.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the ietf@xxxxxxxx mailing lists by
> 2011-06-06.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf