"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > If its SHA-1 you are talking about, I wanted this to be a MUST > use lowercase, but people screamed about it (Jakub and Ilari > IIRC). The current C code accepts uppercase due to its use of > get_sha1_hex(), and they wanted to follow the "be liberal in what > you accept" suggestion from other IETF authors. > > IIRC, all implementations use lowercase. We should be able to safely > say MUST produce lowercase, and MUST accept lowercase, and SHOULD > NOT accept uppercase,... I do not see a point in loosening or tightening the definition document that is written to describe a protocol of a reference implementation after the fact. It is not like producing lowercase hexdegits is a lot more work on some weird platforms. Everybody writes in lowercase, expects to see lowercase, and some may accept uppercase by accident. I think it is acceptable to describe that as "MUST produce, MUST accept lc and MAY accept uc", but I do not think it is even necessary to specifically say "and MAY accept uc". It is actively wrong to say "SHOULD NOT accept uc"---it won't help anybody. -- 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