ietf
[Top] [All Lists]

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

2008-07-07 22:49:59


--On Monday, 07 July, 2008 12:08 -0700 Bill Manning
<bmanning(_at_)ISI(_dot_)EDU> 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>