Re: Request for detailed documentation of git pack protocol

From: Tony Finch <dot@dotat.at>
Date: Jun 3, 2009, 21:38 UTC
Message-ID: <alpine.LSU.2.00.0906032211350.31588@hermes-2.csi.cam.ac.uk>
In-Reply-To: <200906031851.12160.jnareb@gmail.com>

On Wed, 3 Jun 2009, Jakub Narebski wrote:

Show 7 quoted lines

> On Wed, 3 Jun 2009, Shawn O. Pearce wrote:
> > Jakub Narebski <jnareb@gmail.com> wrote:
> >>
> >> I do wonder if existing Internet Standard (in the meaning of RFC)
> >> protocols also have such kludges and hacks...
> >
> > I'm sure they have some... oddities.  But perhaps not as bad as git.

One small example is the way DNS was extended to support extra flags and response codes (and other features). EDNS is signalled using an OPT pseudo-RR, which is basically the same technique as git's .have refs.

There are a couple of examples in RFC 822 / MIME headers: RFC 2047 (for encoding character set information in subject and address headers) and RFC 2231 (the same job but for attachment filenames etc.). In practice common software uses 2047 syntax for both purposes :-/

Mostly Internet protocols have grown generic extension frameworks fairly early in their lives, so syntactic hacks are rare.

> I wonder if there are some BCP (Best Common Practices) RFC for designing
> protocols (and BCP documents for designing file formats). And which one
> of RFC 2360, RFC 2424,... are applicable here.

As far as I know protocol design is pretty much folklore.

> Magic number (magic sequence) identifying protocol / format plus
> version number.  But it is good that we have capabilities now
> (which is better than version number in this case, IMHO).

Yes, capabilities are a good design pattern.

Tony.

-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.