Test that CNetAddr::ToString formats IPv6 addresses with zero compression and canonicalisation as described in RFC 5952 ("A Recommendation for IPv6 Address Text Representation").
Solving #21466 will hopefully be trivial with the ability to check zero compression correctness against these tests.
405 | + {"000:000:000:000:000:000:000:000", "::"}, 406 | + {"00:00:00:00:00:00:00:00", "::"}, 407 | + {"0:0:0:0:0:0:0:0", "::"}, 408 | + {"0:0:0:0:0:0:0:1", "::1"}, 409 | + {"2001:0:0:1:0:0:0:1", "2001:0:0:1::1"}, 410 | + {"2001:0db8:0:0:1:0:0:1", "2001:db8::1:0:0:1"},
2001:0db8:0:0:1:0:0:1 can be represented as 2001:db8::1:0:0:1, but also as 2001:0db8:0:0:1::1.
Are we guaranteed that all getnameinfo() on different platforms will use the variants in this test? I think no.
(similarly in some others below)
RFC 5952 tells us that there is one (and only one) canonical representation of 2001:0db8:0:0:1:0:0:1 which is 2001:db8::1:0:0:1.
Testing CNetAddr::ToString's conformance with RFC 5952 is the entire point of this PR :)
RFC 5952 tells us that there is one (and only one) canonical representation
Where is that text?
I see the following, which seems to be the opposite:
https://tools.ietf.org/html/rfc5952#section-2.2
'The "::" can only appear once in an address.' This gives a choice on where in a single address to compress the zero. 2001:db8::aaaa:0:0:1 2001:db8:0:0:aaaa::1
The text you're quoting is describing the problem: the problem being that there are multiple ways to represent a given IPv6 address (in the absence of canonicalisation rules).
The RFC describes how to solve that problem using canonicalisation :)
See the first paragraph of the RFC: "This document defines a canonical textual representation format."
Note that "canonical textual representation" in this context means one (and only one) way to format a given IPv6 address.
Perhaps reading https://en.wikipedia.org/wiki/IPv6_address#Representation makes the role of canonicalisation in the context IPv6 address formatting more clear? :)
My bad, https://tools.ietf.org/html/rfc5952#section-4.2.3 is pretty clear. Sorry for the noise.
ACK 732c7bddeb9cd4e9fe80ebb7ee98d0f9fcc6a9d3