Jeroen Massar wrote:
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.
Assuming all elements of your argument above are correct, I believe that this supports my suggestion. If you can deal with the addresses programatically regardless of the storage method, this is an argument (in my mind/experience) for storing them in a consistent, lowest common denominator format (read, human-parsable), such as the full, uncompressed form.
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.
Yes, this is exactly the kind of problem I'd like to see avoided, given that this part of the db must be rewritten anyway.
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.
On that we are in complete agreement. Regards, Doug -- If you're never wrong, you're not trying hard enough