With that clarification of "format", it's obvious that we're always
dealing with a stack of three fundamentally separate things:

* Format (a.k.a. encoding) -- The physical structure.

* Implementation limits -- An implementation often uses a different
internal format than the external format it reads/writes; any place
where the internal format has less range than the external format is an
implementation limit. It is the problem of the implementors and the
users of that implementation; not of the external format.

* Validation -- Extra advisory rules about how to play nice with others
by not putting particular kinds of data into the format even though you can.

So for spec writers:

* Format spec -- defines the byte-level structure, short and sweet.

* Implementation spec -- gives extra limits that arise from mismatches
between internal and external formats; most useful as a survey of all
known implementations, so they can be compared.

* Validation spec -- Once we separate physical format and logical
validation, it's obvious that one can be implemented without the other
(and often is). It's also obvious that any number of competing
validation criteria can be drafted for any given format. Often the real
validation criteria arise implicitly from the set of the actual
implementations that need to interoperate. So validation advice carries
no weight in the format spec and should be cut out. Any validation is
advisory unless some military/space joint has the budget and strict
orders to validate everything that passes by. The rest would do best to
build resilient systems that can behave sensibly in the presence of odd
data.