4 ms·

Yeah but like...why bother? Use the more obvious term always & there's no need for ambiguity. If you're saying "these things mean the same thing" in a formal co

Yeah but like...why bother? Use the more obvious term always & there's no need for ambiguity. If you're saying "these things mean the same thing" in a formal context then there should be a REALLY good reason why you need both of them to exist, period. Otherwise remove one and simplify what people need to know.

uxp8u61q 3y ago
I get the feeling that many RFCs are written by programmers who want to cosplay as lawyers. There's no reason for a technical spec to be written like a legal contract with archaic formulations. There's also no reason for legal contracts or laws to be written with archaic formulations, but common law countries have a fetish for this kind of thing.
- PhilipRoman 3y ago
  For understanding what the protocol is meant to do - I agree. But in my experience when actually implementing standards spanning thousands of pages, the strict language has been a lifesaver.
- reichstein 3y ago
  There is every reason for a technical specification to be unambiguous. That's it's one job. Behavior must be clearly within spec or not, otherwise it hurts interoperability. Implementations should support the entire spec, and not produce something outside of spec, then every implementation can interact with every other implementation. If the implementers can't agree what's within spec and what's not, it's a bug in the spec. Law has a similar requirement, only slightly looser because it has a fallback of getting a human judge to decide in case of disagreement. Still, ambiguity in a law is a bug. In both cases, you do use natural language, which can rely on context, so the real test is, or should be, whether a "reasonable person" would choose a different interpretation, not whether one is technically possible.
- bumby 3y ago
  Just to piggyback on the good comments already mentioned, there is often a need for a "technical spec to be written like a legal contract" because legal contracts often reference technical specs. Anyone who's worked a contract that has ambiguous technical specs knows it often becomes fodder for rules-lawyering. One example from my past was a contract that levied specific requirements for equipment operated autonomously with software, but "autonomous" wasn't explicitly defined. A contractor who didn't want to spend the money to meet the extra requirements argued the system couldn't be considered autonomous because it required a human to turn it on (despite being fully autonomous after that point).

uxp8u61q 3y ago

I get the feeling that many RFCs are written by programmers who want to cosplay as lawyers. There's no reason for a technical spec to be written like a legal contract with archaic formulations. There's also no reason for legal contracts or laws to be written with archaic formulations, but common law countries have a fetish for this kind of thing.

PhilipRoman 3y ago
For understanding what the protocol is meant to do - I agree. But in my experience when actually implementing standards spanning thousands of pages, the strict language has been a lifesaver.
reichstein 3y ago
There is every reason for a technical specification to be unambiguous. That's it's one job. Behavior must be clearly within spec or not, otherwise it hurts interoperability. Implementations should support the entire spec, and not produce something outside of spec, then every implementation can interact with every other implementation. If the implementers can't agree what's within spec and what's not, it's a bug in the spec. Law has a similar requirement, only slightly looser because it has a fallback of getting a human judge to decide in case of disagreement. Still, ambiguity in a law is a bug. In both cases, you do use natural language, which can rely on context, so the real test is, or should be, whether a "reasonable person" would choose a different interpretation, not whether one is technically possible.
bumby 3y ago
Just to piggyback on the good comments already mentioned, there is often a need for a "technical spec to be written like a legal contract" because legal contracts often reference technical specs. Anyone who's worked a contract that has ambiguous technical specs knows it often becomes fodder for rules-lawyering. One example from my past was a contract that levied specific requirements for equipment operated autonomously with software, but "autonomous" wasn't explicitly defined. A contractor who didn't want to spend the money to meet the extra requirements argued the system couldn't be considered autonomous because it required a human to turn it on (despite being fully autonomous after that point).