So libuv is a modern library that lives in the modern world, and as such, IPv6 support is a real thing we could have.
But once we have it that means usermode code will be seeing IPv6 addresses. What are we going to do about it?
Seeing if Red has Any Ideas... no
Red's issue database they don't say anything about it, but of URL! parsing they say:
"Host is not detailed per the RFC yet. It covers IPv6 addresses, which go in square brackets, making them a non-loadable URL in Red. They can also contain colons, which makes finding the port marker more involved. The percent encoded options for brackets here are a bit of a hack as well, because Red encodes them in URLs, even in the IP literal segment.|
; simplified from [IPv6address | IPvFuture]|
IP-literal: [copy =IP-literal [[#[ | %5B] thru [#] | %5D]]]
What they're talking about is that in the internet spec, these IPv6 addresses:
would embed into URL!s like:
The brackets don't seem like any particular problem for Ren-C, because we don't intend to load
http://[a b c] as two separate items of a URL! and a BLOCK!, e.g.
http:// [a b c].
(But we do have the question of what to do about
[... http://]. I think that the idea of letting URLs do paired parentheses and paired blocks in them probably would work for most cases people would care about.)
Could we just use a BINARY!?
It might seem like we could just punt on it and use a BINARY!...saying the address is a black box. It sound like it will work, but earl writes the following in the issue I cite in the post above:
As mentioned in my first comment above, IPv6 literal syntax is in latent conflict with url! and get-word! literal syntax: a::b is a valid IPv6 address, but is currently a valid url!; ::a is a valid IPv6 address, but currently a valid get-word!. Maybe there are other conflicts as well.
Also note, that IPv6 addresses may need to be qualified with a "zone index" to be routeable. The suggested notations for a zone index is to append it to the address separated with a %. The syntax for a valid zone index itself is OS-specific. Examples: fe80::1%1, fe80::1%wlan0. (Obviously, this notation conflicts with percent encoding in url!s.) You'll have to store the zone index along with the address. For some usage scenarios you can get by with storing the zone index pre-decoded into a 32-bit integer; for other scenarios, you may have to keep the original, literal zone index specification around.
So that "zone index" is a thorn, suggesting some part of IPv6 addressing might have to be passed around as a string...
I don't know, but if anyone feels like reading up on IPv6 and thinking about it please do so. I was actually going to make a new post to bring it up, but searched and found I'd already brought it up.
Guess the point being we're now past the theory and into the practice of IPv6. So it's a more pressing issue.