On Mon, Jul 27, 2020 at 03:18:25PM +0200, Ladislav Lhotka wrote: > > > On 27. 07. 20 12:44, Juergen Schoenwaelder wrote: > > On Mon, Jul 27, 2020 at 10:51:31AM +0200, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > >> > >>> So would the following do the right thing? > >> > >> The invert-match pattern also needs to be added in order to avoid reserved > >> labels: > > > > Why are they illegal? If we make them illegal, how are we going to > > deal with hosts that have non-ASCII names? > > I am not able to find in what sense the "Reserved LDH" labels of RFC > 5890 are really reserved, and I am not sure about the implications of > permitting "xn--..." hostnames to be explicitly configured.
Right now, inet:domain-name as defined in RFC 6991 says: [...] Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase US-ASCII characters. Internationalized domain names MUST be A-labels as per RFC 5890."; Hence, if you want to configure a non-ASCII hostname using inet:host, you have to write it in a sequence of A-labels, i.e., using the ASCII Compatible Encoding (ACE). Hence, removing xn-- names seems to have a significant potential to break things. > If we want to allow non-ASCII names, then it would IMO be safer to use a > type that expects straight Unicode for lexical representation and leave > it to the implementations to convert to Punycode where necessary, e.g. > when querying DNS. Perhaps. But I am not sure this is the time to fix this or how this can be done in a backwards compatible way. At least this likely can't be done by disallowing ACE. It may be possible to add an additional member to the inet:host union that catches internationalized names. Since this would be enlarging the value space, I believe this is inline with the spirit of section 11 of RFC 7950. Removing the ACE names, however, restricts the value space and hence seem to contradict section 11 of RFC 7950. (The explicit removal of underscore and single letter hostnames may be considered a clarification since we have other RFCs stating these constraints.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod