The format is so simple that it's easy to notice where we'd drive off
into the weeds by trying to be stricter:
Tl;dr: standards are not specs, and for reasons.
I think your discussion misunderstands what a standard is, and it's not what people often think. A standard, as distinct from a spec, is a contract for arms-length communication between mutually suspicious parties of roughly equal market power that spells out what each party can and cannot rely on. Let me say that again, parsed, because every phrase matters.
((A standard) ; whether international, national, local, or private
(as distinct from a spec) ; which is what most people are used to writing and reading
(is a contract) ; sometimes enforced by law
(for arms-length communication) ; in principle, everything should work without the parties having to adjust things
(between mutually suspicious parties) ; like business competitors or their employees
(of roughly equal market power) ; see below
( that spells out what each party ((can) and (cannot) rely on.)) ; explicit is better than implicit, and negative rules matter
When you are talking to your friends or your future self, you don't need a standard. If there is one and it's convenient, you can use it; if not, not.
When you are talking with a monopolist (universal seller) or monopsonist (universal buyer), you may want a standard but you probably won't get one, or only a dumbed-down one that has to be heavily supplemented, or one that's so complicated you can't implement it (or downright secret) and have to rely on your counter-party to implement both ends. That's why Linux and BSD make sure they conform to Posix and Windows doesn't even try, because at the time the Windows API was being developed, Microsoft owned the non-server OS market, and the server market was hopelessly fragmented. It's also why Visual C only supports C89 and some C99 (just recently), and why C# exists at all. (Microsoft today are much nicer players; I'm not knocking them.)
For example, there's a standard for the physical size and layout of credit and debit cards, SO/IEC 7810 ID-1. A bank or other entity that ignores this standard will find that its customers are deserting it, because it can't be used in ATMs or point-of-sale terminals. The response to a bank that says "We want thicker credit cards" is "Fine, then we won't do business with you." The same would happen to an ATM manufacturer whose machines could only accept thinner cards.
So yes, people can violate the constraints of a standard, as in your examples below, but they should be prepared to face a blank wall that they can try to argue with. Indeed, Postel's Law ("Be liberal in what you accept, conservative in what you send") when correctly interpreted says that malformed input *should* be rejected. The law is about not *crashing* when you receive bad input, not about accepting invalid packets or incorrectly encoded strings or whatever. See <
https://tools.ietf.org/html/rfc1122#section-1.2.2> for a more specific explanation. Indeed, the whole of 1.2 is very informative.
* Varints don't specify a maximum value. It's easy to see that people
could just violate that requirement.
* We don't specify that sections or entries have to be in order,
because obviously the format lets people write them in a different
order.
* We don't specify what to do about duplicate section or entry names,
since the format clearly lets people write duplicates and interpret
them how they like.
* The most suspect part of the above spec is the part where it says
strings are UTF-8. This is useful, but it's only a matter of time
before someone finds it convenient to use .BINI with some other
character encoding.
* We don't specify anything about invalid characters and what to do
when reading them, since clearly the format lets people write
invalid characters and read them how they wish.
(The .sig below was chosen at random by /dev/random from a very big list.)
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.org'Tis the Linux rebellion / Let coders take their place,
The Linux-nationale / Shall Microsoft outpace,
We can write better programs / Our CPUs won't stall,
So raise the penguin banner of / The Linux-nationale. --Greg Baker