On Thu, 2006-05-25 at 11:40 -0700, Doug Barton wrote:
Jeroen Massar wrote:
On Thu, 2006-05-25 at 10:43 -0700, Doug Barton wrote:
Marcos Sanz/Denic wrote: [..] And thus when I submit "whois -h whois.ripe.net 2001:0db8:1234/64" it would return an inet6num with (the /48 exists, the /64 doesn't) :
2001:db8:1234::/48
Is that what you meant?
No. I was referring specifically to the case at hand, IPv6 addresses used as glue records. In my opinion, having the addresses always be canonicalized to the full form (not the compressed form) is easier to deal with on a number of levels, including db design, and inclusion in the DNS being the most important.
Compressed/uncompressed is a representation method, the parser which reads/exports into/from the database should not give anything about the external representation and can represent it differently internally. If you would argue for uncompressed being easier to parse by a program, then one should maybe better propose to store it completely in binary, hashtrees etc come to mind ;) Programs should use the OS provided, getaddrinfo() and inet_ntop() functions, these afaik on all platforms support any input format and print out usually compressed formats. In case most of the bits of an IPv6 address are used then there is no difference in compressed/uncompressed form, thus there is not much of an argument there for me. In DNS they are represented as 128-bit binary values, thus there is nothing to pick for representation. The tool that reads/writes should do it in a standard way, but there is no way of changing all tools and I've already soon too much that tools do it their own way, not using the OS provided interface or capsing the string etc. In the end for tool writers, as said before, be liberal in what you get -> rewrite the input to what you require. One thing there though, if you query the RIPE database, which I tend to do a lot, inet6num's are always different, even when created by the NCC, the format is sort of the same, but the contents are wildly variating, sometimes in compressed format, otherwise not, sometimes caps, sometimes not. It would be great to have a single format coming out of whois, if that would only help hurt the eyes a bit. Personally though I prefer the compressed form, as that is how I have been representing a lot of IPv6 addresses for a long time now. But as said that is a personal opinion of taste. Thus my 'vote': represent with compressed lowercase. But I could live with uncompressed too, as long as it would be done then also everywhere in a consistent fashion. Most inet6nums are compressed fortunately ;) Greets, Jeroen