--On Tuesday, 08 July, 2008 04:28 -0700 Bill Manning
<[EMAIL PROTECTED]> wrote:
> On Tue, Jul 08, 2008 at 01:49:24AM -0400, John C Klensin wrote:
>>
>>
>> --On Monday, 07 July, 2008 12:08 -0700 Bill Manning
>> <[EMAIL PROTECTED]> wrote:
>>
>> > John, do you beleive that DNS host semantics/encoding that
>> > form the bulk of the IDN work (stringprep, puny-code,
>> > et.al.) are applicable -only- in the context of zone file
>> > generation or are they also applicable in configuration
>> > and acess control for DNS?
>>
>> I think I don't understand the question. RFC 3490 tries to
>> make a distinction between IDNA-aware and IDNA-unaware
>> applications and domain name "slots". The intent is, more or
>> less, to permit a punycode-encoded string with the prefix
>> (which the IDNA2008 drafts call an "A-label") to appear
>> nearly anywhere in the DNS but to expect conversion to and/or
>> from native characters only in contexts where IDNA is
>> explicitly applied. Even in zone files, IDNA is generally
>> applicable only to labels and not to data fields.
>>
>> > path/alias expansion/evaluation will be interesting if "."
>> > is not what 7bit ASCII thinks of as "."
>>
>> RFC 3490 lists a series of other characters that are to be
>> treated as label-separating dots if encountered in an IDNA
>> context. That model causes a number of interesting problems
>> in contexts where one has to recognize a string as a domain
>> name, and possibly process it, without knowing anything about
>> IDNA. The problems show up in situations as simple as
>> conversions between label-dot-label-dot-label format and
>> length-label list format, making it very important whether
>> one identifies an FQDN as containing IDNA labels or converts
>> it to length-label form first. IDNA2008 (see the IDNABIS WG
>> and its documents and mailing list) does away with all of
>> this as part of a general plan to do a lot less mapping of
>> characters into other characters. So, for the proposed newer
>> version the only label-separating dot permitted in the
>> protocol is the character you know as 7bit ASCII "." (U+002E
>> in Unicode-speak).
>>
>> Does that answer whatever the question was intended to be?
>>
>> john
>>
>
> perhaps - let me try again w/ example.
>
> in my resolv.conf file, I have the following three lines:
>
> search . karoshi.com. ip4.int. ep.net.
> nameserver 198.32.2.10
> nameserver 2001:478:6:0:230:48ff:fe22:6a29
>
> the line of interest is the first line, starting w/ search.
> the expectation is that the items on this list are domain
> names. in my case, they are all "fully qualified". since
> this is a configuration file - not a zone file, is IDNA2008
> expected to apply? this data is not, per se, in the DNS.
Nothing in IDNA2008 makes it apply. Nothing in IDNA2008 even
makes it apply to zone files (!). My personal view --others in
the WG might have other opinions-- is that one would be better
off using A-labels (the punycode-encoded forms) in this sort of
context.
The reasoning involves two points:
* While I don't imagine you would put domain names in
your search rules that you couldn't render (or easily
type) on your machine, I believe that will happen with
some servers who are supporting multilingual
communities. The A-labels can be typed and rendered
accurately on any system that can handle construction of
the config file (with its ASCII keywords) itself. The
U-labels put you at some risk of seeing little boxes or
question marks (or, in some cases, worse) as well as
potentially being hard to type.
* An explicit design goal for IDNA (both versions) is to
avoid changing the DNS or low-level DNS implementations.
The search rule interpreter in your resolver is going to
have to substitute names in that can be used in the DNS
and those are the A-labels. Putting U-labels in the
config file would requires that the resolver be
IDNA-aware, understand those labels, and map them to the
A-label form before doing lookups. It would also
presumably require doing that every time the config file
is read, a small decrement in efficiency.
Now, to give you a slightly different answer, I sort of expect
that communities who use IDNs a lot, especially those for whom
typing ASCII is uncomfortable, will find that IDNs drive them
toward "compilers" or special user interfaces to aid them in
producing all sorts of config files. I'd expect them to develop
tools to permit constructing zone file and resolver config file
templates with IDN U-labels in them and then translating them
into DNS-internal forms (i.e., with the A-labels). I'd even
expect such tools to provide screen interfaces that permit
working with the keywords of the config files without having to
type them out (a process that gets error-prone if words like
"search" or "nameserver" or "$ORIGIN" are not familiar and/or
the keys to enter them aren't on the keyboard).
But those are local tools, not part of anyone's protocol or
global facilities.
Again, just IMO.
john
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
