On Thu, 4 Jun 2009, Jakub Narebski wrote: > > But I do not know what are, or what should be protocol requirements. > Should SHA-1 use lowercase, or be case insensitive? Should commands such > as "have", "want", "done" use lower case or be case insensitive? Should > status indicators "ACK" and "NAK" be upper case, or should be case > insensitive? Should capabilities be case sensitive, and should they be > compared case sensitive or not? I think the current (rough) consensus is that case insensitivity causes pain unless its scope is carefully controlled. I18n causes a lot of the difficulties. One way in which you can control the scope is by limiting case-insensitivity to protocol elements that must be ASCII (commands, replies, SHA-1 hashes). But I'm not sure there's any benefit to making the protocol case insensitive, especially when it isn't possible to type it manually. I've already given one example of interoperability problems in SMTP arising from case insensitivity. In the opposite direction, Unix and XML are good examples of case sensitivity working well in practice. I have to say I spend all my time working with old-school case insensitive protocols, and they have clearly been extremely successful, so it's tempting to copy them. But I think that will lead to ugliness - have a look through the HTTP spec for its mish-mash of sensitive and insensitive protocol elements. In the specific instance of the pkt-length, if all current implementations write the length in lower case, you can say in the spec it MUST be lower case. If you do that then the same requirement can apply to both the client and the server which makes the spec shorter and simpler. Postel's robustness principle suggests that it doesn't really matter if the parser treats it case-insensitively. Tony. -- f.anthony.n.finch <dot@xxxxxxxx> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html