BIND allows an empty 'cm' value for optional LOC RDATA fields

From Support ticket https://support.isc.org/Ticket/Display.html?id=16882

Customer says:

(Checked the behavior with some recent version on the public git repo, but I believe it's the same 
for all versions that support LOC).

I've just noticed somewhat awkward behavior of BIND about parsing textual LOC RDATA: it accepts an
empty 'cm' part after a 'dot' of the SIZE or HORIZ/VERT PRE field.  For example, it accepts the
following textual RDATA as part of a zone file:

22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m 1.
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m 1.m

in this case, the VERT PRE field is specified that way (and is interpreted as "1m").

Is this intentional?  The syntax format described in RFC1876 is not very formal, so it could be
left to the implementor's discretion.  But it looks quite awkward to me at least, and I wonder whether
this was not really intentional.  In that case, you may want to tighten the validation.

I'm reporting this just because I've noticed it.  I'm fine if you decided to keep it as is.

Then follows up with:

(Essentially the same issue but) maybe this looks even more awkward.  BIND accepts these
fields just containing a dot (with or without the 'm' suffix):

22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m .
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m .m

and interprets it as "0.00m" (<1cm).

And:

and one more...it even accepts just with an 'm' (interpreting it as 0.00m):
22 21 54.000 N 71 6 18.000 W -24.00m 30m 0100m m