On Tue, Jul 08, 2008 at 01:49:24AM -0400, John C Klensin wrote: > > > --On Monday, 07 July, 2008 12:08 -0700 Bill Manning > <bmanning@xxxxxxx> 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. -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf