--On Tuesday, October 02, 2012 12:22 +1000 Mark Andrews
<marka@xxxxxxx> 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