Mark Smith writes: > Are you aware of the reason why certain words are capitalised in RFCs ? Yes. I don't see the relevance of that here. > Implementations can be measured against the capitalised words in RFCs. But there are many many ambiguous directives in RFCs, both with and without uppercased terms. For example: "If a host has received an ECN-setup SYN packet, then it MAY send an ECN-setup SYN-ACK packet. Otherwise, it MUST NOT send an ECN-setup SYN-ACK packet." What does "otherwise" mean here? What this appears to say is that a host may AND must not send the packet, because the meaning of "otherwise" is ambiguous. It should have been written this way: "If a host has received an ECN-setup SYN packet, then it MAY send an ECN-setup SYN-ACK packet. If a host has not received an ECN-setup SYN packet, then it MUST NOT send an ECN-setup SYN-ACK packet." Because of the ambiguity in the original text, multiple interpretations are possible, some more robust and compatible than others. The repetition in the second example may irritate some people, but it removes ambiguity. While the inattentive or unreflective reader may incorrectly assert that ambiguity is absent from the first example, implementors may reach contradictory conclusions about the meaning and create conflicting implementations while all of them claim that their own respective implementations are correct. And because of the way the text is written, there is no way to determine who did it correctly, and who did not. While I'm at it (in RFC 3168), here's another example of oddness: "There exists at least one faulty TCP implementation in which TCP receivers set the Reserved field of the TCP header in ACK packets (and hence the SYN-ACK) simply to reflect the Reserved field of the TCP header in the received data packet." If reserved is not synonymous with must-be-zero, then why is reflection of the reserved field "faulty"? And if reserved _is_ synonymous with must-be-zero, then why are transports that send RST whenever they see non-zero reserved bits "faulty"? In the former case, the state of the bits doesn't matter, so reflecting them shouldn't cause a problem. In the latter case, non-zero values in the bits are not allowed, so treating this as an indication of an error is entirely logical. > As friendly piece of advice, the more you argue these points, the > more you are showing what you don't know, and are embarressing > yourself. As long as you depend on personal attacks to support your position, while I depend on facts and reasoning to support mine, I'm not worried about embarrassing myself or seeming ignorant. See above.