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