This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute
- Previous message (by thread): [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute
- Next message (by thread): [db-wg] Maintenance announcement
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Doug Barton
dougb at dougbarton.us
Fri May 26 00:46:48 CEST 2006
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
- Previous message (by thread): [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute
- Next message (by thread): [db-wg] Maintenance announcement
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]