[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [idn] compatibility chars in draft-ietf-idn-nameprep
- To: Frank Ernens <fgernens@enternet.com.au>
- Subject: RE: [idn] compatibility chars in draft-ietf-idn-nameprep
- From: RJ Atkinson <rja@inet.org>
- Date: Fri, 18 Aug 2000 14:05:49 -0400
- Cc: idn@ops.ietf.org
- Delivery-date: Fri, 18 Aug 2000 11:11:22 -0700
- Envelope-to: idn-data@psg.com
At 20:32 17/08/00, Frank Ernens wrote:
>Ran Atkinson wrote
>
>> I think that mundane applications using the network
>>OUGHT NOT to have to know much about DNS rules, which specifically
>>means that I think it would be reasonable for some random application
>>to pass a prohibited character into the DNS resolver library's API.
>
>It depends what we mean by "the resolver".
BIND's current resolver is an example of precisely
what I mean.
>A modern application written in a language supporting dynamic Unicode
>strings and exceptions is probably going to want to say
>
> address = resolve (foldCompat (hostNameString));
Which does no harm to a resolver that does its own foldCompat()
under the hood...
>Whereas, someone who has an existing application which does almost
>no error checking and calls gethostbyname() will find it convenient
>to have that call convert from the locale 8-bit or multibyte character
>set and do the compatibility folding for them.
There are lots of these applications that aren't necessarily
getting updated to support dynnamic UNICODE strings.
>I think it's easier to think of the resolver as returning an error
>if it's passed a compatibility character, even though practical
>implementations might allow folding as an option. In general, I
>think signalling errors rather than trying to silently fix them
>produces more reliable software, so I would favour that as
>the primitive interface.
Again, I'm not being theoretical here. I am talking concretely
in terms of the BINDv9 resolver and its (future) decendants.
To support existing applications, the resolver that's actually
deployed would need to include all normalisation/canonicalisation
if the WG chooses to restrict what goes out on the wire.
Ran
rja@inet.org