Re: [idn] Fast nameprep vs. slow nameprep

["Edmon" <edmon@neteka.com>]

I agree to this comment!:

> The need for this will be measured by the amount of effort required to
> communicate failure back to the client. If it is a simple match->fail
> sequence that uses the same NXDOMAIN errors we already have (and if it
> doesn't happen a lot) then it won't be much of a problem. Conversely, if
> enough users yell about not being able to resolve IDNs (even though it is
> because their patch-current apps/resolvers aren't doing the work) then
> there might be sufficient non-technical motivation to introduce an
> intermediary solution somewhere within the DNS infrastructure, either at
> the server or with patched resolvers.
>
> In short:
>   legacy apps+legacy resolvers=server labor
>   legacy apps+patched resolver=resolver labor
>   new apps=app labor
>
> I'd say spec for the last scenario but implementaions need to be prepared
> for all three.

Thats exactly why we have prepared the known issues paper in our OpenIDN
forum.  These issues must be dealt with because at the end of the day, its
the user who might not know too much about the discussions here that will be
using the domain names.  Also, if these preparations are not made, IDNs will
not pass the business card test.

Edmon

PS. Though I'd add that I see that there should be a 4th scenario:
new apps + new resolvers = full IDN
and specs should be based on this scenario with "new apps only" as an
intermediate solution.


>
> --
> Eric A. Hall                                        http://www.ehsco.com/
> Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/