Juergen Schoenwaelder <[email protected]> writes:

> 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 <[email protected]> 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.

OK.

>  
>> 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.

I think it would be better to have an extra set of parallel definitions such as 
idn-domain-name, or perhaps u-domain-name.

Lada

> 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/>

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to