--On Tuesday, October 02, 2012 12:22 +1000 Mark Andrews
<marka(_at_)isc(_dot_)org> wrote:
Therefore:
(1) Did the WG consider i18n and other issues and
possibilities before deciding to deprecate extended label
types entirely? If so, why aren't those considerations
described in the document? We don't have a lot of codes left
in the RFC 1035 space on which other label type models might
be constructed.
(2) Is there strong justification for deprecating extended
label types, e.g., evidence that they would cause harm?
(3) If the answer to either of both of the above questions is
"no", wouldn't it be wiser to simply deprecate the use of
binary labels, urge great caution in allocating and using
other label types, and then move on rather than eliminating
the facility?
...
I don't think we need to do this in label types. An EDNS
option would be sufficient to specify alternate normalisation
rules should be applied to the QNAME when looking for data and
when normalising the owner names when performing DNSSEC
validation.
Mark,
First, it was just an example. As I thought I made clear, my
main concern is about completely eliminating a facility because
one instance of trying to use it had not turned out to be as
useful as expected. Absent demonstration that all possible uses
of the facility are actually useless or that the facility is
harmful, I don't think the case has been made for deprecating
it. As far as that example is concerned, I don't think this is
the right place to review everything we've learned about i18n,
identifiers, and comparisons in the last couple of decades, but
normalization is just not a very large fraction of the problem.
john