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/db-wg@ripe.net/
Modifications to the inet6num in the RIPE Database
- Previous message (by thread): Modifications to the inet6num in the RIPE Database
- Next message (by thread): Modifications to the inet6num in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Bruce Campbell
bc at apnic.net
Thu Mar 18 00:58:12 CET 1999
On Wed, 17 Mar 1999, Engin Gunduz wrote: > Personally, I would like to see 2030:0:5::/48 instead of > 2030:0:5:0:0:0:0:0/48 as the result of the query in the > whois database, since shorthand notation is, IMHO, more > "readable" by human eye. However, maybe we can introduce > yet another option to the whois server and client to show > the query result on inet6num objects without shorthand > notation? I'm not sure that adding yet-another-option is a good idea for general queries, although it would be for setting up various 'interesting' end-user parsing routines. Can I suggest instead that the database returns a '% Comment' line before the object, which most end-user parsing routines should be ignoring (except for '% No objects found'), in the form: '% IPv6 found: short is xx:xx::/xx, long is xx:xx:0:0:0:0:0/xx' which would make a) casual queries of IPv6 objects easy to read and b) educate said casual queriers about short and long versions of IPv6 numerics. Anything which the database 'officially' returns should be in its expanded form (same as IPv4 objects). > Well, restricting the usage of shorthand notation could > ease the implementation of the whois server. But, IMHO, > in the user side, it is better to allow it. Make shorthand notation on the input side a warning condition when the notification/object is returned to the user (eg: WARNING, expanded xx:xx::/xx to xx:xx:0:0:0:0/xx etc), so that the database works in fully qualified IPv6 numbers (FQIPv6N?), but understands both. Regards, -- Bruce Campbell <bruce.campbell at apnic.net> +61-7-3367-0490 Systems Administrator (#2) Just dis guy Asia Pacific Network Information Centre
- Previous message (by thread): Modifications to the inet6num in the RIPE Database
- Next message (by thread): Modifications to the inet6num in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]