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
