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:
>
> typedef host-name {
> type domain-name {
> pattern '[a-zA-Z0-9\-\.]+';
pattern '(.*\.)?..\-\-.*' {
modifier invert-match;
}
> length "2..max";
> }
> description
> "Host names must be at least two characters long (see RFC 952)
> and they are restricted to labels consisting of letters, digits
> and hyphens separated by dots (see RFC1123 and RFC 952).";
> reference
> "RFC 952: DoD Internet Host Table Specification
> "RFC 1123: Requirements for Internet Hosts: Application and Support";
> }
I am also not convinced that deriving host-name from domain-name is a good
thing to do. Apart from being somewhat complicated, this coupling can also
cause problems, e.g. if domain-name was to be obsoleted in the future.
Lada
>
> /js
>
> On Sun, Jul 26, 2020 at 03:11:15PM +0200, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder <[email protected]> writes:
>>
>> > On Wed, Jul 22, 2020 at 01:46:38PM +0200, Ladislav Lhotka wrote:
>> >>
>> >>
>> >> On 22. 07. 20 13:00, Juergen Schoenwaelder wrote:
>> >> > Tom,
>> >> >
>> >> > my understanding is that Lada is now proposing something slightly
>> >> > different but I am not sure what exactly, hence I asked again.
>> >>
>> >> Oh yes, I messed it up by mixing different things together, sorry. I
>> >> checked again the ML archive, and the message that is relevant to this
>> >> thread is this:
>> >>
>> >> https://mailarchive.ietf.org/arch/msg/netmod/PISOifrtow4oWLGW7meBBSri7nM/
>> >>
>> >> The aim of that proposal was to limit the "inet:host" type to DNS names
>> >> that are reasonable as host names, i.e. eliminate values like "." or "_".
>> >
>> > You are proposing to change the length restriction from 1..253 to
>> > 2..253 following RFC 952:
>> >
>> > [...] Single character names
>> > or nicknames are not allowed.
>> >
>> > And you add
>> >
>> > pattern '(.*\.)?..\-\-.*' {
>> > modifier invert-match;
>> > }
>> >
>> > to restrict things to non-reserved letter-digit-hyphen labels as per
>> > RFC 5890. Is it clear that this second restriction applies to host
>> > names? How do you represent internationalized host names? Perhaps we
>> > need a collection of examples? And is the pattern correct? RFC 5890
>> > says:
>> >
>> > Reserved LDH labels, known as "tagged domain names" in some other
>> > contexts, have the property that they contain "--" in the third and
>> > fourth characters but which otherwise conform to LDH label rules.
>> >
>> > What is the '(.*\.)?' part doing in your pattern?
>> >
>> > Finally, would it be useful to derive a host-name type from the
>> > domain-name type (if host-names are really a strict subset of what
>> > domain-name allows), e.g.:
>>
>> The current definition of "inet:domain-name" in 6991bis also permits the
>> underscore character in labels, so it is not LDH.
>>
>> Lada
>>
>> >
>> > typedef host-name {
>> > type domain-name {
>> > pattern '(.*\.)?..\-\-.*' {
>> > modifier invert-match;
>> > }
>> > length "2..max";
>> > }
>> > description
>> > "Host names must be at least two characters long (see RFC 952)
>> > and they are restricted to non-reserved letter-digit-hyphen
>> > (NR-LDH) labels (see RFC ????).";
>> > reference
>> > "RFC 952: DoD Internet Host Table Specification
>> > RFC ????: ????";
>> > }
>> >
>> > /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
>
> --
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
