Modifications to the inet6num in the RIPE Database

Hi Wilfried,
I am not yet too comfortable with writing IPv6 addresses myself.
There is a standard which also has a couple of notes on how to avoid confusion that can arise from the :: thingy meaning all zeros up to the next part.
However, I always have trouble with this and have to look it up so I will not try to explain it here (I am currently not at the office, so no book). We have adapted the syntax checks to take into account the different way of writing IPv6 addresses since the inet6num was introduced.
May be Engin can elaborate on the cases, particularly when there can be ambiguity.
None of the introduced changes constrain the standard but rather adapt to it.

Regards,
Joao

 "Wilfried Woeber, UniVie/ACOnet" <woeber at cc.univie.ac.at> writes:
 *   Hi David, Joao, et.al.
 *   
 * <disclaimer>
 * 
 * 	My question is going to prove complete ignorance when it 
 * 	comes to IPv6 address formats. So please bear with me :-)
 * 
 * </disclaimer>
 * 
 * => The two suggested changes are:
 * => 
 * => - - addition of a "status" attribute with the following possible values:
 * =>   TLA, NLA and SLA.
 * =>   Syntax checks will be done so that:
 * =>   TLA is only allowed if the prefix length is 3<x<=16
 * =>   NLA is only allowed if the prefix length is 16<x<=48
 * =>   SLA is only allowed if the prefix length is 48<x<=64
 * =
 * =This is fine although, I am not entirely convinced that we really need
 * =it. It's a bit redundant information. By definition something is a
 * =TLA/NLA/SLA so you can just look at the 'inet6num:' field and you
 * =already know what it is. Can't you just generate this field
 * =automatically ?!?
 * 
 *   For the IPv4 case we do have a well-established format for external
 *   representation of addresses and prefixes, i.e. full dotted quad with
 *   /prefix-length.
 *   
 *   In the 6bone registry there's IPv6 prefixes with a "structured" external
 *   representation, like "3FFE::/16" or "5FBC:1000::/32".
 *   
 *   So my questioon is: is there an agreed algorithm to insert punctuation
 *   at the "appropriate" positions, and does the proposal/criticism for the
 *   semantic checks do have an influence on this formatting?
 *   
 *   Thanks,
 *   Wilfried.
 *  --------------------------------------------------------------------------
 *   Wilfried Woeber                :  e-mail: Woeber at CC.UniVie.ac.at
 *   Computer Center - ACOnet       :  Tel: +43 1 4277 - 140 33
 *   Vienna University              :  Fax: +43 1 4277 - 9 140
 *   Universitaetsstrasse 7         :  RIPE-DB (&NIC) Handle: WW144
 *   A-1010 Vienna, Austria, Europe :  PGP public key ID 0xF0ACB369
 *  --------------------------------------------------------------------------
 *