Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John C Klensin <[e-mail]>]

--On Monday, 07 July, 2008 12:08 -0700 Bill Manning
<[e-mail]> 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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf