Review of draft-ietf-idnabis-defs
John C Klensin
klensin at jck.com
Mon Oct 26 05:39:08 CET 2009
--On Saturday, October 17, 2009 08:43 -0700 Bernard Aboba
<bernard_aboba at hotmail.com> wrote:
> I have reviewed draft-ietf-idnabis-defs. Overall, I found
> the document clear and easy to read.
> Some specific comments below.
> Section 2.2
> When discussing the DNS, this document generally assumes the
> terminology used in the DNS specifications [RFC1034]
> [RFC1035] as
> modified by [RFC1123] and [RFC2181]. The term "lookup" is
> used to
> describe the combination of operations performed by the
> protocol and those actually performed by a DNS resolver.
> The process
> of placing an entry into the DNS is referred to as
> similar to common contemporary usage in other contexts.
> [BA] Does the term "registration" apply to DNS dynamic update,
> or only to the initial process of placing an entry?
Uh, yes. If dynamic update is configured to require that an
RRSET (from the viewpoint of IDNA, a label) is already present,
then one has a lookup situation. If it is configured for the
"RRSET does not exist" or "Name not in use" cases, then one has
a registration situation. That said, my personal recommendation
would be to use the more conservative Registration rules any
time one is going to start modifying DNS zones rather than
simply looking something up. But the WG has not discussed this
topic. If people are convinced that something must be said on
the subject, we will need to have that discussion.
> Section 2.3.1
> Labels within the class of R-LDH labels that are not
> prefixed with
> "xn--" are also not valid IDNA-labels. To allow for future
> use of
> mechanisms similar to IDNA, those labels MUST NOT be
> processed as
> ordinary LDH-labels by IDNA-conforming programs and SHOULD
> NOT be
> mixed with IDNA-labels in the same zone.
> [BA] If one were to write a conformance test based on this
> what kinds of behavior would be prohibited in an
> IDNA-conforming program?
> For example, does "not processed as ordinary LDH-labels" imply
> that an
> that these labels are not looked up? Is there also an
> implication that these labels should not be registered?
I believe that the confusion here arises from reading
draft-ietf-idnabis-defs in isolation from
draft-ietf-idnabis-protocol. Writing a conformance test based
on one or the other alone would get one into a lot of trouble,
or at least confusion. The specifications in Protocol will not
permit an IDNA-aware application to look up or register one of
Ignoring some edge cases related to IDNA2003 compatibility and
an important optimization, an IDNA-conforming program should not
look up anything that is not a valid A-label. The optimization
is the reason for the slightly-convoluted language here: if a
lookup-side user supplies a string starting in "xn--" in a way
that claims it is an IDN A-label, the specification does not
require that it be fully validated by conversion to U-label
form, verifying that conversion is successful, and then applying
all of the tests to the characters and their relationships
required by draft-ietf-idnabis-protocol (and, by extension,
draft-ietf-idnabis-bidi and draft-ietf-idnabis-tables). That
is explained fairly clearly in draft-ietf-idnabis-protocol.
> Section 18.104.22.168
> Clients issuing queries or interpreting responses cannot be
> assumed to have any knowledge of zone-specific restrictions
> [BA] Does this statement also extend to clients issuing DNS
> dynamic updates?
If I correctly understand your question, as far as IDNA is
> Section 22.214.171.124
> Specifically, for IDNA-aware applications, the three allowed
> categories are A-label, U-label, and NR-LDH-label. Of the
> LDH labels (R-LDH-labels) only A-labels are valid for IDNA
> [BA] A similar statement is made in Section 2.3.1; you might
> consider consolidating this paragraph into that section.
Getting the terminology right was a major preoccupation of the
WG for some time, with many rearrangements and rewrites. The
risk of causing undesired side-effects by making seemingly
reasonable consolidations or rearrangements of text seems to me
to vastly exceed the advantages of eliminating some redundancy
that the WG has checked and accepted.
More information about the Idna-update