Larry,
The tool could convert from "x.y" when processing for submission, so you wouldn't have to deal with 2 different formats.
Yes, it could. I'm not sure if it will though. There is a canonical representation for printing these numbers and as a developper I'd use that. If somebody wants another format internally because that is easier, I expect him to do that in his tool. For the same reason, I allow people to enter an IPv4 adress as 193.0.1.49, I don't expect them to do the artimethic to convert it to 3238002993 even if in my code, I use unsigned int's.
An AS has been a 16 bit number forever (in terms of the lifetime of the Internet) and authors have implicitly used that when writing their tools. That means: regular int's (or even short unsigned ints) in the code, checks on input that numbers entered are below 65536 and/or 5 digits, arrays dimensioned to 65536, etc. All this code will have to be checked and updated. I would definitely not feel comfortable using code with numbers outside the range of the original spec.
The original spec doesn't specify a range. Some code will have problems with numbers greater than 16-bit, others won't. Certainly fewer implementations will have issues with 32-bit numbers than "x.y" notation.
The AS spec does. Then, nothing prevents you to convert "x.y" into an unsigned int in your code and use that internally. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.