Is your feature request related to a problem? Please describe.
The message attribute VFrameFormat alone is under-specified, and always paired with the CANFD_BRS message attribute which is parsed additionally for messages of frame format StandardFD and ExtendedFD.

The difference between the StandardCAN and the StandardFD format is only whether the frame may make use of CAN FD extensions at all. Those extensions are:

• Extended data length codes
• The BRS bit in the CAN FD header is no longer "reserved" - this detail is quite important because setting this reserved bit in a frame of format StandardCAN will trigger an error frame in a compliant receiver.

In the opposite direction, StandardFD as frame format alone does not declare the value of the BRS bit.

Describe the solution you'd like
Correctly describe the CANFD_BRS message attribute in the list of "standard" message attributes, and its conditional relationship to the frame formats its applicable to.

It's typically defined as:

BA_DEF_ BO_  "CANFD_BRS" ENUM  "0","1";
BA_DEF_DEF "CANFD_BRS" "0";

The default varies between DBC that has been migrated from non-FD to FD ("0") and native FD networks ("1").

Describe alternatives you've considered
Well, you can't correctly communicate in an FD enabled networks if you don't understand the CANFD_BRS message attribute. Blindly enabling BRS just because a frame is using FD extensions just makes you a babbling idiot.

Additional context
Add any other context or screenshots about the feature request here.