> Le 9 juin 2022 à 16:32, Takahiro Nemoto via Datatracker <nore...@ietf.org> a > écrit : > > Reviewer: Takahiro Nemoto > Review result: Ready with Issues > > I am the assigned ART-ART reviewer for this draft. > > Summary: > I think this document is concise and generally good, but a few things are not > explained well enough. Please consider revising the following points. > > Minor issues: > - It is unclear how to provide "alternative ASCII addresses" in Section 5.3.2 > and how to distinguish between an EAI address and an alternative ASCII > address, > so it would be better to add an explanation. > > - It is unclear how to verify the code points of domain names in Section 8, so > it would be better to add an explanation. RFC5892 describes how to determine > the code points that can be used in IDNA2008 but does not describe how to > validate domain name code points. So it would be easier to convey the > intention > to the reader to write "validate whether the domain name consists of the code > points allowed by IDNA2008" rather than just writing "validate all code points > in the domain name according to IDNA2008". Also, if the validation described > in > this section is intended to be compared to the code points listed in Appendix > B.1. of RFC 5892, it would be better to refer to IDNA Rules and Derived > Property Values > <https://www.iana.org/assignments/idna-tables-12.0.0/idna-tables-12.0.0.xhtml> > listing the latest IDNA Derived Property Values. >
Quick comment: the registry has a base URL which redirects to the latest version. So in an RFC, it would be better to refer to that URL: https://www.iana.org/assignments/idna-tables <https://www.iana.org/assignments/idna-tables> Regards, Marc. > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
