net: comments preceding IP.String should reflect RFC 5952 conformance status #44485
Comments
ianlancetaylor
changed the title
ianlancetaylor
added
help wanted
NeedsInvestigation
|
Change https://golang.org/cl/337369 mentions this issue: |
|
Change https://golang.org/cl/337290 mentions this issue: |
|
Change https://golang.org/cl/337409 mentions this issue: |
|
I think that it's reasonable to document IP.String as producing RFC 5952-conforming strings. This constrains our ability to change it in the future, but a) it seems unlikely that it would be practical for us to do so, b) it seems unlikely that RFC 5952 will be superseded by a new canonical string representation for IPv6 addresses, and c) the benefit of providing a supported RFC-compliant canonical textual representation outweighs the constraint on future changes to this function. |
dmitshur
added
NeedsFix
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Y
The method in src/net/ip.go
func (ip IP) String()is supposed to conform to RFC 5952 according to this comment:#30264 (comment)
The comment is by @mikioh
But, unfortunately, the source-code comments above src/net/ip.go
func (ip IP) String()donot in any way mention that the IPv6 output is supposed to conform to RFC 5952.
RFC 5952 is "A Recommendation for IPv6 Address Text Representation"
If, indeed, -> src/net/ip.go
func (ip IP) String()should conform to RFC 5952 for IPv6 addresses,could the comments preceding the method be changed?
I would be happy to submit a PR if it is deemed:
func (ip IP) String()does (shall) need to conform to RFC 5952The reason this is valuable, is some developers need to store, and then compare the ASCII representations of
IPv6 addresses.
A developer presented with the issue of needing to compare ASCII representations is then presented with the
issue of how to normalize the ASCII representation, so that systems, such as databases can use a uniform
method of representing the IPv6 addresses. This is important so that addresses which are truly equal are also
recognized when comparing the ASCII representation.
"stuff needs to work correctly, as expected when storing & comparing IPv6 addresses"
The text was updated successfully, but these errors were encountered: