UNSUBSCRIBE > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > John C Klensin > Sent: Tuesday 8 July 2008 15:30 > To: Bill Manning > Cc: Mark Andrews; ietf@xxxxxxxx > Subject: Re: Services and top-level DNS names (was: Re: Update of RFC > 2606 > > > > --On Tuesday, 08 July, 2008 04:28 -0700 Bill Manning > <bmanning@xxxxxxx> 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 > >> <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. > > 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ================================================ CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to <mailto:webmaster@xxxxxxxxxxxxxxxx>webmaster@xxxxxxxxxxxxxxxxx Thank you<http://www.loquendo.com>www.loquendo.com ================================================ _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf