No, to záleží. Někdy bývá formát definován tak, že existuje jakási šedá zóna, co by konzument měl nějak zpracovat, ale producent by to podle specifikace dělat neměl. Důvodem může být třeba kompatibilita s další verzí.
Například některé volitelné sekce budou podle specifikace první verze rezervovány pro budoucí použití. Dekodér je bude muset podle specifikace ignorovat (protože je nezná), ale to neznamená, že enkodér tam může dát cokoli. Když tam hodí něco neuváženého, může to způsobit problémy s dekodérem novější verze.
Někdy ty šedé zóny mohou být celkem intuitivní, někdy nemusejí.
Pár příkladů, co mě z hlavy napadají:
U formátů mě napadá třeba HTML5, kde – co si vzpomínám – je definováno, jak se má parser stavět k nevalidním dokumentům.
U x509 certifikátů je prostor pro nějaké extensions. Čistě podle logiky „výstup uděláme tak, aby ho současný standard-compliant parser zpracoval“, by bylo OK vymyslet si vlastní extension, a označit ho jako non-critical (pak musí být podle standardu ignorován, pokud ho aplikace nezná). Jenže jeho identifikátor může kolidovat se standardizovaným extension, který vznikne časem, a najednou podle nového standardu má takový certifikát být odmítnut, protože obsahuje nějaké blbosti.
Pokud netrváme jen na formátech, ale mohu uvést i příklad u protokolů, pak mě napadají různé reserved ranges u IP adres. Tyto rozsahy nemají být přidělovány. Nevím o tom, že by standard zakazoval těmto IP adresám odpovídat nebo na ně posílat jiné pakety, ostatně by to jen omezovalo interoperabilitu mezi starším a případným novějším standardem. Pak ale z toho, jak mám na co reagovat, nemusí být ani zřejmé, že některé IP adresy nemám přidělovat.
Nevím, jestli u tohoto standardu je reálné riziko šedé zóny, která by nebyla zřejmá. Vím ale, že je to někdy problematické.