This takes me back to the early days of TCP, when I used to do this. I had a TCP implementation with a "bit bucket"; every packet that was either rejected or didn't advance the connection (such as a duplicate) was logged. Then I'd send out emails to other developers; "Your packet sent at T did not conform to spec, per para..." Gradually, things got better.
The "urgent" option could be deprecated. The original purpose was for when a TELNET connection was sending data to a slow printing terminal such as a Teletype, and you wanted to cancel the output. The TCP connection was being held back by flow control waiting for the printer on output, and might be held back on input if you'd typed ahead but the server wouldn't take another line until the output was done.
The user would push BREAK, the TCP connection would send an urgent message, bypassing any queued data, and the server would get this, stop sending, and clear its output queue.
Almost nobody has needed that feature in this century. But there's probably someone, somewhere, with some ancient embedded device like a cash register printer, using it.
Mark Pilgrim once had a hilarious blog post in which he argued that all software developers were either assholes are psychopaths. He also argued that some people believed in angels, who followed the specs for the best of reasons, but who were actually mythical. Your """"Your packet sent at T did not conform to spec, per para..." Gradually, things got better""" would make you an angel, as you did it for the right reasons, though I imagine some of the people you wrote gave you a different classification.
Sadly, Mark Pilgrim committed info-suicide and erased everything he'd written from the Web. (Off topic: it is sad how much disappears from the Web, and how many weblogs shut down. Some of the best essays I've ever read were on weblogs, now gone. I just revived a weblog I had run in 2005, and checking the links I found that the linkrot was running in the area of 50% to 60%.)
I was at an aerospace company. In aerospace, specs matter, because part A has to plug into part B. You can remove the Pratt and Whitney engines from an airliner and substitute Rolls-Royce engines. One is not emulating the other; they both meet the same spec. DoD used to be big on having multiple sources, all making interchangeable units to the same spec.
We used to say, "if A won't work with B, check the spec. If A doesn't match the spec, A is broken. If B doesn't match the spec, B is broken. If you can't tell, the spec is broken.
Much of this worked in the early TCP/IP days because DoD was funding most of the players, both industrial and academic. They wanted interoperabilty.
There's much less of that today. Compatibility tends to involve reverse engineering the dominant player's product.
On the latter topic, one of my favorite ever weblogs was that of Nat Friedman, now CEO of GitHub. Excluded from the Wayback Machine and gone forever (unless he kept a personal archive, I guess), but a lot of the stuff in the 2000-2010 era covered some very interesting technologies he was involved with building.
The "urgent" option could be deprecated. The original purpose was for when a TELNET connection was sending data to a slow printing terminal such as a Teletype, and you wanted to cancel the output. The TCP connection was being held back by flow control waiting for the printer on output, and might be held back on input if you'd typed ahead but the server wouldn't take another line until the output was done. The user would push BREAK, the TCP connection would send an urgent message, bypassing any queued data, and the server would get this, stop sending, and clear its output queue.
Almost nobody has needed that feature in this century. But there's probably someone, somewhere, with some ancient embedded device like a cash register printer, using it.