Add test to ensure dotted-decimal IPv4 addresses are rejected by format: hostname

[VIDIT45AGARWAL]

The current format-hostname test suite does not include a case ensuring that dotted-decimal IPv4 addresses (e.g., 192.168.0.1) are rejected.
Because hostname labels are allowed to:

1. start with digits, and
2. be entirely numeric,

a validator may incorrectly validate 192.168.0.1 as four numeric labels and accept it as a hostname.

However, RFC 1123 section2.1 mentioned in the spec states:
a valid host name can never have the dotted-decimal form #.#.#.#

Therefore, dotted-decimal IPv4 addresses must not be considered valid hostnames.
Since we already provide a separate format: ipv4, allowing such values to pass hostname would blur the distinction between the two formats.

[MeloveGupta]

Hey, Would love to work on this issue...
Could you assign it to me...

[SorinGFS]

@VIDIT45AGARWAL

the part you quoted is not normative, is a discussion! And a very old discussion, since 1989. The appliable part is the one highlighted in green.

[SorinGFS]

@jdesrosiers

this is another case where whatwg url (that is flexible compared to rfc 3986) accepts the URI, then normalizes. Overall, as the RFC states, there is no other terminology for the case when the hostname is infact DNS IP.

[SorinGFS]

@jdesrosiers

I think the whole confusion comes from how format hostname is defined in your spec. I think the RFC 1123 shouldn't be mentioned at all, but instead RFC 3986 host abnf should be pointed for hostname and RFC 3987 ihost abnf should be pointed for idn-hostname. Both, completed with IDNA, punycode and UTS#46 rules, but without going into DNS area (IANA, ICANN).

authority:
  syntax: |
    [ userinfo "@" ] host [ ":" port ]
  description: Authority component.
host:
  syntax: |
    IP-literal / IPv4address / reg-name
  description: Host component.
reg-name:
  syntax: |
    *( unreserved / pct-encoded / sub-delims )
  description: Registered name.

[jdesrosiers]

I thought I found where it says that the top-level label can't be all numeric, but I can't find it now. Maybe I just assumed that the rule existed because the text in the "DISCUSSION" block says that there is. I'm really not sure what's what at this point.

I think the RFC 1123 shouldn't be mentioned at all, but instead RFC 3986 host abnf should be pointed for hostname and RFC 3987 ihost abnf should be pointed for idn-hostname.

I'm not sure about that. Hostnames could be used in contexts other than URIs, so I'm not sure that's going to cover everything it needs to.

[SorinGFS]

I'm not sure about that. Hostnames could be used in contexts other than URIs, so I'm not sure that's going to cover everything it needs to.

Actually I think it does cover everything we would expect, here is the key point:

So, they are actually deferring the hostname syntax exactly where you defined it in the spec, but if you read the spec with that in mind (to find out its specs related to hostname) to the end, it has more than that:

So, basically they wrote this spec with multiple use cases in mind, including seeking hostnames in yellow pages, BUT when it comes to web they say it's the DNS system that makes the rules! So, they allow percent encoding in hostname (to cover multiple things), but for web the rules must be read from those two RFC's which sais that % is not allowed in label (in fact the only allowed chars are alpha, digits and hyphen-minus, same as punycode). The same delegation to DNS exists in RFC 3987, basically IRI hostnames are infact idn-hostnames, with all implications including UTS#46. You need to follow the links in those specs to track the info, because for example in RFC 3987 the refs are going to obsoleted versions of what you would expect, e.g RFC 3490 infact is Obsoleted by RFC 5891, RFC 5890 😄

[SorinGFS]

Right in overview in RFC 3986 is this

A URI is an identifier consisting of a sequence of characters
matching the syntax rule named in Section 3. It enables
uniform identification of resources via a separately defined
extensible set of naming schemes (Section 3.1). How that
identification is accomplished, assigned, or enabled is delegated to
each scheme specification.

So, the key here is the word scheme. That is what whatwg for example is doing, treating each identifier based on its scheme:

• http, https, ws, so on... means web, means dns, etc
• file, means os
• ...
• undefined, means fallback to defaults defined in RFC

[jdesrosiers]

I think the RFC 1123 shouldn't be mentioned at all, but instead RFC 3986 host abnf should be pointed for hostname and RFC 3987 ihost abnf should be pointed for idn-hostname.

@SorinGFS Can you create an issue in the spec repo making your case about this? I think you have some good points. Since this is the test repo, getting into that discussion here isn't going to lead anywhere.

[SorinGFS]

Sure.