Howdy, I note John suggests a reference to either RFC 8499 or RFC 5980. The latter is almost certainly meant to be RFC 5890, since that is the definitions and document framework for the IDNA 2008 series. I would disagree, however, that this is a useful reference, since neither RFC 5980 or RFC 5984 (which supplies the rational) actually has a definition of the form this document presumes. RFC 3490 does:
An "internationalized domain name" (IDN) is a domain name in which every label is an internationalized label. This implies that every ASCII domain name is an IDN (which implies that it is possible for a name to be an IDN without it containing any non-ASCII characters). This document does not attempt to define an "internationalized host name". Just as has been the case with ASCII names, some DNS zone administrators may impose restrictions, beyond those imposed by DNS or IDNA, on the characters or strings that may be registered as labels in their zones. Such restrictions have no impact on the syntax or semantics of DNS protocol messages; a query for a name that matches no records will yield the same response regardless of the reason why it is not in the zone. Clients issuing queries or interpreting responses cannot be assumed to have any knowledge of zone-specific restrictions or conventions. but given it was obsoleted by RFC 5980, I think you are left with RFC 8499 as the best choice. regards, Ted On Tue, Mar 5, 2019 at 12:18 PM RFC Errata System <rfc-edi...@rfc-editor.org> wrote: > The following errata report has been verified for RFC7482, > "Registration Data Access Protocol (RDAP) Query Format". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5621 > > -------------------------------------- > Status: Verified > Type: Editorial > > Reported by: John Klensin <john-i...@jck.com> > Date Reported: 2019-02-01 > Verified by: Adam Roach (IESG) > > Section: 2.1 > > Original Text > ------------- > IDN: Internationalized Domain Name > > IDNA: Internationalized Domain Names in Applications, a protocol > for the handling of IDNs. > > Corrected Text > -------------- > IDN: Internationalized Domain Name, a [fully-qualified] domain name > containing one or more labels that are intended to include one or more > Unicode code points outside the ASCII range (cf. "domain name", > "fully-qualified domain name" and "internationalized domain name" in > RFC 8499). > > IDNA: Internationalized Domain Names in Applications, a protocol for > the handling of IDNs. In this document, "IDNA" refers specifically to > the version of those specifications known as "IDNA2008" [RFC5980]. > > > Notes > ----- > While the proposed new text above borders on the painfully pedantic, > failure to be specific about these things undermines the technical validity > and consistency of the text (making this a technical issue rather than > exclusively an editorial one like a missing reference). IDNA2008 [RFC5890 > Section 2.3.2.3] is very precise about what an "IDN" is (a definition > incorporated by reference in RFC 6365 and consistent with the definition in > RFC 8499) , but there are other things around that, e.g., assume either > that "IDN" refers to a label, not an FQDN; that an ASCII label, even one in > ACE form, does not make the FQDN in which it is imbedded an IDN; that all > of the label components of an IDN must be U-labels or A-labels, etc. > Without the definition being clear, some of the statements in the document > make no sense. > > A reference to 8499 is suggested above because it is the most recent > authoritative definition (and because I didn't write it), but 5980 would be > equally legitimate if the authors prefer. > > Pinning down the IDNA definition is even more important. While there are > IDNA2008 references further on in the document, if the question of what the > generic term "IDNA" means is left to the imagination of the reader, then > the specification is missing language about what to do if, e.g., a query is > inconsistent with the U-label form of what is stored in the registry > database without mapping. The opportunity for that sort of problem is > clearly created by the "performs any local case mapping deemed necessary" > statement in Section 6.1 of the document, at least unless that case mapping > is constrained to not be applied to domain name labels (which the text > definitely does not say). > > -------------------------------------- > RFC7482 (draft-ietf-weirds-rdap-query-18) > -------------------------------------- > Title : Registration Data Access Protocol (RDAP) Query Format > Publication Date : March 2015 > Author(s) : A. Newton, S. Hollenbeck > Category : PROPOSED STANDARD > Source : Web Extensible Internet Registration Data Service > Area : Applications > Stream : IETF > Verifying Party : IESG > >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext