Hi Ronald
It says in the documentation that you cannot split the primary key
attribute value over multiple lines. To make sure that is still the
case, I just tried to create this object in the test database:
INETNUM: 10.0.0.0
-
10.0.0.255
NETNAME: fred
descr: whatever
COUNTRY: NL
ADMIN-C: dw-test
TECH-C: dw-test
abuse-c: [email protected]
STATUS: Assigned Pa
MNT-BY: AARDVARK-MNT
SOURCE: TEST
this is the response I got back:
Create FAILED: [inetnum] 10.0.0.0 - 10.0.0.255
inetnum: 10.0.0.0 - 10.0.0.255
***Info: Continuation lines are not allowed here and have been removed
netname: fred
descr: whatever
country: NL
admin-c: dw-test
tech-c: dw-test
abuse-c: [email protected]
***Error: Syntax error in [email protected]
status: ASSIGNED PA
***Info: Value Assigned Pa converted to ASSIGNED PA
mnt-by: AARDVARK-MNT
source: TEST
The important bit is that first info message:
***Info: Continuation lines are not allowed here and have been removed
Exactly as it says in the documentation, the pkey split lines have
been merged back into a single line separated by single spaces and
without causing an error.
cheers
denis
co-chair DB-WG
On Tue, 8 Jun 2021 at 23:45, Ronald F. Guilmette via db-wg
<[email protected]> wrote:
>
> In message <[email protected]>,
> Piotr Strzyzewski <[email protected]> wrote:
>
> >On Mon, Jun 07, 2021 at 04:48:38PM -0700, Ronald F. Guilmette via db-wg
> >wrote:
> >> inetnum: A1.B1.C1.D1 -
> >> A2.B2.C2.D2
> >>
> >> My parser wasn't expecting THAT!
> >
> >That says a lot about the parser, as this is well described in
> >documentation:
>
> Although it may have escaped your attention, as a general matter, reality
> frequently diverges from documentation.
>
> In any case, it is easily possible to parse WHOIS records sufficiently well
> to do a multitude of useful things without consulting any documentation
> of the format. It can be done just by eyeballing what is fundamentally
> a rather simple syntax.
>
> Furthermore, as I noted, there are literally hundreds of thousands of
> objects in the APNIC data base. Of these only a single one had an
> inetnum: field that was splattered, needlessly, and for no apparently
> good reason, across multiple lines.
>
> (I hope to soon find out whether such pointless oddities are present
> also in the RIPE data base.)
>
>
> Regards,
> rfg
>
