Re: [PATCH] Update packfile transfer protocol documentation
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 2, 2009, 17:31 UTC
- Message-ID
- <7vhbtcvnoo.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20091102154104.GR10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 9 quoted lines
> 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.