--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 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf