That's not something to get hung up on: what matters is the semantics, not whether or not each bit is defined.
Here's a good example, in 3.2:
> Also note that when an MPI is encrypted, the length refers to the
plaintext MPI. It may be ill-formed in its ciphertext.
What does this mean? Is the MPI encrypted separately (how?), or something else? Why would you even mention it being "ill-formed" in its ciphertext (it has to be, unless something has gone very wrong), much less use a wiggle phrase like "may"?
If you dig further through the spec, you find under 5.5.3 that MPIs can be "secret" MPIs, which are apparently encrypted with a passphrase that gets munged through a KDF defined by an S2K identifier. But this is inexplicable under the "secret packet" part of the spec, not the MPI part. And it does nothing to address the second ambiguity.
Here's a place (5.2.3.1) where the spec is unambiguous, but forces clients to be ambiguous:
> If a subpacket is encountered that is
marked critical but is unknown to the evaluating software, the
evaluator SHOULD consider the signature to be in error.
This is the exact opposite of what ecosystems like X.509 do; it's a pointless source (perfectly well-specified!) variance on the client side.
Here's a good example, in 3.2:
> Also note that when an MPI is encrypted, the length refers to the plaintext MPI. It may be ill-formed in its ciphertext.
What does this mean? Is the MPI encrypted separately (how?), or something else? Why would you even mention it being "ill-formed" in its ciphertext (it has to be, unless something has gone very wrong), much less use a wiggle phrase like "may"?
If you dig further through the spec, you find under 5.5.3 that MPIs can be "secret" MPIs, which are apparently encrypted with a passphrase that gets munged through a KDF defined by an S2K identifier. But this is inexplicable under the "secret packet" part of the spec, not the MPI part. And it does nothing to address the second ambiguity.
Here's a place (5.2.3.1) where the spec is unambiguous, but forces clients to be ambiguous:
> If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error.
This is the exact opposite of what ecosystems like X.509 do; it's a pointless source (perfectly well-specified!) variance on the client side.