[perching_aix]

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?

[tptacek]

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.

[vitus]

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

[halter73]

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

[perching_aix]

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.

[convolvatron]

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.