|
I have reviewed draft-ietf-idnabis-defs.
Overall, I found the document clear and easy to read. Some specific comments below. Technical 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 IDNA2008 protocol and those actually performed by a DNS
resolver. The process of placing an entry into the DNS is referred to
as "registration", 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? 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
statement, 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? Section 2.3.2.3 Clients issuing queries or interpreting responses
cannot be assumed to have any knowledge of zone-specific
restrictions or conventions. [BA] Does this statement also extend to clients issuing DNS
dynamic updates? Editorial Section 2.3.2.1 Specifically, for IDNA-aware applications, the
three allowed categories are A-label, U-label, and
NR-LDH-label. Of the reserved LDH labels (R-LDH-labels) only A-labels are
valid for IDNA use. [BA] A similar statement is made in Section 2.3.1; you
might consider consolidating this paragraph into that section. |
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf