Further, even UNIX paths containing ‘..’ and other things need normalisation, and with symlinks you can’t necessarily just compare two paths to determine whether they point to the same file.
The problem, as plenty of other people have said in these comments, is that you just need to parse the address and compare the structure. There are standard library calls for this, and most databases have types that can do this.
https://tools.ietf.org/html/rfc3986#section-3.2.3
Specifically part of the URI RFC.
Probably should have picked something wildly unrelated as a separator instead of colons - but the horse has already left the barn, so now we just get to play cleanup.
You're right that there's already a decent amount of support for this in various languages and persistence mechanisms, but I've spent enough time in my career playing with truly bleeding edge barely-an-alpha platforms to know that sometimes you do just get stuck writing your own parser and comparators. It's good to know in advance what sort of potholes you will be trying to navigate :)
Edit: I just discovered the URI RFC is dated 2005, with IPV6 being dated 1998. ( https://www.ietf.org/rfc/rfc2460.txt )
Still, it struck me as odd that we had been using host:port for so long. The URL conceptual predecessor to URI RFC also mentions using host:port in section 3.1.1 - which came out in 1994.
Regardless of which RFC made a hash of things though, all 3 are widely used specifications, so we're stuck in this boat now!
Let’s be honest, the creation of ipv6 was badly handled.
IPv4 address also have multiple valid forms. Besides the most common form, a.b.c.d where a, b, c, and d are decimal numbers in [0, 255] representing four 8-bit parts of a 32-bit address, there is a.b.c form, where a and b are decimal numbers in [0-255] and c is a decimal number in [0-65535], representing two 8-bit parts and one 16-bit part of a 32-bit address. Then there is a.b form where a is a decimal number in [0-255] and b is a decimal number in in [0-16777216], representing an 8-bit part and a 24-bit part of a 32-bit address. There is also a form, where a is a 32-bit decimal number, representing a 32-bit address.
Any of the aforementioned decimal numbers may instead be given in octal by prefixing with 0, or hex by prefixing with 0x or 0X.
> Using colons for separators when they’re already being used for ports served no purpose but to confuse.
Dots and colons are the only separators I can think of that are available on common keyboards, and don’t look ugly. We can’t re-use dots because then there’d be addresses that are _both_ IPv4 and IPv6. And I’m serious about the ugly part! Try writing an address out using commas or semicolons or asterisks or something, it just looks weird.
> Having more than a single valid form of an address again only serves to confuse.
Yes, as the article demonstrates, it certainly introduces edge cases that aren’t present in IPv4 — but the alternative is having to type out all the zeroes. Would you want to type out ’0000:0000:0000:0000:0000:0000:0000:0001’ each time?
> If there’s anything to learn from the UNIX principals it’s there is great power in making things easily manipulated as strings.
I think this is a testament to how wrong that statement is. How many scripts have broken because a file path has a space character in it? How many content injection attacks have there been, caused by code that blindly concatenates strings together? IPv6 addresses are just another example.
It’s a shame, but IPv6 is the best we’re going to get.
How so? 192:168:1:1 is not a valid IPv6 address, so it'd be easy to differentiate with dots
If you were to interpret it as ::192:168:1:1 then it'd be a valid IPv6 address, but that interpretation would be incorrect and even so would be in the "IPv4-Compatible IPv6 address" range that was intended to map directly to the IPv4 address as a transitional function anyways.
Not really sure why that idea got dropped, it seems to me like it makes a lot of sense to do any v4 mapping in the ::0/96 range.
Ack, you’re right. For some reason, I was thinking it would get parsed as “192:168::1:1”.
That mapping does make sense.
That's not fair. Features like this obviously have a purpose. (It makes a whole lot of IPv6 addresses a whole lot shorter to type!). You may not like it or use it or think that the complexity tradeoff was worth it, and that's a reasonable position to take, but it's not fair to say that the other perspective serves no purpose.
I think we should just define a .ip6 pseudo-tld and then you can write e.g. ff::12:34 as ff.x.12.34.ip6 (with .x. being the equivalent of ::). This should be enough for any practical purpose of users specifying free-form addresses, where the address can be ipv4, ipv6 or a host name. For configuration files and the like where you're only writing IPs, the colon form would be acceptable as well. The good part about this is that it also won't require us updating any address validation regexes (of which there must be many, despite all the advice against it).
The complexity of handling addresses is plainly a failure of the design. Using colons for separators when they’re already being used for ports served no purpose but to confuse. Having more than a single valid form of an address again only serves to confuse.
If there’s anything to learn from the UNIX principals it’s there is great power in making things easily manipulated as strings. The design of IPv6 makes this impossible.