zero suppression vs compression in addresses

[Ted Mittelstaedt]

> -----Original Message-----
> From: ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+tedm=ipinc.net at lists.cluenet.de] On 
> Behalf Of Gert Doering
> Sent: Sunday, May 17, 2009 8:31 AM
> To: michael.dillon at bt.com
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: zero suppression vs compression in addresses
> 
> Hi,
> 
> On Sun, May 17, 2009 at 03:45:09PM +0100, michael.dillon at bt.com wrote:
> > The point is that the text representation of IPv6 addresses 
> might be 
> > about to change, so if you are writing code to read IPv6 
> text format 
> > addresses, you probably want to accept the format defined in this 
> > draft. Unless of course, there is some fundamental flaw in 
> which case 
> > you might want to communicate that to the author of the draft.
> 
> The whole point of this draw is the *output* format of an 
> IPv6 address (and it's using fairly weak language, like 
> "should" instead of "SHOULD", at that).
> 
> Input parsers need to understand every possible 
> representation, as long as it's syntactically correct. 

Only for automated or script-fed input, if it's a webform your
presenting to a user to input the IP address, you can always
stick with making the user enter the "long-form" of the address,
IMHO.

HaCi for example accepts the shortened IPv6 then expands it and
displays it as long-form when it's displaying the tree.  I can
see lots of potential for trouble if the RFC changes the logic and
people are copying and pasting addresses from configs to the HaCi input
form from a device using different parser rules to display addresses
in a shortened form.

Ted