That's just two systems that happen to agree on garbage.

At that point, what does garbage even mean? There's just functional software and non-functional software.

> Standards documents are not laws; the horse drags the cart.

They can be: c.f. legally-enforced safety-regulations.

These aren't.

Laws are also just some ink on paper (and are routinely overruled, circumvented or unenforced in certain jurisdictions), so using this kind of logic in order to encourage standard violations is unsound.

There is a method to this madness, and that's revising the standards.

What's a "standard violation"? The original history of the IETF is a rejection of exactly this mode of thinking about the inviolability of standards, which was the ethos of the OSI.

Elephant in the room is the trillions of actual servers and user agents that would need to be tested and patched if you retroactively change a standard. Luckily there are some digits after HTTP that allow the concept of new versions of the standard.

When an implementation is noncomformant to a standard in question.

IETF standards are tools to help developers get stuff done on the Internet. They are not the only tool, and they don't carry any moral force.

Apart from colloquially considering standards not-necessarily-normative being, in my opinion, nonsensical (see below), to the best of my knowledge at the very least the STD subseries of IETF standards documents are normative in nature: https://datatracker.ietf.org/doc/std

> They are not the only tool, and they don't carry any moral force.

Indeed there are countless other standards bodies in the world also producing normative definitions for many things, so I'm definitely a bit confused why the focus on IETF specifically.

To be even more exact, I do not know of any standards bodies who would publish what they and the world consider as standards, that would be entirely, or at least primarily, informational rather than normative in nature. Like, do I know the word "standard" incorrectly? What even is a point of a standard, if it doesn't aim to control?

Ok, but just to be clear: the standards-track HTTP RFC says you can use a single LF. I don't think this issue is as clear as people seem to want it to be.

Can you provide a citation for this? I’ve read older RFCs that "recommend" recipients allow single LFs to terminate headers for robustness. I’ve also read newer RFCs that weaken that recommendation and merely say the recipient "MAY" allow single LFs. I’ve never noticed an HTTP RFC say you can send headers without the full CRLF sequence, but maybe I missed something.

https://datatracker.ietf.org/doc/html/rfc2616#section-19.3 https://datatracker.ietf.org/doc/html/rfc9112#section-2.2

Sure. HTTP/1.1 isn't the only network protocol, though, IETF standardization or otherwise.

For SMTP (which this subthread started with):

   In addition, the appearance of "bare" "CR" or "LF" characters in text
   (i.e., either without the other) has a long history of causing
   problems in mail implementations and applications that use the mail
   system as a tool.  SMTP client implementations MUST NOT transmit
   these characters except when they are intended as line terminators
   and then MUST, as indicated above, transmit them only as a <CRLF>
   sequence.

https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.8

none of this is as clear as anyone wants it to be. if standards _could_ be completely formally described, it would be an entirely different world. I did quite a bit of work implementing draft standards in the IETF, and and the end of the day the standard is the best we can make it, but for non-trivial things good luck actually implementing it without something to test against or a reference implementation.

thats the context in which Postel's law make absolute sense. not that you should forgo any sanity checking, or attempt to interpret garbage or make up frame boundaries. but when there is a potential ambiguity, and you can safely tolerate it, then its really helpful for you to do so.

Ah, this is a subthread about HTTP specifically - didn't notice. Explains why you focused on the IETF too. Nevertheless, my points I believe still all stand.

As for HTTP or any other protocols' definitions go, I'd rather not join in on that back and forth. I'd imagine it's well defined what's expected. Skim reading RFC-2616 now certainly suggests so.

I've implemented a lot of protocols. Most implementations I've come across for most protocols not strictly standards conformant, for many reasons.

Big ones being:

* The standards are often not detailed enough, or contain enough loose verbage that there are many ways to understand how to implement some part, yet those ways are not interoperable.

* Many protocols allow vendor specifications in such a way that 2 implementations that are 100% compliant won't interoperate.

* Many protocol implementations are interoperable quite well, converging on behavior that isn't specified in any standard (often to the surprise of people who haven't read the relevant standards)

At least this is my experience for ietf rfc standards.

I'm aware of these factors, wasn't trying to suggest that the practice doesn't differ from the theory. What I was more going for was to highlight that the goal should be to primarily try and have these eventually converge, preferably sooner than later, not trying to strongarm the practice side and wait for the standards body in question to wake up one day and decide to amend the standard. That might give the impression of suddenness, but the core issue remains unsolved that way.

Usually when there's a high disparity between the "de jure" and the "de facto", it's due to a discrepancy in the interests and the leverage, resulting in a breakdown in communication and cooperation. Laying into either then is a bandaid attempt, not a solution. It's how either standard sprawl starts, or how standards bodies lose relevance.

This is, by the way, exactly the stance the Microsoft used to have in the 90-s and 00-s on the standards (it probably still has). And MS caught a lot of flak for that, for a very good reason.