InetAddresses.toUriString does not return canonical form of IPv6 address

[GoogleCodeExporter]

What steps will reproduce the problem?
1. InetAddresses.toUriString(InetAddresses.forString("feed::3"))

What is the expected output? What do you see instead?
Expected: "[feed::3]"
Instead: "[feed:0:0:0:0:0:0:3]"

What version of the product are you using? On what operating system?
Guava r.08 / Windows XP 32

Please provide any additional information below.
According to the latest http://tools.ietf.org/html/rfc5952 canonical form of 
IPv6 text representation is it's shortest possible form compliant with the 
http://tools.ietf.org/html/rfc4291.

Original issue reported on code.google.com by krzyszto...@gmail.com on 21 Apr 2011 at 10:55

[GoogleCodeExporter]

Why is [feed::3] output expected, per se?  I know it's the short form, but the 
fully expanded form is Java-standard, and not at all wrong.  Doing string 
comparison on IP string literals is not recommended.

Original comment by ek@google.com on 4 May 2011 at 6:18

[GoogleCodeExporter]

Technically Java doesn't implement RFC5952, but upon reflection that, if for no 
other reason, is a good enough reason to have a library that does.  Makes 
sense.  I still don't think it's wise to rely upon any particular string 
representation (at least not until there's a ".toCanonicalString()" method  ;-).

Original comment by ek@google.com on 4 May 2011 at 6:31

[GoogleCodeExporter]

String comparison on IP (especially ipv6) is of course out of the question 
you're right. But the shortest form of an address seems to be the most 
user-friendly one.
I assume java 1.6 does not implement latest RFC recommendation simply because 
of the date it's been released, when every form of a text representation 
compliant with the rfc4291 was just as good.
Although changing this request from defect to enhancement providing 
toCanonicalString() method would be conforming to java 1.5/1.6 and imho even 
more predictable.

Original comment by krzyszto...@gmail.com on 5 May 2011 at 9:44

[GoogleCodeExporter]

Erik, what is the plan on this, or was it already done?

Original comment by kevinb@google.com on 13 Jul 2011 at 7:30

• Added labels: Milestone-Release10

[GoogleCodeExporter]

Original comment by kevinb@google.com on 16 Jul 2011 at 8:27

• Changed state: Accepted

[GoogleCodeExporter]

Paul Marks has an open change that I think will suffice (or will get
there PDQ).  Failing that, there may be an intern who can help with
this, since I'm clearly not getting/making the time required.

Original comment by ek@google.com on 20 Jul 2011 at 11:17

[GoogleCodeExporter]

This should now be fixed. Let me know if the recent change failed to deal with 
the problem.

Original comment by fry@google.com on 27 Jul 2011 at 6:01

• Changed state: Fixed

[GoogleCodeExporter]

I'm not seeing my InetAddresses.toAddrString() change in the public branch yet:

http://code.google.com/p/guava-libraries/source/list

Is there something I need to do to get it there?

Original comment by pma...@google.com on 27 Jul 2011 at 6:10

[GoogleCodeExporter]

Ah, there it is:
http://code.google.com/p/guava-libraries/source/detail?r=561

Original comment by pma...@google.com on 27 Jul 2011 at 7:08

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit